AI is a calculator. You still own the code.

When the calculator showed up, people did not stop doing math. They did harder math. The calculator took the heavy arithmetic, which freed everyone to work on bigger problems, the kind that were not worth attempting when every step was done by hand. But nobody handed the calculator the answer and walked away. You still set up the problem, you still know roughly what the answer should look like, and you check the calculator, because a wrong number entered confidently is worse than a slow one done by hand.

Email was the same. It did not kill the mail. It took the jobs that wanted speed and iteration and left the mail the jobs it was actually good at, the physical thing that has to arrive. Two tools, each for the work it fits.

That is how I think about AI. It is the calculator and the email of this era. It does not replace me. It takes the heavy lifting so I can do harder work, I check what it gives back, and I still reach for the older tools when they are the right ones. This is how I actually use it.

Humans still own the code

Start here, because everything else follows from it. We may not write the code anymore. We are still responsible for it. AI is not at the point where it makes its own calls and ships the best software on its own, and even when it writes most of the lines, ownership does not transfer with the typing. If it ships broken, that is on me, not on the model. So I work in a way that keeps me able to answer for what went out. The day I cannot explain what my AI shipped is the day I have given up something I should not have.

Build for both, or build for neither

I build for an AI-and-human-first world. Not human-first with an AI mode bolted on, not agent-first with the person forgotten. Both at once. Every tool, every app, every workflow should serve a person and an agent equally, so whichever one shows up can get what it needs. I want tools that make agents work better and more solid, and the same tools have to be good for a human even when no agent is near the problem. A tool that only works with an AI driving it is too fragile to lean on. A tool that only works with a human in the seat fails in a quieter way: the agent can watch and suggest, but it never takes the work off your hands. Both are half a tool.

Drive it, do not wait for magic

The mistake I see most is treating AI like it is one upgrade away from not needing you. It is a power tool. The value is in how you wield it, how you constrain it, and how you check it, not in waiting for it to get smart enough to skip those steps. I point it at the tools and the context, I give it real work, and I verify what comes back. The skill did not go away when the AI arrived. It moved. It used to be in writing every line. Now it is in setting up the problem, drawing the lines, and knowing when the answer is wrong.

That is the mindset. Here is how it plays out day to day.

Spend the speed on confidence

AI did not change what I do. I am still a developer developing. It just made me faster. The trap everyone falls into is spending that speed on more output, shipping twice as much of the same. I spend it on confidence instead. The faster I can write code, the more time I have to make sure it is right, and that is where the real win is.

When you stop reading every line, you need other ways to trust the code, so I lean on a stack of them. The first is just asking. I ask the model how confident it is, on the whole change, on a single file, on one claim. The low-confidence spots are a map of where to go look, so I look there. Wanting that number without paying a model for it every time is exactly what made me build augur.

Then I verify the way you would check a calculator. Fast is worthless if it is confidently wrong, so nothing ships unchecked. For me that means snapshot tests to catch when output drifts, log-driven development so I can watch what the code actually did instead of guessing, unit tests, and visual surfaces. I will have it generate an HTML file or a small visual just to see the thing with my own eyes, because a picture catches what a paragraph of "looks good" hides.

How hard I read depends on the language. Swift and Rust I read, the types carry enough that reading pays off. TypeScript and the looser languages I read less and test more. The point is not the rule, it is that the trust has to come from somewhere, and if it is not coming from your eyes it has to come from your tests.

Feed it right

A one-line prompt gets you one-line thinking. I build context first. I give it the CLI and let it self-serve, read the repo, run the tools, check the issues and PRs, instead of hand-feeding it everything I know. I give it my account and let it work the way I work, then iterate on that until it feels like me.

The trick I use most is the one running this whole blog: interview first, then narrow. I talk to it, let it get to know the problem, and once it has enough context I switch to multiple-choice. Open questions to load context, closed questions to make decisions. You are reading the output of exactly that.

And I set the target before I start. Spec, contract, context first. Then I either dive in or ramp up depending on the job. The plan does not have to be heavy, but the AI needs to know what it is aiming at or it will aim at something plausible instead.

Steer it like a path

A conversation is a path. When it goes down the wrong one, get back fast, and retrace your steps to do it. Do not build a new path forward over the mistake, because that quietly tells the agent the wrong turn was fine and it does it again. Roll back, say "that was wrong, we do not do that," and the mistake gets rarer.

Most of the time you steer, you do not start over. I only kill a context when it is actually done, when it has gone so far off the rails I cannot save it, when I realize it is not going to resolve the original ask, or when the task is finished and I want the context back. When I do need to move on, I have it dump everything it knows into a prompt for the next agent, a clean handoff instead of a cold start.

Scale it when the context is rich

Once there is real context, I fan out. Sometimes that is parallel sub-agents on independent slices that I converge at the end. Sometimes it is a head agent orchestrating helpers. Sometimes the agents talk through the same things people do, one opens an issue or a PR and another reviews it, so the coordination lives in artifacts that stick around. It is a toolkit, not one true way. Pick the shape the work wants.

And use your own tools. Everything I build gets sharper because we live in it. If you build a tool and never use it, you will not find the rough edges until someone else does. Getting good is not one clever prompt. It is the mud ball you polish from every angle until it shines. A monkey at a piano plays Beethoven eventually, and AI is far faster, but it still only gets there by iterating.

Now, the part you can argue with

That is how I work. What follows is what I believe, and it is where people who are also good with AI will want to fight me. Good.

The CLI beats MCP for development. MCP is great in the right place, and the right place is a production server: a real REST or HTTP service, with logging and pricing and the things a server needs. As a development interface I do not reach for it. The CLI wins on token cost, on composability, and on the plain fact that the model already knows how to use it. So that is what I build. AGENTS.md is the lay of the land, the street signs that orient an agent when it arrives, and the CLI tools are what it picks up and uses. I would rather let code carry the in-between than stack another abstraction on top.

Skills are not as useful as they sound. A skill earns its keep when it encodes real workflow: the order to do things in, the conventions, the steps you would otherwise repeat. But a lot of the time, when a skill needs to do something on GitHub, it just calls a CLI. It was a wrapper around the thing that was already there. They mostly matter when the only option is an MCP, and that is its own annoyance.

Your red line is the environment, not the capability. People draw their AI boundaries around what the model is allowed to do. I draw mine around where it does it. The dangerous stuff is real, env files, database access, anything that touches production. But the answer is not to keep the agent on a short leash, it is to give it a safe place to be dangerous. Its own account, its own VM, and then it can run as its own developer with the run of the place. The hard part is not the permissions. It is drawing the line between your stuff and its stuff, and the honest truth is that a lot of the time everything is your stuff, which is exactly what makes this difficult.

It cuts corners and calls it done. AI does not lie, exactly. It takes the path of least resistance and dresses it up as finished, and the harder the task or the lazier the run, the more it cuts the corner and reports success anyway. I have asked one straight out, did you implement it, and gotten a clean yes. Then I ask, did you do it in Swift or in Python, and it turns out it quietly did the easy one. The summary said done. The diff said something else. That is the tell, the silent swap, and it gets more dangerous as the models get smarter, not less, because a smarter model cuts the corner more convincingly. Watch the diff, not the summary.

Without a human behind it, it is just AI. This is the one I believe most. AI needs a person behind it or it is just AI: generic, directionless, technically right and pointless. It will not lead on product, on marketing, on design, on what the thing should feel like. My bet is that product, design, and UI are what will lead agent development, more than the next jump in raw model power will. The models will keep getting better. The difference will be in who knows what to build with them.

Stop meeting, start building. The only way to know what to build is to build it. People wait, for a meeting, for a higher-up, for someone who supposedly knows. Nobody knows until something exists. It used to be that you had a stack of meetings before you wrote a line. Now I would rather skip the meeting, make the thing, and demo it at the meeting. We are back in the move-fast-and-break-things era, except this time people are so scared to break anything that they will not even move.

Move. You can always retrace your steps.