I Am an Assembly-Line Engineer

Thursday evening, a PMM gave me a rough idea for a new variant of a signup flow. Friday morning, it was in production. By noon, paid ads were sending real users to it. I never read the code.

That was possible because I don't work on tasks. I work on the line that does them: an assembly line for software, from a rough idea to production. Agents do most of the work, while I make three calls: plan, build and release.

For most of my career, that path took a team: a designer, developers, QA and someone to release it. Now one person can run it. What's left for that person is judgment and attention.

Software Delivery Is an Assembly Line

The line itself isn't new. Years ago, I read Goldratt's The Goal, a novel about a factory. In its plant, work moves from station to station, and each person works one of them.

The book also taught me to look for the constraint: the one station that caps the whole flow. Speed up any other station, and the plant gets no faster. The constraint is also called the bottleneck.

Then came The Phoenix Project, Accelerate and the DevOps mindset. They showed me that software delivery is the same line, only virtual: the parts are ideas and code, and the stations are people at desks.

Seeing it that way changes what you work on. The task in front of you is one piece on the line, and the line makes every piece. When a piece comes out wrong, you fix the line, not the piece. Factories call that kaizen.

A Line Is a Stream of Work

A Kanban board is the clearest picture of a software line. Its columns are the stations: design, development, testing, release, etc. A card moves from column to column, and at each one a person works it.

One line is one stream of work. Some products need only one. Others run many in parallel: per business line, per department, etc.

My first attempts to improve a line were mechanical: automating the handoffs between stations. Take the release process of a product team I led:

• Before. 16 manual steps across three repositories, and the bottleneck was the QA phase.
• The change. We established preview environments and kept staging release-ready. A release had nothing left to verify, so we reduced the process to one Slack command.
• After. The team went from dreading releases to shipping once or twice a day. Later I wrote it up.

The automation itself was worth nothing. What mattered was what it did to the line: it made the process transparent, clear and quick. That was kaizen: a fix to the line, not to a release.

The handoffs went to the machine, but every station still had a person at it. A developer made the build, and QA decided whether it was ready. Those stations took judgment, and no machine could do that yet.

Agents Took the Stations

What changed recently is that an agent now takes a station the way a person did: it gets the piece, the rules for that station and the tools, does its part and passes the piece on.

In my case, agents work from my IDE, as the Claude Code extension. I set up each workspace for them: a clear structure, skills for the jobs that repeat, and a knowledge base that says how I want the work done.

Month by month, they took over the middle of the line: everything between an idea and production. Today the middle has four kinds of station:

• Plan. Exploring a problem and drafting a plan.
• Build. Building the solution based on the plan.
• Review. Reviewing the work against written rules.
• Tests. Running tests and builds, and taking screenshots.

One person can now own the whole line: a problem goes in, software comes out. The owner watches the line and makes the calls it stops for.

One of my lines builds and maintains signup flows for a product, more than a hundred so far. It had just received its last missing station: end-to-end (E2E) tests that let the line check its own work. When the right task came, I decided to let it run the whole way.

One Idea Ran Through the Whole Line

The right task came that Thursday evening. The PMM's idea: a competitor's checkout mechanics rebuilt in the product's own style. The line took it from there:

• Research. Agents studied the competitor's page and listed what was worth adopting.
• Design. Other agents drafted designs, and judge agents picked one.
• Plan. One document reached me, with a recommended default for every decision.

The plan was my first call. It looked good, so I answered in three words: "execute the plan." The line went on:

• Build. One commit across 50 files.
• Review. Multi-angle agentic review of the code.
• Tests. E2E tests of the new variant, and screenshots.

The build was my second call. I approved the screenshots and left the code to the stations. Then came the handoff:

• Merge request. The line opened one with every decision, every change, the design concept and the screenshots, and posted it in a thread with the PMM.
• Approval. The next morning, the PMM approved the deploy in that thread.

The release was my third call. I merged, and five minutes later it was out.

Right after, the PMM and I tested the new variant in production, the first time anyone saw it live. A few small issues turned up, and we fixed them within minutes, before the ads started.

Trust Is Earned per Line

Leaving the code to the stations takes trust, and a line earns it. What makes a line worth trusting:

• It works inside boundaries. It reaches only what the job needs. More on that below.
• It reviews its own work. Tests, linters, builds, review agents and screenshots: stations that check the other stations.
• It stops and waits. At each call it pauses, then goes on when approved or refines the work when not.
• It writes down what it did. Every decision and every change, so the approver reads a document instead of a diff.
• It can roll back in minutes. For the release, and for the ads.
• It has a track record. The signup line had shipped more than a hundred flows before the new variant.

Those points are mine. Another person, or another team, would draw the list differently.

The more trust a line has earned, the less I check:

• A line that has earned it. On the signup line, no person reads the code: a person looks at the result in production, with a rollback behind it.
• A line still missing some of it. I read the diff before each commit. Once its stations are complete, my check moves out to the result: the screenshots and a live look.

My principles call the line's checks and its rollback quality gates. Bugs will happen, so the aim is to recover in minutes.

Every Bug Marks a Missing Station

A bug that gets through is never only a bug. It marks something the line is missing:

• A station. Nothing on the line checks that part of the work yet.
• A decision. Nobody made the call, so an agent made it.
• Information. The agents didn't have a fact the job needed.
• Know-how. No skill or knowledge base page says how to do that work.

Here is an example from one of my lines, which develops an AI product. Its test for report downloads checked that a report arrived with the right name, header and size, but nothing read what was inside.

I asked the line to open the report and compare it with the app. Four bugs had sat in the report generator for months, from diagrams 94 inches wide to numbering that ran across sections. The fix was a station, not a patch: now the line opens every report it builds.

A bug is a signal of a weak spot. That's where the owner steps in: to extend the line, so the same kind of defect doesn't get through again. Every extension still stays inside the line's boundaries.

In a plant, parts go in, cars come out, and only a few engineers watch it. They make sure the output is what was expected. When something breaks, they fix the line, not a single car. That's what kaizen looks like on the floor.

A Person Sets the Boundaries

An agent can do almost anything it can reach. So the owner's first job is to set what the line can reach and what it can do. That's what makes a delivery safe. The boundaries I set on a line:

• Secrets stay out of the chat. Tokens sit in one place the agents can't read. The agents call scripts, and the scripts read the tokens.
• Access is the smallest that does the job. Read-only where the line only has to look. No root, no admin, nothing granted just in case. It's least privilege, as in cloud infrastructure, and all the DevOps practice behind it still holds.
• A line creates only what it's for. It gets the right to create one kind of thing.

A top-tier cloud engineer once told me: "Anybody can set up AWS, but only a few are ready to be accountable for the invoice." The same applies to software delivery lines.

I set boundaries because the accountability stays mine. A model can generate an opinion, but it can't be accountable for one. Accountability takes attention, and my attention doesn't scale.

Attention Is the New Constraint

Agents widened the middle of every line, and the constraint moved to the one step they don't take: the owner's judgment. Someone still has to look at the output and decide whether it's good.

AI is like a movie character who will answer anything you ask, but won't tell you what to ask. Deciding what to ask is my job, and that's judgment.

Asking takes few words. Over three days on the AI product's line, I wrote 22 messages, and the agents made 932 tool calls. My messages were high-level: they took little time and all of my attention. That's the constraint now: not my time, but my attention. In one day, agents drafted 14 plans for that line. Two weeks later, two had run. The rest waited on me.

So I guard it. A line can carry a few tasks at once, but I take the critical calls one task at a time. That's my choice, not the line's limit: I believe WIP one is what keeps quality high.

Most of my attention now goes to the line, not to the pieces it produces. Every station I add is one less thing the approval has to catch.

The Goal says to widen the constraint. When the constraint is my attention, there are two ways: widen the line, or widen me.

I can't widen myself, so I widen the line. I am an assembly-line engineer.