AI is not a code generator, it's a thinking partner

After more than 20 years of development, I didn't expect an AI assistant to still change the way I design code.

At first, I used it like most people do: "Write me this class", "Write this test", "Optimize this method". It was compelling.

Then I caught myself a few times accepting suggestions almost without challenging them. I was saving time, but I also felt like I was thinking less. That bothered me.

Describing the problem instead of asking for a solution

A few months ago, I was working on a validation rule around a counterparty's risk limits. Instead of directly asking for an implementation, I simply described the business context: the rules to respect, the constraints, the edge cases.

Its first proposal wasn't what I would have shipped to production. But its reasoning genuinely interested me. It suggested a different approach, one I wouldn't have thought to use. It wasn't the right answer, but it was an argued enough answer to deserve a conversation.

That's when the conversation became interesting.

 describe the      AI's first        question the       keep or
 problem      ───► proposal     ───► reasoning      ───► reject,
 (context,                           (why, what if,       justifying
 constraints)                        how)                 it
      ▲                                                      │
      └──────────────── iterate if the answer ◄──────────────┘
                         doesn't hold up

The questions that make the difference

I started asking questions instead of simply accepting or rejecting the answer:

• Why this approach rather than another one?
• What happens if the business rules change in six months?
• How do we test this logic if an external service becomes unavailable?
• Are we over-engineering the problem?

Sometimes its answers make me completely rethink my approach. Sometimes it's the opposite: it proposes an architecture far too sophisticated for the actual need. What matters isn't whether I accept the answer, but understanding why I keep it, or why I reject it.

That's probably what struck me the most about this practice.

What it changes in how I review code

That same reflex ended up bleeding into how I do code reviews, AI or not. Facing a pull request, I now catch myself asking a human developer the same questions I'd ask an assistant: why this approach, what happens if the context changes, has the edge case been checked. That's no coincidence: challenging a piece of reasoning, whether it comes from a model or a colleague, relies on the same discipline. AI became a low-stakes training ground, without the relational cost, for a skill I then use with humans.

A partner, not an executor

Today, I see AI as a thinking partner, not a code generator. If a conversation hasn't led me to question a design choice, I usually feel like I missed something.

Looking back, I realized something: the quality of the answers depends far more on the questions I ask than on the model being used. The model sets the ceiling, but it's our engineering posture that lets us reach it. A developer who accepts the first answer without challenging it will never get what the same tool can deliver in the hands of someone who insists on understanding the why before the what.