Agentic development is making one thing very cheap:
the demo.
That is exciting. But also slightly dangerous.
From my own experience in product development inside a consulting company, the hardest part is rarely getting to the first impressive version.
The hard part is everything after that:
- the integrations,
- the edge cases,
- the quality issues,
- the operational headaches,
- the code you now have to live with.
AI can accelerate delivery. But it can also accelerate technical debt if teams confuse “generated quickly” with “engineered properly”.
The real question is no longer:
Can we build this?
It is:
Can we make this robust enough to survive real usage?
That is where the extra thousands of commits live.
The teams I have seen do this well use agents for speed, but stay very disciplined on architecture and ownership. Some are even encoding that discipline directly into the agents themselves: TDD-first workflows, mandatory code review steps, structured planning before implementation.
That is the right direction.
An agent should not just produce code. It should participate in an engineering process:
- understand the issue,
- inspect the existing system,
- propose a plan,
- implement the smallest useful change,
- run verification,
- report evidence,
- leave a reviewable diff.
Without that structure, agentic development becomes a faster way to create uncertainty.
With that structure, it becomes a real productivity tool.
I am optimistic about AI-assisted software development, but not because I think it removes engineering. I am optimistic because it can make disciplined engineering more scalable.
The demo is cheap now.
The product is still the product.