AI Works Best Before You Start Coding
AI is most useful before coding starts: expanding the problem space, surfacing assumptions, and helping shape better decisions before implementation narrows the options.
Most conversations about AI in software still orbit around code generation. How much can it write? How long can an agent run? Can it replace a developer for a particular task?
Those are useful questions, but they start too late.
I used to think of AI mainly as a development accelerator. I would arrive with a reasonably clear idea of what I wanted to build, sketch out the functions or architecture in my head, and then ask the model to help me implement it. That worked, and in many cases it worked very well.
But over time I noticed that the most useful conversations were often happening before I asked for code.
Start With The Problem, Not The Implementation
I have fallen into a pattern now where I rarely start by asking AI to build something. Instead, I describe the outcome I am trying to achieve and ask the model to interrogate the problem.
- What have I missed?
- What assumptions am I making?
- What constraints have I not considered?
- What are the standard patterns here?
- What other approaches could achieve the same goal?
Those answers often change the implementation before it starts.
That is the point. Once implementation begins, the work naturally starts to narrow. You make choices about frameworks, data models, APIs, screens, permissions, deployment, and operational behaviour. Each choice creates momentum. That momentum is useful, but it also makes it harder to question whether you are solving the right problem in the right way.
AI is particularly useful just before that happens, while the problem is still open enough to be reshaped.
The Subscriber Module Example
Recently I was building a simple subscriber module for this blog. In my head, the requirements were straightforward: capture email addresses from a form and send subscribers a weekly summary email. Functionally, I thought I had it covered.
Then I asked the AI what I was missing.
It immediately surfaced a set of things I had not properly considered: unsubscribe handling, GDPR consent flows, double opt-in confirmation, suppression lists for “do not market” requests, retention policies, and auditability around consent.
None of those were the feature I thought I was building, but all of them were part of building it responsibly.
The useful part of the exchange was not code generation at all. The AI was acting more like an experienced reviewer who had seen this kind of system fail before. It did not just help me build the thing faster. It changed my understanding of what the thing was.
That only helps if I am willing to take the review seriously. Not blindly accept every suggestion, but not dismiss awkward answers just because they make the original plan less convenient. If I ask what I have missed, I need to be prepared for the answer to change the shape of the work.
Expand Before You Commit
I have seen the same pattern repeatedly in development work. Sometimes AI identifies a cleaner design. Sometimes it suggests a simpler operational model. Sometimes it challenges whether the problem should be solved the way I originally imagined at all.
One of the most useful prompts I use now is:
What other viable approaches are there for achieving this goal, and what are the trade-offs?
That changes the interaction completely. Instead of treating AI as an implementation assistant, I start using it as a design partner. Not because it always knows the best answer, but because it is very effective at expanding the solution space before implementation narrows it again.
That pattern feels close to design thinking. Rather than converging immediately on a solution, I use AI to expand the problem space first: to explore assumptions, investigate alternatives, surface risks, challenge constraints, and examine trade-offs before narrowing back down to a practical MVP.
This is where the timing matters. If I ask the question after the system is half built, the answer arrives as rework. If I ask it before I start, it arrives as better judgement.
Keep The Scope Under Control
There is a danger in this, of course.
AI is relentlessly enthusiastic. It will happily suggest every enhancement, optimisation, integration, edge case, and governance concern imaginable. Left unchecked, a small MVP becomes an enterprise platform surprisingly quickly.
So I find myself playing two roles at once. First, the curious one willing to ask, “What am I missing?” Then the experienced one willing to say, “Yes, but not yet.”
That balance matters. I want enough exploration to discover better options, hidden constraints, and flawed assumptions. But I still need judgement, prioritisation, and restraint.
In practical terms, that means separating two activities that often get blurred together:
- exploration, where the aim is to widen the field of view;
- commitment, where the aim is to decide what will actually be built.
AI is very good at helping with the first. It can help with the second, but it should not own it. The final call still needs to come from someone who understands the context, the risk, the budget, the people who will maintain the thing, and the consequences of getting it wrong.
Open Wide, Then Close Deliberately
The pattern I keep coming back to is simple:
- describe the outcome before the implementation;
- ask what assumptions, risks, and alternatives need to be considered;
- explore several viable paths before choosing one;
- decide what belongs in the first version;
- only then start coding.
This does not make development slower. In my experience, it usually saves time. The cost of changing direction is much lower before there is a codebase, a database schema, an API contract, or a user interface to defend.
It also changes the role AI plays in the work. It is not just there to generate code from decisions already made. It is there to improve the decisions before they harden into code.
Open the problem space wide enough to learn something useful. Then close it again before the scope escapes.
For me, that is the most useful shift. AI is not just a faster way to produce the code I already had in mind. Used earlier, it helps me decide whether the code I had in mind is the right code at all.