AI-first engineering workflows for senior ICs

These are working notes, not a finished essay. I keep revising them as the tools change, which is often. The only thing that hasn't changed in eighteen months is the core question: where does the human add value when the machine writes the first draft of everything?

The two modes that matter

I switch between two modes, consciously. Most of my bad AI days come from being in the wrong one.

1. Drafting mode. The model is fast, I'm the editor. I describe a target, it produces a draft, I reshape. The bar for "good enough" is low because I'm going to edit anyway.
2. Reasoning mode. The model is a sparring partner. I'm stuck on a design decision and I want someone to poke holes in my plan before I commit. The bar is high, and I trust nothing without verifying.

Drafting mode is where most of the speedup comes from. Reasoning mode is where most of the value comes from. Mixing them produces bad code fast — which is the worst of both worlds.

Context is still the job

The single biggest lever is the context I hand the model. Bad context produces bad output with immense confidence. Good context produces output I can actually ship.

• Show, don't tell. Pasting the actual file is worth ten sentences of description.
• Name your constraints. "Don't introduce a new dependency" catches 80% of the bad suggestions.
• Give the recent history. What did we just try? What failed? Otherwise you get the same suggestion again.

Most "the AI is dumb today" moments, when I look back at the transcript, were really "I gave it a bad context and it did its best with it".

The model is a function of its context. Changing the context is almost always easier than changing the model.

Verify like a junior's PR

The model is a very fast junior engineer with zero situational awareness. You would not merge a junior's PR unread. Don't merge the model's either.

My verification loop, for anything non-trivial:

1. Read every line, not just the diff summary.
2. Run it. Not "it compiles" — run the thing the change is supposed to affect.
3. Ask the model to explain a piece of code I find suspicious. If the explanation doesn't match what the code does, that's a bug.
4. Keep a running note of where this model is wrong. Different models have different weaknesses. Knowing them saves time.

That last one matters more than people admit. "The model sometimes invents function names" is a tax you can plan around. Pretending it never happens is how you ship a broken import.

Agents vs. copilots

An agent takes actions. A copilot suggests them. The difference is enormous.

A copilot's worst case is a wasted keystroke. An agent's worst case is a production incident. So my rule is: give agents narrow jobs with tight feedback loops. Rename a symbol across a repo. Regenerate a type. Run a test and tell me what's red. I don't hand agents loose, open-ended objectives in a live system unless I've scoped the blast radius to something I can throw away.

The demos that show an agent autonomously "doing tickets" work because the ticket was already a glorified diff. For real ambiguous work — the kind senior ICs get paid for — agents are still co-pilots, and the best ones know it.

What the AI doesn't replace

After a year of serious AI-augmented work, here's what still lives on my side of the line:

• Picking what to build. No model has context on your users, your roadmap, or your team's politics.
• Picking what not to build. Arguably more important, and harder to delegate.
• Naming things. Good names compress understanding the model doesn't have yet.
• Drawing the line between "clever" and "load-bearing". The model will happily make a clever thing load-bearing.
• Saying no to the product manager with a straight face.

Everything else is up for negotiation, and that negotiation keeps moving. I try not to be precious about which tasks I'm willing to hand over. The calendar of "things I was sure the AI couldn't do" has gotten shorter every quarter.

Tooling is downstream of habit

The last note is the one I keep re-learning. No amount of tool upgrades compensates for bad habits. Good habits with a mediocre tool beat bad habits with a state-of-the-art one, every time.

My current habits, which I will happily revise in six months:

• Write a one-line intent before I ask for anything substantial.
• Keep the conversation focused — spin up a new one when the topic shifts.
• Commit model-written code in its own commit, with a clear message. Easier to revert, easier to review.
• Once a week, read back the transcripts where the model surprised me. That's where the next workflow change lives.

The senior IC's job isn't going away. It's getting denser, faster, and more about judgment per minute. Tools change; taste compounds.

I'll keep updating this note as the tools change. If you're working through your own version of this question, I'd love to hear what you landed on.