Using LLMs and AI agents can accelerate our output exponentially. But there is a dangerous side effect to this velocity.

Atomic Object is a software consultancy specializing in custom software development and product design. Readers can learn about software development methodologies, user-centered design principles, and agile practices. With case studies, blog posts, and technical insights, Atomic Object provides  guidance and expertise for building innovative and user-friendly software products.

Atomic Spin

As AI agents and LLMs accelerate code output, developers risk falling into a 'speed trap' where working code replaces architecturally sound code. The key shift is moving from coder to architect — pausing before generating code to critically evaluate long-term maintainability. Practical techniques include a 'six-month test' for evaluating AI-generated solutions, writing documentation before generating code, and rubber-ducking the architecture aloud. Speed is only valuable when heading in the right direction; thoughtful architectural judgment is the developer's core value in the AI era.

Velocity: Why the Best Software Architects Move the Slowest

I fear that more and more engineers are joining the “dark side” of AI prompting. The scary part is that these are factors we can’t control. So to anyone reading this, please become the engineer that still asks “why” and still “challenges” the AI for better code and architecture. It is up to us to clean up the mess generated when this landfill overflows.

So, stop making garbage because it causes tons of issues. Got it.

The six-month test is useful, but I would add a reversibility test before implementation: what decision becomes expensive to undo once data, clients, or operations depend on it? A short architecture note should record constraints, rejected alternatives, and the signal that would trigger reconsideration, not try to predict every future detail. That keeps deliberation bounded while preventing fast code generation from silently hardening a temporary assumption into a platform contract.

The six-month test is a useful pause button. AI can make the first implementation cheap, but unclear boundaries and undocumented decisions still become expensive later. Writing the intended architecture first gives the agent constraints and gives future maintainers something better than generated code to infer from.

Great article which touches a fresh pain point of AI assisted coding era.
<blockquote>
As we get more comfortable using agents, we start to trust the agent’s output more and more.
</blockquote>
In my case it is the opposite situation – my confidence in AI agents (I use latest Opus) gets lower, despite we move step by step with the small scoped tasks. It just invents (generates) the suitable answers, which often have nothing common with the reality, so I must force it to examine the code/docs first, before generate a line of code. I don’t mention the ticket and task context with its own sessions logs, which it reads before the every session.
So finally it turns into the classic architect-assistant tandem, where it just generates fast what I could write myself, but much slower. No architectural decisions from agent, tight code review from my sight after the every iteration. But still I’m much faster with the agent, as without it.