When I wrote my last article about whether developers should still learn programming in the age of AI, I expected people to debate syntax, programming languages, and jobs.
Instead, the comments took the conversation somewhere much more interesting.
Someone made a point that I haven't been able to stop thinking about.
We've spent decades building processes to review code.
We have code reviews.
We have QA.
We have unit tests.
We have integration tests.
We have security reviews.
But AI has exposed a review process we barely have.
Who reviews whether we're solving the right problem?
That question has stayed with me because I think it points to the biggest shift AI is creating in software engineering.
We know how to review code
Imagine a feature has just been completed.
The pull request is opened.
The code is clean.
The naming is good.
The architecture looks sensible.
The tests pass.
The application works.
Most engineering teams would call that a successful implementation.
But there is another question we often forget to ask.
Was this the right thing to build in the first place?
That isn't a code review problem.
It's a thinking problem.
AI has changed the cost of implementation
Before AI, implementing a feature took time.
Writing boilerplate.
Looking up documentation.
Fixing syntax errors.
Refactoring.
Testing.
That friction wasn't always enjoyable, but it forced us to think.
Today, AI can produce a working implementation surprisingly quickly.
That's incredible.
But it also means the bottleneck has moved.
The expensive part is no longer writing code.
The expensive part is making good decisions.
A bad idea that once took two weeks to implement can now become a polished feature in an afternoon.
The speed is impressive.
The risk is that we're now able to build the wrong thing much faster.
Good code can still solve the wrong problem
This is the part I think many developers are beginning to experience.
AI doesn't usually fail because it writes ugly code.
It often fails because it confidently solves the problem you gave it, even if that wasn't the problem you should have been solving.
I've seen this happen while building products.
You ask for a feature.
The implementation is technically correct.
The code is clean.
The tests pass.
Then a real user tries it.
Immediately they do something nobody considered.
Or they use the feature differently from what everyone assumed.
Or they reveal that the original problem wasn't actually the one worth solving.
The implementation wasn't the mistake.
The assumptions were.
We review execution more than direction
One comment on my previous article summarized it perfectly.
We're mostly evaluating execution against a decision we've already accepted.
That sentence changed how I think about AI-assisted development.
Most of our engineering practices happen after we've already committed to a direction.
We ask:
- Is the implementation correct?
- Is it secure?
- Is it performant?
- Is it maintainable?
Those are important questions.
But they all assume something.
They assume the original decision was right.
Maybe we need a new engineering habit
I'm starting to think that before writing code, we should spend more time writing something else.
Not implementation notes.
Not architecture diagrams.
Assumptions.
Questions like:
- What problem are we actually solving?
- What assumptions are we making?
- What evidence supports those assumptions?
- What trade-offs are we accepting?
- What would prove this decision was wrong?
That last question is my favourite.
What would prove this decision was wrong?
It's uncomfortable because it forces us to admit we might be mistaken before we've written a single line of code.
But that's exactly why it's valuable.
AI shouldn't review its own homework
This also changed how I think about documentation.
I love using AI to help organize ideas.
I use it to refine documentation.
I use it to improve clarity.
But I've become more aware of something.
If the same context creates the idea, explains the idea, and validates the idea, we haven't really introduced another perspective.
We've just made one perspective more efficient.
Good documentation shouldn't only explain why we chose something.
It should also expose what could make that decision fail.
That's the part another engineer can challenge.
That's where real discussion begins.
Great engineers think about failure early
When I was learning to code, I thought engineering was mostly about making things work.
The longer I've built software, the more I've realized good engineering is often about understanding how things fail.
What happens if the payment succeeds but the email doesn't?
What happens if the user clicks the button twice?
What happens if two requests arrive at the same time?
What happens if the network disappears halfway through?
AI can help generate code for those situations.
But it still takes engineering judgment to recognize that those situations exist.
Maybe this becomes our new advantage
As AI continues to improve, writing code will become less of a differentiator.
Thinking probably won't.
The developers who stand out won't just be the ones who can prompt an AI effectively.
They'll be the ones who consistently ask better questions before the prompt is ever written.
Because once you've pointed AI in the wrong direction, it's remarkably good at getting there quickly.
Final thought
I don't think AI is replacing software architects.
I think it's making architecture more important.
Not architecture in the sense of boxes and arrows.
Architecture in the sense of making good decisions before implementation begins.
We've become very good at reviewing code.
Maybe the next discipline software engineering needs is reviewing the thinking that comes before the code.
Because if AI has made implementation cheap, then judgment has just become one of the most valuable skills we have.
Disclosure: I use AI as a writing partner to help organize ideas and improve clarity. The opinions, experiences, and technical decisions expressed here are my own.
Top comments (0)