How I Use AI as a Senior Engineer: Where the Day Actually Goes

Everyone wants the tools list. The tools list is the least interesting part.

The tools changed three times this year. What stayed constant is more useful to write down: where the hours go now, what I hand off, and what never left my desk. The work underneath spanned infrastructure, applications, this site, and creative systems that have nothing to do with my day job, and the same shape held across all of it.

The day, roughly

Mornings are for specs. Before agents, my morning was often the first implementation push of the day. Now it is writing: what needs to exist, what done looks like, what the constraints are, what the agent should not touch. A good spec takes twenty minutes and saves three hours. A lazy spec costs you the afternoon, because the agent will build the wrong thing with great competence and you will read all of it before you find out.

Then the delegation. Several pieces of work running at once, each one scoped so it can fail independently. This is the part that genuinely did not exist before. One stream is a migration, one is a bug, one is a draft of something I am not sure about yet. Multiples of output. The constraint stops being my typing speed and becomes my attention.

Afternoons are batch review. Everything the agents pushed to staging gets read in one sitting, with the three-pass review I described in my AI code review workflow. Batching matters more than it sounds. Context-switching between writing specs and reading diffs all day shreds both. Separating them keeps each one sharp.

What I hand off

The pattern under everything I delegate: work where the destination is known and the path is mechanical.

Migrations. Scaffolding. Test coverage for code that already works. Sweeps across a codebase, the kind where the same change needs to happen forty times with small variations. Config plumbing. First drafts of documentation. The bottom ninety percent of any task whose top ten percent I care about.

I also hand off investigation, which surprised me. "Find every place this assumption appears" is agent work now. The agent reads faster than I do and does not get bored on file thirty. What it brings back still needs my eyes, but the gathering is no longer my job.

What stays

Deciding what to build. That one never moves. The cost of writing code fell through the floor and the cost of knowing what to write did not budge, which is the whole story of how AI is changing software engineering compressed into one sentence.

Naming. Architecture. The judgment call on whether a change belongs at this layer or two layers down. Taste, which sounds soft until you watch its absence compound across a hundred agent-written diffs. And reading, though what reading means at this volume is worth saying. There is more shipping than any one person reads start to finish: the code, the configs, the ADRs, the prompts, the docs. So reading turned into triage. I read the places where a mistake is expensive and the seams where pieces meet, and for the rest I lean on the systems that read for me, the tests, the gates, the second agent whose whole job is to find what I would have missed. What I will not do is stop reading my own systems entirely, because the mental model is the part I cannot hand off, and a model you have stopped maintaining quietly rots.

What it costs the body

There is a physical cost to working at this multiple. The pressure behind the eyes after a long parallel session, the way the speed bends your sense of time. I wrote about it honestly in Working at the Frontier, and I bring it up here because no workflow advice is complete without it. Water. Breaks. The heat is information. Work near the forge without standing in the fire.

What the job is now

The thing I keep coming back to is that the agents did not compress the experience ladder. They moved it.

Anyone with agents can produce volume. Producing volume that holds up takes something the model does not have yet: a verification instinct, the kind you only earn by watching systems fail in production and being the reason a few of them did. I do not think that makes me special. It makes me someone who has made enough of the mistakes to feel the next one coming. Applied to ten times the throughput, that instinct is most of the job now: less producing, more conducting, and the conductor is responsible for every note, including the ones an agent played.

The cognitive load is real and it is different from the old load. I wrote about that trade in The Cognitive Cost of Modern Software Engineering. The short version: you trade the strain of producing for the strain of judging, and judging all day is its own discipline.

The work on the work

One more thing stays, and I underrated it at first. The way I work is not a method I arrived at and locked. It is a system like any other, which means it leaks, so I study it and refactor it the way I would refactor code. The specs, the review passes, the ADRs that record why a decision went the way it did, the gates that catch my own mistakes before they ship, all of it keeps getting revised. A lot of that revision now happens in agent mode too. I point an agent at my own process and ask it where the process breaks. Leveling up the work and leveling up the way I do the work turned out to be the same activity, and I am nowhere near finished with either.

If you want the operating manual version of all this, it is in The AI-Assisted Engineering HOWTO, the working method for directing an agent through your repo is in Agentic AI Development, the tool question I get asked about most is settled in Claude vs Copilot for DevOps, and the full hub of this work lives at AI development. The honest place to start, though, is smaller: pick one mechanical task tomorrow, write a real spec for it, hand it off, and read the change that comes back, the costly parts first. The workflow grows from there.