“I stopped trying to make AI write my code. That’s when it actually became useful.”

Question

Tell us a bit about your context — what kind of work do you do, and what does your team look like?

I’m a senior backend engineer, primarily working in Python and Go. I work across a mix of internal platform work and client-facing API development — the kind of codebase that has been around long enough to have decisions in it that nobody fully remembers making. The team is mid-sized, distributed, mostly working in two-week sprints with async code review.

Question

How has AI tooling changed the way you work — and I mean specifically, not in general?

The honest answer is: it changed my planning more than my coding.

Early on I tried to use it the way everyone talks about it — generating functions, completing code, that sort of thing. And it worked, up to a point. For greenfield work, new utilities, writing tests for well-understood functions, it was genuinely fast. But for anything in our actual codebase — where there are implicit rules, dependencies that aren’t obvious from the code, performance constraints that live in someone’s head — the output was plausible but subtly wrong often enough that I stopped trusting it.

What changed things was starting to use AI before I opened my editor. I use it to think through the problem first — what are the edge cases, where are the likely failure modes, what have I not considered. By the time I’m writing code, I’ve already surfaced the ambiguity. That’s where I get the time back. Not in the typing.

Question

What is AI consistently bad at, in your experience?

Our codebase. Specifically, the parts that require understanding why something was built a certain way, not just what it does. AI is very good at reading code and describing it. It is not good at understanding the decision history behind it. When it suggests a refactor, it often optimises for the code in front of it without knowing what constraints drove the original design. That is a meaningful limitation for anyone working on a system with real history.

It is also bad at knowing when to stop. It will produce an answer before it has enough context, and the answer will look confident and be wrong. You have to learn to slow it down.

Question

Was there a point where you nearly gave up on it?

About six months in. I was spending more time fixing AI output than I would have spent writing the code myself, and I had started to feel like I was fighting the tool rather than working with it.

The shift came from watching a colleague use it in a completely different way. She wasn’t asking it to write code at all. She was having a conversation with it about the problem — almost like rubber-duck debugging, but the duck talks back. The code came after, and it came quickly, but that wasn’t the point. The point was that she had a much clearer picture of what she was building before she started building it. I changed my approach after that, and things got better relatively quickly.

Question

What would you tell a developer who is still figuring this out?

Start with the problem, not the solution. Before you ask AI to write anything, ask it to help you understand what you’re actually trying to do. Explain the context, the constraints, what you’ve already tried, what you’re uncertain about. You will get better output, and more importantly you will catch the gaps in your own thinking before they become bugs.

Also: treat AI output the way you’d treat code from someone you don’t know yet. Review it properly. Don’t skip that step because it came quickly.

Question

What do you wish engineering managers understood better about how AI-native developers actually work?

That the value isn’t in code volume. If you’re measuring AI benefit by lines of code or tickets closed, you’re measuring the wrong thing, and you’re creating pressure to skip the verification step that makes AI output trustworthy.

The developers getting the most from these tools are the ones who have built new habits around them — better planning, better review, better documentation. Those habits make the whole team faster, not just the individual. That is the thing worth looking for when you’re hiring.