How I Actually Use AI

Useful exactly where the output can be tested. Suspicious everywhere else. Here's where I let agents near real work, and where I don't.

I ship more code than at any point in my career, and I write a smaller share of it than I ever have. Both are true. Neither is the interesting part. And the usual stories about AI, the ones where it replaces developers or where it's a toy you can't trust, don't describe my week at all.

Code is the one output you can check

There's a reason coding is where AI is landing hardest, and it isn't that models are somehow better at TypeScript than at prose.

Look at the outputs where the models arrived and the work got worse. AI writing is fluent and says nothing. AI images have the plastic sheen and the light coming from nowhere. AI video drifts between cuts. You clock all three in about a second and can rarely name what gave it away. You feel it before you can point at it, and a feeling is not a test.

Code is different because code is specced to an output. It compiles or it doesn't. The tests pass or they don't. The migration returns the row count you expected or it doesn't. The check is mechanical and gives the same answer every time. That's the difference between generating code and using a tool that made the typing faster.

The fleet

Here's the frame that survived contact with real work: AI is a fleet of junior developers.

A junior developer is genuinely useful. Fast, tireless, happy to take the ticket nobody wants. Give one a well-scoped task and enough context and you get working code back the same day. What you don't do is merge it unread.

That's the entire model. I run several coding agents in parallel: one refactoring, one on a migration script, one chasing a bug. Every one of them hands work back for review. I can direct three or four workstreams in the time one used to take, but every line still passes through review, same as any junior's PR. The bottleneck moved from writing code to scoping work and checking it.

That's a management job. It turns out management scales better than typing.

Scripts that were never worth writing

The change I feel most day-to-day isn't the big features. It's the manual jobs.

Every developer carries a list of tasks that were technically automatable but never worth it: renaming a pattern across two hundred files, munging an export into a different shape, pulling one answer out of a pile of logs. The script would take an hour to write and save twenty minutes, so you did the job by hand, forever.

That math is dead. An agent writes the script in minutes. I read it, test it, run it, and keep it.

They all go in one directory. Some get reused as-is. Some are a baseline for the next job shaped like them. And all of them are context: point an agent at that directory and it can read how I test, what I check before trusting a result, and what my tooling actually looks like. The scripts document my methodology better than a style guide would, because they are what I actually did rather than what I said I do.

The threshold for "worth automating" collapsed, and a whole category of work I used to grind through went with it. The same move scales: most tooling and automation jobs are a process someone has run by hand for years, written down once and made repeatable.

The line I don't cross

Notice what both of those have in common: the model writes the automation. It is never the automation.

I wouldn't hand a live process to an AI and walk away, leaving an agent to make fresh decisions on every run, unattended. Scope drift is real: give a model an open-ended standing job and its interpretation of that job wanders. Context loops are real: agents wedge themselves into corners and burn cycles re-deciding things they already decided. Anyone who has run agents on real work has watched both happen.

An agent that writes a script is different in kind, not just degree. The script is deterministic. It does the same thing every run. I can read it, test it against real cases, and know exactly what it does before it touches anything. The model's judgment gets exercised once, at build time, with me standing there to check it. It doesn't get re-exercised forever at runtime, where I'm not.

Put the model in the build loop. Keep it out of the run loop.

Lines of code were never the constraint

Call the tool what it is: a line-of-code multiplier. Point it at a codebase and code comes out faster than any team could type it.

But producing lines of code was never the real constraint on shipping good software. The constraints were always clean architecture and solid testing: knowing what to build, structuring it so it can change, proving it works. Those were the scarce skills before AI, and they're scarcer now, because a multiplier amplifies whatever you point it at. Good architecture and real tests get multiplied. So does mess.

The developers who get the most out of this era won't be the ones with the best prompts. They'll be the ones who were already good at the parts that were never about typing.

If you're curious what one of these builds looks like up close, the MCP server post walks through a real one. And if you've got a manual process that deserves to be a script, let's talk ↗︎