Own the Slice

What fragmented work costs

Picture the board on a Tuesday afternoon. One card says "in progress." Another says "blocked." A third says "waiting on design." From across the room they look identical, and nobody walking past can tell you what a customer can do today that they could not do last week.

That is the cost boards hide. Each card is easy to assign. Each one also demands a context reload: reopen the ticket, rebuild the story, remember why the field exists, then lose the thread when the next ping lands. Multiply that across a team and the product disappears behind its own workflow.

Gerald Weinberg put rough numbers on the reload decades ago. His rule of thumb from Quality Software Management says two concurrent projects cost about a fifth of productive time to switching, and five cost three quarters. It is a heuristic from the early 1990s, and practitioners still cite it because it matches what they see.

Ryan Singer has argued, most fully in Shape Up, that visible work should be organized into scopes named in the language of the product. A handful of those scopes, recognizable from a distance, tells you more than a wall of cards. "Use a saved card at checkout" is a scope. "Add billing-address column" is a task.

Teams have understood this for a long time. AI makes it practical for one person to own an entire slice.

What a slice is

I call this unit of work a slice. A slice cuts through every layer the work touches and delivers one thing a customer can use, or a stakeholder can watch in a demo. Its name comes from the domain. Anyone who reads it should know what customers can do once it ships, and what they still cannot.

Agile teams will recognize the shape. A well-written user story is close to a slice, and the INVEST checklist asks for many of the same qualities. The trouble starts after the story is written. The team breaks it into subtasks, hands those to different people, and the story survives only as a parent link that nobody opens.

Why AI shifts the constraint

AI compresses the time it takes to do things. It does not necessarily compress the time it takes to get things done. Those are two different clocks, and most teams only watch the first one.

The cost of producing working code has fallen sharply. The cost of verifying it, integrating it, and deciding whether it was worth building has moved far less. Two of the better datasets available make that gap visible.

In early 2025, METR ran a randomized controlled trial with 16 experienced open-source developers working 246 real tasks in repositories they knew well. When AI tools were allowed, tasks took 19% longer. The same developers had forecast a 24% speedup, and after finishing they still believed they had been sped up by 20%. METR now treats the result as a snapshot of early-2025 tools, and newer tools may well do better. The perception gap is the lesson that lasts: typing faster feels like finishing faster.

DORA's annual research lets you watch that gap shift year by year. In 2023, more than half of respondents already used AI for some technical tasks, DORA described AI's effect on teams as still in its infancy, and AI tooling already correlated with worse delivery performance. In 2024, a 25% rise in AI adoption was associated with better documentation, faster code review, and higher individual productivity, alongside a 1.5% drop in delivery throughput and a 7.2% drop in stability. DORA's leading explanation was batch size: AI makes it easy to put more code into each change, and larger changes carry more risk.

By 2025, 90% of respondents used AI at work. Throughput turned positive, instability stayed, and DORA found no support for the idea that faster recovery would offset it. Working in small batches appeared on DORA's list of seven capabilities that amplify AI's benefits. The 2026 ROI report describes adoption as a J-curve, with a "verification tax" paid before returns arrive.

A slice is a batch-size discipline. It caps each change at one customer outcome, which is the very constraint AI-assisted teams are losing.

That pushes value toward a particular kind of person: someone who can start from a customer need, cut it down to a slice small enough to finish, pull in whatever judgment is missing, and stay accountable until it ships. Call them the new full-stack builder. The old definition counted layers of technology. This one counts steps in a loop.

The builder still depends on specialists. What changes is the direction of the handoff. The builder carries the slice to the designer, gets an answer, and folds it back in. Ownership never moves into a column called Blocked.

Saved cards at checkout

A client sells coffee refills that customers reorder every three or four weeks. Support hears the same complaint daily: people have to type their card again on every order, and some give up halfway through. The revenue leaks at checkout.

The wider data says this client is not unusual. Baymard Institute puts average cart abandonment at 70.22% across 50 studies, and 17% of US shoppers have abandoned an order because checkout felt too long or complicated. The average US checkout shows 23.48 form elements by default, while Baymard's usability testing suggests 12 to 14 is enough.

The familiar response opens a board with nine cards. Ten people can stay busy for a sprint while no customer can yet do the one thing the client asked for. Attach an AI agent to each card and the fragmentation simply runs faster. Every agent holds a task, and none holds the outcome.

The slice-first response starts by naming the outcome, then writing nine lines of scope: four in, five out. Writing them is the shaping work, and they come from the customer's complaint rather than the architecture diagram. Switch between the two views below.

Then the builder takes the slice to the three people whose judgment it needs.

Design. The current checkout was built around a blank form. The builder brings the designer the need, the definition of done, and the out-of-scope list. They leave with a simple chooser (last four digits, expiry date, one button) and wire it into the working flow.

Data. Storing raw card numbers is off the table. The builder confirms the approach with whoever owns the data model: use the processor's tokens, store only the display fields, and reuse the existing charge path. Nobody opens a side project called "payment platform refactor."

Security. A saved card sounds like a compliance event, so the builder takes the slice to whoever can approve it and states the scope plainly. The processor holds the card data, and we hold a token and four digits. If the answer changes the slice, the slice changes. If security needs a review before launch, the builder books it and keeps building everything the review does not touch. The gate is real, and the builder respects it. The builder still owns the date.

AI handles the mechanical work inside those boundaries: the chooser component, the query, the charge call, and tests for the happy path and the expired card. That speed is real, and it is also where slices quietly dissolve. A model will cheerfully build default cards, wallets, and dunning emails if nobody stops it. The builder's job is to keep pointing at the nine lines.

When the slice ships, the board (if one survives) records a product fact: customers can pay with a card they have used before. Only then does the next need get shaped, perhaps "update an expired card without abandoning the order."

A distro learns what done means

The coffee client is illustrative. Omarchy, an Arch-based Linux distribution, supplied a real one in September 2026. Version 4.0.4 shipped on September 15 with the project's own kernel, linux-omarchy, as the new default. Tom Ballard's thread on the release catalogs a week of the same pattern: a piece of the system is correct, and the machine is still in the wrong state. The kernel story is fully documented in the project's public issue tracker, so it makes the cleanest case.

Every task-level check passed. The package installed, the boot order was set, the migration was marked complete, and the boot menu listed the new kernel first. Machines kept booting the old kernel anyway, along two separate paths.

One user ran the wrong kernel for four days with no symptom beyond uname -r. Another user then wrote a plugin, kernel-guard, that finds the intended kernel by identity on every boot and corrects the default. That plugin is the missing slice test, built by the community after the fact.

Here is the same release written both ways. Switch between the views.

Why slices work: two classic lenses

Two thinkers explain why this works better than any productivity tip. Eliyahu Goldratt, a physicist turned management writer, told the story of a failing factory in The Goal (1984) and gave the world the Theory of Constraints. Donella Meadows, an environmental scientist, spent her career showing how systems behave, and left a short essay called "Leverage Points: Places to Intervene in a System" (1999) that still circulates among people who fix organizations. You do not need to have read either one. Their core ideas fit on this page.

Goldratt: a system moves at the speed of its narrowest point

Every system has one step that limits how much comes out the other end. Goldratt called it the constraint. Speeding up any other step does not raise output. It only piles more work up in front of the constraint, where it waits. The pile is the giveaway. Wherever work accumulates, the constraint sits just downstream.

AI changed one step dramatically: writing code. The model below shows what that does to a system whose real constraint is review and verification. Try each switch.

Three things fall out of the model, and they match the evidence in this essay. Faster coding alone grows the pile while output stays flat, which is the pattern DORA found in 2024. Limiting work in progress, one slice per person, keeps the pile small, so each outcome waits days instead of weeks. Only raising the constraint's own capacity, for example by turning the done test into something a machine runs, increases what ships.

Goldratt reduced his method to five focusing steps. Each maps onto a slicing habit.

Applied to the cases in this essay, the pile points straight at the slice.

Meadows: some changes matter far more than others

Meadows ranked twelve places to intervene in a system, from weakest to strongest. The weak end is adjusting numbers: budgets, headcount, how many agents you run. The strong end is changing the rules, the goals, and the shared beliefs that shape everything else. Most organizations reach for the bottom of the ladder because it feels concrete. Slices act much higher up. Tap any rung to see how.

Her best-known example makes the information-flow rung concrete. In her account, a set of identical Dutch houses differed in one respect: some had the electricity meter in the front hall, others in the basement. The houses with the meter in plain sight used about a third less electricity. A slice you can see from across the room is the meter in the hall. So is the kernel-guard plugin, which tells a user the moment their machine drifts.

Where agents fit

Agents can already propose scope, flag edge cases, and draft an out-of-scope list, and they will keep improving. Accountability is a different matter. When the client calls because a charge went through twice, someone has to answer, and that person should be the one who decided what shipped. Agents write the code. A person answers for it.

What the queue does to people

Obie Fernandez recently wrote about an evening with a longtime friend, a staff engineer at a large startup, who told him he no longer knows how to do his job. The friend had dozens of browser tabs and half a dozen terminals open, with an AI agent running in each. He had machine-written architecture plans in Confluence that his boss did not read. His next step was always to turn those plans into Jira epics. He said he could not make progress on anything, and that nobody around him was thinking anymore.

Obie's own demonstration that night produced a draft pull request and five Jira epics in about twenty minutes. He admits in the essay that they never established whether anything important had improved. He also quotes a viral post from an engineer at a large company describing 12 to 13 hour days of pressing enter, no sense of victory, and managers asking why teams are slow when code is no longer the bottleneck.

Read against this essay, those are queue symptoms. Six terminals is the far right of the Weinberg chart. Plans nobody reads are the board in document form. "Nobody is thinking" describes a place where nobody owns an outcome. Obie's advice to his friend is, in effect, a slice: pick something this week small enough to finish and consequential enough that another person will notice.

"But I want to use my brain"

Obie's friend kept coming back to one objection: he wants to think, and he wants to use his brain. Obie's first answer that night was to let go and trust the model. By the end of his essay he lands somewhere closer to the friend: deciding what matters, and getting people to agree on it, is the work that cannot be skipped.

The friend should take heart. An engineer who moves from tickets to slices gets to think. More than that, they have to. A ticket arrives already decided. Someone else chose what matters, what is in, and what done means. A slice arrives as a complaint, and every decision that turns it into an outcome belongs to the builder.

• Which need matters. Out of every complaint in the queue, which one is worth a week.
• What stays out. The out-of-scope list is judgment in its purest form, and the model will never write it for you unprompted.
• What proves it. The done test. For an engineer on payment code, this is where his caution belongs, because it is what shows behavior held.
• Who has to agree. Bringing design, data, security, and teammates the slice itself, and getting a yes.

AI can do the typing inside every one of those decisions. The decisions stay with the builder.

Why "philosopher builder"

This is why I named the role the way I did in The Philosopher Builder. Philosophers think. Builders build. They have traditionally been different people. A builder who only thinks builds nothing, and the friend's shelf of Confluence plans shows what that looks like. A builder who only builds ships whatever the model suggests, and the viral post Obie quotes shows where that leads. The research is not the work. The thinking is not the shipping. The slice asks for both in one person: think hard enough to name the outcome and the test, then build until the test passes.

The same essay proposed testing builders with projects on a 7, 30, and 90 day arc. Read as slices, that arc becomes a ladder anyone can climb, including Obie's friend.

The churn is real, and history has seen it

Obie is blunt that many roles in software will not survive this shift, and he is right that the work is changing shape. The story of setting type shows how that tends to unfold. It begins with the scribes and runs through two more machines.

Two lessons carry over. The first wave is Jevons paradox, applied to labor. In 1865 the economist William Stanley Jevons noticed that more efficient steam engines raised Britain's total coal consumption, because cheaper power found so many new uses. The Linotype did the same for typesetting labor: cheaper type meant more pages, more newspapers, and more compositors overall. It works only when demand is large enough to absorb the cheaper output, and it is the strongest argument that AI could grow software work. The second wave shows what happens when the tool moves the work itself to someone else's keyboard: the craft shrinks within a generation, and the remaining work goes to whoever owns the whole page. If AI is a second-wave tool for software implementation, and the evidence so far points that way, the durable job is the one that owns the outcome. That means finding the slice, shaping it, and finishing it.

Conditions for slices to help people

Slices can also become a faster treadmill: shorter finish lines, run back to back, twelve hours a day. They help people only when three conditions hold.

• Outcomes are what's measured. Leadership counts shipped slices that passed their done test. Lines of code and ticket counts stay off the scoreboard.
• One slice at a time. Each person carries a single slice, which caps the switching cost and the mental load.
• Shipping means stopping. A finished slice is a real stopping point. Obie wanted his friend to finish something useful every day and still have energy for his daughters. A slice is how both happen.

How to find and finish your first slice

Slices are everywhere. Every stuck project, open loop, and recurring complaint has one inside it, waiting to be named. It takes a little practice to see them. Once you can, it is hard to stop.

Nine steps

1. Find the pile. Look for where work waits: unreviewed changes, parked plans, a support queue, a step everyone routes around. The constraint sits just downstream, and your first slice should pass through it.
2. Start from a complaint someone actually made. Support tickets, a client's frustration, the thing your team keeps apologizing for. A backlog item is at least one step removed from a real person.
3. Name the outcome in their words. Use the form "[who] can [do what]." If the sentence mentions a table, an endpoint, or a ticket, keep rewriting until it describes a person doing something.
4. Write the done test. One observable check that someone other than you can run: a customer completes a payment, uname -r prints the right kernel, the car fits. If you cannot write the test, you have found a topic and still need to find the slice.
5. Draw the line. List what is in (five items or fewer) and what is out for now. The out list is the most important thing you will write. It protects the slice from you, your manager, and the model.
6. Size it. Could one person finish this in a week or less with AI doing the mechanical work? If not, split it by outcome. "Customers can see saved cards" and "customers can pay with one" are two slices. Frontend and backend are layers.
7. Name the judgment you need. Design, data, security, legal, a teammate's approval. Write down who, and plan to bring each of them the slice itself: the need, the done test, and the out list.
8. Put one name on it, in public. One owner, stated where the team can see it. Help is welcome. Ownership stays put.
9. Ship, run the test, stop. When the done test passes, the slice is finished. Tell the person who complained. Then shape the next one.

Use AI to find slices, and to argue with you about them

AI helps with more than the typing inside a slice. The most capable models available as of September 2026, such as Anthropic's Claude Fable and OpenAI's GPT-6 Astra, can read a codebase, a support queue, or a year of meeting notes and point to where work is piling up. They are also good at the part people most often skip: finding what a slice forgot.

They are at their best when you treat the slice as an argument and apply the rules of logic to it. A slice is a claim: if we ship this, that person can do that thing. Rhetoric has a long tradition for testing claims, and Stephen Toulmin's model of argument, from The Uses of Argument (1958), maps onto a slice almost exactly. Ask the model to play each part, and especially to find the rebuttal.

A practical sequence looks like this:

1. Have the model find the piles. Point it at tickets, support threads, pull requests, or notes and ask where work waits and why.
2. State the slice as a claim. Write "if we ship this, [who] can [do what]," with your done test.
3. Ask for the grounds and the warrant. What evidence supports the claim, and what assumption connects the evidence to the outcome?
4. Ask for the strongest rebuttal. Which paths, users, or conditions would make the claim false? Ask for the case you would be most embarrassed to have missed.
5. Revise the scope or the qualifier. Either bring the missed path into the slice, or state plainly that the slice excludes it.
6. Decide. The model argues. The builder chooses what ships and answers for it.

Where this model breaks

• Some work does not slice cleanly. A database migration, a compliance audit, or a platform rebuild may need coordinated specialists and a longer runway.
• Some slices are too big for one person even with agents. Cut them smaller rather than staffing them larger.
• A builder who works alone becomes the only person who understands the slice, so every slice needs a short, deliberate handoff at the end.

1. Gerald M. Weinberg, Quality Software Management, Vol. 1: Systems Thinking, Dorset House. Table summarized at contextcost.com.
2. Ryan Singer, Shape Up, Basecamp.
3. Bill Wake, "INVEST in Good Stories, and SMART Tasks" (XP123, 2003); Mike Cohn, User Stories Applied (Addison-Wesley, 2004).
4. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025), and the February 2026 design update.
5. Google Cloud, Announcing the 2023 State of DevOps Report and DORA 2023 report.
6. Google Cloud, Announcing the 2024 DORA report; 39.2% low-trust figure per the 2024 report errata. Batch-size explanation summarized by DX. 2023 to 2024 delivery trend summarized by DX.
7. Google Cloud, Announcing the 2025 DORA Report; throughput and instability findings summarized by IT Revolution.
8. DORA, ROI of AI-assisted Software Development (2026.01), with coverage by InfoQ.
9. Baymard Institute, Cart Abandonment Rate Statistics.
10. Omarchy: GitHub issues #12664 and #12145; omarchy-kernel-guard; Linuxiac; Tom Ballard, thread on X (September 2026).
11. Obie Fernandez, essay on X (September 2026), including the viral post it cites.
12. Eliyahu M. Goldratt and Jeff Cox, The Goal (North River Press, 1984).
13. Donella Meadows, Leverage Points: Places to Intervene in a System (1999), and Thinking in Systems (Chelsea Green, 2008).
14. Kent Langley, The Philosopher Builder (July 2026).
15. William Stanley Jevons, The Coal Question (1865); see Jevons paradox.
16. Stephen Toulmin, The Uses of Argument (Cambridge University Press, 1958); see Toulmin model.
17. Eltjo Buringh and Jan Luiten van Zanden, "Charting the Rise of the West: Manuscripts and Printed Books in Europe," Journal of Economic History 69, no. 2 (2009).
18. Typesetting history: Glenn Fleishman (on the 1929 BLS report); The Conversation; UPI; BLS Monthly Labor Review; BLS TED, 2016.