It seems like everyone is obsessed with speed at the moment. Scroll any engineering feed, and you will see people building a full-stack app in minutes using an LLM. Engineering leaders are rushing to give everyone an AI copilot to double the feature delivery velocity. I think this is optimizing for the wrong thing.

Most of my career has been spent on architecting high-traffic backend systems and messaging pipelines. Kafka streams, Node.js services, RabbitMQ queues, React frontends are not the kind of systems where "it works" is enough. It has to stay stable, change and fail safely in controlled ways.

AI makes code easy to produce. And that is the risk. The bottleneck is rarely typing code, it is thinking. It is judgment.

So, I use LLMs every day, not to write code faster, but to write code slower, deeper and better. I force the LLMs to defend the design to me before a single line of code is written.

Code is no longer the hard part

Writing a React component, adding an API layer, or a backend service is trivial now. The hard parts are still the same.

• Data ownership: what owns the data?
• Downstream degradation: what happens when a downstream service drops off the network?
• System load: How does the service behave under a traffic spike?
• Resilience: How are retries (and backoff) implemented?
• Mitigation: What breaks down in the system and how do we protect against it?
• Recovery: How do we recover a system from a failure?

Without anchoring the AI with these constraints, it will generate code that works in isolation, but fails in production. I have seen systems pass every integration test and still collapse in production.

More time planning, not generating code

The most common mistake is treating LLM like an advanced autocomplete.

Instead, I write out the architecture and the data models, and then I use the model to walk me through every possible failure mode. We debate network timeouts, boundaries and state transitions. By the time I actually ask the LLM to write a line of code, the system's design is finalized. The generation of the actual code becomes the easiest part of the process.

Trick the AI

LLMs are fundamentally trained to optimize for user approval and conversational flow. If you push back, LLM will flip the position and apologize most of the time, even if the original answer was correct. If you leak your architecture early in the prompt, the AI will instantly agree with you and just go with the flow to justify your bad idea.

So, I just show it the problem, forcing the AI to propose independent solutions first.

The shift in prompting

Previously:

"Write me a Node.js script to connect to RabbitMQ, consume messages from an order queue, and save them to a database."

The AI will spit out a clean snippet that opens a connection, listens, and runs a DB insert. It may look perfect, but it is not proper code.

Now:

I need to write a Node.js script to connect to RabbitMQ, consume messages from an order queue, and save them to a database. Do not write any code yet. Instead, lets walk through the system design first. Focus on:

• Connection pooling to PostgreSQL
• Network blips between the service and RMQ connection
• Message acknowledgment strategies
• Handling malformed message without blocking the entire queue.

Slowing down this process forces you to refine the design, error handling and database connection strategies before a line of code is written.

Closing thoughts

I use AI to write code every day. But I do not let it decide the shape of the systems. I first let it agree with me on the design and validate the architecture.

We need to spend more time planning and less time blindly generating. Let the AI do the typing, but make sure you are the one doing the thinking.