When Job Boundaries Dissolve: What Engineers Need in the AI Era

AI is making it easier to write code. But that does not necessarily make software engineering simpler.

As implementation becomes faster and more accessible, engineers face a different set of questions: What should we build? Which problems are worth solving? How much of an AI-generated system must humans still understand? And when professional boundaries begin to dissolve, what capabilities remain distinctly valuable?

These questions shaped Loglass AI TALK vol.8, held on 7 September 2026 under the theme “A Night to Redefine Software Engineering in the AI Era.” Organised by Loglass in a hybrid format, the event brought together experienced software leaders to discuss what changes—and what does not—when AI can perform an increasing share of implementation work.

The most important message was not that engineers must compete with AI. It was that they must expand the area in which they can create value.

Redefining engineering does not mean abandoning its foundations

The event featured a panel with Takuto Wada, President and Representative Director, Towers Quest, Inc., Daichi Hiroki, CEO of Rector, Inc., and Hiroshi Ito, Head of Product Development at Loglass, moderated by Koichiro Matsuoka from the Loglass AI Platform Development Team.

The discussion began with a familiar tension. If an AI agent can implement a system, how deeply must a human understand the resulting code?

Ito described building an OLAP database by treating Claude Code almost like a highly capable engineering team. Rather than directing every implementation detail, he concentrated on the perspectives and criteria required to verify the result. His position was concise: let go of implementation details, but never let go of the outcome.

This distinction matters. AI allows people to operate at a higher level of abstraction, but abstraction does not eliminate responsibility. Someone must still determine whether the system solves the intended problem, identify where it may fail and decide whether it is safe to release.

The role of the engineer is therefore not disappearing. Its centre of gravity is shifting—from producing every line personally to designing, directing, validating and owning the complete system.

A new risk: cognitive debt

Wada introduced the idea of cognitive debt.

Traditional technical debt refers to software that becomes difficult to maintain because of earlier design or implementation choices. AI coding tools can sometimes reduce this burden by making rewriting, testing and refactoring much cheaper.

But another gap can grow in its place: the difference between what the system actually does and what the people responsible for it understand.

Limited understanding has always existed. The difference is speed. AI can now generate functionality faster than a team can form a reliable mental model of it. People may not merely misunderstand part of the system; they may fail to recognise that their understanding is incomplete.

Hiroki connected this risk to the concept of leaky abstractions. Every abstraction hides complexity, but no abstraction is perfect. At some point, the hidden details reappear—through a physical limitation, an unexpected customer question, a regulatory change or another external event.

This is particularly relevant to financial and accounting software. A system can appear stable until a new reporting requirement, an unusual transaction or a jurisdiction-specific rule exposes an assumption that nobody realised had been embedded in the design.

The goal is not to understand every generated line equally. It is to know where an abstraction is likely to leak and retain enough control to investigate when it does.

Understanding is demonstrated through output

How can teams prevent cognitive debt from growing invisibly?

One answer discussed at the event was to create deliberate opportunities for output. Understanding is difficult to assess through passive consumption. It becomes visible when someone must explain a decision, design a test, respond to an exception or defend why a system should be released.

Ito described maintaining a traceable flow from vision and hypotheses through features, specifications, test design, implementation, verification and release—even when AI performs much of the work. The purpose is not to preserve an old process for its own sake. It is to ensure that human responsibility can still follow the chain from intention to outcome.

Hiroki also introduced the idea of a human harness: constraints that prevent an AI agent from proceeding until the person directing it has demonstrated sufficient understanding.

This reverses the usual assumption that only AI requires guardrails. In an AI-enabled workflow, humans may also need mechanisms that stop them from accepting fast output before they have asked the necessary questions.

Job descriptions are becoming more permeable

One of the clearest themes from the evening was that professional boundaries are beginning to dissolve.

As AI lowers the cost of coding, an engineer can explore product design, automate an operational process or prototype a business idea without waiting for a large specialist team. The same applies in the opposite direction: product managers, finance professionals and domain experts can participate more directly in building and testing software.

This does not mean expertise no longer matters. It means expertise becomes more useful when it can travel.

The ability to cross into an adjacent field—to understand enough of the customer, business model, data, regulation or user experience to work effectively across the boundary—is becoming a core professional capability.

Wada suggested that AI makes these adjacent moves easier and that organisations should use this opportunity to increase the number of people who can search for value, rather than simply maintaining the same work with the same role structure. He described a path of continuous adventures: small, repeated moves beyond one’s current responsibilities instead of choosing only between staying still and making a dramatic career change.

This may be one of the most realistic career strategies for the AI era. “Crossing borders” does not always require changing professions. It can begin with joining a customer interview, building a small internal tool, studying a regulatory issue, testing a new business assumption or explaining a technical decision to a non-technical audience.

More output is not the same as more value

AI can dramatically increase output. It can generate code, documents, prototypes and analyses at a speed that was previously impossible.

But the panel returned repeatedly to a more difficult concept: outcome.

An outcome is not simply the quantity of material produced. It is a change in customer behaviour, business performance or social impact. Increasing output without clarifying the intended outcome may only allow a team to move faster in the wrong direction.

This is why contact with customers remains essential. Teams need experiments, observation and conversations outside the building to determine which problems are real and which merely appear logical from inside the organisation.

Lower development costs also make previously uneconomic ideas possible. Software can now serve narrower needs, automate smaller workflows or support markets that would once have been too expensive to address. However, identifying those opportunities still requires someone to notice a need that conventional analysis may overlook.

Why “slightly strange” research becomes useful

Hiroki argued for developing a habit of investigating things that may initially appear ordinary, peripheral or even slightly strange.

This advice is more practical than it sounds. Obvious questions are increasingly easy to answer with AI. Widely discussed information can be summarised almost instantly. The advantage moves toward the person who notices an unusual detail, studies an unfamiliar community or asks why behaviour does not match the expected model.

Such knowledge often becomes useful in unexpected ways. It can improve a product decision, reveal a hidden stakeholder, provide a better analogy or simply make a conversation more insightful.

A memorable example shared around the event concerned an entrepreneur who initially planned to build a counselling application. After finding that the expected market did not exist in Japan in the anticipated form, the concept was redirected into a fortune-telling application—and it sold.

The underlying demand was not necessarily for prediction itself. Women ranging roughly from their late twenties to their fifties appeared to value the experience of being told something about themselves: a structured moment of attention, interpretation and emotional engagement.

Whether one views the product as entertainment, guidance or a substitute for another unmet need, the case illustrates an important point. Market opportunity is not always revealed by starting with a conventional category. It may emerge from observing the experience people seek and then changing the product accordingly.

AI can help build and test the application. It cannot automatically decide what the behaviour means.

“Human skills” are becoming engineering skills

When roles overlap and implementation becomes cheaper, qualities sometimes labelled vaguely as “human skills” become more—not less—important.

Wada emphasised an interest in people and the ability to empathise. Value begins and ends with humans: colleagues who must understand a decision, customers experiencing a problem, and stakeholders affected by the resulting system.

For engineers, this means communication and empathy are not supplementary soft skills. They are part of the mechanism by which relevant problems are found and appropriate systems are designed.

It also means taking responsibility for ambiguity. AI performs best when a task and its evaluation criteria can be expressed clearly. Real organisations, however, contain conflicting goals, incomplete information, political constraints and needs that users may not articulate directly. Navigating those conditions requires judgment and relationships.

The more AI handles what can be specified, the more human value may concentrate in what has not yet been specified well.

What this means for finance and accounting communities

Although the event focused on software engineering, its lessons extend directly to finance, accounting and IFRS implementation.

These fields are also experiencing a dissolution of boundaries. Accounting professionals increasingly work with data models, systems and automation. Engineers building financial products need to understand reporting logic, internal controls and regulatory context. Product teams must translate technical accounting requirements into workflows that users can actually operate.

AI can make each group more capable in the others’ territory—but it also creates the same cognitive-debt risk discussed at the event. A generated analysis, accounting treatment or system rule may appear complete even when the responsible person cannot explain its assumptions or verify its sources.

For IFRS Labo, this reinforces a principle behind our own work: AI is most valuable when it expands the directions we can investigate, while domain expertise, verification and human responsibility remain connected to the final conclusion.

The future may belong less to narrowly defined specialists working in isolation and more to people who can bring a strong foundation into conversation with adjacent disciplines.

The engineer’s role is expanding, not shrinking

The title of Loglass AI TALK vol.8 promised to redefine software engineering. Yet one of the evening’s conclusions was that many longstanding principles remain intact.

Engineers still need to understand systems, seek customer value, test assumptions and take responsibility for outcomes. What changes is the scale and range at which they can do so.

AI compresses implementation and accelerates exploration. It also makes it easier to cross professional boundaries, undertake small continuous adventures and investigate opportunities that previously would have required a much larger organisation.

The differentiator is no longer simply the ability to produce an answer. Increasingly, it is the ability to notice the question that everyone else—and perhaps the AI—has overlooked.

About the event

Loglass AI TALK vol.8: “A Night to Redefine Software Engineering in the AI Era” was held on Monday, 7 September 2026, from 19:00 to 21:30, with both in-person and online participation. The event was organised by Loglass Inc.

Read Loglass’s official event report.