Previous article: Real Problems I Encountered When Developing With AI Agents
Early ChatGPT Usage
When ChatGPT first appeared, I would not say that it immediately transformed my coding work in some dramatic way. It mattered quickly, but in a narrower sense at first.
The way I used it in those early days was fairly ordinary. I asked it to generate small methods. I used it to discuss possible design directions when I had not yet decided which structure I wanted. And I used it as a practical research tool when I needed to investigate libraries, tools, small implementation details, or operational procedures outside my current focus.
That stage was useful, but it still felt like assistance around development rather than a fundamental change in development itself. The coding work still centered on me, and the AI mostly acted as a fast conversational helper around the edges.
One detail that people often focus on now is freshness of knowledge. In practice, I did not feel that as a major problem in those early workflows. If I needed the latest factual precision, I could verify it by other means. For the kinds of work I was actually doing most often, slight lag in freshness was not what mattered most. What mattered was whether the answer helped me move forward.
The Copilot Moment
The first moment that really changed how coding itself felt was GitHub Copilot.
I found it while moving from Visual Studio for Mac to VS Code. At that time, the end of support for Visual Studio for Mac had been announced, and that announcement pushed me to start shifting my C# work toward VS Code. Copilot was not the main reason for that move. I discovered it more or less by chance while trying to rebuild a usable daily environment.
Then I saw it completing code directly in the IDE. That moment had a very specific kind of impact on me. It was not abstract anymore. It was not a chat window on the side. The code was appearing where I was already working, at the moment I was trying to write it.
Even when the results were often wrong, the workflow was obviously faster. That part was clear almost immediately. You did not need a benchmark to see it. You could feel the difference in your hands.
What especially struck me was how much it helped when I returned to development after being busy with other work. In my actual life, development is not the only thing I do. There are stretches where business tasks, operational issues, and other responsibilities occupy most of my attention. After a period like that, returning to code usually requires a kind of rehabilitation period. You have to load the structure back into your head. You have to remember your own patterns again. You have to recover your development rhythm.
Copilot shortened that recovery period in a very practical way. It did not replace understanding, but it helped me re-enter the flow much faster. That was one of the earliest points where I thought: this is not just a convenience feature. This changes the shape of actual work.
The ChatGPT and Copilot Period
After that, there was roughly a year in which most of my AI-assisted development was built around ChatGPT and GitHub Copilot.
That combination became my normal working environment. ChatGPT handled design discussion, idea shaping, research support, and occasional code generation. Copilot handled the direct coding rhythm inside the editor.
Copilot chat and inline command features existed by then, but I did not use them especially heavily. My practical usage stayed centered on the more direct completion-oriented flow.
Looking back now, I sometimes wonder whether early forms of agent-style development might already have been possible in some limited sense. Perhaps the boundary was not as sharp as it now appears in hindsight. But even if that is true, I do not think the practical feeling was the same. The real shift came later, when the tool stopped being mostly predictive assistance and started behaving more like a delegated worker.
The Arrival of AI Coding Agents
That next shift came with AI coding agents.
Once those tools became usable in everyday development, the workflow changed again. Now the tool was no longer only completing local code or answering local questions. It could modify an entire solution, run commands, manage git operations, inspect the project more broadly, and help with environment setup.
At that point the scale changed. The range of actions changed. And because of that, the practical value changed as well.
Now engineers often use tools in the broad family of Codex-style agents, Claude Code, and other coding agents that operate with similar ambitions. The names will continue to vary. The details may differ. But the general direction is already clear.
Unless there are strict security constraints, it is becoming difficult to justify not using such tools. That does not mean blind trust is justified. It certainly is not. But refusing the tools entirely begins to look less like discipline and more like unnecessary self-limitation.
Japanese Engineering Structure
Thinking about where this may lead also makes me think about the structure of engineering work in Japan.
What I am describing here is based on my own experience, and I do not claim it represents the entire industry in a complete or current way. Still, in the system integration work I saw, there was often a recognizable split between roles that were treated as more like System Engineer work and roles that were treated as more like Programmer work.
The System Engineer side was expected to handle design, specification coordination, and communication. The Programmer side was expected to implement.
There were also pricing differences between those roles. That distinction was not merely conceptual. It appeared in how work was valued and billed.
At the same time, the reality was often less clean than the names suggested. Programmers were frequently expected to do more than the role title implied. Responsibility could expand beyond nominal boundaries without compensation or authority expanding at the same rate.
That historical context matters. I do not think the structure existed only because people misunderstood software work. Part of it also reflected the fact that implementation itself consumed a tremendous amount of time and human effort. The reason was often simpler than people now remember: writing the software itself took an enormous amount of sustained labor.
Programming as Intellectual Manual Labor
Because of that, I have often thought that programming historically functioned as a kind of intellectual manual labor.
I do not mean that dismissively. I mean that a very large amount of value came from sustained, detailed, repetitive implementation effort. That effort was intelligent, but it was still labor-heavy in a very concrete way.
The separation between engineer and programmer existed partly because programming itself was so time consuming. Someone had to think at the higher structural level. Someone had to absorb the enormous cost of turning that structure into working code.
AI agents reduce the weight of that labor significantly. Not to zero, and not safely without supervision, but significantly enough that the old balance between design and implementation work may not remain stable. And to be fair, the need for supervision is not unique to AI. The same is true when humans are involved. At the same time, AI agents have a different risk profile from human teams, including no interpersonal retaliation dynamics and no intent-driven disclosure behavior.
A Small Team Hypothesis
This leads me to a hypothesis I keep returning to.
I think development productivity per engineer tends to decrease as team size grows. That is not because more people are useless. It is because communication cost grows relentlessly.
With one person, there is no coordination cost. With two or three people, coordination is still manageable. With five to ten people, communication becomes heavy enough that it starts changing the nature of the work itself.
At that point, meetings, alignment, interpretation, handoffs, and review structures consume a meaningful share of energy. Sometimes they consume far too much of it. When the team grows, shared context also starts to fragment, and the cognitive load required just to stay aligned becomes part of the cost of development itself. Coordination work begins to grow faster than productive work.
So my current hypothesis is that the optimal team size may often be around three people. Not always, and not universally, but often. That size is still small enough for shared context to remain alive while being large enough to divide work meaningfully. I also think three can be better than two for another reason. With two people, the discussion can easily stay trapped in a direct back-and-forth. In Japanese there is a proverb, three people together have the wisdom of Monju, which expresses the idea that a third perspective can create a disproportionate increase in insight. When a third viewpoint exists, the team can sometimes gain a disproportionate amount of leverage from that extra perspective.
AI agents change this equation because they reduce part of the mechanical work that previously required multiple programmers. In other words, the implementation labor that once justified larger teams may shrink, while the coordination cost of those teams remains. If AI agents continue improving, then teams of that size may be able to produce systems that previously required much larger organizations. That possibility seems very real to me.
AI and Software Review
One of the more interesting things about AI is that it often makes mistakes while coding and yet performs surprisingly well at review.
One of the real problems in solo development or very small-team development is that it is hard to recognize the problems you caused yourself. In larger teams, that weakness is usually offset by having someone else review the work. That is one of the classic ways software quality has been maintained.
I have seen it point out design inconsistencies, logical problems, and code quality issues that were worth taking seriously. That contrast is interesting. And that is exactly why AI review matters so much. It can take over part of the role that, in a larger organization, would normally be handled by another engineer. At the same time, I do not think that removes the need for final human judgment on domain invariants, security-critical decisions, and accountability-heavy trade-offs.
Why would a model that often writes questionable code also review fairly well? I do not think I can answer that rigorously. But I suspect it may relate to the statistical nature of generative models. Review is closer to pattern recognition than to original construction. In practice, code review is also closer to anomaly detection than to construction. Generative models are fundamentally optimized for recognizing patterns in large amounts of data.
When reviewing code, the model does not need to invent a structure from scratch. It only needs to detect inconsistencies, unusual patterns, or deviations from common design structures. That kind of task appears to align surprisingly well with how these models actually work.
That is only a working thought, not a final conclusion. Still, the contrast is real enough that I no longer think of AI only as a generator. It is also a reviewer, and sometimes a very useful one.
Future Outlook
So what kind of engineer is likely to succeed in the AI era?
I think it will be the engineer who can imagine the full system architecture rather than only a local code fragment. It will be the engineer who can communicate with customers, extract the real operational problem, produce and share design materials with AI support, and then drive development forward quickly using AI tools. And if smaller teams really do become more important, then each member will need to be a relatively independent presence. They will need to share the business problem, understand it, think through a solution, and actually execute development with a meaningful degree of autonomy.
It will also be the engineer who can connect software to the customer’s actual business growth. That matters more than people sometimes admit. A system is not valuable because code exists. A system is valuable because it changes the customer’s operation in a useful direction.
I also think many systems will continue running primarily on cloud infrastructure. That direction already feels normal. If that is combined with strong AI assistance, then small teams, and in some cases even individual engineers, may be able to deliver systems that previously required much larger organizations.
I do not say that with blind optimism. There will still be mistakes. There will still be weak designs, security failures, and bad decisions. The difficulty does not disappear. But the shape of the work is changing, and I think cautious optimism is justified.
At the same time, I do have one concern. Small teams often do not have much room to train junior engineers patiently. AI can support learning in many ways, but I do not think it easily replaces the kind of sustained human guidance that helps someone grow through real work. And unless the person is proactive, there is only so much the tool can do. The problem is that truly proactive people are not the majority. So while I think AI may make very small teams more powerful, I also think it leaves a real question about whether the next generation of engineers will be developed well enough.
AI will not eliminate engineers. Instead, it may raise the value of people who can think structurally, communicate clearly, and move quickly without losing control. The engineer who succeeds in that environment may not be the one who writes the most code. It may be the one who can understand the whole system, communicate with real business problems, and guide both humans and AI toward a coherent design.
When the mechanical part of programming becomes cheaper, design decisions, system understanding, and communication with real business problems become more valuable. The center of gravity of software work may shift. In that sense, the role of engineers may shift. Less manual coding. More responsibility for the direction of the system.
Next article: Working Safely with AI Coding Agents
