For a long time, I used AI in software development for one primary purpose: Write the code.
Give it a requirement.
Get some Python.
Ask for a function.
Get a function.
Describe an API.
Get an API.
It was fast. Sometimes impressively fast.
But recently, I've been using AI differently.
Instead of asking:
"Can you write this for me?"
I've started asking:
"Can you review what I wrote?"
And the difference surprised me.
AI wasn't just helping me write code faster.
It was helping me look at my own code differently.
The Problem With Asking AI to Write Everything
There is an obvious benefit to AI-generated code.
You can move from an idea to a working prototype extremely quickly.
But there's a downside.
When AI writes the code, I can become focused on whether the code works rather than whether the code is actually good.
It is very easy to accept:
It runs → Ship it.
But software engineering doesn't end when the program runs.
What happens with unexpected input?
What happens when the API fails?
What happens when the database is unavailable?
What happens when the data is empty?
What happens when another developer has to maintain it six months from now?
Those questions are much harder to answer by simply generating more code.
That's where code review becomes interesting.
So I Tried a Different Workflow
Instead of starting with AI, I started with myself.
I wrote the code.
Then I asked AI to review it.
My prompt was intentionally simple:
Review this code as a senior software engineer. Don't rewrite it immediately. First identify potential bugs, edge cases, security concerns, maintainability problems, and unnecessary complexity. Explain why each issue matters.
That last sentence matters.
I didn't want AI to immediately produce another 100 lines of code.
I wanted it to think about the code first.
It Found Things I Hadn't Considered
Some findings were obvious once pointed out.
Others were not.
For example, a function might work perfectly for normal input but behave incorrectly when it receives: None of these necessarily appear during a quick manual test.
And that's the interesting part.
A second reviewer doesn't need to discover something magical.
Sometimes it simply needs to ask:
"What happens if this assumption isn't true?"
That question alone can expose a surprising number of problems.
But AI Didn't Always Get It Right
This is where things get interesting.
I don't treat AI's review as truth.
Sometimes it identifies a genuine issue.
Sometimes it identifies something that isn't actually a problem.
And sometimes it suggests a change that would make the code more complicated without providing meaningful value.
This is exactly why I don't think AI replaces code review.
It changes the review process.
The developer still has to decide:
Is this actually a problem? How serious is it? Is the suggested solution appropriate? What trade-off does it introduce?
AI can point at something.
It cannot automatically decide whether changing it is worth the cost.
The Most Useful AI Review Isn't "Fix My Code"
I've noticed a subtle difference between two prompts.
Prompt 1
Fix this code.
Prompt 2
Review this code and tell me what I should worry about.
The first asks AI to become the programmer.
The second asks AI to become the reviewer.
I find the second approach much more interesting.
Because it keeps me involved in the reasoning.
Instead of outsourcing the entire task, I'm using AI to increase the number of perspectives looking at the problem.
I Wouldn't Use AI as the Only Reviewer
There are still things AI may not understand.
It might not know why a particular architectural decision was made.
It might not understand the business requirement.
It may not know which performance trade-off is acceptable.
It may flag code that looks unusual but is intentionally designed that way.
And it can confidently make incorrect claims.
So I think of AI code review as another layer.
Something like:
Developer writes code
↓
Automated tests
↓
AI review
↓
Human review
↓
Production
↓
Monitoring
Each layer answers a different question.
Tests ask:
Does the software behave correctly for the cases we've defined?
AI review asks:
What problems might we have overlooked?
Human review asks:
Does this implementation make sense in the real system?
Monitoring asks:
What happens after real users start using it?
No single layer is enough.
There's Another Benefit I Didn't Expect
AI reviewing my code has also changed how I write code.
When I know I'll eventually ask an AI to review something, I become more deliberate about my implementation.
I think more about:
In other words, the reviewer starts influencing the author.
And that's a useful side effect.
The goal isn't simply to have AI catch mistakes.
The goal is to become better at anticipating mistakes before they happen.
This Applies Beyond AI-Generated Code
There's a temptation to think AI code review is useful only when AI generated the original code.
I don't think that's true.
Human-written code has bugs.
Human-written code has assumptions.
Human-written code becomes difficult to maintain.
Human-written code gets reviewed by people who are tired, rushed, or unfamiliar with the particular problem.
A second perspective can be valuable regardless of who wrote the original code.
AI is simply an unusually fast second perspective.
But Don't Confuse Review With Testing
This distinction is important.
AI can tell me:
"This function may fail when the API returns an empty response."
That's useful.
But a test can actually execute the scenario.
For example:
`def test_empty_api_response():`
response = process_api_response([])
assert response == expected_result
The two approaches complement each other.
AI can help identify what to test.
Tests can verify what actually happens.
That's a much stronger workflow than relying on either one independently.
I've written before about how developers routinely test traditional software while treating AI behavior differently. I think the same principle applies here:
AI should become part of an engineering discipline, not a replacement for it.
The Bigger Lesson
The most interesting change isn't that AI can review code.
We've known that AI can analyze code.
The bigger change is that we can now cheaply introduce additional reasoning into our development process.
A developer working alone can effectively have another pair of eyes available within seconds.
That doesn't mean the second pair of eyes is always correct.
It means the cost of asking for another perspective has become extremely low.
And when something is cheap enough, we can incorporate it into our workflow.
I'm Changing How I Use AI for Coding
I still use AI to generate code.
It would be silly not to take advantage of that capability.
But I don't want my relationship with AI to become:
Human thinks → AI writes.
I'd rather have:
Human thinks → AI helps build → AI challenges → Human evaluates → Tests verify.
That is a much healthier development loop.
Because the objective isn't to remove the developer from the process.
It is to make the developer better at the process.
Maybe AI's Best Coding Feature Isn't Code Generation
We spend an enormous amount of time talking about how quickly AI can write code.
I'm starting to think another capability deserves more attention:
AI can challenge the code we already wrote.
It can ask questions we didn't think to ask.
It can point toward assumptions we forgot we were making.
It can identify edge cases hiding behind apparently simple functions.
It can suggest tests.
It can act as a tireless second set of eyes.
But there is an important condition:
We still have to think.
If we blindly accept AI-generated code, we haven't improved the engineering process. We've simply accelerated it.
And accelerated bad decisions are still bad decisions.
So perhaps the better question isn't:
"How can AI write more of my code?"
Maybe it's:
"How can AI help me become a better engineer?"
That's the question I'm increasingly interested in.
How are you using AI in your development workflow today, primarily as a code generator, debugger, reviewer, teacher, or something else?
Want More:
Head over to ReThynk AI to access our latest research, magazine articles, and developer resources. Click Here