Three projects, three opposite methods, all monster output days: what that taught me about when process helps and when it's just comfort

Hey, it’s Paul. Thursday, February 26, 2026.

I’ve been running a portfolio of software projects using a mix of autonomous AI pipelines and human-led parallel agent sessions. Yesterday, three different projects had monster output days — and they did it through completely opposite methods. That divergence surfaced something I’ve been circling for a while, something that extends well beyond software into how any organization actually gets things done.

Here’s the setup. One project ditched all process ceremony, spawned three AI agents working in parallel, and I reviewed and merged their output in series. Fourteen issues closed. Another project loaded twenty issues into an automated pipeline the night before and I walked away. Nineteen landed clean by morning. A third project spent the entire day rewriting its own operational documentation — no new features, no code shipped, just making existing content accurate and legible.

All three worked. And the fact that all three worked is the interesting part.

The ceremony question

Most organizations treat process as a binary. You either have it or you don’t. You’re either disciplined or you’re cowboying. Agile or chaos. Pipeline or ad hoc.

That framing is wrong, and it’s wrong in a way that costs people enormous amounts of time and energy.

What I saw yesterday is that the right amount of process depends on the shape of the work, not the preferences of the team. The project that needed human-led parallel grind was dealing with tasks that touched shared infrastructure in unpredictable ways. Three agents were modifying the same navigation layer simultaneously. Merge conflicts were inevitable — not because the process was bad, but because the work was inherently entangled. Having a human watch the merge sequence wasn’t ceremony. It was the actual job.

The project that ran overnight on autopilot was handling tasks that were naturally isolated. Each one touched its own component. They didn’t interfere with each other. The pipeline model worked because the issues were parallel by nature, not parallel by force.

Frederick Brooks made this distinction in 1975 with The Mythical Man-Month — essential complexity versus accidental complexity. The essential complexity of entangled work doesn’t go away because you automate the pipeline. You just discover the tangles later, at merge time, when they’re harder to fix. The essential simplicity of isolated work doesn’t need a human hovering over it. You’re adding ceremony for comfort, not for value.

Here’s what I actually do now: before I decide how to execute a batch of work, I look at the dependency graph between issues. If they share files, shared state, or UI layout — grind model, human in the loop. If they’re isolated components or migrations — pipeline model, walk away. It’s not a sophisticated framework. It’s a two-second judgment call. But it’s a judgment call most teams never make because they’ve committed to one process for everything.

And when you think about this beyond software — think about how many organizations run every initiative through the same approval workflow, the same meeting cadence, the same review process. A routine budget reallocation gets the same ceremony as a strategic pivot. A well-scoped task gets the same oversight as an ambiguous one. The cost isn’t just time. It’s the signal it sends: we don’t trust anyone here to judge what needs oversight and what doesn’t.

That’s a judgment problem. And judgment doesn’t automate.

The verification debt nobody talks about

Here’s the thing that made yesterday genuinely uncomfortable. Every single high-output session created a morning-after problem.

The project that closed fourteen issues? Some of that code can’t be verified without running Xcode, which the AI agents can’t do. The project that landed nineteen PRs overnight? No end-to-end testing of the actual user flow has been done. Twelve new database migrations need verification against production. A new API dependency needs its key configured in a live environment. The documentation project caught stale numbers — a spec that claimed 32 tools when there were actually 30, claimed 50 modules when there were 47. Those numbers had been wrong for weeks. Nobody noticed because nobody was reading the document as an operational artifact.

The pattern is consistent: autonomous throughput creates a verification debt that compounds silently.

This is the part that doesn’t show up in the productivity metrics. If you can grind fourteen issues or pipeline nineteen in a day, but the next morning requires a manual walkthrough of every change, you haven’t eliminated the bottleneck. You’ve moved it. You’ve shifted the constraint from production to verification — and verification is harder to parallelize, harder to automate, and harder to make exciting.

I think this is where a lot of organizations are headed with AI adoption generally, not just in software. The capacity to produce — reports, analyses, drafts, code, content — is about to explode. It’s already exploding. But the capacity to verify that what was produced is correct, coherent, and structurally sound? That scales with human attention. And human attention is finite.

James Reason’s work on organizational accidents is relevant here. He showed that catastrophic failures rarely come from a single error. They come from the accumulation of small unchecked assumptions — his “Swiss cheese model,” where holes in multiple layers of defense happen to align. High-throughput autonomous systems are essentially adding more cheese slices faster. Each individual output might be fine. But the interaction effects, the merge conflicts, the stale references, the route collisions — those are the holes, and they only become visible when someone actually looks.

One of my projects is now running a post-merge scouting process — an AI agent that reviews what the pipeline produced and flags quality issues. That’s one answer. But scouting for problems after merge is fundamentally different from catching them before. It’s the difference between quality assurance and quality control, and most people treat those as synonyms when they’re not.

So if you’re leading a team that’s about to dramatically increase its output using AI tools, here’s the question you should be asking: who is doing the verification work, and when? Because that work is about to become the actual bottleneck. Not production. Verification.

The curation problem hiding in plain sight

The third project yesterday — the one that shipped no new features — might have done the most important work of the day.

What happened was straightforward. Someone went through thirty-one blog posts and retitled every single one. They’d all been named “Dev reflection - 2026-01-23” or similar. Generic, date-based, invisible. After the retitling, each post communicated its actual argument before you clicked on it. “The steps that don’t feel like steps.” “What the pipeline can’t decide.” Titles that tell you what the piece is about.

Separately, an operational spec got rewritten from a marketing pitch into an accurate description of what the system actually does. Stale numbers corrected. Missing sections added. The daily workflow documented for the first time.

None of this was new content. It was existing content made legible.

And here’s where I want to push on something. In most organizations, this work is invisible. It doesn’t show up in sprint velocity. It doesn’t close tickets. Nobody gets promoted for retitling thirty-one posts or correcting a spec that was quietly wrong. It’s “housekeeping.” It’s “documentation.” It’s what you do when you don’t have “real work.”

But every person who did this work yesterday described it as significant. Because it is. Systems that produce content faster than they can curate it eventually drown in their own output. The content exists but can’t be found. The spec exists but is wrong. The posts exist but nobody reads them because the titles are meaningless.

This is editorial judgment. It’s the ability to look at thirty-one pieces of writing and see that each one has a distinct argument buried under a generic label. It’s the ability to read a spec and notice that the numbers don’t match reality. It requires having read the material, understanding what matters, and making decisions about how to surface it.

That doesn’t automate. Not because AI can’t generate titles — it obviously can. But because the judgment about which title captures the actual argument of a piece, the one that will make someone click and read and think — that requires understanding the argument. And understanding the argument requires doing the reading. There’s no shortcut.

Peter Drucker said the most important thing in communication is hearing what isn’t said. The curation problem is similar. The most important thing about a body of content is what isn’t surfaced — the connections that aren’t visible, the arguments that aren’t labeled, the errors that aren’t flagged. Surfacing those things is work. Real work. Arguably the most important work in any knowledge-intensive operation.

The phase transition

So here’s what I think is actually happening, and not just in my projects.

We’re in a phase transition where raw output is no longer the constraint. Between AI agents, automated pipelines, and focused human sessions, the capacity to produce is enormous. The constraint is shifting — to verification, curation, and structural integrity. Every high-output day creates a follow-up list that’s primarily about checking what was produced, not producing more.

That’s not a problem to solve. It’s a shift to recognize.

The work of building is giving way to the work of ensuring what was built is correct, discoverable, and sound. The projects that are thriving are the ones where someone is actively doing that second kind of work. The ones that are drifting are the ones where nobody is.

And if you’re sitting in an organization that’s about to dramatically scale its output with AI tools, you need to ask yourself: who is going to do the verification? Who is going to do the curation? Who is going to read the thirty-one posts and notice they need better titles? Because that person — the one doing the unglamorous, invisible, editorial, judgmental work of making output legible and correct — that person is about to become the most important one in the room.

Not the one producing. The one checking.