How AI Is Reshaping Engineering Organizations
#How AI Is Reshaping Engineering Organizations
#Smaller teams, thinner management layers, and the rise of engineers who decide what to build
AI is changing the basic assumptions behind engineering organizations. Code can now be written faster. Small teams can launch products that previously required larger groups. But that acceleration is also creating new questions around team design, information flow, quality assurance, security, hiring, and career development.
In a panel moderated by Yoshimasa Iwase 
iwashi, speakers Taichi Nakashima (
deeeet) and Yuki Matsumoto discussed how engineering organizations are already changing in the AI era — and what may come next.
#Teams are becoming smaller and more cross-functional
One of the clearest themes was that product teams are likely to become smaller.
Yuki Matsumoto explained that at LayerX, the company has long hired engineers with broad, cross-functional capabilities rather than narrow frontend or backend specialists. In that sense, the AI era has not completely changed the hiring philosophy. What has changed, however, is the expected size and speed of product teams.
When new products are being launched every month, the question becomes: how many people are actually needed to build one? In some cases, assigning four engineers to a new product can already feel like too many. Development timelines that once looked like five months may now be compressed into three.
The result is a shift toward small, autonomous teams that can move quickly with the help of AI.
#From “engineers” and “designers” to “AI builders”
The panel also explored how traditional roles may blur.
Matsumoto introduced the idea of the AI builder: someone who can understand a business problem, design the solution, think through the architecture, and use AI to bring it into reality.
In this world, designers are not simply people who manually create every interface. Their responsibility becomes building design systems and standards so that AI agents can produce designs that are already 80 or 90 percent aligned with the company’s quality bar.
The same applies to engineers. Their job is not only to write code themselves, but to create the architecture, context, and development environment that allow AI agents to produce code that is good enough, safe enough, and consistent with the company’s engineering principles.
In other words, expertise does not disappear. It moves up a level.
#Information flow becomes the organization’s nervous system
As teams get smaller and more numerous, communication becomes harder.
Taichi Nakashima described how Mercari is experimenting with AI pods and information aggregation through tools such as Linear and Notion. The idea is to gather project updates, documentation, risks, decisions, and context into AI-native systems so that managers and other teams can ask questions and retrieve what they need.
Rather than relying on humans to attend every meeting or manually sync every piece of context, AI can help surface the right information at the right time.
Matsumoto connected this to the idea of a digital nervous system inside the company. If management is partly about collecting facts, understanding what is happening, and transmitting information quickly, then AI can reduce the need for some traditional management work.
That does not mean management as a function disappears. But the role of “manager” may become lighter, flatter, and more focused on judgment rather than information collection.
#AI infrastructure is becoming company-wide infrastructure
The panel also discussed the internal infrastructure required for AI adoption.
Nakashima described a setup where employees can access models and tools such as Claude Code and Codex through internal LLM infrastructure, including LiteLLM. Importantly, this is not limited to engineers. Business development, product managers, and other non-engineering roles are also beginning to use these tools.
Matsumoto described a similar direction at LayerX, where internal tooling makes it easier for people across the company to use Claude Code, Codex, OpenCode, and other AI tools through a common authentication and proxy layer.
But widespread use brings a new problem: cost.
When everyone is encouraged to use AI heavily, token costs can become material at the business level. Matsumoto noted that AI spending became significant enough to affect planning discussions. This makes cost tracking essential: companies need to know who is using which models, how much they are spending, and where the money is going.
The next phase of AI adoption is not just “use more AI.” It is “use AI freely, but with visibility and governance.”
#The bottleneck moves away from coding
AI has compressed the coding part of software development. That means the bottleneck is moving elsewhere.
Matsumoto argued that organizations now need to look beyond the path from planning to deployment. The real process ends only when customers understand, adopt, and gain value from the product.
If a company ships new products or features too quickly, sales teams may struggle to keep up. Customers may also struggle to absorb the pace of change. This is especially true in B2B, where software needs to be installed into real business workflows.
That makes the earliest stage more important than ever: deciding what to build.
The faster AI makes implementation, the more dangerous it becomes to build the wrong thing quickly. Engineers therefore need to get closer to customers. Matsumoto put it bluntly: engineers should go to sales meetings, watch customer calls, and understand the real problems firsthand.
#QA and security become even more important
If AI generates more code, then quality assurance and security become more critical, not less.
Matsumoto argued that the final bottleneck may move to QA and security checks. When AI can produce large numbers of patches and pull requests, companies need stronger gates to ensure that what gets released is safe.
Nakashima agreed, emphasizing that development environments, test infrastructure, E2E testing, scenario generation, and validation quality all become more important. If AI speeds up implementation but the testing environment is unstable, the organization still cannot move safely.
This also changes the value of platform engineers and QA specialists. Their role becomes less about manually checking everything and more about enabling developers and AI agents to validate work reliably.
QA, security, and platform engineering become force multipliers.
#Code review is becoming a harder problem
The panel also touched on a growing pain point: code review.
As AI generates more code, humans are asked to review more output. In practice, engineers are already using AI to summarize pull requests, identify risky areas, and guide reviewers toward what matters.
But both speakers suggested that the current pull request model may not survive unchanged.
Nakashima raised the challenge of cross-team contributions. If one team sends a large AI-generated pull request to another team’s foundational system, the receiving team has to bear the review burden. This resembles the “AI slop” problem seen in open source, where maintainers receive large volumes of low-context contributions.
This link in Mitchel Hashimoto releases Vouch to solve the slop PR problem.
Possible solutions include trust mechanisms, onboarding signals, or even shifting from pull requests to intent-based contributions. Instead of sending a full implementation, a team might submit the intent — what they want to achieve — and let the owning team or its agents decide how to implement it.
The future of review may be less about reading every line of code and more about validating intent, ownership, trust, and responsibility.
#Are junior engineers still needed?
The panel also addressed one of the most uncomfortable questions in the industry: will junior engineers still be needed?
Matsumoto acknowledged that if companies think of junior engineers only as immediate implementation capacity, that need may shrink. Senior engineers with AI can now produce much more than before.
But he also argued that companies must think in five- and ten-year timeframes. If organizations stop developing the next generation of engineers, they risk losing long-term continuity. Senior engineers may need to take on explicit responsibility for mentoring and developing juniors, much like masters training apprentices in traditional crafts.
Nakashima also rejected the idea that juniors are unnecessary. At Mercari, he has seen new graduates and interns adapt extremely quickly to AI-native development workflows. Their learning speed and flexibility can be a major advantage.
The key is that juniors must not outsource their understanding to AI. AI can accelerate learning, but only if people remain committed to understanding what is happening underneath.
#Three possible career paths for engineers
The discussion closed with a reflection on engineering careers in the AI era.
One path is the product-focused engineer: someone who moves closer to customers, understands what should be built, and uses AI to turn that understanding into products.
Another path is the enabler: someone who builds the platforms, tools, systems, and workflows that allow other engineers — and AI agents — to work safely and effectively.
A third path is the deep specialist: someone who goes further into areas such as databases, infrastructure, security, performance, or advanced UI/UX. These are complex domains where deep expertise will continue to matter.
The common thread is that simply wanting to “only write code” may become a fragile career strategy. Engineers will need to decide whether they want to move toward product judgment, enabling systems, or deeper technical specialization.
#The AI era may make engineering more interesting, not less
The panel’s overall message was not pessimistic.
AI will change engineering work, but it does not make engineers irrelevant. Instead, it shifts the center of gravity.
Less time may be spent manually writing every line of code. More time will be spent deciding what to build, understanding customers, designing systems, improving quality, enabling teams, and taking responsibility for outcomes.
For engineers who enjoy ownership, this may be an unusually exciting era.
The central question is no longer just:
How fast can we write code?
It is increasingly:
Can we decide what is worth building?