I’m Not a Coder. I Ship Features Anyway.

This is the longform companion to a piece I’m posting on LinkedIn next week. The work is real. The pattern is repeatable. Whether it’ll work the same in your shop depends on what kind of operator you already are.

the week

I shipped five features across three internal apps this week. I’m a Director of IT Infrastructure. I’m not an engineer.

The features:

• A multi-trainer field in our training-management app, so a session can have more than one instructor and they all get the calendar invite
• A one-time-update flow in our team-updates portal, so we can run a one-off cycle like yearly self-reviews without forcing a recurring schedule
• A winner-celebration email system in our vulnerability tracker — when someone wins the daily / weekly / monthly badge, the team gets a real email instead of just an in-app notification
• An admin force-close on audit cycles, with a mandatory reason that gets cryptographically signed into the evidence, for our audit-compliance app
• A read-only API endpoint on a fourth app so my AI agent can ingest the team’s daily updates instead of me copy-pasting from the UI

Each one used to be “I’d have to find an engineer to build that, and it’d take a sprint.”

None of them used a sprint. None of them used an engineer. None of them used a line of code I hand-wrote.

the workflow

Here’s what every one of those features looked like, end to end:

1. describe

I write a spec for the AI coding agent. Not a one-line prompt. A spec. The kind of spec I’d hand a senior engineer if I were briefing them on the work.

For the multi-trainer feature, the spec was about a page and a half. It described what I wanted (multiple trainers per session, all of them on the invite, profile photos in the UI). It described what to check first (the existing data model, the calendar-invite path, the photo-fetch pattern). It described the constraints (no breaking changes to existing single-trainer sessions, no new dependencies, follow the repo’s existing patterns). And it described the hard rules (don’t push, two-strike rule on errors, no fabrication).

The spec quality is the whole game. If the spec is sloppy, the agent guesses. If the spec is tight, the agent ships. I write specs better now than I used to write code.

2. recon

The agent reads the codebase first. Maps the data model. Finds the existing patterns. Looks at recent commits to understand what’s in flight.

On the multi-trainer feature, the agent came back with a finding I hadn’t anticipated: there was no trainer dropdown at all. The existing code silently assigned the creator as the trainer. My spec had asked for “add a co-trainer picker.” The agent’s recon turned that into “you don’t have a primary trainer picker either.” So the work expanded — appropriately. That’s the agent doing what a careful engineer would do.

3. design and build

The agent designs the change to fit existing patterns. Writes the migration. Builds the UI. Wires the calendar-invite logic to include all trainers. Adds the profile-photo render. Opens the PR.

I’m not watching the build live. I’m doing something else in another window. The agent works, asks questions when stuck, surfaces decisions when it makes them.

4. review

This is where I earn my title.

I read every change in the PR. Not skim — read. Run the tests. Check that the new tests actually cover the new logic, not just the happy path. Look for places where the agent took a shortcut I disagree with. Look for missing edge cases. Look at the migration and ask whether it’s safe under concurrent writes. Look at the UI and ask whether it’ll look right at the smallest screen size we support.

If something’s off, I ask the agent to fix it. Sometimes I describe the fix; sometimes I just describe what’s wrong. The fix loop is fast — usually one or two iterations.

5. merge and deploy

The agent merges to main. My local sync. The deploy pipeline pushes the new image to our Coolify infrastructure. Coolify reloads.

6. migrate and verify

I apply the database migration on prod manually — the one part of the stack that still needs a human-in-the-loop step. SSH into the host, run the prisma migrate command inside the container, verify the new table or column exists. Then test the feature against the live system.

Six steps. Most of the elapsed time is the agent working in step 3 while I do something else.

what I’m actually doing

I’m not writing code. I’m not designing schemas. I’m not picking variable names.

I’m describing outcomes, validating output, and making judgment calls. The agent does the typing.

This is a different job than the one I trained for. I came up writing PowerShell scripts and slogging through Active Directory. That decade of hand-work gave me taste — I know when output is right or wrong, when a stack feels clean or hacky, when an edge case is going to bite. That taste is the only reason this workflow works for me. If I’d skipped the hand-coding decade and started here, the agent’s output would look fine and I wouldn’t know what to question.

The hand-coding taught me what to check. The AI does the typing now. Both are necessary.

the failure modes

It would be a bad essay if I only described what works. Here’s what doesn’t.

The spec quality bottleneck. When I’m tired or distracted and I send a sloppy spec, the agent ships sloppy work. Not bad code necessarily — but work that solves the wrong problem cleanly. The first time you experience this is uncomfortable. You think the AI is unreliable. It’s not. You wrote a bad spec and the AI did exactly what you asked for.

The over-confident shipper. Sometimes the agent will ship a change that compiles, passes the tests, and looks reasonable — but is subtly wrong in production. The review step catches most of it. The migration step catches a little more. Some still slips through. You need a real environment, not just CI, to catch these. We’ve had two of these in 18 months. Both got patched within an hour. Both taught me to write tighter specs.

The unfamiliar codebase. When I send the agent into a repo it hasn’t worked in before, the first feature takes two or three rounds of “no, that’s not how this repo does things.” The agent learns the patterns by reading. But the first build in a new codebase costs more attention than the tenth. After the tenth, the agent knows the shape.

The thing the agent can’t do. Anything requiring a credential I haven’t given it, a network it can’t reach, or a system it doesn’t have an API for. The agent isn’t magic — it’s a really fast typist with good taste. If the system needs a human at a console, a human at a console is still required.

the compounding leverage

I started this workflow seriously about 14 months ago. The first month was slow — I was learning to write specs, the agent was learning my repos, and every feature took two or three iterations.

The fourth month was when it clicked. By then, the agent had seen most of my repos, I’d written enough specs to know what level of detail it needed, and the loop was tight. I started shipping features I’d had on my “someday” list for years because the cost dropped to “an afternoon of writing a spec and doing reviews.”

By the twelfth month, the bottleneck had moved entirely. The bottleneck wasn’t engineering time anymore. It was what I knew about my org’s workflows and what I could describe well enough to delegate.

That shift matters more than the productivity number. It means the directors who win at this aren’t the ones who can hand-code. They’re the ones who can see their org’s friction points and write tight specs against them. That’s not the same skill as engineering. It overlaps. It’s not identical.

the operator role

I’m not a coder. I’m an operator who knows how systems fit together, points AI at the right cuts, validates the output, and ships the result. The role doesn’t have a settled name yet. The closest labels I’ve seen are “technical product manager,” “platform engineer,” “senior IC with org context” — none of them are quite right because the role only became possible at this scale in the last 18 months.

Whatever it ends up called, it’s not coding. The skill is direction. The skill is taste. The skill is knowing what your org needs and being able to describe it well enough that something else can build it.

If you’re sitting in an IT or ops leadership role and you’ve been waiting for an opening, this is the opening. Start with one feature. Pick the smallest annoyance in your org that should-already-exist. Write the spec like you’re briefing a senior engineer. Hand it to the agent. Review what comes back. Ship it.

The first one feels weird. The third one feels natural. By the tenth, you’ve forgotten what it was like to wait three weeks for “I’ll get to it next sprint.”

What’s the last thing you shipped where you didn’t write the code? I’m curious how other IT and ops leaders are running this pattern — what works, what doesn’t, where the agent earns its keep and where it doesn’t. Drop me a line.