Enhanced teams
Overlooking the blind rush of engineering teams to grab these blackbox machines to build everything they could imagine in their wildest dreams, I am more interested to look at what are the actual, objective, positive points this tech brings to the table for teams.
It is safe to say that AI proved that it's here to stay, at least in the software development world, even if nothing improves for the coming years, today's models are good enough for it to be disregarded by development teams.
In this post I will try to distill the current situation of AI agents and what teams should look out for.
Learning curve
AI, like any other tool or programming paradigm, has a learning curve to it. I don't believe that AI is a "god machine" spitting out perfect code and can be used for everything. The evidence doesn't show that either, even though there are industry "thought leaders" and paid YouTube influencers are trying to gaslight you into believing that.
What evidence shows, that currently, all LLMs have a small "smart" zone in the beginning of their context window, a large "dumb" zone in the middle, and emphasis is always put on the beginning and the very end of every context window. I think most people who are getting bad results from these models fail to optimize for this context window and also not breaking down the problem domain into clear, simple steps.
Solo developer within a team
There is a growing trend of programmers becoming "solo developers" again, one person using multiple AI agents to do the work that previously required a team. I see this framing as somewhat misleading.
If I have three agents running simultaneously and I coordinate their work, I am not managing a team of three engineers. I am using three tools in parallel.
That can be incredibly powerful, and it may allow one developer to accomplish what previously required several people, but the distinction matters. Agents don't have independent goals, accountability, judgment, or ownership in the way human team members do. Teams still generate a better output it's just each team member now have a larger, more capable toolbox.
Pair programming
Pair programming with an AI agent is not the same thing as two humans pair programming with an AI agent.
Two experienced developers can discuss the problem, spot mistakes, divide the work, and steer the agent. One developer may notice something the other missed, while the agent handles implementation and exploration. The humans provide the context, and feedback loop that the agent itself cannot provide.
AI can make pair programming more powerful, but simply adding an agent does not automatically reproduce the benefits of adding another human engineer.
Team size
A common prediction is that software teams will become smaller as companies replace developers with AI agents. So far, I don't think that is the trend at all. In many cases, team sizes remain relatively stable while developers use AI to increase their throughput (As far as productivity goes, that is still up for debate).
This also makes sense from a management perspective. If you already have a team of good engineers, the obvious goal is to make that team more productive, not necessarily to reduce its size. If AI agents allow the same people to ship more, investigate problems faster, automate tedious work, or take on larger projects, everyone benefits. The company gets more output from the same team, while developers spend more of their time on higher value work.
Agents don't have to replace people to be valuable. Making existing teams significantly more capable is already a very good outcome.
The endless productivity mirage
So, there is the assumption that using agents automatically means software teams are becoming much more productive. I don't think we have enough evidence to make that claim yet.
It is easy to measure how much code an agent produces, how many tasks it completes, or how quickly a developer gets a first implementation. It is much harder to measure whether that translates into better software, like fewer bugs, faster delivery of meaningful features, lower maintenance costs, or better longterm architecture. Agents can make speed up tasks implementation, but faster isn't more productive if the resulting code requires a more thorough review, or even a refactor.
Reading the code
I keep hearing that if agents fully produce the code then developers no longer need to care about it because the agent can just as easily change it. This assumption does not hold up in any serious work.
What happens when the agent can't fix a bug? These situations happen more often than developers care to admit.
An agent can get stuck in a loop, repeatedly generate the same incorrect fix and fail to understand the underlying problem. At that point, someone still needs to understand the system deeply enough to fix it. If you are responsible for the software, you are also responsible for its behavior, regardless of who or what generated the code. You can't delegate accountability to an agent.
AI can reduce how much code you write by hand, but it doesn't eliminate the need to understand what that code actually does. If anything, the more code you delegate, the more important that understanding becomes.
In this context, the "engineers as managers" notion doesn't hold up either.
Training data bell curve
Agents are trained on code that is available as training data, and much of that code is average. It works, but that doesn't mean it represents the best engineering practices or the most sophisticated production code.
There is also an entire industry around producing, curating, licensing higher quality code and other training data. That alone should tell us that not all code is equally valuable as training material.
If most code training data falls in the middle of the bell curve, than the output can't be better code.
Average in, average out.
Maintenance
AI agents are very good at solving the problem immediately in front of them, but software will live with those decisions for years. A solution that works on the surface can still create unnecessary technical debt and complicated abstractions that make future changes harder.
This is even more difficult, because an agent's context is reset with every new prompt and can only parse the accumulated context window. To minimize this, again, we have to circle back to learning how these tools actually work under the hood and routhlessly review the output they produce.
Basics of programming still matter
Even though software development is shifting from writing every line of code by hand toward describing problems and directing agents, you still need to understand what to ask for and what good code looks like.
A simple example, I once had an agent generate a chart that looked completely correct and worked perfectly on the surface. Visually, there was nothing wrong with it, the chart rendered correctly, it was even interactive using JavaScript. Under the hood, however, a recursion bug caused it to consume 100% of the CPU.
Without understanding programming fundamentals or how production software actually works, that kind of problem is easy to miss because the output appears to work.
Understanding algorithms, complexity, recursion, memory leaks, and the overall system is still required in agentic programming. AI may change how we write code, but it doesn't make the underlying principles of computing disappear, at least not yet.
Cost
Writing enterprise software is very very different from startup code. I think that until capable local LLMs become practical for everyday development, using AI at scale means depending on hosted models and paying for inference.
The levers of the current token economy is in the hands of a few companies, who force the entire World's tech supply chain to adapt rubs people the wrong way.
Prices may fall as open-weight models catch up and competition increases, but that will also grow demand too. It's similar to Braess's paradox.
Running several agents continuously can turn what looks like an inexpensive developer tool into a significant operational expense. Local models could eventually reduce this dependency, but we're not there yet.