I have agents running while I make a cup of tea. One refactoring a service in Task Board, one writing test cases in TestPlan, one chewing through a CSS problem I have already given up on understanding. I am, by any reasonable definition, an AI-first developer now. The sceptic who spent two years rolling his eyes at the whole thing has been thoroughly, embarrassingly converted.
Which is exactly why I want to write this one. Because the people who tell you to use AI for everything are usually selling something, and the people who tell you to use it for nothing stopped paying attention around 2023. The interesting question is not whether to use it. It is where the line sits for someone who genuinely reaches for it first. And I have a list of jobs I keep it well away from, not out of nostalgia or principle, but because I have been burned often enough to know better.
The change that is faster to type than to describe
Here is the one nobody warns you about. You get so used to prompting that you start prompting for things you could have just done. I caught myself the other day writing a paragraph of instructions to change a hardcoded margin from 16 pixels to 24, with the file path and the class name and a polite request not to touch anything else. That is maybe forty seconds of typing. The change itself was four keystrokes.
There is a real category of work here, and it is bigger than you think. Renaming a variable in a file you already have open. Flipping a boolean default. Adding a property to a model when you can see the class on screen. If you can describe the change faster by making it than by explaining it, making it is the correct tool. The prompt-for-everything reflex is genuinely worse for these, because now you are also reading the diff to confirm it did the thing you could have done with your own hands in less time. I'll be honest with you, this is the one I still slip on most. The convenience is a habit, and habits do not check whether they are earning their keep.
The why is mine. Always.
AI is extraordinary at the how. Given a clear instruction it will execute faster than I can, more consistently than I can, and without getting bored on the fortieth near-identical endpoint. What it cannot do, and what I will not let it do, is decide what we are building or why.
When I was naming the Forest School App, I did not ask for forty name suggestions. I sat with what Sarah actually needed it to feel like to a parent at the gate on a wet Tuesday, and I named it. When I decide a feature in TestPlan should suggest test cases rather than just store them, that is a product call about what testers are actually short on, which is time and ideas, not storage. An AI will happily generate a roadmap. It will be a plausible, generic, average roadmap, because it is built to produce the most likely next thing, and the most likely next thing is by definition not a differentiated product.
The human is the product manager. The AI is the most capable junior you have ever worked with, and like every junior, it should not be setting the vision. The moment you outsource the why, you ship something that looks like everyone else's something. I have written before that the human stays the product manager, and naming and direction are the purest version of that. It is the part that is supposed to be hard, and the difficulty is doing its job.
Stateful debugging, where loading the context costs more than it saves
This is the one that surprises people who assume AI is best at exactly the hard stuff. Some bugs are not about the code in front of you. They are about a sequence of things that happened in a particular order, in a particular bit of state, in a session that started ten minutes ago. A race condition in CoSurf's real-time sync. A MongoDB query that is fine in isolation and catastrophic only after a specific document got into a specific shape.
To use AI here I have to load it with the context, and the context is the entire problem. By the time I have explained the state, the timing, what I have already ruled out, and which three things looked guilty but turned out innocent, I have done the thinking that solves the bug. The explaining is the debugging. And there is a second trap, which is that a bug it kept re-introducing taught me the hard way: an agent without the full history will confidently undo the exact fix you just made, because from where it is sitting the fix looks like the anomaly.
When the bug lives in the state rather than the source, I am usually better off with a debugger, a notepad, and my own short-term memory than with anything I have to bring up to speed first. The context window is not just a limit on what the AI can hold. It is a limit on how much of the problem you can afford to re-narrate before you have effectively solved it yourself.
Anything I would not be comfortable owning blind
There is a class of change where being right matters more than being fast, and where being wrong is expensive or permanent. Auth and permissions. Anything touching payment flows. A migration that rewrites data in a way I cannot cleanly reverse. A query that runs a delete against production-shaped data.
The issue is not that AI gets these wrong more often than I do. Honestly, on a good day it gets them wrong less often. The issue is ownership. For irreversible or security-sensitive work, I want to understand every line well enough to have written it, because if it goes wrong at two in the morning I am the one explaining it, not the agent. Reviewing AI output gives you a softer kind of knowledge than writing it does. It feels like understanding, and for most code that is fine. For the code that can lose someone's data or let the wrong person in, fine is not the bar.
So I still write that stuff by hand, slowly, with the boring caution of someone who has been doing this for nearly twenty years and has the scars to prove caution is cheaper than the alternative. I will use AI to write tests around it. I will not use it to write the thing the tests are protecting.
Learning something I do not yet understand
This is the subtle one, and the one I feel most strongly about. When I am picking up something genuinely new, a corner of the .NET runtime I have not needed before, a Blazor rendering behaviour that is biting me, I deliberately do not let the AI hand me the answer.
Because if it hands me the answer, I get a working result and no understanding, and understanding is the thing I am actually trying to acquire. Next time the same shape of problem turns up I am right back where I started, asking again, never building the model in my own head that lets me reason about it. Outsourcing the answer is fine. Outsourcing the understanding is a slow way of staying junior forever.
That sounds a lot like a productivity sacrifice. It is not. It is an investment, and the return is that six months from now I make a hundred small decisions correctly and instantly because I actually grasp the thing, rather than stopping to prompt each time. I will use AI to check my understanding once I have built it. I try very hard not to use it to skip building it.
The line keeps moving, and that is the point
Here is the thing though. Every category I have just listed is provisional. The small-change line moves as voice input gets faster. The debugging line moves as context windows get bigger and agents get better at holding state. A year ago I would not have trusted an agent with a multi-file refactor, and now I kick one off without thinking. Nobody writes about this part, but the honest position is that the boundary is a moving target and pretending you have it pinned down is just a different flavour of not paying attention.
So I do not have a rule. I have a question I ask myself in the moment, and it is roughly this. Does using the AI here cost me more in context, ownership, or understanding than it saves me in time? If describing the task takes longer than doing it, I do it. If getting it wrong is expensive or permanent, I own it. If the point is to learn the thing, I learn the thing. Everything else, and it is genuinely most things now, I happily hand off.
The conversion was real. I am not walking any of it back. But being AI-first does not mean AI-only, and the developers who will be worth working with in five years are not the ones who use it for everything or the ones who refuse to touch it. They are the ones who can tell you, specifically and without flinching, the handful of jobs they still do themselves and exactly why. That list is short. It should never be empty.
