Building with Agents
If you peel back the layers from agents and all the AI stuff, the true serendipity is when an agent actually generates a project that takes almost every consideration into account — something big and almost ready to roll out, but not quite.
I have tried generating a full-blown enterprise-grade project, and it gets 90% done. But finishing it — the last mile, with all the bugs — is exhausting. There is also the temptation to just ship it as is, which is more dangerous.
Another pitfall is when people use agents as decision makers. Agents are assistants; you cannot make them take decisions on your behalf, because the decision is irrational to begin with — it is randomized. The reasoning is human-like, but it is not human reasoning.
The reason quite a lot of software was stable in the pre-AI era is that the scope was limited to begin with. Limited scope and handcrafting led to better know-how. Creeping the scope is very easy with AI, and I think that gives a sense of fake productivity. Scope creep is subtle with agents: you have a sense of the end goal, it feels like you are almost there, but then you run into issues that are now extremely difficult to solve. So you prompt the agents again, and layer by layer you accumulate tech debt.
Conclusion
None of this is an argument against building with agents. It is an argument for building with them honestly. The leverage is real; getting to 90% in a fraction of the time it used to take is genuinely new. But the 90% is the easy part — the last 10% is where the actual engineering lives, and no amount of prompting moves that work onto the agent. It still belongs to you.
So treat agents as what they are: fast, tireless assistants — not collaborators you can hand the wheel to. Keep the scope deliberately small, own the decisions, and stay close enough to the code to understand what was actually built. The teams that win with agents will not be the ones who shipped the most in a weekend; they will be the ones who knew exactly which 10% they still had to earn.