What AI-augmented delivery looks like on a Tuesday

Everyone’s seen the demo by now. Someone types a sentence, waits a beat, and a working app appears on screen. The room claps. Somebody films it for their feed.

I want to talk about the Tuesday instead. Not launch day, not the demo, just the ordinary Tuesday where real software gets shipped. That’s where I’ve spent the last couple of years, inside the delivery pipeline of a previous engagement, and the honest version looks nothing like the demo.

The loop

Here’s the actual motion, start to finish.

A feature starts as a sentence. Not a spec, a sentence. That sentence goes into a step that turns it into a properly structured ticket, with acceptance criteria a developer could build against and references to the real files it’ll touch. That’s already more discipline than most teams manage by hand.

The ticket becomes work. The work happens on its own isolated branch, off to the side where it can’t hurt anything. Tests get written. And at the end you don’t get merged code, you get a draft pull request. Draft, deliberately, because a human still has to read it, argue with it, and press the button.

Then the boring bit. The merged changes become a changelog, the changelog becomes a release, and the release announces itself in the channel the team already lives in. Nobody wrote the release notes by hand. Nobody forgot to tell anyone it shipped.

Sentence to shipped, with a person at every gate that matters. That’s what augmenting delivery with AI actually means. The AI isn’t writing your software while the developers watch. It’s doing the wiring between the parts developers care about, and it never touches production without someone nodding first.

The dial nobody tells you about

Every one of those steps sits somewhere on a dial, and the dial is the whole game. At one end the AI proposes and you approve every move. At the other it plans and acts on its own. Low agency is safe and slow. High agency saves the most time and lets the most go wrong.

The mistake I see constantly is people picking one setting and using it for everything. They crank it to full autonomy because a video told them to, then act surprised when it does something expensive. Or they leave it pinned at maximum caution and wonder why they’re not saving any time.

The rule is simple: match the dial to the blast radius. Throwaway draft nobody will ever see? Let it run. Anything that touches a customer, moves money, or is hard to undo? Dial it down and read every line. The skill isn’t picking a tool, it’s knowing where to set the dial for the job in front of you.

Read-only first

The other thing that keeps this sane is a rule I now apply everywhere. When you connect an AI to your actual systems, connect it read-only first.

Reading is close to harmless. It can look at your code, your tickets, your metrics, and tell you things. The damage lives in the writing: sending, posting, deleting, deploying. A wrong assumption that stays in a draft is a shrug. A wrong assumption with write access is forty wrong emails before your coffee’s cold.

So it reads first, always. It earns write access one narrow scope at a time, and anything outbound gets a human. That one habit is the difference between AI that quietly makes you faster and AI that’s a liability with an API key.

The unglamorous truth

None of this films well. There’s no moment where a sentence becomes an app and the room gasps, just a pipeline that turns intentions into shipped software a little faster every week, with humans still firmly in charge of the decisions that count.

That’s the version worth building. It just doesn’t make for a good video.