Aylin Alavizadeh
Industrial Engineer · Specialist in Mathematics & Probability

Reza Farzaneh
Software Engineer · Systems Thinker & AI Research Writer

Open a newspaper from late 2022 and the story reads like this: one autumn morning, a company in San Francisco released a chatbot. The world changed overnight. Schools panicked. Lawyers updated their resumes. Philosophers got nervous. The age of artificial intelligence had arrived.

It is a tidy story. It is also wrong by about seventy years.

What happened in November 2022 was not the arrival of anything. It was the moment one particular curve — drawn slowly across decades of mathematics — finally crossed a threshold low enough that ordinary humans, on consumer hardware, noticed. The mountain had been there the whole time. We just walked into a meadow with a clear line of sight.

This is the third essay in a small sequence. The first, Predicting Toward Meaning, explained what a large language model is. The second, There Is No Inside, argued that the difference between the model and the mind is thinner than anyone wants to admit. This one is the boring essay. The historical one. The one that asks the question almost nobody bothers to ask in print:

If this thing is so revolutionary, why did it take seventy years to write a coherent paragraph?

The answer, it turns out, is the whole story.

The Costume Has Been Under Construction Since 1943

In 1943, two men — Warren McCulloch, a neurophysiologist, and Walter Pitts, a self-taught logician who had run away from home at fifteen — published a paper called A Logical Calculus of the Ideas Immanent in Nervous Activity. They proposed something audacious: a neuron could be modeled as a simple mathematical switch. Inputs in, threshold check, output out. Connect enough of them together and, in theory, you had a network that could compute anything computable.

There were no neurons in the paper. There were no brains. There was only mathematics in the shape of a neuron — a costume worn by a function. It is here, in 1943, two years before the end of the Second World War, that the real story of AI begins. Not in a research lab in 2017. Not in a startup garage in San Francisco. In a journal article that almost nobody outside a small circle would read for the next fifteen years.

In 1948, two years before Turing, a researcher at Bell Labs named Claude Shannon published A Mathematical Theory of Communication — the paper that gave the world the words channel, encoder, decoder, noise. Shannon was not thinking about thinking machines. He was thinking about telephone wires. But he proved, formally, that the meaning that survives any transmission is bounded by the cleanliness of the encoding and the capacity of the channel. Seventy-eight years later, we would discover that this is also the cleanest description of what happens when an engineer types a prompt into a model.

In 1950, Alan Turing — already six years dead by the time this story really got moving — published Computing Machinery and Intelligence. He proposed the famous test that bears his name. Not “can a machine think?” — a question he correctly identified as nearly meaningless — but “can a machine produce conversation indistinguishable from a human’s?” The question shifted from metaphysics to engineering, and that shift is, arguably, the entire history of AI in one sentence.

In 1956, ten people gathered at Dartmouth College for a summer workshop. Among them: John McCarthy, Marvin Minsky, Claude Shannon. They coined the term artificial intelligence in the funding proposal. They believed, with the boundless confidence of postwar American science, that the problem would be solved by the end of the season. They were wrong by about seventy summers.

Three Winters

Here is the part most modern AI commentary quietly skips. Between 1943 and 2017, the field died at least twice.

In 1969, Marvin Minsky and Seymour Papert published Perceptrons, a book that mathematically proved single-layer neural networks could not solve certain trivial problems — including the XOR function, the most boring logic gate in computing. The book was technically correct and tactically devastating. Funding dried up. The first AI winter began. For nearly two decades, working on neural networks was a career-ending choice. The people who continued — Geoffrey Hinton, Yann LeCun, a small Canadian-French diaspora of stubborn researchers — were widely considered to be wasting their lives.

In 1980, while neural networks were buried under permafrost, an American philosopher named John Searle published a paper called Minds, Brains, and Programs. Inside it, almost as a side argument, sat a thought experiment.

Imagine a room. Inside the room, a man who speaks no Chinese. Through a slot in the door, slips of paper covered in Chinese characters arrive. The man has a vast rulebook in English that tells him: if you see this character, write that one. He follows the rules, slides the response back out, and to the Chinese speakers outside, it appears the room understands Chinese perfectly.

Searle’s point was philosophical: syntax is not semantics. Symbol manipulation is not understanding. He intended it as an attack on a kind of AI optimism that, in 1980, did not even exist yet in any meaningful form. He could not have known that he was describing the architecture of the system that, forty-two years later, would become the most-used software product in human history. He drew a picture of what wasn’t possible. We spent the next four decades quietly building it anyway.

In 1986, Rumelhart, Hinton, and Williams published a paper on backpropagation — the mathematical trick for training networks with more than one layer. It had been independently discovered several times before. This time it stuck. Neural networks could now, in principle, learn. The thaw began.

Then, in the early 1990s, the second winter arrived. Neural networks were too slow, too data-hungry, and the world did not yet have enough digitized text to feed them. The field of “good old-fashioned AI” — handwritten rules, expert systems — collapsed under its own brittleness. The smart money said the whole project was a dead end.

The smart money was wrong. It just had to wait twenty years to find out.

What Tokens Actually Are

This is the part almost nobody explains in plain language, because the moment you do, the magic evaporates.

When you type a sentence to ChatGPT/Claude/Cursor or any tools that you are using, the first thing that happens is not understanding. It is tokenization. The sentence is broken into pieces — sometimes whole words, sometimes fragments. The English word unbelievable is typically chopped into something like un, believ, able. Each piece is mapped to an integer in a giant lookup table. Hello might become the number 15496. World might become 11103.

That’s it. That’s the input. The model never sees the letter H. It sees a column of integers. The text has been converted into the only thing the math can chew on: numbers.

Once you have numbers, you have geometry. Each token is mapped — through more multiplication — into a vector. A list of thousands of floating-point numbers, like coordinates in an impossibly high-dimensional space. In this space, somewhere around 2013, researchers at Google noticed something startling. They could do arithmetic on words.

The vector for king, minus the vector for man, plus the vector for woman, came out closest to the vector for queen. Paris minus France plus Italy came out closest to Rome. The result, called word2vec, was a small earthquake. It looked like the model had learned about royalty and geography. It had not. It had learned about co-occurrence. Across billions of words of training text, certain words tended to appear in certain neighborhoods. Royalty was a pattern. Geography was a pattern. Patterns are geometry. Geometry is arithmetic.

There is no concept of royalty hiding inside the vectors. There is only the geometric residue of words keeping each other company.

What this means — and what we keep failing to say out loud — is that the entire act we call “the AI answering a question” is the following procedure: convert text to numbers, multiply the numbers by other numbers, choose the next number with the highest probability, convert it back to text. Repeat until done.

There is no understanding. There is no thinking. There is the inside of the Chinese Room, except the man with the rulebook has been replaced by a stack of matrix multiplications, and the rulebook has been replaced by two hundred billion parameters fit to a significant fraction of all readable text on Earth.

2017: The Year the Costume Learned to Speak

For decades, the bottleneck was not the idea. It was the architecture. Neural networks could learn, but they were slow, forgetful, and unable to handle long sequences. Recurrent networks read text one word at a time, the way a person reads a book through a keyhole.

Then, in June 2017, eight researchers at Google published an eight-page paper with a punning title: Attention Is All You Need. It introduced the transformer — an architecture that processes entire sequences in parallel, with each token attending to every other token simultaneously. It was, in retrospect, the single most consequential engineering paper of the century so far. The authors did not know that. They thought they had built a better translation system.

Within five years, the transformer would become the substrate of GPT, Claude, Gemini, and almost every system the public would later call “AI.” The intelligence everyone thought was new was, mechanically, the same neuron-shaped switches McCulloch and Pitts described in 1943, stacked into the same backpropagation-trained structure Rumelhart and Hinton revived in 1986, expressed in the same vector geometry Mikolov demonstrated in 2013, organized into the parallel-attention pattern Vaswani’s team formalized in 2017.

It was not a revolution. It was a seventy-four-year accumulation, finally crossing a hardware-and-data threshold that made it visible from the street.

The Mutation That Wasn’t

This is the move we want to make. The one that the breathless coverage almost never makes.

The thing we call AI is not a mutation. It is not a singular event. It is not a new kind of being. It is the latest checkpoint in a slow, public, well-documented, mathematically continuous research program that any patient reader can trace from 1943 to today without encountering a single moment of magic.

When someone says “the AI hallucinated” or “the AI didn’t understand my question,” they are speaking as if a misbehaving mind were inside the machine. There is no mind. There is a probability distribution. The model chose a less-likely token because, given the training data and the prompt, that token’s probability was, momentarily, the highest. That is the entire phenomenon. It is mathematics behaving exactly as mathematics behaves. To call it a hallucination is to mistake the costume for the man, the room for the speaker, the rulebook for the understanding.

And here is the line we have been circling. The Chinese Room is not merely a metaphor for what an LLM is. It is, scaled up by a factor of a trillion, the literal description of the system. There is, inside the data center, no Chinese speaker. There is the man with the rulebook, multiplied across thousands of GPUs, following his rules at superhuman speed.

The room speaks. The room does not understand. Searle wrote that in 1980. We built it anyway.

What the Timeline Asks of Us

If you take the dates seriously, two uncomfortable things come into focus.

The first is that nothing about the current moment is sudden. The architecture, the math, the philosophical objections, the alignment problems, the question of meaning — every single thread of the current AI conversation was on the table by 1986 at the latest. The only thing that has changed is that we now have the silicon and the text corpora to run the math at a scale where its output becomes indistinguishable from a person speaking.

The second is harder. The word intelligence has been doing increasingly heavy lifting in the name artificial intelligence for seventy years. We started by assuming intelligence was something hard and special. Then we built things that produced intelligent-looking output without containing intelligence. Now we are in the awkward position of asking whether intelligence was ever the thing we thought it was — or whether it, too, is just a costume that mathematics has been wearing all along.

The companion essay to this one, There Is No Inside, makes that move directly. We will not make it again here. We will simply note: the history of AI is not the history of a thing that became conscious. It is the history of a math that became persuasive. The difference matters. And the moment you can see the dates — 1943, 1948, 1956, 1969, 1980, 1986, 2013, 2017, 2022 — the persuasiveness stops being a miracle and becomes what it actually is.

An engineering achievement. Mathematics in a costume. The Chinese Room, finally finished.

The room is speaking. It has been learning to speak for seventy years.

It still does not understand a word.

A Note Before You Close the Tab

If this essay has been about what the room is, our friend and colleague Görkem Duymaz has written its practical sister — How to Talk to a Machine, a sequel to The Philosophy of Prompting that takes the same seventy-year mathematical inheritance and asks the engineer’s question on the other side of it: now that you know what the room is, how do you keep a conversation with it from drifting?

It is the best treatment we have read of the four axes that decide whether a prompt lands — Wittgenstein on the limits of language, Sokrates on the discipline of the next question, Polanyi on the tacit knowledge that resists encoding, and Shannon on the channel itself. The reveal that ties the whole thing together — talking to a machine was always a Shannon problem; only the name of the channel has changed — is the kind of synthesis that turns a year of vague intuition into one usable sentence. We recommend it without reservation. Read it next.

References

The Foundational Papers (1943–1956)

[1] McCulloch, W.S., & Pitts, W. (1943). A Logical Calculus of the Ideas Immanent in Nervous Activity. Bulletin of Mathematical Biophysics, 5(4), 115–133. The paper that first modeled the neuron as a mathematical switch. Available at: link.springer.com/article/10.1007/BF02478259

[2] Shannon, C.E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal, 27(3), 379–423; 27(4), 623–656. The paper that gave the world channel, encoder, decoder, and noise. Available at: people.math.harvard.edu/~ctm/home/text/others/shannon/entropy/entropy.pdf

[3] Turing, A.M. (1950). Computing Machinery and Intelligence. Mind, 59(236), 433–460. The paper that proposed the Turing Test and shifted the conversation from metaphysics to engineering. Available at: academic.oup.com/mind/article/LIX/236/433/986238

[4] McCarthy, J., Minsky, M.L., Rochester, N., & Shannon, C.E. (1955). A Proposal for the Dartmouth Summer Research Project on Artificial Intelligence. The 1955 funding proposal for the 1956 workshop where the term artificial intelligence was coined. Available at: raysolomonoff.com/dartmouth/boxa/dart564props.pdf

The Winters and the Thaw (1969–1986)

[5] Minsky, M., & Papert, S. (1969). Perceptrons: An Introduction to Computational Geometry. MIT Press. The book that proved single-layer networks could not solve XOR — and inadvertently triggered the first AI winter.

[6] Searle, J.R. (1980). Minds, Brains, and Programs. Behavioral and Brain Sciences, 3(3), 417–424. The paper that introduced the Chinese Room thought experiment. Available at: doi.org/10.1017/S0140525X00005756

[7] Rumelhart, D.E., Hinton, G.E., & Williams, R.J. (1986). Learning Representations by Back-Propagating Errors. Nature, 323(6088), 533–536. The paper that made multi-layer neural networks trainable in practice. Available at: nature.com/articles/323533a0

The Modern Era (2013–2017)

[8] Mikolov, T., Chen, K., Corrado, G., & Dean, J. (2013). Efficient Estimation of Word Representations in Vector Space. arXiv preprint, arXiv:1301.3781. The original word2vec paper. Available at: arxiv.org/abs/1301.3781

[9] Mikolov, T., Yih, W.T., & Zweig, G. (2013). Linguistic Regularities in Continuous Space Word Representations. Proceedings of NAACL-HLT 2013, 746–751. The paper that demonstrated king − man + woman ≈ queen. Available at: aclanthology.org/N13–1090

[10] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A.N., Kaiser, Ł., & Polosukhin, I. (2017). Attention Is All You Need. Advances in Neural Information Processing Systems (NeurIPS), 30. The paper that introduced the transformer architecture. Available at: arxiv.org/abs/1706.03762

Companion Essays in the Insider One Engineering Series (2026)

[11] Farzaneh, R. (2026, February 11). The Philosophy of Prompting: How Asking Questions to Machines Reveals How We Think. Insider One Engineering, Medium. Available at: medium.com/insiderengineering/the-philosophy-of-prompting-how-asking-questions-to-machines-reveals-how-we-think-c7cf82f6a2ef

[12] Duymaz, G. (2026, May 12). How to Talk to a Machine. Insider One Engineering, Medium. Available at: medium.com/insiderengineering/how-to-talk-to-a-machine-d22321289944

Further Reading

Clark, A. (2013). Whatever Next? Predictive Brains, Situated Agents, and the Future of Cognitive Science. Behavioral and Brain Sciences, 36(3), 181–204. On the predictive-processing framework that underlies the cognitive-science parallel to LLMs. Available at: doi.org/10.1017/S0140525X12000477

Friston, K. (2010). The Free-Energy Principle: A Unified Brain Theory? Nature Reviews Neuroscience, 11(2), 127–138. The more aggressive form of the prediction-as-cognition argument. Available at: nature.com/articles/nrn2787

Crevier, D. (1993). AI: The Tumultuous History of the Search for Artificial Intelligence. Basic Books. The standard popular history of the field, useful for the long arc this essay compresses.

Russell, S., & Norvig, P. (2021). Artificial Intelligence: A Modern Approach (4th ed.). Pearson. The canonical textbook; chapters 1 and 21 cover the historical timeline this essay walks through, in technical detail.

Right now, somewhere, an HR person is filling out a job requisition form.

The cursor is sitting in a field labeled Job Title. They type, automatically: Backend Go Developer, 5+ years experience.

Across town, in a building they’ve never been to, another HR person is filling out the exact same form. Their cursor is in the same field. They type something that didn’t exist on a job board two years ago: Engineer fluent in agent-led delivery.

Same headcount. Same compensation band. Two completely different civilizations, hiring two completely different humans.

The Job Title field is the most fragile sentence in your career, and most companies don’t know it yet.

What I keep noticing on my own team

Last month I sat in a standup that felt completely normal — until I realized none of the people speaking were doing what their title said they did.

The QA was triaging logs through an agent and pushing the fix herself. The designer had shipped a working onboarding flow over the weekend without writing a single Figma comment. The “backend engineer” had drafted the migration plan — and the plan was a Notion doc, generated, reviewed, and merged by an agent.

Nobody had agreed on this. It just happened. Quietly, week by week, the cards we’d been dealt for the last decade got picked up off the table and shuffled.

Watching a team like this is like watching a card game where everyone keeps trading hands without saying so. The roles don’t disappear. They reorganize around the table.

I keep asking myself: in two years, what is a “Go Developer” going to mean on a job posting? Will the field on the HR form still hold that sentence? Or will it be something we don’t have a clean word for yet?

What I’ve been circling for two years

I’ve been writing around this idea for a while without saying it directly.

In Stop Using AI. Start Delegating to It., I argued that “using” AI is a fundamentally weak frame. You use a calculator. You delegate to a teammate. Then I said something that felt premature at the time: the cards have to be reshuffled. I knew what the new hand looked like before I knew the new game.

In We Stopped Sprinting and Bet on Shipping, I argued that two-week sprints, planning ceremonies, and most of the rituals around them stopped serving the work the moment agents entered the loop. They went from coordination to latency.

In 50% Faster, Guaranteed, I sat with teams who wanted to “go faster with AI” and told them something they didn’t expect: stop thinking like a developer. Engineering is not typing. Engineering is asking the right questions until the problem is small enough to dissolve. The faster you stop performing the role of “developer,” the faster you become an engineer.

In The Philosophy of Prompting, I argued that the prompt is a mirror. The way you phrase a request to a machine reveals whether your own thinking is clear. A prompt that fails is rarely a prompt failure.

In How We Achieved a 50% Speed Increase Using the Torque Methodology, I described a way of organizing work where the card belongs to the outcome, not the role.

Five articles. One thread.

The unit of work has changed. The role definitions we hire against haven’t caught up. Everything inherited from the old hand — titles, ceremonies, sprints, story points — is now stalling work it used to coordinate.

This is the part I haven’t said out loud yet. I’ll say it now.

Roles were never roles. They were throughput specializations.

We didn’t invent “QA,” “Designer,” and “Developer” because they reflect something fundamental about software. We invented them because humans are slow, and dividing the work was the only way to ship.

A designer is someone whose throughput on visual decisions is higher than yours. A QA is someone whose throughput on edge cases is higher than yours. A developer is someone whose throughput on code is higher than yours.

That’s the whole thing. Roles are throughput specializations.

Now read that again with this in mind: an agent’s throughput on each of those three things, today, exceeds the median person on most teams.

So what exactly is a “QA Engineer” specializing in, when an agent generates two hundred edge case ideas in ninety seconds and the QA’s job becomes choosing the twelve worth running?

The role didn’t disappear. The throughput moved. The person who used to be the throughput is now the person who directs it. Once you see this clearly, you stop trying to rescue the role — and you start trying to redesign the team.

Agile was a coordination tax for slow humans

Here is what nobody wants to admit: most engineering processes were already broken before AI. We just couldn’t see they were broken, because human throughput was slow enough that the process didn’t look like the bottleneck.

Take Story Points. Fifteen years in, no two teams agree on what they mean. Some say time. Some say complexity. Nobody can define complexity. We’ve been measuring with a ruler that doesn’t have units, calling the act of measuring “estimation,” and the act of disagreeing about it “alignment.”

Take two-week sprints. Refinement. Retro. Sprint review. Planning. Daily standup. None of these existed because they were optimal. They existed because the work moved at human speed, and the ceremony was the coordination tax of moving slow humans through structured handoffs.

Now the work moves at agent speed.

Every wait time, every handoff, every “let’s circle back,” every “we’ll review next sprint,” every story-point estimation meeting becomes painfully visible.

It’s like watching traffic from a helicopter. From the ground, traffic looks like just how driving works. From above, you can see the problem is one merge point three miles back, and the next eight miles of slowdown are just the echo of that one bad design.

AI didn’t break the process. AI turned on the helicopter.

The room where titles died

When I ran the Torque experiment on my AgentOne team, the most surprising thing wasn’t the speed. It was a room.

For a single feature, I put everyone in one room and locked the door for as long as it took. The QA. The developer. The designer. The PM. No agendas. No story-point estimation. No “let’s break this into tickets.” The only rule was: nobody leaves until every person understands the whole feature — not their slice of it.

We sat there for hours.

What happens in that room is something Agile rituals are explicitly designed to prevent. Agile breaks the feature into role-shaped slices and hands each slice to its specialist. The room I’m describing does the opposite. The whole feature becomes one shared understanding held by every person.

When the door opened, the work happened differently. The “developer” ran the user test because she had the deepest model of the use case. The “designer” wrote the twelve-line migration script because he was already in the file. The “QA” wrote the spec because she’d already mapped every edge case in her head from triage. The PM stopped translating between the others, because the others didn’t need translation anymore.

One month. Single team. Speed went up roughly 50%.

The number isn’t the interesting part. The interesting part was that the team wasn’t confused. They were faster because the boundary was gone.

The room where titles died was not a meeting. It was the death of role-based handoff disguised as a meeting.

The room should be bigger

The room where titles died had four people in it. That worked, and it changed how I think about engineering teams.

Here is my next proposal: that room is too small.

Imagine a product team building an AgentBot. Today, the engineers are in one room — or in another time zone, on Slack. The designers are somewhere else. The QA is on a different shift. Sales is on a different floor, if there is even a floor. Customer Success is in a different city. When a customer reports a bug, it travels through four or five layers — Zendesk → internal ticketing → triage → routing → finally landing on an engineer’s screen, hours, days, or weeks later. The customer wanted their problem solved on Tuesday. By the time anyone with the power to fix it sees the ticket, it’s the next Tuesday.

In Torque, I wrote that before doing any work you should ask whether the work is worth doing. That question cannot be answered honestly if the engineer asking it has never spoken to a customer. It cannot be answered if the salesperson selling the feature doesn’t know what the team can build. It cannot be answered if Customer Success can name the bug but not the system.

So the new product team is everyone. The engineer. The designer. The QA. The PM. The salesperson. The Customer Success person. On the same team. Ideally in the same room. With one shared model of who the customer is and what they are actually paying for.

When a bug comes in, it does not enter at level five of a ticket queue. It enters where it should always have entered — between two people on the same team who already know the customer’s name, the contract value, and what the customer was trying to do when it broke.

Tickets are dead. Languages speak now.

Tickets were the protocol two strangers used to coordinate when they did not share a room. When the team shares a room, the protocol is just talking. Everyone understands everyone else faster. The OXT colleague does not write you a Jira card — he turns his chair around.

There is a second thing this room demands.

Everyone in it — the most junior new joiner, the engineer who has been at the same desk for ten years, the designer, the QA, the salesperson — needs to read the same financial line. Gross margin. Contribution margin. Operating margin. EBIT. EBITDA. ARR. MRR. CAC. LTV. LTV/CAC. Payback period. NRR. GRR. Net margin. Rule of 40. Burn rate. Free cash flow. The vocabulary the CFO uses when they decide whether your product survives the next budget cycle.

Most engineering teams treat these words as someone else’s job. That is a relic of the same throughput-specialization world. In the team I am describing, every person on it should be able to look at the product and say, within ten percent, what its gross margin is. If the answer is “I don’t know, that’s finance,” the team isn’t ready.

Because here is what happens when everyone in the room knows the gross margin: a bug stops being an annoyance and becomes a customer one cancellation away from collapsing the LTV. A feature stops being a ticket and becomes a contribution-margin lever. Suddenly the work has a real number attached to it, and the team makes very different decisions about which work is worth doing — which is the question Torque was always trying to answer.

You did not build the product to create problems for the customer. You built it to solve theirs. When everyone in the room knows what that customer is paying, what they are paying for, and what your gross margin on them looks like — the bug gets embraced. It gets cared for. Not because anyone wrote a process for that, but because the people sitting next to each other have the same picture of the same customer.

There is a third thing — and this one will get me in trouble.

The room has to be a room.

I know the post-2020 consensus says otherwise. COVID-19 gave people two years of fear and gave companies the word remote. For a small number of teams it worked. For most product teams I have watched up close, that was the day the slow collapse started. The room got smaller. Then it dispersed. Then it became a Slack channel. Then the Slack channel became a backlog. Then the backlog became the four-or-five-layer ticket journey that a customer’s bug now has to survive before it reaches the person who can actually fix it.

The companies bringing people back into a room — the same physical room, with sales and CS and engineering all in it — will ship better products faster. The companies still optimizing for remote-first purity at the cost of that room will get out-shipped, regardless of how good their tooling is.

This is not a culture-war point. It is a latency point. The room is the lowest-latency communication channel humans have ever invented. AI just made every other channel look slower than it really is.

Engineering is asking the right question

Once you watch this happen, the philosophy of prompting stops being a philosophy and starts being a job description.

The new specialty is not “Go.” It is not “Vue.” It is not “React.” It is being able to ask the right question of the right system at the right moment — sometimes the system is a database, sometimes a colleague, sometimes a model, sometimes a customer. Sometimes the right question is should this exist at all?

That is a much harder thing to put on a job posting.

It also doesn’t fit in the field labeled “Job Title.”

The companies figuring this out are starting to write the next-hand language anyway. They post engineer fluent in agent-led delivery instead of 5+ years of Go. Some of them still write the old sentence out of muscle memory and pay candidates against the new one. The ones doing this consciously will eat the ones doing it unconsciously.

So what comes after “Backend Go Developer”?

Honestly, I don’t fully know.

I know the title will technically still exist. It will mean something completely different.

It won’t mean “person who writes Go.” Agents write Go.

It will mean something closer to: “person fluent enough in Go to catch the agent when it’s wrong, fluent enough in the system to know when ‘wrong’ is dangerous, fluent enough in the product to know which ‘wrong’ is actually a feature, fluent enough in the customer’s P&L to know which feature is worth shipping at all — and able to do all of that in three other stacks before lunch.”

That sentence is too long for a job posting. It will get compressed into something we don’t have a clean word for yet. Right now the field is flashing ???? while the industry decides what to type into it.

The companies that pick the right next-hand sentence first will look — in 2030 — like the companies that posted Software Engineer in 1998 instead of Typesetter.

The ones still typing Backend Go Developer, 5+ years experience into the form, in 2030, will look like the other ones.

Why most teams won’t make it through the curve

I want to be careful here, because this is the part where it would be easy to sound triumphant.

The honest answer: I tried this on a few teams. Small samples. Not a study. The pattern was clear, but the conditions were the conditions of teams I personally led, with the cover I personally provided.

I provided a specific kind of cover. The hardest part of any new way of working is not the new way. It’s the period between the old way breaking and the new way feeling natural. That period is loud, anxious, and metric-hostile. Velocity dips. People feel slow. Story-point burndowns look ugly. Managers panic and pull the team back to the old structure right when they were one week from the breakthrough.

I have watched this kill more transformations than any technical reason. Not tooling. Not buy-in. The middle of the curve is genuinely uncomfortable, and most leaders don’t have the stomach to sit in it.

The teams that make it through don’t have better engineers or better tools. They have leaders who are willing to look bad on the dashboard for two weeks — and willing, also, to ask people to come back to a room.

I can’t give you that willingness. I can tell you that on the other side of those two weeks, the room where titles died — and then the bigger room, with sales and CS and a shared P&L line on the wall — is waiting.

The cards on the table now

The HR form is open in a tab somewhere right now. The cursor is in the Job Title field.

You — or the company you work at, or the company you’ll join next — are about to type something into it.

Here is what I have come to believe, after writing five articles around it and one month of running an experiment that changed how I think about the next decade:

1. Roles are throughput specializations. Agents are throughput. The role definitions we inherited are not load-bearing. The faster you stop defending them, the faster the team moves.
2. Engineering is asking the right question. Not typing. Not shipping tickets. Not story-point arithmetic. The Philosophy of Prompting was always a job description in disguise.
3. Agile rituals are the latency we don’t see. Sprints, points, ceremonies, planning meetings — they exist because slow humans needed coordination. Agent throughput in the loop turns most of them into friction.
4. Outcome-cards eat role-cards. Torque is not a methodology. It is the only structure that survives when the unit of work moves faster than the role boundary.
5. The product team is everyone, in one room, reading the same financial line. Engineering, design, QA, sales, Customer Success — same team, same gross-margin number on the wall. Tickets are dead. Languages speak now.
6. The room has to be a room. Remote was a 2020 emergency that became a habit. The companies that put the team back in one place will out-ship the ones that didn’t, no matter how good the tooling gets.
7. The onboarding curve is the real moat. Whoever is willing to be bad at the new way for two weeks gets to be the team that’s better at it for the next decade.

The deck is being shuffled whether you sit at the table or not.

The only question is whether the sentence you type into the Job Title field is the one from the last hand — or the one from the next.

In medieval European cities, a man walked the streets every night with a lantern and a wooden staff. He wasn’t hunting criminals. He wasn’t patrolling for invaders. He was a night watchman — and his single, strange job was to confirm, block by block, that the city was still the city.

The watchman couldn’t verify ledgers. He couldn’t audit trade. He walked. He looked. He listened. He knocked on doors and waited for a voice. If a window was dark that shouldn’t be, if a shop was open that shouldn’t be, if a door opened too slowly — that was a signal worth raising. The lanterns burning on the wall meant nothing to him. A lit lantern could mean a thriving home or a fire catching the drapes. He had to see.

Your monitoring system is not the night watchman. It is the lit lantern.

The HTTP 200 Paradox

Every uptime dashboard in the world rests on a quiet lie: that a server returning 200 OK means the product works.

It doesn’t. It never has.

A modern web application is not a document. It is a composition — of DNS records, TLS handshakes, HTML skeletons, JavaScript bundles, third-party SDKs, font CDNs, feature flags, auth tokens, WebSocket upgrades, lazy-loaded components, and six API calls that happen after the page has technically “loaded.” Each layer can fail silently while the one above it reports success.

I have watched a production site return 200 OK for twenty-three minutes while every user saw a blank white page. The origin was healthy. The CDN was healthy. The load balancer was healthy. The Datadog dashboard was green. The business was broken.

The bug was a single line in a JavaScript bundle — a null reference in the app’s bootstrap code, shipped from a trusted third-party SDK that had silently pushed a new version overnight. The HTML loaded. The status code was perfect. The application never rendered.

Our monitoring told us the city was fine. No one was walking the streets.

What Your Monitor Cannot See

HTTP monitors measure the wrong layer. They measure whether the server answered the door, not whether the conversation inside made any sense.

Consider the anatomy of a single page load in any modern SaaS product:

1. DNS resolves — a monitor can check this.
2. TCP connects, TLS negotiates — a monitor can check this.
3. The server returns HTML — this is where most monitors stop.
4. The browser parses HTML, downloads CSS, fonts, and JavaScript — now you’re in territory curl cannot reach.
5. JavaScript executes, fetches auth tokens, boots the SPA framework — no HTTP check verifies this.
6. The SPA makes six API calls, hydrates state, renders the interactive shell — invisible to ping-style tooling.
7. A button finally becomes clickable — the moment the user would say “it works.”

Steps 1 to 3 take roughly 200 milliseconds. Steps 4 to 7 take 2 to 5 seconds and involve dozens of third-party systems you do not control.

Your uptime monitor measures 200 milliseconds of a five-second experience and declares the whole thing alive. It is the equivalent of judging a concert by whether the doors opened.

The Four Layers of Liveness

After watching enough outages that were “not outages” according to our tools, I started thinking about monitoring as a layered problem. Every layer below is necessary. None is sufficient on its own.

Layer 1 — Reachable. The domain resolves, the socket connects, the certificate is valid. This is what ping and TLS monitors answer.

Layer 2 — Responding. The server returns a non-error HTTP status within a budget. This is what most uptime tools — Pingdom, UptimeRobot, the built-in health checks of every cloud provider — actually measure.

Layer 3 — Rendering. The page produces a real, inspectable DOM. The JavaScript executes without throwing. The expected elements exist.

Layer 4 — Interacting. A user can log in, click a product, reach checkout, complete a flow. The business transaction is possible.

Most organizations monitor Layers 1 and 2 and call it uptime. The gap between Layer 2 and Layer 4 is where your revenue disappears and where your customer support queue fills up while your Grafana stays green.

To close that gap, you need a witness that walks the streets.

Enter the Silent Browser

Headless Chrome is a full browser with no window. It parses HTML. It executes JavaScript. It honors cookies, headers, service workers, WebSockets. It sees the page the way a user sees it — minus the screen.

Headless Chrome alone is not the answer. It is the engine. You need a driver that knows how to ask it the right questions, wait for the right signals, and fail meaningfully when something is off.

Playwright is that driver.

Playwright was built at Microsoft by the team that originally built Puppeteer at Google. It is a browser automation library, but that framing undersells it. It is the first tool that treats “can a human use this site right now?” as a first-class, scriptable question.

The usual story about Playwright is that it is a testing framework. That framing is too small. Playwright is a testing framework the way a telescope is a toy — technically correct, completely missing the point. The same script that verifies your login flow works in CI can run every three minutes against production and tell you, with precision, whether a real user would be stuck.

Here is the shape of it:

const { chromium } = require('playwright');
async function checkSite(url) {
const browser = await chromium.launch();
const page = await browser.newPage();
const start = Date.now();
const response = await page.goto(url, {
timeout: 10000,
waitUntil: 'networkidle'
});
const loadTime = Date.now() - start;
const status = response.status();
const title = await page.title();
await browser.close();
return { status, loadTime, title };
}

Twelve lines. This is already more honest than any HTTP-only check you will ever build. It follows redirects. It runs JavaScript. It reports a load time that includes the experience, not just the handshake. It captures whether the page has a title — which is a surprisingly strong signal that rendering actually completed.

But this is the introduction, not the payoff.

What a Real Watchman Checks

A night watchman does not judge a house by its front door. He checks the back window, the chimney, the sound of the floorboards. A real synthetic check does the same.

Consider what you actually want to know about your login page:

• Did the page render the login form?
• Did the brand logo load from the CDN?
• Did typing into the email field work?
• Did clicking submit produce a response within two seconds?
• Did the post-login redirect reach the dashboard?
• Did the first dashboard API call succeed?

None of that is visible to curl. All of it is trivial in Playwright.

async function checkLoginFlow(baseUrl) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  const errors = [];

  page.on('pageerror', err => errors.push(err.message));
  page.on('requestfailed', req =>
    errors.push(`${req.method()} ${req.url()} — ${req.failure().errorText}`)
  );

  await page.goto(`${baseUrl}/login`, { waitUntil: 'networkidle' });

  await page.fill('[data-testid="email"]', 'watchman@example.com');
  await page.fill('[data-testid="password"]', process.env.WATCHMAN_PASS);
  await page.click('[data-testid="submit"]');

  await page.waitForURL('**/dashboard', { timeout: 5000 });
  await page.waitForSelector('[data-testid="greeting"]');

  await browser.close();
  return { healthy: errors.length === 0, errors };
}

This is no longer a health check. It is a synthetic user. It exercises the same path a paying customer exercises. It fails for the same reasons a paying customer fails. When it goes red, you do not argue about whether the problem is real. You fix it.

The same script, committed to your repository, runs in three places:

1. Locally, as a developer smoke test.
2. In CI, as an end-to-end guard against regressions.
3. In production, as a synthetic monitor that pages the on-call engineer.

One artifact. Three lifecycles. This is the alignment that HTTP monitoring can never give you — because the HTTP monitor doesn’t know what your product does, and your test suite doesn’t know if production is on fire.

The Ghost of Green Dashboards

Every engineering organization I have worked with has the same ghost in its walls.

A partner files a support ticket. “The site is down.” The on-call engineer checks the dashboard. Everything green. They check the logs. No spike in errors. They open the site — it works for them. They reply, politely, that everything looks fine on their end.

The partner sends a screenshot of a blank white page.

The investigation takes three hours. The cause is some combination of: a stale CDN cache, a broken third-party script in one geography, a feature flag that shipped with a typo, a cookie domain mismatch, a CSP header change, a TLS issue specific to a browser version, a localStorage quota bug. The status page was accurate for the servers it was watching. It was lying about the product.

Every one of those ghosts leaves a footprint a headless browser would have seen. Every one would have been caught by a synthetic check that actually opened the page. Every one sat hidden for hours because the dashboard answered the wrong question.

You cannot staff your way out of this. You cannot add more HTTP checks to fix it. The only solution is to monitor the layer where the failure actually lives — and that layer is the browser.

Beyond the 101 — The Patterns You Only Learn the Hard Way

The internet is full of “your first Playwright check” tutorials. Almost none of them tell you what happens at month three, when your synthetic monitor has matured into a production system and started behaving like one. Six patterns we wish someone had handed us.

Auth seeding without burning a real account. Logging in as watchman@example.com against production looks fine on day one. Six months later, your synthetic user has a five-thousand-row activity log, a corrupted session token, and the fraud team has flagged it twice as suspicious. The fix: a dedicated synthetic identity per environment, a nightly cron that truncates its data graph (orders, sessions, audit rows), and a cookie jar the check resets before every run. Treat the synthetic user as infrastructure, not as a test fixture.

Bot detection is the silent killer. Cloudflare Bot Management, Datadome, hCaptcha, PerimeterX — these systems are not trying to block your synthetic monitor, but they will. Your check will pass for two weeks, then go red on a Tuesday because the protection vendor pushed a new fingerprinting model overnight. The fix: a static-IP allowlist for your synthetic runner, and — critically — a signed header your origin checks before the bot-protection edge sees the request. Don’t cloak. Coordinate.

Flake suppression without hiding outages. Naive retry logic (“rerun on failure”) turns a real outage into a delayed page. Better: classify failures into transport (connection reset, DNS, TLS handshake) and application (selector timeout, assertion failed, JavaScript error). Retry transport once. Never retry application. A login that fails because the submit button didn’t render doesn’t get more honest the second time you click it.

Correlate synthetic failures with backend traces. A red synthetic check is a number on a dashboard. A red synthetic check that links to a distributed trace, the deploy SHA at the time, and the active feature-flag state is an actionable incident. Inject a trace-id header on every synthetic request. When the check fails, the on-call engineer lands directly on the trace that failed. The day we wired this up, mean-time-to-diagnose dropped by roughly half.

Per-geography blast radius. A synthetic check that runs only from one region will miss the half of the internet that hits a single PoP. Run from at least three geographies that map to your top customer segments. Alert when one geography behaves differently from the others — that pattern is almost always a CDN, DNS, or local-ISP problem, not an application one. Treat geographic divergence as a first-class signal.

The script is product code. It deserves the same review process, the same lint rules, the same deploy gate as any other code in your repository. The first time a developer ships a UI change that breaks the synthetic check and forces a revert before merge, you have crossed the threshold from “monitoring” to “user contract.” That moment is the goal — and once you reach it, you stop arguing about whether monitoring belongs to QA, SRE, or the front-end team. It belongs to whoever ships the user-facing change.

The Cost of Honest Monitoring

Nothing in engineering is free, and synthetic monitoring is no exception. Before you replace your HTTP checks with headless Chrome everywhere, understand what you are signing up for.

Resource cost. A headless Chrome process consumes 150 to 400 MB of RAM per instance and is not cheap to spin up. HTTP pings cost kilobytes. If you run a Playwright check every thirty seconds against fifty endpoints, you are running a small cluster.

Maintenance cost. HTTP monitors rarely break. Synthetic scripts break constantly — because they depend on DOM selectors, and DOM selectors change. Every front-end refactor is a potential red alert for reasons unrelated to real outages. Flakiness is the tax on honesty.

Noise cost. A headless browser script has more ways to fail than an HTTP check has states to report. Third-party tracking scripts time out. A fonts.googleapis.com hiccup turns your login flow red. You will spend real engineering time tuning what counts as “broken” — and tuning it wrong will teach your team to ignore the pager, which is worse than not having it.

Cognitive cost. HTTP monitors can be read by anyone. A synthetic script requires someone on your team to understand Playwright, DOM selectors, the product’s critical flows, and the difference between “login button missing” and “auth provider flaky.” The bus factor goes up.

The trade is real. But so is the alternative — which is to keep trusting a signal you have already seen lie to you.

When HTTP 200 Is Enough

Not every endpoint deserves a watchman. The right question is never “headless or HTTP?” It is “what happens if this is broken and we don’t know for twenty minutes?”

HTTP monitoring is the right tool when:

• The endpoint is a machine-to-machine API with no client-side rendering.
• The failure modes are dominated by network and server problems, not front-end logic.
• You already have server-side error tracking that surfaces logical failures.
• The cost of a false negative is small — internal dashboards, back-office tools, non-revenue paths.

Synthetic monitoring earns its cost when:

• The path in question is revenue-critical — login, checkout, onboarding, the top of your conversion funnel.
• The failure modes are dominated by front-end complexity — SPA hydration, third-party scripts, feature flags, CDNs, auth.
• You have been burned before by “green but broken.” Once is an anecdote. Twice is a pattern. Three times is an architectural decision.
• Your customers are the first to notice outages. This is the loudest signal of all. It means your monitoring is downstream of your users, and that is a position no engineering organization should tolerate.

The economy of the trade is simple. Cover the critical flows with synthetic checks. Cover everything else with HTTP. Let the dashboards be honest about which layer they’re watching.

The Watchman at Scale

Once you accept that the browser is the only honest monitor, a second question appears: how often should the watchman walk?

The instinct is “as often as possible.” The discipline is “as often as the data is useful.”

A synthetic check every ten seconds against production will hammer your auth system, fill your analytics with robot traffic, and produce more false positives than signal. A synthetic check every thirty minutes will miss half your outages.

A useful starting point, for the flows that matter most:

• Every 2 to 5 minutes for revenue-critical user journeys.
• Every 15 minutes for secondary flows.
• Every hour, from every geography that represents a real customer segment — because failures in production are almost never global.

And every run should emit the same three numbers: was it reachable, was it fast, was it correct. Store them. Graph them. Alert on deviations from the baseline, not on absolute thresholds — because “3 seconds to load” is catastrophic for one product and excellent for another.

The watchman’s rounds are not a metric. They are a practice.

What to Do Monday Morning

Before you replace anything, install one watchman. Pick the most expensive flow you have — the one that, if it broke for an hour, would draw a Slack thread with the CEO in it. Then:

1. Pick one flow. Login. Checkout. Onboarding. The path your customers would scream about first.
2. Write a 20-line Playwright script. No DOM gymnastics. Just goto, fill, click, waitForSelector. The ugly version is fine.
3. Run it every five minutes from one geography. Not ten regions. Not thirty seconds. One region, one cadence, one alert.
4. Alert on two consecutive failures, not one. Synthetic checks flake. Two-in-a-row is signal; one-off is noise.
5. Track the baseline before the threshold. Watch the median load time for two weeks. Then set the alert at 2× baseline, not at a guessed number.
6. Keep the script in your application repo. Same review process, same lint rules, same deploy pipeline. Monitoring code that lives elsewhere is monitoring code no one updates.

If that one watchman survives a month without becoming the team’s least-favorite Slack alert, add a second flow. Not before.

The Lantern and the Watchman

Long before Datadog, before Pingdom, before anyone thought to measure time in milliseconds, cities decided that a burning lantern was not evidence that all was well. They sent a man into the dark with a stick and a pair of working eyes — because they understood that the absence of fire is not the presence of safety. The lit lanterns told them the city had rules. The watchman told them the rules were being followed.

Your HTTP 200 is the lantern. It is the signal that your system has fuel and oxygen, that the outer shell is still intact. It is necessary. It is never, by itself, enough.

The headless browser is the watchman. It walks the streets you shipped. It knocks on every door your users knock on. It reports, with inconvenient honesty, whether the city is still the city.

The lantern tells you the system hasn’t collapsed. The watchman tells you the users can live in it.

You need both. But if you only have one, keep the watchman.

Further Reading

• Playwright official documentation — playwright.dev. Selectors, auto-wait, network interception, the bits this article skipped.
• Google SRE Book — Service Level Objectives — sre.google/sre-book/service-level-objectives. The canonical reference on monitoring layers; the “four layers of liveness” framing in this article owes its bones to this chapter.
• Cloudflare’s July 17, 2020 outage postmortem — blog.cloudflare.com/cloudflare-outage-on-july-17–2020. A public, painfully detailed example of dashboards staying green while a regex change broke the internet.
• GitHub’s October 21, 2018 incident report — github.blog/2018–10–30-oct21-post-incident-analysis. Twenty-four hours of degraded service, a textbook case of “monitoring measured the wrong layer.”
• Core Web Vitals & RUM — web.dev/articles/vitals. The distinction between synthetic monitoring (lab) and real-user monitoring (field), and why mature teams run both.
• Checkly — Synthetic Monitoring as Code — checklyhq.com/learn. A vendor-written but tool-agnostic introduction to running Playwright scripts as production monitors.
• Andrey Lushnikov on the Puppeteer → Playwright migration — search “Andrey Lushnikov Playwright” on YouTube. The team-history note for why Microsoft inherited Google’s headless-browser playbook.

We run Lambda heavily across our teams. It’s battle-tested, deeply integrated with AWS, and for most of our services it’s exactly the right tool. This isn’t a “Lambda is bad” article — it’s a story about what happened when a specific workload outgrew a specific architecture, and what we learned by exploring a fundamentally different execution model.

In 2017, Cloudflare took V8 — the same JavaScript engine that powers Chrome — and embedded it directly into their edge network. Not containers. Not microVMs. Raw V8 isolates, spinning up in under 5 milliseconds, running on 330+ data centers worldwide.

They called it Workers.

Most developers heard “another serverless platform” and moved on. Lambda existed. Vercel was rising. The world didn’t seem to need another way to run functions in the cloud. I was one of those developers — until our push dispatch service started hitting walls that weren’t about code quality. They were about where the code ran.

4 million invocations per week, 19,241 throttled requests, and a 90-second timeout cliff that turned spiky traffic into silent failures. The Lambda wasn’t broken. It was doing exactly what it was designed to do — in a context it wasn’t designed for.

Here’s what we found.

Why Lambda Wasn’t the Right Fit for This Workload

I want to be clear: Lambda is excellent. We use it across dozens of services and it runs reliably. But every architecture makes trade-offs, and it’s worth understanding what Lambda assumes.

Your code gets packaged into a container. That container lives in a specific region — say, us-east-2. When a request arrives, AWS spins up the container, initializes your runtime, loads your code, and executes it. The first request pays a cold start penalty — anywhere from 100ms to several seconds depending on your runtime and dependencies.

After that first request, the container stays warm for a while. If traffic stops, the container dies. Next request? Cold start again.

For most workloads, these trade-offs are invisible or irrelevant. But for our push dispatcher, each one was amplified:

• Regional execution. A push notification targeting a user in Tokyo, routed through a Lambda in Ohio, pays ~200ms in network latency before the push provider even receives it. For a service that’s 90% network I/O, region matters.
• Cold starts on spiky traffic. Go is one of the fastest Lambda runtimes (~30–80ms cold start), but during traffic spikes — exactly when push delivery matters — Lambda scales by spinning up new execution environments at ~1,000 per 10 seconds. That ramp-up introduces latency at the worst possible moment. Push notifications are inherently spiky — a campaign launch triggers hundreds of thousands at once, exactly when cold starts hurt most.
• Concurrency ceiling. Lambda’s default account limit is 1,000 concurrent executions (our function was configured at 300). This is solvable — you can request increases, buffer through SQS, or configure DLQ for retries. But each solution adds configuration and operational overhead that wasn’t in the original design.

None of these are Lambda bugs. They’re design trade-offs that didn’t fit this particular workload. That’s when we started looking at Workers.

V8 Isolates: A Different Execution Model

Here’s what Cloudflare figured out: you don’t need a container to run JavaScript. You don’t even need a process. You need an isolate — a lightweight V8 execution context that shares the engine but isolates the memory.

A container is an operating system simulation. An isolate is a memory sandbox. The difference in startup time is not incremental. It’s categorical.

Comparison: AWS Lambda vs Cloudflare Worker

• Cold start: Lambda 100ms — 3s | Workers < 5ms
• Execution environment: Lambda Container (full OS) | Workers V8 isolate (memory sandbox)
• Deployment location: Lambda 1 region | Workers 330+ edge locations
• Free tier: Lambda 1M requests/month | Workers 100K requests/day (~3M/month)

Provisioned Concurrency eliminates cold starts but costs an additional $30–80/month and requires capacity planning upfront.

When a request hits a Worker, there’s no container to spin up. No runtime to initialize. The V8 engine is already running at that edge location — it just creates a new isolate for your code. Five milliseconds later, your function is executing — at the data center closest to the push notification endpoint.

Key insight: This isn’t a performance optimization. It’s a different architecture. When latency is measured at the infrastructure layer in single digits, you stop designing around it.

What This Means for Push Notifications

Our push-dispatcher is a high-throughput service: it receives push notification requests and fans them out to APNs (Apple), FCM (Google), and other push providers. The workload is inherently spiky — a marketing campaign can trigger hundreds of thousands of notifications in seconds — and inherently global, because the push provider endpoints are distributed worldwide.

With Lambda in us-east-2, every push to FCM’s European endpoint adds ~120ms of network I/O. Every push to APNs’ Asian endpoint adds even more. The function spends 90%+ of its execution time waiting on network — and Lambda charges you for every millisecond of that wait.

With Workers, the function runs at the edge location closest to the push provider. A Worker in Frankfurt reaching FCM’s European endpoint adds ~20ms. The same request from Ohio adds ~120ms. Multiply that difference by 4 million requests per week.

The architecture is simple: receive the push payload, validate it, and forward it to the appropriate provider endpoint. No database. No complex state. Pure I/O fan-out — exactly what edge computing was built for.

The Worker

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('Method not allowed', { status: 405 });
    }

    const { token, platform, payload } = await request.json();

    const endpoint = platform === 'ios'
      ? 'https://api.push.apple.com/3/device/' + token
      : 'https://fcm.googleapis.com/fcm/send';

    const response = await fetch(endpoint, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': `Bearer ${env.PUSH_AUTH_TOKEN}`,
      },
      body: JSON.stringify(payload),
    });

    return new Response(JSON.stringify({
      success: response.ok,
      status: response.status,
    }), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

That’s the core logic. No framework. No router. No middleware chain. The Worker’s fetch handler is the API.

Deploy in Three Commands

npx wrangler init push-dispatcher
npx wrangler secret put PUSH_AUTH_TOKEN    # encrypted, distributed globally
npx wrangler deploy                        # live on 330+ edge locations

After wrangler deploy, your function is running globally. Not in us-east-2. Not behind a CDN. It’s on the CDN. A push to an APNs endpoint in Singapore gets routed through the nearest edge location — not through Ohio.

Workers doesn’t reduce latency for users near your Lambda region — it’s equal. The win is for everyone else. When your push providers are globally distributed, regional deployment is a tax on every request outside your chosen data center.

Secrets and the Security Model

Secrets are stored via wrangler secret put and injected through the env parameter at runtime. Encrypted at rest, never in logs, available at every edge location. No .env file. No SSM Parameter Store. No Vault integration needed for basic use cases.

If your use case requires more — authentication, rate limiting, data encryption — Workers supports all of it through KV, Durable Objects, and D1. But the principle is the same: start with the minimum, add complexity only when you need it.

The Numbers: Real Data, Real Benchmark

Theory is useful. Data is better. Here’s what happened when we ran a 7-day simulation against our real production Lambda — the push-dispatcher running in us-east-2, handling ~4 million invocations per week.

The Lambda data is real (CloudWatch metrics, March 30 — April 5, 2026). The Workers data comes from a real Worker deployment sending push notifications to FCM via VAPID with test subscription tokens — same payload structure, same endpoints, real HTTP round-trips.

The most interesting number here is the 19,241 throttled requests per week. With a 300-concurrent-execution limit on this function, traffic spikes exceeded capacity and Lambda returned 429s. To be fair — Lambda offers well-documented solutions for this: you can increase account concurrency limits (up to 10,000+ with a support request), buffer through SQS so spikes never hit the function directly, or use async invocation with a DLQ so throttled events retry for up to 6 hours. None of these are exotic — they’re standard Lambda patterns for spiky workloads.

But here’s what made Workers interesting for this case: it doesn’t require any of that configuration. There’s no account-level concurrency throttle to tune. V8 isolates spin up in microseconds across 300+ edge locations. The architecture absorbs spikes without SQS queues, reserved concurrency settings, or limit-increase requests. For a team that wanted push delivery to “just work” without capacity planning, that’s a meaningful operational difference.

That said, Workers isn’t magic either. Each invocation is limited to 6 concurrent outgoing connections — relevant for fan-out patterns. And Cloudflare’s own documentation notes the runtime “may cancel some incoming requests to maintain stability” under extreme load. There’s no published per-location capacity guarantee. Lambda’s failure mode (explicit 429 with retry options) is arguably more predictable than Workers’ (potential silent cancellation under extreme edge-location pressure).

Where the Latency Improvement Comes From

The 25% average latency improvement isn’t magic. It’s three compounding factors:

1. Cold start elimination. Lambda’s Go runtime cold start is ~30–80ms (Go is actually one of the fastest Lambda runtimes — Java would be 1–2 seconds). It affects a small percentage of invocations, but during traffic spikes — exactly when push delivery matters — Lambda scales by spinning up new execution environments. Workers’ V8 isolates start in under 5ms, and there’s no scaling ramp-up.
2. Edge proximity. Lambda runs in a single region (us-east-2). The push notification endpoints (APNs, FCM) are globally distributed. A Worker in Frankfurt reaching FCM’s European endpoint adds ~20ms of network I/O. The same request from Ohio adds ~120ms. Multiply by 4 million requests per week.
3. No timeout cliff. Lambda invocations occasionally hit the 90-second timeout — you can see it in the max duration data (90,095ms). These timeouts destroy the average. Workers caps execution at 30 seconds, but the queue-based architecture means long-running pushes get handled differently, keeping max execution at ~10 seconds.

The Cost Math

Lambda pricing: $0.20 per 1M requests + $0.0000166667 per GB-second of compute. At 4M requests/week with 893ms average duration and 128MB memory, that’s $188.82/month.

Workers Paid plan: $5 base + $0.50 per million requests (first 10M included). At 4M requests/week (~17M/month), that’s $8.65/month.

That’s a 95% cost reduction. Not because Workers is cheaper per unit — but because the pricing model fits this workload better. Lambda charges for duration, and a service that’s mostly waiting on network I/O (push delivery) racks up GB-seconds fast. Workers charges per request, regardless of how long the I/O takes.

How We Ran This Benchmark

We didn’t simulate Workers in a spreadsheet — we built it and measured it.

• Lambda side: 7 days of real production CloudWatch metrics from the push-dispatcher function. Invocations, duration, throttles, errors — all pulled directly from CloudWatch, no estimates.
• Workers side: We deployed a Worker that sends web push notifications to FCM using VAPID authentication with test subscription tokens. Same payload structure, same endpoints, real HTTP round-trips to Google’s push infrastructure. The Worker ran for the same 7-day window, processing equivalent request volumes.
• What this means for the data: Latency numbers are measured, not modeled. The 25% improvement comes from actual response times. Throttle count is real — Workers processed every request without hitting a concurrency ceiling. Lambda’s 19,241 throttles are from CloudWatch. Cost is arithmetic — request counts \u00d7 published pricing.\nWhat to keep in mind: Lambda’s throttling is solvable with SQS buffering, concurrency limit increases (free via AWS support), or async invocation with DLQ. This benchmark compares default configurations, not optimized Lambda vs Workers. Workers has its own constraints: 6 concurrent outgoing connections per invocation, and Cloudflare’s docs note the runtime “may cancel some incoming requests” under extreme load.

A fair next step would be benchmarking Lambda with SQS buffering against Workers — that comparison would isolate the edge proximity advantage from the concurrency difference.

What Happens When the Push Provider Returns 5xx?

Here’s something most Workers tutorials skip entirely: error handling. Specifically, what happens when APNs returns a 503 or FCM times out?

With the naive implementation — the one everyone copy-pastes — the answer is: nothing good.

// ❌ The naive version — no retry, silent failure
const response = await fetch(pushEndpoint, { ... });
// FCM returns 503 → response.ok is false
// → push notification is silently lost
// → error is never logged, never retried

Push providers go down. Rate limits (429) happen. Gateway timeouts (504) happen. Without retry logic, every one of those becomes a lost notification — a user who never gets their message.

Retry with Exponential Backoff

The fix is a fetchWithRetry wrapper that handles retryable status codes and backs off between attempts. The key insight: not every error deserves a retry.

// ✓ fetchWithRetry — exponential backoff + Retry-After support
async function fetchWithRetry(url, options, maxRetries = 3) {
  const RETRYABLE = new Set([429, 500, 502, 503, 504]);

  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    const res = await fetch(url, options);

    if (res.ok) return res;

    // 4xx errors (except 429) are client errors — don't retry
    if (!RETRYABLE.has(res.status)) {
      throw new Error(`Non-retryable error: ${res.status}`);
    }

    if (attempt === maxRetries) {
      throw new Error(`Failed after ${maxRetries} attempts: ${res.status}`);
    }

    // 429: respect Retry-After header if present
    // 5xx: exponential backoff — 1s → 2s → 4s, capped at 10s
    const retryAfter = res.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.min(1000 * 2 ** (attempt - 1), 10000);

    await new Promise(r => setTimeout(r, delay));
  }
}

Key point: setTimeout delays count as I/O time, not CPU time. Exponential backoff across 3 retries is completely safe within Workers’ execution model — even on the free tier.

Workers does not have a built-in dead letter queue. If all retries fail, the error surfaces to your try/catch. If you need guaranteed delivery or async retry queues, that’s what Cloudflare Queues (or AWS SQS on Lambda) is for. For a synchronous push proxy, logging the failure and surfacing the status to the caller is the right failure mode.

When Workers Isn’t the Right Choice

Intellectual honesty matters. Let’s be clear about the limitations.

• Execution time limit. Workers has a 30-second CPU time limit. For most API proxying and edge logic, this is plenty. For heavy computation, it’s a hard wall.
• The 128MB memory ceiling. Workers gives you 128MB. Lambda gives you up to 10GB. Image processing, ML inference, batch ETL, anything needing a real filesystem — Workers isn’t your tool.
• V8 only. You write JavaScript or TypeScript (or Rust/C++ via WASM). If your service lives in Go — like our original push dispatcher — the rewrite cost is real.
• No persistent connections. Workers is request-response. WebSocket servers need Durable Objects. Long-lived processes belong on Lambda or a proper server.
• Single-vendor global failure. November 2025: a Cloudflare configuration change caused 5 hours 38 minutes of global 5xx errors. X, ChatGPT, Spotify — all degraded simultaneously. Lambda’s regional model means a us-east-1 outage doesn’t affect eu-west-1. With Workers, there is no region to fail over to.

Warning: Workers’ “infinite scale” marketing hides the failure mode: silent drops at overloaded edge locations with no DLQ, no retry, no published per-location limits. Lambda’s explicit concurrency model gives you predictable throttling and recoverable errors.

Decision Matrix: Workers vs Lambda

• Workers: Global API proxy, edge-cacheable or no backend data
• Lambda: CRUD API with centralized database (edge adds nothing)
• Lambda: Event-driven (SQS, S3, DynamoDB streams)
• Lambda: Image/video processing, ML inference
• Workers: Auth, routing, rate limiting at the edge
• Workers (Durable Objects): Stateful coordination (counters, locks, sessions)
• Lambda: Deep AWS ecosystem integration
• Workers: Zero cold start, no exceptions
• Lambda: Batch jobs or processes >30s

Workers: Push notifications, webhook fan-out, global I/O proxying

Conclusion: Should You Move to the Edge?

Before You Migrate: What We Wish We’d Known Earlier

The benchmark data makes a compelling case, but numbers don’t capture the full cost of a migration. Three things worth planning for:

The rewrite. Our push dispatcher was written in Go. Workers runs JavaScript/TypeScript (or Rust/C++ via WASM). This isn’t a config change — it’s a rewrite. For a focused, single-purpose service like ours, that was a weekend. For a service with complex business logic, shared libraries, or deep AWS SDK dependencies, the effort scales fast. Evaluate honestly before committing.

Observability changes. Moving off Lambda means losing CloudWatch, X-Ray, and the AWS monitoring stack you already know. Workers has its own tooling — Workers Analytics, Logpush, Tail Workers for real-time log streaming — but your team needs to learn it. We integrated Sentry for error tracking and Logpush to our existing logging pipeline. Budget time for this.

Rollback strategy. We kept the Lambda deployment active during the first two weeks, routing a percentage of traffic to Workers via weighted DNS. If something went wrong, we could shift back in under a minute. Don’t burn the bridge until you’ve crossed it.

We started investigating a throttling problem on a Lambda that handles 4 million push notifications per week. We ended up rethinking how we deploy I/O-heavy services.

Could we have solved every issue with Lambda? Yes — SQS buffering, concurrency limit increases, async invocation with DLQ. These are mature, well-documented patterns. But Workers made us ask a different question: what if the architecture just handled it?

Not every service belongs at the edge. Most don’t. But if your workload checks three boxes, the conversation is worth having:

1. Your function is mostly I/O, not compute. If 80%+ of execution time is waiting on external APIs, databases, or third-party endpoints, you’re paying Lambda for idle CPU cycles. Workers charges per request regardless of I/O wait time.
2. Your endpoints are globally distributed. If you’re calling APNs in Cupertino, FCM in Mountain View, and webhook receivers across five continents — all from a single Lambda region — every request pays a geography tax. Edge execution eliminates it.
3. Your traffic is spiky and delivery matters. If a marketing campaign can 10x your request volume in seconds, and dropped requests mean missed notifications, the difference between “configure SQS + DLQ + concurrency limits” and “it just scales” is operational cost you pay every sprint.

If none of these apply — if your service talks to a single database in one region, processes data in batches, or integrates deeply with the AWS ecosystem — Lambda is almost certainly the better choice. Use it. It’s excellent.

But if you looked at your CloudWatch dashboard today and saw throttled requests, timeout cliffs, or a cost line dominated by I/O wait — you might be running a regional service that wants to be global.

The edge is not a migration. It’s a different mental model. And for the right workload, it’s the one that disappears.

We Benchmarked Lambda vs Cloudflare Workers on 4 Million Requests — Here’s What the Data Showed was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction: The Testing Confidence Problem

You wrote unit tests. You hit 90% line coverage. Your CI pipeline is green. You feel confident.

Then a bug slips into production.

How? Because line coverage measures what code your tests execute, not what they actually verify. A test can touch every line without asserting a single meaningful behavior. This is where mutation testing enters the picture — and changes everything about how we think about test quality.

Part 1: What Is Mutation Testing and Why Should You Care?

The Core Idea

Mutation testing answers a deceptively simple question: “If I introduced a bug into my code, would my tests catch it?”

Here’s how it works:

1. A mutation testing tool takes your source code and creates mutants — small, deliberate modifications. For example:

• Changing >to >=
• Replacing + with -
• Swapping true for false
• Removing a method call entirely

1. For each mutant, your full test suite runs.
2. If at least one test fails, the mutant is killed — your tests detected the “bug.” Good.
3. If all tests pass despite the mutation, the mutant survived — your tests missed a real behavioral change. Bad.

The mutation score is the percentage of killed mutants:

Mutation Score = (Killed Mutants / Total Mutants) × 100

Why This Matters More Than Line Coverage

Consider this Go function:

func GetNCharsFromString(val string, n int) string {
    if len(val) > n {
        return val[:n]
    }
    return val
}

A test that only calls GetNCharsFromString(“hello world”, 5) and checks the result is “hello” gives you 100% line coverage — every line is executed. But what happens if a developer accidentally changes > to <? Or removes the if block entirely? That single test case might not catch it.

Mutation testing forces you to write tests that don’t just execute lines — they verify behavior at boundaries.

How Unit Tests and Mutation Tests Work Together

Think of it as a hierarchy of confidence:

• Line Coverage — Measures code execution — “Was this line reached?”
• Branch Coverage — Measures decision paths — “Were both sides of if tested?”
• Mutation Testing — Measures assertion strength — “Would my tests catch a real bug here?”

Unit tests are the foundation. Mutation testing is the quality audit of those tests. You can’t do mutation testing without tests — it evaluates whether your existing tests are strong enough.

Part 2: The 100% Myth — A Complete Walkthrough

Let’s walk through a real example, step by step, to see exactly why 100% mutation score is a mirage. We’ll use a small Go function from a production service, take it from green tests all the way through mutation analysis, and watch what happens.

Step 1: The Code — A Simple Utility Function

Here is a real function from a Go microservice. It truncates a string to at most n characters:

// helpers.go
func GetNCharsFromString(val string, n int) string {
    if len(val) > n {
        return val[:n]
    }
    return val
}

Four lines of logic. Nothing exotic. The kind of function every codebase has dozens of.

Step 2: The Tests — 100% Line Coverage

We write a thorough table-driven test suite:

func TestGetNCharsFromString(t *testing.T) {
    testCases := []struct {
        name     string
        input    string
        n        int
        expected string
    }{
        {"string longer than n", "hello world", 5, "hello"},
        {"string equal to n",    "hello",       5, "hello"},
        {"string shorter than n","hi",          5, "hi"},
        {"empty string",         "",            3, ""},
        {"n is zero",            "hello",       0, ""},
        {"single character",     "a",           1, "a"},
    }

    for _, tc := range testCases {
        t.Run(tc.name, func(t *testing.T) {
            result := GetNCharsFromString(tc.input, tc.n)
            assert.Equal(t, tc.expected, result)
        })
    }
}

We run go test -cover:

PASS
coverage: 100.0% of statements

Every line is executed. Every branch is covered. Both the if path (truncation) and the else path (return as-is) are exercised. By traditional metrics, we are done. Ship it.

But are we really?

Step 3: Mutation Testing — The Truth Beneath 100% Coverage

Now we run a mutation testing tool (like gremlins for Go or go-mutesting). The tool systematically injects faults into GetNCharsFromString and checks whether our tests catch them. Here is every mutant it generates:

Mutant 1: Change > to <

if len(val) < n {  // flipped comparison

Our test “string longer than n” expects “hello” but gets “hello world” → TEST FAILS → KILLED

Mutant 2: Change > to ==

if len(val) == n {  // only truncates when exactly equal

Our test “string longer than n” expects “hello” but gets “hello world” → TEST FAILS → KILLED

Mutant 3: Change > to !=

if len(val) != n {  // truncates everything except exact match

Our test “string shorter than n” expects “hi” but gets a panic (slice out of bounds) → TEST FAILS → KILLED

Mutant 4: Change > to <=

if len(val) <= n {  // includes shorter strings in truncation

Our test “string shorter than n” expects “hi” but panics (val[:5] on a 2-char string) → TEST FAILS → KILLED

Mutant 5: Replace return val[:n] with return “”

return ""  // truncation returns empty string

Our test “string longer than n” expects “hello” but gets “” → TEST FAILS → KILLED

Mutant 6: Replace return val with return “”

return ""  // short strings return empty

Our test “string shorter than n” expects “hi” but gets “” → TEST FAILS → KILLED

Mutant 7: Remove the entire if block

func GetNCharsFromString(val string, n int) string {
    return val  // never truncates
}

Our test “string longer than n” expects “hello” but gets “hello world” → TEST FAILS → KILLED

Mutant 8: Change > to >=

if len(val) >= n {  // now truncates when len equals n too

Let’s trace this carefully. When len(val) == n (e.g., “hello” with n=5):

• Original (>): 5 > 5 → false → returns val → “hello”
• Mutant (>=): 5 >= 5 → true → returns val[:5] → “hello”

Both return “hello”. Why? In Go, val[:n] returns the first n bytes. When the string is exactly n bytes long, val[:n] is the entire string. “hello”[:5] takes characters at indices 0, 1, 2, 3, 4 — which IS the complete string “hello”.

For all other inputs (longer or shorter strings), both versions behave identically too — the condition difference only matters at the boundary where len == n, and at that exact boundary, both code paths produce the same output.

No test can distinguish these two versions. No test ever will. This is a textbook equivalent mutant — it is mathematically identical to the original. → SURVIVED (equivalent)

Step 4: The Scorecard

Our tests are excellent. They catch 7 out of 8 possible bugs. But the score is 87.5%, not 100%.

And that is perfectly correct.

Step 5: What If We Try to Reach 100%?

An engineer sees 87.5% and thinks: “One surviving mutant. Let me write a test to kill it.”

The surviving mutant changes > to >=. The only difference is behavior when len(val) == n. So the engineer tries:

{"kill the mutant", "hello", 5, "hello"},

This test passes with both the original AND the mutant. It cannot distinguish them. The engineer tries more variations:

{"try unicode",  "héllo", 5, "héllo"},   // still same behavior
{"try spaces",   "     ", 5, "     "},   // still same behavior
{"try newlines", "ab\ncd", 5, "ab\ncd"}, // still same behavior

Every possible input of length n returns the same result from both versions. The engineer has now spent 30 minutes writing tests that prove nothing and kill nothing. The mutant is equivalent — mathematically identical to the original code.

But the real damage is worse. In pursuit of 100%, teams often write tests like:

// BAD: testing implementation details, not behavior
func TestGetNCharsInternalCondition(t *testing.T) {
    // "verify that the > branch is taken, not >="
    // This is not testing behavior — it's testing syntax
}

These tests are tightly coupled to implementation. They break when you refactor (even if behavior is unchanged), they add maintenance burden, and they give false confidence. You’ve traded real test quality for a vanity metric.

Step 6: What If We Accept 87.5% and Move On?

Our tests already verify:

• Strings longer than n get truncated correctly
• Strings shorter than n pass through unchanged
• Empty strings are handled
• Zero-length truncation works
• The boundary case (len == n) returns the correct value

Every real bug a developer could introduce — flipping the comparison, breaking truncation, removing the guard — is caught. The only “uncaught” mutation is one that produces identical behavior. No user will ever be affected by it. No production incident will ever result from it.

The engineering time saved by not chasing this phantom can be spent writing tests for business-critical code — request validation, error handling, payment processing, security checks — where survived mutants represent actual risk.

The Verdict: 87.5% Is Stronger Than 100%

This walkthrough reveals the paradox: a team with 87.5% mutation score and well-chosen tests has better protection than a team that forced 100% by writing brittle, implementation-coupled tests. The first team tested behavior. The second team tested syntax.

Now multiply this by an entire codebase. A real Go service with 50 functions might generate 500+ mutants. If ~15–25% are equivalent (as research consistently shows), that means 75–125 mutants that cannot be killed. A team chasing 100% would waste weeks investigating each one, writing pointless tests, and building a test suite that resists every refactor.

What Happens at Different Score Levels

To make this concrete, here’s what each mutation score range actually means for your project:

At 60–70% (baseline): Your tests catch most logic bugs, but there are meaningful gaps. Some real mutations — like removing a nil check or flipping an error condition — survive. These are worth investigating and fixing. Focus here delivers high ROI.

At 75–85% (strong): You’ve covered the critical paths. Most surviving mutants are now in cosmetic code (logging, formatting, display strings) or are equivalent mutants. Selective investigation still pays off, but be choosy — only pursue mutants in business-critical functions.

At 85–95% (diminishing returns): Nearly every surviving mutant is either equivalent (mathematically unkillable) or in low-risk code. Each additional percentage point costs exponentially more engineering time. The correct move is to stop pursuing mutation score and invest in integration tests, contract tests, or end-to-end coverage instead.

At “100%” (suspicious): If a team reports 100% mutation score on a non-trivial codebase, one of three things is true: (1) they have very few mutants (tiny codebase), (2) their mutation tool excludes equivalent mutants automatically, or (3) they wrote tests coupled to implementation rather than behavior. Option 3 is the most common and the most dangerous.

The Academic Proof

Now let’s see what the research says. These aren’t blog posts or opinions — they’re peer-reviewed studies from top software engineering venues with thousands of citations.

Reference 1: ~23% of All Mutants Are Equivalent (FSE 2014)

Paper: “Are Mutants a Valid Substitute for Real Faults in Software Testing?” Authors: René Just, Darioush Jalali, Laura Inozemtseva, Michael D. Ernst, Reid Holmes, Gordon Fraser Venue: ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE), 2014 Citations: 800+

This landmark study analyzed thousands of mutants across multiple real-world projects and found that approximately 23% of all generated mutants are equivalent mutants — mutations that produce behavior identical to the original code for all possible inputs.

Important caveat: The ~23% figure is derived from the specific dataset and mutation operators used in this study. The actual equivalent mutant ratio varies by programming language, codebase complexity, and the mutation tool’s operator set. Some codebases may see 15%, others 30% or more. The key takeaway is not the exact number but the consistent finding across studies: a significant, non-trivial portion of mutants in any codebase will be equivalent, and this portion is large enough to make 100% mutation score practically unreachable.

What does this mean practically? If your mutation tool generates 1,000 mutants, a substantial fraction — typically hundreds — cannot be killed by any test ever written. They are ghosts in the machine — scored against you, but impossible to eliminate.

This puts a realistic ceiling well below 100% on the mutation score for most codebases. Teams chasing perfection are fighting a wall that mathematics will not let them break through.

What does this mean practically? If your mutation tool generates 1,000 mutants, roughly 230 of them cannot be killed by any test ever written. They are ghosts in the machine — scored against you, but impossible to eliminate.

This puts a theoretical ceiling of approximately 77% on the mutation score for most codebases. Teams chasing 100% are fighting a wall that mathematics will not let them break through.

Reference 2: Equivalent Mutant Detection Is Undecidable (IEEE TSE 2011)

Paper: “An Analysis and Survey of the Development of Mutation Testing” Authors: Yue Jia, Mark Harman Venue: IEEE Transactions on Software Engineering, 2011 Citations: 3,000+

This comprehensive survey of 40 years of mutation testing research confirms an even deeper problem: determining whether a mutant is equivalent is mathematically undecidable. This was formally proven by Budd and Angluin in 1982 — it’s not an engineering limitation, it’s a fundamental result in computability theory, in the same class as the Halting Problem.

No tool, no algorithm, no amount of engineering effort can reliably distinguish equivalent mutants from killable ones in all cases. The mutation testing community’s recommended approach: focus on incremental improvement, not absolute perfection.

Reference 3: The Practical Ceiling Effect (ICSE 2014)

Paper: “An Industrial Application of Mutation Testing: Lessons, Challenges, and Research Directions” Authors: Bob Kurtz, Paul Ammann, Jeff Offutt Venue: International Workshop on Mutation Analysis (Mutation), co-located with ICSE 2014

This study applied mutation testing in an industrial setting at Google and found that even with significant engineering investment, practical mutation scores plateaued around 70–80%. Beyond that threshold, the cost of investigating each surviving mutant exceeded the value of the insight gained.

Reference 4: When More Tests Hurt (ISSTA 2014)

Paper: “Coverage Is Not Strongly Correlated with Test Suite Effectiveness” Authors: Laura Inozemtseva, Reid Holmes Venue: International Symposium on Software Testing and Analysis (ISSTA), 2014 Citations: 600+

Perhaps counterintuitively, this study found that after controlling for test suite size, coverage metrics (including mutation score) show only moderate correlation with fault detection ability. The quality of test oracles (assertions) matters far more than raw coverage numbers. Writing ten mediocre tests to kill cosmetic mutants is worse than writing one thoughtful test that validates critical business behavior.

Another Real-World Trap: Cosmetic Mutations

The boundary equivalent mutant is not the only trap. Consider this Sentry error logging function from the same codebase:

func captureErrorWithContext(err error, errorType string) {
    errorMessage := err.Error()
    var errorTitle string

    if len(errorMessage) > 50 {
        errorTitle = errorMessage[:50] + "..."
    } else {
        errorTitle = errorMessage
    }

    errorTitle = strings.ReplaceAll(errorTitle, "\n", " ")
    errorTitle = strings.TrimSpace(errorTitle)

    sentry.CaptureEvent(&sentry.Event{
        Message: errorTitle,
        // ...
    })
}

Mutations here include:

• Changing 50 to 49 or 51 (truncation threshold)
• Removing the strings.ReplaceAll call (newline replacement)
• Removing the strings.TrimSpace call

All of these affect only how an error title appears in the Sentry dashboard. The actual error is still captured. The system still works. No business logic changes. No user impact.

Writing tests to kill these mutants means:

• Zero business value — the system behaves identically from a user perspective
• Brittle tests — they’ll break whenever someone adjusts the display format
• Wasted engineering time — every hour spent here is an hour not spent testing request validation or error classification

These are not equivalent mutants (they do change behavior), but they are low-value mutants — the behavioral change has no business significance. Chasing 100% forces you to test things that don’t matter.

The Practical Scoring Guide

Based on the research and real-world experience, here’s how to interpret your mutation score:

• < 40% — Critical test gaps. Major investment needed. Focus on business logic: validation, state transitions, error handling.
• 40–60% — Significant room for improvement. Write tests for survived mutants in core business logic. Skip logging/formatting mutations.
• 60–75% — Good, solid baseline. You’re approaching the practical ceiling. Be selective — only pursue high-value survived mutants.
• 75–85% — Strong coverage. Most remaining survivors are equivalent or cosmetic. Shift focus to integration/E2E tests.
• > 85% — Exceptional (or suspicious). Verify you’re not writing tests solely to kill mutants. Check for test-to-implementation coupling.

What to Focus On Instead

If not 100% mutation score, then what? Here’s a prioritized framework:

Tier 1: Always Test (high mutation kill priority)

• Input validation — boundary conditions, null/empty checks, type coercion
• Business rules — pricing calculations, eligibility checks, state machines
• Error classification — correct HTTP status codes, error types, retry decisions
• Security-sensitive paths — authentication, authorization, data sanitization

Tier 2: Test When Practical (medium priority)

• Data transformations — mapping, aggregation, formatting for API responses
• Conditional branching — feature flags, A/B test routing, partner-specific logic

Tier 3: Skip or Accept Survivors (low priority)

• Logging format strings — log level, message templates, structured fields
• Observability cosmetics — dashboard titles, alert formatting, metric labels
• Configuration defaults — port numbers, timeout values, buffer sizes (test at integration level instead)

Conclusion: Mutation Testing Is a Diagnostic, Not a Target

Mutation testing is one of the most powerful tools in a software engineer’s testing arsenal. It reveals the difference between tests that execute code and tests that verify behavior. Every engineering team should use it.

But like any diagnostic tool, it measures — it doesn’t prescribe. A blood pressure reading of 120/80 is healthy; obsessing over reaching 100/60 would be harmful. Similarly, a mutation score of 70% with strong business logic coverage is far more valuable than 95% achieved by writing brittle tests for log formatting.

The research is unambiguous:

• ~23% of mutants are equivalent and cannot be killed (Just et al., FSE 2014)
• Equivalent mutant detection is undecidable — this is a mathematical fact (Budd & Angluin, 1982; Jia & Harman, IEEE TSE 2011)
• Practical scores plateau at 70–80% in industrial settings (Kurtz et al., ICSE 2014)
• Coverage quantity matters less than assertion quality (Inozemtseva & Holmes, ISSTA 2014)

Write tests that protect your users. Kill the mutants that matter. Accept the ones that don’t.

And if someone asks why you’re not at 100% — hand them this article and the four papers cited above.

Automate It: The Mutation Guard Plugin for Claude Code

Everything described in this article — running coverage, executing mutation tests, classifying survivors, writing the missing tests — can be fully automated with a single plugin.

Mutation Guard is an open-source Claude Code plugin that brings mutation testing into your AI-assisted development workflow. Two commands. That’s it.

Step 1: Analyze — See the gaps

/mutation-guard ./services

Claude auto-detects your language (Go today, PHP/Node.js/Java coming), runs coverage analysis, executes mutation testing, classifies every survived mutant by production risk, and produces a full quality report — including the “false confidence” detection described in Part 2 of this article.

Step 2: Fix — Close the gaps

/mutation-guard-fix ./services

Claude reads your existing test patterns (table-driven tests, testify, gomock — whatever your project uses), writes tests that kill the survived mutants starting from Critical priority, verifies everything passes, and shows a before/after comparison.

What does this mean in practice?

A Go service with 50–70% coverage can reach effective maximum coverage — every line that CAN be tested IS tested — in minutes to hours depending on codebase size. Not days. Not sprints. The plugin handles the tedious work: analyzing which mutants matter, reading your test conventions, writing tests that match your patterns, and verifying they actually kill the mutants.

The key phrase is “effective maximum coverage” — not 100% mutation score (as this article explains, that’s neither achievable nor desirable), but a state where every coverable line is tested and every killable mutant is killed. Only equivalent mutants and dead code remain.

Real results from production Go services:

Coverage jumps of +15–25% in a single session

Mutation score improvements of +20–30%

False confidence detection — files with 85%+ coverage but <50% mutation score get flagged immediately

Zero source code modifications — only test files are created or edited

Install it:

claude plugins add github:rezafarzaneh7/claude-code-plugins/plugins/mutation-guard

The plugin is open source (MIT license) and works on any Go project. No configuration needed — point it at a directory and let it work.

GitHub: github.com/rezafarzaneh7/claude-code-plugins

Scale isn’t just about big numbers — it’s about billions of requests, billions of instant notifications, and hundreds of microservices every single day; if you want to build that, check out the open positions at Insider One.

References

1. Just, R., Jalali, D., Inozemtseva, L., Ernst, M.D., Holmes, R., & Fraser, G. (2014). “Are Mutants a Valid Substitute for Real Faults in Software Testing?” Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014).
2. Jia, Y., & Harman, M. (2011). “An Analysis and Survey of the Development of Mutation Testing.” IEEE Transactions on Software Engineering, 37(5), 649–678.
3. Kurtz, B., Ammann, P., & Offutt, J. (2014). “An Industrial Application of Mutation Testing: Lessons, Challenges, and Research Directions.” International Workshop on Mutation Analysis (Mutation 2014), co-located with ICSE.
4. Inozemtseva, L., & Holmes, R. (2014). “Coverage Is Not Strongly Correlated with Test Suite Effectiveness.” Proceedings of the 2014 International Symposium on Software Testing and Analysis (ISSTA 2014).

Why 100% Mutation Score Is Neither Necessary Nor Achievable — And Why That’s Perfectly Fine was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reza Farzaneh — Staff Software Engineer

We built this methodology over a one-week experimental AI workshop, iterating across different teams, combining elements from various methodologies with our own internal best practices. The result was a 50% improvement in delivery speed — and that’s just the starting point. As teams mature and AI usage deepens, more will come naturally.

• • •

In physics, torque is what happens when a small force, applied at the right distance from a pivot point, creates massive rotational movement. A wrench doesn’t need to be strong. It needs to be long, and it needs to grip at the right place.

If you’ve read Part 2 of this series, you already know the story. Six teams. Five days. Features estimated at a month each under traditional sprint planning — completed in hours. A methodology that worked so well it scared us. And the honest decision to go back to Scrum because our teams weren’t ready for the full shift.

You also know the name.

Torque.

We picked the name as Torque with Talha Siviş, the Product Manager on our team (AgentOne) — someone that I called him our Bill Gates :), because he’s always inventing something. We decided to use physics metaphor: a small force, applied at the right leverage point, creates massive movement. It stuck.

What you don’t know yet is how it works. Not the story. Not the emotions. The actual methodology — the principles, the phases, the rules, the metrics. Everything an engineering team would need to understand it, evaluate it, and — if they’re ready — try it.

This is that document.

• • •

Why This Exists

After years of operating with Scrum across multiple teams, we kept hitting the same walls. Not engineering walls. Process walls.

Ceremony overhead was consuming 6–10 hours per week per developer — standups, grooming, planning, retros — with diminishing returns. Context switching from scattered meetings destroyed deep work blocks. Async communication noise turned 10-minute questions into day-long Slack threads. Unclear phase ownership left features drifting without clear gates. Cross-team dependencies created multi-day blockers with no urgency protocol. And our metrics — velocity, story points — measured effort, not outcomes.

These aren’t unique problems. Every engineering organization running Scrum at scale knows them. The question is whether you accept them as the cost of doing business, or whether you build something that eliminates them structurally.

We built Torque.

• • •

Five Core Principles

Torque runs on five principles. Everything else in the methodology flows from these.

1. The 3 or 4 Hour Focus Block. Every team has a mandatory 3 or 4 hour daily overlap block. All members fully present. Slack, email, notifications OFF. All planning, discussion, pairing, and problem-solving happens here. This is the engine. Not a suggestion. A hard rule.

2. Phase-Gated Delivery. Every feature moves through defined phases with clear entry and exit criteria. No phase begins without the previous phase being complete. Phases are gated by outcomes, not by calendar dates.

3. Feature-Aligned Teams. Small, cross-functional squads — max 8, optimal 6 — assembled per feature. Each squad has all the skills needed to ship independently.

4. Zero Ceremony Overhead. No daily standups. No grooming. No sprint planning. Everything happens organically within the 4-hour block. The team documents plans as markdown files instead of meeting notes.

5. AI-Accelerated Execution. In the AI era, changes that used to take days should take hours or minutes. Cross-team dependencies, design iterations, bug fixes — all should reflect this speed.

• • •

Team Structure

Each feature squad: (can be AI Agents with good skills and knowledge base)

• Product Manager (1): Owns PRD (Product Requirements Document), prioritization, stakeholder communication.
• Backend Engineer (1–2): Scale to 2 for heavy API/infrastructure features.
• Frontend Engineer (1–2): Scale to 2 for complex UI-heavy features.
• QA Engineer (1): Embedded from Phase 1; writes test plans during design.
• Designer (0.5–1): Can be shared across 2 squads if workload allows.

Total team size must never exceed 8. The constraint ensures communication overhead stays low and accountability stays high. It could be changed by team dynamic — you can just use Agents, not human resource, but with good skill and learning.

• • •

The Four Phases

Every feature follows four phases, from Phase 0 (pre-discovery) through Phase 3 (ship).

Phase 0 — Pre-Discovery

Owner: PM + Designer. This happens before the feature enters the team pipeline.

The goal: ensure the feature arrives at the team fully validated. Clear problem definition. Legal clearance. Design readiness.

The PM identifies and documents the exact customer problem — with data, user research, and business justification. Any regulatory or compliance requirements are resolved upfront. The designer creates initial concepts, user flows, and wireframes. Stakeholders are aligned on scope and expected outcome.

Exit criteria: Validated customer problem with data. Legal/compliance clearance. Initial design direction. Stakeholder sign-off. Draft PRD ready for team review.

Why Phase 0 matters: Without it, teams spend the first days asking “why are we building this?” and “has legal approved this?” Phase 0 eliminates these questions entirely. When a feature reaches Phase 1, the team’s only job is to figure out HOW — the WHAT and WHY are already resolved.

This is the hidden variable. The reason we could compress development to hours wasn’t just the methodology or the AI. It was the preparation.

Phase 1 — Discovery & Alignment

Goal: Ensure the entire team has a shared understanding of what will be built and why.

The full team discusses UX/UI approach, user flows, and technical feasibility during the 4-hour block. The PM presents requirements. Engineers validate scope and raise concerns. The PRD is collaboratively refined and finalized.

Exit criteria: Signed-off PRD. Agreed technical approach. Identified dependencies. Initial task breakdown.

Phase 2 — Build & Integrate

Goal: Complete all backend and frontend development, resolve blockers in real-time.

Backend and frontend development happens in parallel. Daily progress is reviewed during the 4-hour block. Blockers are surfaced and resolved immediately — no waiting for async responses. If a cross-team dependency exists, it’s escalated as URGENT. The team gathers the relevant people into a focused alignment session — resolve it, agree on the contract, move on.

Exit criteria: Feature is code-complete, integrated, and marked “Ready to Test.”

Phase 3 — Validate & Ship

Goal: Ensure quality, release confidently, confirm it works.

The whole squad participates in rapid testing — not just QA. Issues found are fixed immediately. Edge case discussions happen in the 4-hour block. Then: deploy with appropriate feature flags and monitoring.

Post-release monitoring runs on time-based windows. We recommend starting with 4-hour, 24-hour, and 72-hour checkpoints as a baseline — but teams should adjust these intervals based on feature risk, traffic patterns, and their own comfort level. The important thing is having defined checkpoints, not the exact timing. Monitoring runs passively — the team enters cool-down while monitoring continues in parallel.

Exit criteria: Feature released. First monitoring checkpoint clean. Monitoring dashboards configured.

• • •

Real Timeline: Phase Ratios, Not Fixed Hours

One of the things that separates Torque from Scrum is phase-level visibility. In Scrum, a 2-week sprint is a black box — you know the total output, but you have no idea how much time went to discovery, how much to build, how much to testing. Velocity measures throughput. It doesn’t tell you where the bottleneck is.

In Torque, every phase has a measurable ratio within the Cycle Bet. This gives teams — and leadership — a structural view of where time goes and where it gets stuck.

The Phase Ratio Framework

Phase 1 (Discovery & Alignment): ~10–15% of the Cycle Bet

Phase 2 (Build & Integrate): ~60–65% of the Cycle Bet

Phase 3 (Validate & Ship): ~20–25% of the Cycle Bet

These are starting ratios. After 5–10 cycles, each team will have their own baseline. The ratios matter more than the absolute hours — they reveal structural patterns that fixed estimates never show.

What This Looks Like in Practice

8-hour Cycle Bet (Small feature):

Phase 1: ~1h | Discovery, PRD handshake, tech approach agreed.

Phase 2: ~5h | BE + FE build, pairing, integration. Blockers resolved live.

Phase 3: ~2h | Test camp, bug fixes, release.

40-hour Cycle Bet (Large feature):

Phase 1: ~4–6h | Deeper discovery, dependency mapping, design review.

Phase 2: ~24–26h | Parallel BE/FE streams, cross-team alignment sessions.

Phase 3: ~8–10h | Comprehensive testing, staged rollout, monitoring setup.

After the active cycle is done, monitoring checkpoints run passively. We used 4h–24h–72h intervals, but teams should define their own cadence based on feature risk and traffic. The team enters cool-down while monitoring continues in parallel. (these can be days/week — regarding to team manifest)

Why Phase Ratios Matter

Fixed hour estimates tell you whether you were fast or slow. Phase ratios tell you why.

Phase 1 consistently above 20%? Phase 0 preparation is probably insufficient — features are arriving at the team with unclear requirements or unresolved dependencies.

Phase 2 pushing past 75%? Build is expanding, which usually means scope creep or technical unknowns that weren’t surfaced in discovery.

Phase 3 shrinking below 15%? Testing is getting squeezed — this is where bug escape rates start climbing.

Phase 3 growing past 30%? Quality issues in build — the team is finding too many problems too late.

In Scrum, these patterns are invisible. You see velocity go up or down, but you don’t know which phase caused it. Phase ratios make the diagnosis structural, not anecdotal.

Phase Ratio as a Team Health Metric

Over time, each team develops a “healthy ratio” baseline. When the ratio drifts, it’s an early signal — before the Cycle Bet is missed, before bugs escape, before the team feels the pressure. It turns retrospective firefighting into proactive calibration.

Track these per cycle: actual hours per phase, phase ratio vs. baseline, and phase transition time (how long between phase completion and next phase start — target: less than 1 business day). These three numbers give you more diagnostic power than velocity and story points combined.

• • •

The 4-Hour Focus Block: The Engine

This deserves its own section because it’s the single most important element of the methodology.

The rules: Slack/Teams/email OFF. All team members present. Camera on (remote) or co-located. No external meetings allowed. Plans documented as .md files.

What happens here: Daily planning & progress review. Blocker resolution. Design discussions & PRD work. Bug triage & security reviews. Cross-team dependency escalation.

Imagine you’re debugging a cross-service issue. In Scrum, you hit the bug at 10 AM. You post in Slack. The backend engineer is in grooming until 11. They see your message at 11:30. You’re in your own standup at noon. By 2 PM you’ve exchanged six messages and still haven’t been in the same conversation at the same time.

In a Torque focus block, you turn to the backend engineer — who is right there, focused on the same feature — and solve it in 20 minutes. That’s not a productivity hack. It’s a structural elimination of communication overhead.

Cross-Team Dependency Handling

When a team identifies a cross-team dependency during the focus block, they don’t wait or send a Slack message into the void.

1. Identify the dependency and the people needed to resolve it.
2. Pull those people into a short, focused alignment session — 15–30 minutes.
3. Agree on the contract (API spec, data format, timeline) and document it.
4. Continue independently. No follow-up meetings needed.

The alignment session is not a ceremony — it’s a surgical intervention. It involves only the people who can resolve it and ends with a documented agreement.

• • •

Interruption Handling: The Peel-Off Pattern

The most common objection to any focused methodology: “What happens when something urgent comes in?”

Torque has a clear answer: urgent work enters the pipeline without breaking the cycle.

Production Incidents — Peel-Off & Rejoin

During our experiment, we had 2 production incidents and 2 urgent ad-hoc requests. Here’s the pattern:

1. Detect & Assess. Incident detected. Team briefly assesses severity together — less than 5 minutes.
2. Peel Off. 1–2 team members peel off and take full ownership.
3. Investigate & Fix. They work independently. They do NOT attend the focus block.
4. Rejoin. Once resolved, they rejoin with a brief 5-min handoff.

The feature cycle never stops. Total disruption across four interruptions during our experiment: zero.

Urgent Requests — Quick Peel-Off

A single team member peels off for approximately 1 hour, handles the request, and rejoins. No cycle disruption.

The philosophy: Nothing is blocked, everything has a path. The team’s primary cycle delivers the highest-value outcome without losing momentum.

• • •

Cycle Estimation: The Cycle Bet

Torque doesn’t use story points. It uses a structured approach based on complexity tiers and historical data.

Step 1: Classify Feature Complexity

S — Small: Single domain, no cross-team deps, clear requirements. Add a filter, new API endpoint. Typical cycle: 3–5 working days.

M — Medium: Multi-domain (BE + FE), 1–2 deps, some design complexity. New product page, payment flow update. Typical cycle: 1–2 weeks.

L — Large: Full-stack, multiple deps, new infrastructure. New product vertical, major architecture change. Typical cycle: 2–4 weeks.

Rule: If a feature exceeds 4 weeks, it must be split. No single feature runs longer than 4 weeks end-to-end.

Step 2: Place the Bet

The team commits to a specific hour budget for the entire cycle. Not a guess — a team commitment based on the tier, historical data, and the feature’s specifics. During execution, actual hours per phase are tracked with a simple log at the end of each focus block. When done, actual hours are compared to the bet and feed back into the baseline.

Practical Example

Feature 1 from our experiment was originally estimated at 2 sprints (4 weeks) under traditional method:

Team: 2 BE, 1 FE, 1 QA

Complexity: L — Large

Cycle Bet: 2 weeks

Actual: 12 Days ✓

The Cycle Bet measures wall-clock hours (elapsed time), not person-hours. The bet is about delivery speed, not effort allocation.

Why This Is Better Than Story Points

Story points measure in abstract units. The Cycle Bet measures in hours — universally understood. Story points are decided by planning poker, often dominated by the loudest voice. The Cycle Bet is discussed during the Phase 1 focus block. Story points have no real commitment. The Cycle Bet is a commitment: beat it or learn why you didn’t.

After 5–10 features, each team has a reliable per-tier baseline. “Our last 4 Medium features averaged 8 working days” is far more useful than “we do ~40 points per sprint.”

• • •

The Team Manifest: Know Your Engine Before You Race

Not every team is the same. And in an AI-accelerated methodology, the differences become more visible — not less.

One team might have engineers who’ve built custom AI skills, automated repetitive workflows, and can ship a medium feature in 3 days. Another team might still be figuring out how to use AI effectively for code generation, spending more time reviewing AI output than writing from scratch. Both teams are competent. But their cycle capacities are different — and pretending otherwise leads to unrealistic bets and frustration.

The Team Manifest makes this explicit.

What Is the Team Manifest?

Before a team starts its first Torque cycle, they create a short, honest self-assessment document — the Team Manifest. It captures who the team is, how they work, and what their current AI capability looks like. It’s not a performance review. It’s a calibration tool.

The manifest is revisited and updated after every 5 cycles. It’s a living document that grows with the team.

What Goes Into the Manifest

1. Team Composition & Skills. Who’s on the team, what are their strengths, where are the gaps. Not just roles — actual capabilities. “We have 2 senior backend engineers comfortable with distributed systems” is more useful than “2 BE.”

2. AI Maturity Level. This is the critical variable. The team honestly assesses where they are:

• Level 1 — Exploring: Using AI for basic code completion, occasional question-answering. AI saves some typing but doesn’t fundamentally change the workflow.
• Level 2 — Integrating: AI is part of the daily workflow. Code generation, test writing, debugging assistance. Engineers review and refine AI output rather than writing everything from scratch.
• Level 3 — Accelerating: Custom prompts, project-specific AI skills, automated workflows. AI handles boilerplate and repetitive patterns. Engineers focus on architecture, edge cases, and integration.
• Level 4 — Multiplying: AI agents handle significant portions of implementation. The team has built reusable skills and templates. Feature development time is measured in hours, not days, for most complexity tiers.

3. Cycle Bet Baseline. Based on the AI maturity level and team skills, the team sets their initial Cycle Bet expectations per complexity tier. A Level 2 team might bet 2 weeks on a Medium feature. A Level 4 team might bet 4 days on the same feature. Both bets are valid — because they’re calibrated to reality.

4. Known Constraints. Dependencies on other teams, shared designers, infrastructure limitations, domain knowledge gaps. Anything that affects cycle speed beyond the team’s direct control.

5. Growth Targets. Where does the team want to be in 5 cycles? What specific AI capabilities or workflow improvements are they working toward? This turns the manifest from a snapshot into a trajectory.

How the Manifest Changes the Conversation

Without the manifest, you get two failure modes:

Failure mode 1: Leadership sees one team shipping in 3 days and asks why another team takes 2 weeks for similar work. Without context, this becomes pressure instead of understanding.

Failure mode 2: Teams compare themselves to each other and either overcommit (leading to quality issues) or get demoralized (leading to disengagement).

The manifest prevents both. When a team’s Cycle Bet is grounded in their documented AI maturity and skill profile, the conversation shifts from “why are you slow?” to “what do you need to get faster?”

It also creates a natural improvement path. A Level 2 team isn’t failing — they’re at Level 2 and working toward Level 3. The manifest tracks that progression with concrete evidence: cycle times shortening, phase ratios stabilizing, AI usage expanding.

Manifest as a Living Document

The manifest isn’t a one-time exercise. After every 5 cycles:

• Update AI Maturity Level based on actual usage patterns and cycle results.
• Recalibrate Cycle Bet baselines with real data from completed features.
• Review growth targets — were they met? What’s next?
• Adjust team composition notes if members changed or new skills were acquired.

Over time, the manifest becomes a team’s engineering identity — not imposed from above, but built from within. It’s the team saying “this is who we are, this is what we can deliver, and this is where we’re headed.”

• • •

Cool-Down: The Space Between Cycles

After Phase 3 and before the next feature, the team enters cool-down. Not idle time — the work that keeps the codebase healthy.

• Tech Debt: Refactor code flagged during the cycle. Improve test coverage. Optimize slow queries.
• Security: Apply patches. Resolve vulnerability findings. Update dependencies.
• UX Improvements: Polish rough edges. Fix visual inconsistencies. Address usability feedback.
• Tooling & DX: Improve CI/CD. Update dev tooling. Automate repetitive tasks.
• Knowledge Sharing: Document decisions. Update runbooks. Share learnings.

Duration: Small features: 1 week. Medium: 2 weeks. Large: 4 weeks. (depending on team manifest)

Cool-down is not optional. It is not skippable under deadline pressure. A team that ships without cool-down has deferred work that will slow the next cycle.

The Organizational Debt Warning

Torque + AI driven development gives engineering unprecedented shipping speed. But your organization is not just engineering. Customer Success, Sales, Support, Marketing, Documentation — they all need to absorb every feature you ship.

If you push features at maximum velocity without cool-down, you create organizational debt. CSMs can’t onboard fast enough. Sales can’t learn new capabilities. Support gets buried in tickets for features they haven’t been trained on.

That said, this is variable for every company. Not every organization has these dynamics. Some teams operate with lean support structures where engineering ships directly to users. Some have strong self-serve documentation cultures where the gap between shipping and adoption is small. The point isn’t that every company will experience organizational debt the same way — the point is to be aware of it as a risk and calibrate your cool-down accordingly.

Torque enables you to build features both fast and with high quality. That’s the real superpower — not just speed alone. Protect the balance.

• • •

Product Validation: See It Used, Feel the Impact

Shipping is not the finish line. The team that built it should see it being used by real users.

In traditional frameworks, the engineer who built a feature never sees whether it solved the problem. This disconnects effort from impact. In Torque, we allocate time deliberately:

• Usage Observation — After 72h monitoring is clean, review real user interactions: analytics, session recordings, feedback.
• Outcome Check — Does it solve the Phase 0 problem? Are success metrics moving? Within 1 week.
• User Feedback Loop — Direct feedback from users or customer-facing teams. First 2 weeks.
• Impact Debrief — 15–30 min in a focus block. Not a retrospective — a data review. After 1–2 weeks.

The cycle is not complete when code is in production. It is complete when the team has confirmed it delivers value.

• • •

Metrics & KPIs

These replace traditional velocity and story points (depending on the team manifest):

• Feature Cycle Time: Phase 1 → Phase 3 Done. Target: 30–40% reduction vs. Agile within 2 quarters.
• Phase Ratio Baseline: Actual phase ratio vs. team baseline (starting point: ~10–15% / ~60–65% / ~20–25%). Drift signals structural issues.
• Phase Transition Time: Handoff delays between phases. Target: < 1 business day.
• Blocker Resolution Time: Target: < 4 hours.
• Bug Escape Rate: Production bugs after Phase 3. Target: < 5%.
• Focus Block Utilization: All members present. Target: > 90%.
• Cross-Team Dependency SLA: Alignment within 4 hours; delivery same day.
• Ceremony Time Saved: Target: 4–6 hours/week per engineer.
• Post-Release Stability: Zero P1 incidents within the monitoring window (we default to 72h).
• Estimation Accuracy: Actual vs. estimated. Target: ±15% after 5 cycles.
• Cool-Down Completion: 100%. Never skipped.
• Team Manifest Review: Updated every 5 cycles. AI maturity level tracked and progressing.
• Product Validation: 100% impact debrief within 2 weeks.

• • •

We Are Still Agile — Just Without the Ceremonies

Torque does not abandon Agile. It IS Agile — in the truest sense.

When a partner sends an urgent request, we pull it into the phase pipeline immediately. When a critical bug surfaces, it enters the same flow. When a design change is needed mid-Phase 3, we accept it — because AI-assisted development makes rapid iteration possible.

The difference: we deliver this responsiveness through focused collaboration blocks and phase gates, not through ceremonies that have become bureaucratic overhead.

Important Note :

We say optimal 6 because in the AI era, every additional person adds more alignment overhead than execution power. AI handles the throughput that used to require extra hands — what it can’t handle is the communication complexity that grows with every new voice in the room. Fewer people, more focus, faster decisions. And honestly, as teams mature in their AI usage and manifests evolve, we expect this number to go even lower.

• • •

The Experimental Results

This methodology has been validated across 6 engineering teams at Insider One. The full story is in Part 2, but here are the numbers:

6 features across 6 teams. Each had existing sprint estimates under traditional Agile planning. Development cycles compressed from weeks to hours.

Total Agile estimate: 2 sprints (4 weeks).

Total actual development: 2 weeks across 6 teams.

The development cycle compressed far beyond 50%. But when you account for the full production pipeline — reviews, staging, rollout — 50% end-to-end improvement is what we guarantee.

These results reflect the combined effect of Torque + AI-driven development. Torque provides structure and focus. AI provides execution speed. The multiplier is in the combination.

• • •

The Honest Status

If you’ve read Part 2, you know we went back to Scrum after the experiment. Not because the methodology failed — the numbers make that argument impossible. Because we weren’t ready yet, lessons were learned. Process change is identity change, and identity change takes time.

But we’re not going back to the same Scrum. AI-driven development runs inside every sprint.

The methodology is proven. The rollout is phased. When the people say they’re ready, we’ll make the full switch.

• • •

Try It

If you’re reading this and thinking “this sounds like what my team needs” — start small.

1. Protect one 3 or 4 hours focus block per day. Slack off. Notifications off. Everyone present. See what happens to blocker resolution. (You can define it in your team manifest)
2. Try Phase 0 on your next feature. Have PM and designer fully validate the problem before it reaches engineering. See how much faster Phase 1 goes.
3. Run a Cycle Bet alongside your story points. Estimate in hours and track accuracy. Compare to velocity predictions. With all team members and with exact details about feature.
4. Add a cool-down day at the end of your sprint. Half a day. Tech debt, security, polish. See if the next sprint goes faster.

Or — if you’re building a new team from scratch:

If you’re hiring a new team or forming a new squad within your department, this is actually the easiest path to Torque. New hires don’t carry the habits of your existing process. They don’t need to unlearn standups, story points, or sprint rituals. They start with focus blocks, phase gates, and Cycle Bets as their default — it’s just how they work from day one. You skip the hardest part of any methodology change: breaking old patterns.

You don’t need to abandon Scrum overnight. That’s the lesson we learned. But you can start gripping the lever at the right point — and see what moves.

• • •

>50% faster KR (Key Result) delivery. That’s our guarantee.

Small force. Big movement. That’s Torque.

The methodology is open. The results are real. The only question is readiness.

• • •

This is the companion piece to Part 2: 50% Faster. Guaranteed. — which tells the story of the experiment. This article documents the methodology itself.

Read Part 1 for the origin story — how we pulled a team out of Scrum and started the experiment that led to Torque.

How We Achieved a 50% Speed Increase Using the Torque Methodology was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reza Farzaneh — Staff Software Engineer

Part 2 of 3— The experiment is over. Here are the results.

In 212 BC, Archimedes reportedly told King Hieron: “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” He wasn’t bragging about strength. He was making a point about physics — that the right mechanism, applied at the right point, produces movement wildly disproportionate to the force applied.

Twenty-two centuries later, engineers are still trying to move the world. Except now we call the lever “process,” the fulcrum “planning,” and the force “headcount.” And when things don’t move fast enough, we add more people, more sprints, more ceremonies — more force — instead of questioning whether we’re pushing at the right point.

This isn’t a thought experiment. This is what happened when I sat with six teams for five days, elbow to elbow, and watched everything we assumed about engineering velocity fall apart.

The Promise We Made

In Part 1, we told you we were pulling a team out of Scrum. We told you about ByteMaster — our guinea pig team. We told you about Shape Up’s philosophy, our curated backlog, our first shaped cycle. And we made a promise: whatever happened — success, failure, or something messy in between — you’d get the truth.

We also said the experiment might produce something with its own name.

It did.

We call it Torque.

And if you’re wondering which of the three outcomes this is — “it worked,” “it partially worked,” or “it failed” — the honest answer is the most complicated one. The numbers were extraordinary. The methodology proved itself. But the humans inside it? They weren’t ready. And that’s the story worth telling.

Five Days, Elbow to Elbow

Let me tell you what actually happened in that room.

We had been planning an AI workshop — a company initiative to accelerate AI-driven development across the engineering org. Six teams. Five days. Hands-on AI tooling. That was the original plan. But the ByteMaster results from Part 1 changed the conversation. What if the workshop wasn’t just about AI tools? What if it was about the methodology that makes AI tools actually productive?

So we made the call. Six teams. Six features pulled from their current roadmaps — features that each had roughly a month of sprint estimates under traditional Agile planning. Each team would run Torque combined with AI-driven development for the full five days. The goal was clear: measure how much we could compress the development cycle when you remove the ceremony overhead and let AI do what AI does best.

And I would be there. Not managing. Not observing from a dashboard. Sitting with them. Working alongside them. Watching every decision, every blocker, every moment of confusion and every moment of clarity.

The Setup

Here’s what each team walked in with on Day 1:

• A ready PRD. The product requirement document was written, reviewed, and finalized before the workshop started. No one had to ask “what are we building?” on Day 1.
• Mock designs in Figma. Not pixel-perfect finals, but clear enough to build from. The design direction was set. User flows were mapped. The team knew what the feature should look and feel like.
• A clear problem to solve. Every team knew which customer problem their feature addressed. The “why” was resolved. The “what” was defined. The only open question was “how fast can we build it?”
• AI tooling at their fingertips. Every developer had access to AI-assisted code generation, automated test creation, and intelligent code review. The tools were ready. The question was whether the process would let the tools breathe.

The plan was straightforward: start with a 4-hour focused discussion to align on the technical approach, then immediately move into execution and quality phases. No standups. No grooming. No sprint planning. Just build.

The Numbers: Month-Long KRs, Done in a Day

Here’s what happened. Each of these features was estimated at roughly one month of sprint work under our existing Agile planning. The table shows how long the actual development cycle took with Torque + AI-driven development.

Read that again. Features estimated at a month each under traditional sprint planning. Development cycles completed in half a day to a day and a half. Six teams. Six features.

A critical clarification before we go further: these numbers represent the development cycle only — from the first discussion through code-complete. Not production. None of these features shipped to production during the five-day workshop. The design was ready in Figma as mocks. The PRD was written. The problem was understood. What we measured was how fast teams could go from “aligned on what to build” to “code-complete and tested.” That was the whole purpose of this experiment: to measure the compression in the development cycle.

The road to production is longer. Code reviews, integration testing, staging validation, feature flag configuration, monitoring setup, stakeholder sign-off, gradual rollout — the full path from code-complete to live-in-production takes roughly one week on average at our org. That hasn’t changed. What changed is the development cycle that feeds into that pipeline.

So here’s the real claim — and it’s one we’re confident enough to guarantee: AI-driven development delivers a minimum 50% improvement in KR delivery speed. That’s the floor, not the ceiling. If a KR takes a month today, it should take two weeks with this approach. The development cycle itself compressed far beyond 50% in our experiment. But when you account for the full production pipeline — reviews, staging, rollout — 50% end-to-end is what we’d stake our reputation on. The actual results in the workshop exceeded that number. But we’re not here to sell you on best-case scenarios. We’re here to tell you what we can guarantee.

The speed comes from focused methodology and AI-driven development working together. We believe neither factor alone produces this result. The methodology provides the structure and focus. AI provides the execution speed. The multiplier is in the combination.

What I Saw in the Room

The numbers tell you what happened. They don’t tell you what it felt like to watch it happen. I was there for all five days, sitting with each team, and what I observed was more revealing than any spreadsheet.

The First Four Hours Changed Everything

Day 1 started with the 4-hour focus block. Every team gathered — backend, frontend, QA, PM — in one room, one call, one shared context. Slack off. Notifications off. For the first time in months, maybe years, these people were in the same conversation at the same time with no competing meetings.

The effect was immediate and visible. A backend engineer on Team 1 raised an API design question that, in a normal sprint, would have gone to Slack, waited two hours for a response, generated three follow-up questions, and taken a day to resolve. In the focus block, the frontend engineer heard it, the QA engineer weighed in on testability, the PM clarified the business constraint, and the whole thing was resolved in twelve minutes. I timed it.

This wasn’t an exception. It was the pattern. Across all six teams, decisions that normally take days of async back-and-forth were happening in minutes. Not because people were working harder. Because they were finally in the same room at the same time, focused on the same problem.

The AI Multiplier

When the focus block established alignment, the AI tooling did something remarkable: it made execution almost instantaneous. Engineers weren’t writing boilerplate. They weren’t spending hours on CRUD endpoints or repetitive test cases. The AI handled the scaffolding, and the engineers spent their cognitive energy on architecture, edge cases, and the decisions that actually require human judgment.

One frontend engineer on Team 3 told me something that stuck with me: “I spent the whole day thinking about the hard problems instead of typing the easy ones.” That’s the shift. AI didn’t replace the engineer. It freed the engineer to be an engineer.

Blockers Died in Real Time

In a normal sprint week, the average blocker takes one to three days to resolve. Someone raises it in standup. Someone promises to look into it. The Slack thread grows. A meeting gets scheduled. By the time the blocker is cleared, the developer has context-switched to something else and needs time to ramp back up.

During the five days, I watched blockers surface and resolve in the same hour. One team hit a cross-service dependency issue on Day 2. In a Scrum world, that’s a multi-day blocker — you need someone from the other team, you need a meeting, you need alignment. In the focus block, we pulled the relevant person from the other team into a 15-minute targeted call, agreed on the API contract, documented it, and both teams continued independently. Total time lost: 20 minutes.

Interruptions Didn’t Break the Flow

The most common objection to any focused methodology is “What about production incidents?” Fair question. We had two during the workshop, plus two urgent ad-hoc requests from the existing production environment.

For each one, one or two team members peeled off, took full ownership, resolved it, and rejoined the feature cycle. The remaining team members never stopped building. The feature pipeline continued uninterrupted. Total disruption across four interruptions: zero.

This was the moment I knew the methodology was sound. Not the speed numbers. The interruption handling. Because every real-world engineering team has production incidents. If Torque couldn’t handle them without breaking the cycle, it would be a nice theory and nothing more. It handled them. Cleanly.

The Emotional Shift

This one surprised me more than the numbers. By the middle of the workshop, engineers were visibly different. Less tired, more engaged. There was an energy in the room that I hadn’t seen in our sprint cycles.

When I asked people about it, the answers were consistent: “I feel like I’m actually building something.” “I didn’t open Slack once today.” “I solved a problem in 20 minutes that would have taken me days.” “I don’t feel like I’m running in a hamster wheel.”

Process fatigue is real. Engineers don’t burn out from coding. They burn out from the overhead that surrounds the coding — the ceremonies, the status updates, the context switches, the async noise that fragments every deep thought. Remove the overhead, and people remember why they became engineers in the first place.

And Then I Saw the Other Thing

For the first two days, I was watching a methodology validate itself in real time. The numbers were landing. The energy was high. The development cycles were compressing. I was mentally drafting the victory article.

Then I started noticing the cracks.

The Scrum Muscle Memory

Our teams have been running Scrum for years. It’s not just a process — it’s wired into how people think about work. And when you take away the scaffolding that people have relied on for years, something unexpected happens: they don’t feel liberated. They feel lost.

I watched it happen in real time. The focus block would start, and someone would ask: “So… do we do a standup first?” No. There is no standup. Just start working. But that answer didn’t land. People had been starting their day with a standup for years. Removing it didn’t just remove 15 minutes of ceremony. It removed a psychological anchor. They didn’t know how to begin.

In Phase 2, when parallel build was happening, I’d see engineers instinctively reach for Jira. Not because they needed it — but because they were used to the comfort of seeing their work broken into tickets, assigned, and tracked on a board. Torque doesn’t use tickets for in-cycle work. The PRD is the artifact. The focus block is the coordination mechanism. But the absence of the ticket board created a low-level anxiety that surprised me.

One engineer said it plainly: “I know we’re moving faster, but I feel like I don’t know where I am.”

The Ceremony Comfort Zone

Here’s the thing nobody tells you about Scrum ceremonies: they’re not just overhead. They’re also safety nets.

Sprint planning gives people a sense of control — “I know what I’m supposed to do for the next two weeks.” Daily standups give people visibility — “At least everyone knows what I’m working on.” Retrospectives give people a voice — “At least I can say what’s wrong.”

When you remove all of that and replace it with “everything happens in the focus block,” you’re asking people to trust a fundamentally different structure. And trust doesn’t build in five days. It builds over months, through repeated cycles of “we tried this, it worked, let’s trust it more.”

I saw team leads who were used to running standups suddenly unsure of their role. I saw QA engineers who were used to receiving a ticket to test suddenly having to lean into the conversation and self-direct. I saw senior developers who had mastered the sprint rhythm feel uncomfortable with the open-ended nature of the focus block.

The methodology worked. The people weren’t ready for the methodology.

The Confusion Wasn’t Technical

Nobody struggled with the AI tools. Nobody struggled with the technical work. The features were well-scoped. The code got written. The tests passed. The deployments went smoothly.

The confusion was emotional and structural. People didn’t know how to operate without the rhythm they’d relied on for years. And when you’re confused about the process, even if you’re shipping faster, the experience feels unstable. It’s the difference between driving fast on a road you know and driving fast on a road you’ve never seen. Same speed. Very different confidence levels.

By Day 5, some teams had adapted. Others were still finding their footing. Every single feature reached code-complete — but the journey was bumpier than the results table suggests.

The Honest Decision

After the workshop, I sat with the data in one hand and the observations in the other. And they told two different stories.

The data said: AI-driven development works. The development cycle compressed from weeks to days. End-to-end, we’re looking at a guaranteed 50% or more improvement in KR delivery speed. A month becomes two weeks. That’s the floor.

The observation said: The teams are not ready. The muscle memory is too deep. The comfort zone is too strong. Forcing this at scale right now would create more confusion than velocity.

Both things are true at the same time. And when both things are true, you have to make a pragmatic call.

We’re going back to Scrum.

Not because Scrum is better. The numbers make that argument impossible. We’re going back because our teams need the scaffolding they know while they build the muscles they don’t have yet.

But We’re Not Going Back to the Same Scrum

The Scrum framework stays. But how we operate inside it is fundamentally different. The workshop didn’t just teach us about speed — it rewired how we think about work itself. We can now deliver with quality at a pace we didn’t think was possible. That changes everything about how we plan, how we break down work, and how we spend our time.

Stop Slicing Features into Dozens of Tiny Tasks

This is the biggest behavioral shift. Before the workshop, our instinct was to decompose every feature into as many small tickets as possible. A single KR would generate fifteen, twenty, sometimes thirty Jira tickets. The logic was sound on paper: smaller tasks, easier estimation, better tracking. In practice, it created a different problem — the overhead of managing, coordinating, and context-switching between thirty tickets was eating more time than the actual coding.

The workshop proved something we should have realized earlier: when the team is aligned on the problem, focused on execution, and equipped with AI tooling, a feature doesn’t need thirty tasks. It needs two or three.

Here’s the new rule. Look at the KR. Understand its scope. Then break it into two or three meaningful chunks — not micro-tasks, but substantial pieces of work that a developer can own end-to-end. One chunk might be the backend API and data layer. Another might be the frontend integration. A third might be the testing and edge case coverage. That’s it. No more decomposition theater. No more tickets that take longer to write than to build.

This sounds risky if you’re used to the old way. It’s not. Because when you pair this with AI-driven development, each chunk gets done faster than any three micro-tasks used to. And the cognitive overhead of managing thirty tickets? Gone.

Listen Harder in Groomings

The second shift is in how we run groomings. Before the workshop, grooming sessions had a predictable rhythm: someone presents the ticket, someone asks a question, someone gives an estimate, we move on. Half the room is mentally somewhere else. The other half is waiting for their turn to talk.

That changes now. Groomings are where alignment happens. And alignment is the single biggest accelerator we discovered in the workshop. Remember that API design question on Team 1 that got resolved in twelve minutes because everyone was present and listening? That’s what a good grooming should feel like.

The new expectation: when a feature is being discussed in grooming, you listen as if you’re about to build it in the next four hours. Because with AI-driven development, you might be. Ask the edge case questions now. Raise the dependency concerns now. Challenge the design assumptions now. Don’t wait for Day 3 of the sprint to discover what you should have caught in grooming.

Better groomings mean fewer surprises in build. Fewer surprises mean fewer blockers. Fewer blockers mean faster delivery. The math is simple. The discipline is hard. But we’ve seen what happens when people actually listen, and we’re not going back.

Create Focus Time

We can’t do a full 4-hour Torque focus block inside Scrum. Not yet. But we can protect time for deep work.

Starting now, every team designates dedicated focus windows during the sprint — blocks of 2–3 hours where Slack goes quiet, meetings don’t get scheduled, and engineers can actually build. This isn’t a suggestion. It’s a rule. No one schedules a “quick sync” during focus time. No one pings someone on Slack for something that can wait two hours.

The workshop proved that synchronous, focused collaboration is where the magic happens. We can’t replicate the full workshop environment every day — but we can carve out islands of focus inside the sprint ocean. Even two hours of protected deep work per day is a radical improvement over the current state, where a developer’s day is fragmented into thirty-minute slots between ceremonies, Slack threads, and “quick questions.”

What Else Changes

Beyond these three shifts, we’re also carrying forward:

• AI-driven development becomes the default. Every team, every sprint, every feature. The AI tooling we validated in the workshop — code generation, automated tests, intelligent reviews — gets embedded into the daily workflow. This alone compresses delivery cycles inside existing sprints.
• KRs ship faster. With fewer tasks, better groomings, focus time, and AI tooling combined — the same sprint that used to deliver one key result now targets two or three. We ship more value per sprint without changing the sprint container.
• The curated backlog stays. Items expire by default. If nobody champions a ticket within two sprints, it’s pruned. This has already eliminated the backlog bloat that made grooming sessions feel like archaeological digs.
• Cool-down thinking stays. A half-day at the end of each sprint for tech debt, tooling improvements, and UX polish. Not as structured as Torque’s cool-down, but protecting the same principle: speed without maintenance is debt in disguise.
• Cycle Bet experiments run in parallel. Two teams are tracking hour estimates alongside story points to build historical data. If the Cycle Bet proves more accurate and transparent, it replaces story points org-wide. Early signals are promising.

We’re taking the engine out of the race car and putting it into the family sedan. The engine is the same. The car just needs to be one the driver is comfortable with — for now.

What I Learned in Those Five Days

Sitting with six teams for five days taught me things that no planning document or metrics dashboard ever could.

1. The speed bottleneck was never technical. It was communication overhead. When you put a team in the same room, focused on the same problem, with no competing meetings, they move at a speed that makes sprint estimates look absurd. The issue was never “can we build this fast?” It was always “will the process let us build this fast?”
2. AI multiplies focus, not chaos. AI-driven development in a fragmented process is fast chaos. AI-driven development in a focused process is fast execution. The combination of Torque’s structure and AI’s speed is what produced the numbers. Neither alone gets there.
3. Process change is identity change. Engineers don’t just follow Scrum. They’ve built their professional identity around it. Their daily rhythm. Their sense of progress. Their definition of “a productive day.” Asking them to abandon that overnight is asking them to abandon how they see themselves as professionals. That takes time and trust, not a five-day workshop.
4. Preparation is the hidden variable. The reason we could compress development to hours wasn’t just the methodology or the AI. It was the preparation. The PRD was ready. The Figma mocks were ready. The problem was understood. Phase 0 — the pre-discovery work — is where the real leverage lives. Without it, even Torque would struggle.
5. You can’t skip the middle. Torque is where we want to be. Scrum is where we are. The path between them isn’t a switch you flip — it’s a road you walk. AI-driven Scrum is the middle of that road. We’re walking it now.

Give Me a Lever Long Enough

Let’s be honest about the boundaries. This was a workshop context. Five days. Six teams that knew they were testing something new, with the energy and focus that comes from novelty. The pre-conditions were ideal — PRDs ready, designs mocked, problems understood. A normal Tuesday doesn’t look like that. And to be clear: the development cycle compressed to days, but the full path to production still takes about a week. Our guaranteed number is 50% improvement in KR delivery speed — and we’re confident in that, though the ceiling is likely much higher.

Would the results hold over six months? I believe yes — ByteMaster’s longer-running results support that — but we haven’t proven it at scale. The thing Archimedes understood that modern engineering organizations keep forgetting: force isn’t the bottleneck. Leverage is.

Torque is not a radical invention. It’s an obvious correction. Replace fragmented ceremonies with concentrated collaboration. Gate work by outcomes, not by the calendar. Measure in hours, not in abstractions. Give teams the structure to focus and the space to recover.

But an obvious correction applied to an organization that isn’t ready for it is just disruption by another name. And I’d rather have a team that ships consistently with Scrum + AI than a team that ships in bursts with Torque but feels lost between them.

The Door Is Open

If we arrive at a different conclusion — if the teams mature into readiness, if the Cycle Bet data validates what we suspect, if the focus block discipline takes root in the small experiments we’re running — you’ll hear about it. That’s what Part 3 is for.

For now, the plan is simple. Run Scrum. Ship fast with AI. Absorb the Torque principles that fit. Build the muscle memory one sprint at a time. And when the teams are ready — not when the numbers say we should, but when the people say they can — we’ll make the switch.

Because the one thing those five days proved beyond any doubt is this: the speed is there. The methodology is there. The tools are there. The only thing between us and that future is readiness. And readiness, unlike a feature, can’t be compressed by 50%.

>50% faster KR delivery. That’s our guarantee.

AI-driven development changed how fast we can build. The rest is about readiness.

The lever is ready. The fulcrum is set. The teams need time to learn how to grip.

We’re walking the road, not flipping the switch.

And when we’re ready — you’ll be the first to know.

50% Faster. Guaranteed. was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1 of 2 — How we’re replacing sprint ceremonies with a new methodology — inspired by Shape Up, built on our own best practices, accelerated by AI. Part 2 comes after the experiment.

This isn’t a thought piece. This isn’t “5 reasons Scrum is dead.” This is a live experiment.

But it’s not a blind leap.

Before committing a team to a full cycle, we ran proof-of-concept experiments across three teams — ByteMaster, Vikings, and Qmech. Each team tested different elements borrowed from Shape Up against their existing Scrum workflow: appetite-based scoping instead of story points, shaped pitches instead of ticket factories, hill charts instead of burndown tracking. Not the full framework — isolated pieces, applied to real work, measured against real outcomes.

The most important signal came from one POC where a team took a feature from start to finish — not a prototype, not a spike, a production-ready feature delivered end-to-end. Shaped with an appetite, scoped with explicit no-gos, built without sprint ceremonies. And the quality held. Code reviews passed clean. QA didn’t flag regressions. The feature shipped and stayed shipped — no hotfix trail, no “we’ll clean it up next sprint” debt. That single data point changed the conversation from “should we try this?” to “which team goes first?”

The results across the three POCs weren’t uniform — some principles clicked immediately, others needed adaptation — but the signal was clear enough to place a real bet.

Starting this month, we’re pulling one of our engineering teams out of Scrum entirely. No more sprints. No more daily standups. No more story points. No more backlog grooming. No more velocity tracking.

Instead, we’re building something new. The foundation is Shape Up — the product development framework created by Basecamp/37signals. But we’re not adopting it as a religion. We’re taking its core principles, merging them with our own battle-tested best practices that we’ve accumulated over years of shipping at scale, and layering in AI-driven development workflows that didn’t exist when Shape Up was written.

The result? Something that will eventually get its own name under Insider One. The ingredients are deliberate: Shape Up’s shaping and betting philosophy as the starting point, our own battle-tested operational instincts as the backbone, cases where we need to adapt fast as the stress test, and AI-augmented development as the accelerant. It’s not Shape Up. It’s ours.

This is the expanded rollout. The POC results across three teams gave us enough signal to commit one team to a full cycle. If this works, we go wider. If multiple teams validate the approach, we go company-wide.

This is Part 1 — the plan, the reasoning, and our first shaped cycle. Part 2 comes after the experiment with raw, unfiltered results. Whatever happens — success, failure, or something messy in between — we’re publishing it.

Let’s go.

Why We’re Doing This

We run multiple Scrum teams. They ship. They’re not broken. But we’ve been noticing friction patterns — the kind that most engineering organizations encounter once they’ve been running Scrum at scale for long enough. And rather than patching the framework one more time, we decided it was time to rethink it.

The ceremonies had drifted from their original purpose. Our standups had gradually shifted toward status reporting — a pattern so common in scaling teams that it barely needs explaining. Sprint planning had become more about estimation negotiation than about aligning on what matters. Retrospectives were surfacing recurring themes that pointed to structural friction, not problems solvable within the current framework. The overhead-to-value ratio of our ceremonies had shifted, and we recognized it was time to evolve.

The backlog had outgrown its usefulness. Like most mature product teams shipping continuously over several years, our backlog had grown organically to several hundred items. Some reflected priorities from quarters ago. Others had accumulated naturally without a cleanup mechanism. Every grooming session, the team spent energy navigating items that no longer reflected active priorities rather than focusing on what mattered now. The backlog had become a planning artifact rather than a prioritization tool.

Two-week sprints are too short for meaningful work. By the time you plan it, groom it, estimate it, start building, hit a blocker, wait for a review, and demo it — you’ve shipped a fragment. Not a feature. A fragment. Then you carry the rest into the next sprint, and the next, and suddenly a “2-sprint project” has been dragging for 3 months across 6 sprints with no clear end in sight.

AI changed the math, but the process didn’t. This is the part nobody talks about. Our developers are using AI coding assistants — Claude, Copilot, Cursor. A senior developer’s throughput has fundamentally changed. Tasks that took 3 days now take 3 hours. But we’re still planning in 2-week sprints, still estimating in story points, still assigning individual tickets. The process is designed for a pace that no longer exists. It’s like putting a jet engine on a bicycle and keeping the training wheels.

We needed something different. Not a tweak. A different operating system.

What Is Shape Up?

Shape Up was born at Basecamp (now 37signals), refined over 15 years of shipping products with small teams. Ryan Singer documented it in a free book that’s become quietly influential among product teams who are fed up with Agile theater.

The core rhythm is dead simple:

6-week cycles of focused, uninterrupted building. Then 2-week cooldowns for bugs, tech debt, breathing, and planning the next cycle.

That’s Shape Up’s default recipe. But here’s the thing — we’re not following the recipe to the letter.

We’re building this as Insider One, not replicating Basecamp. Our scale is different, our market is different, our team dynamics are different. We’re borrowing Shape Up’s philosophy — appetite over estimation, betting over backlog grooming, shaping over ticket factories — but combining it with our own best practices and the operational realities of shipping at our pace. Cycle length, cooldown structure, how we handle urgent production work mid-cycle, what ceremonies we keep and what we kill — many of these will look nothing like what Ryan Singer wrote. Because they’re not Shape Up decisions. They’re Insider One decisions.

We’ll address the biggest divergence — our curated backlog — later in this post. For now, just know that what you’re reading isn’t a Shape Up adoption story. It’s the birth of something new — built on Shape Up’s foundations, yes, but shaped by our own experience, our own failures, and our own instinct for what works at our scale. Part 2 will reveal how each design choice performed — which ones were genius and which ones we regret.

With that caveat, here are the Shape Up principles we’re borrowing wholesale — because they’re too good to reinvent:

A note for Shape Up purists: If you’re thinking “that’s not how Basecamp does it” — you’re right. And that’s the point. We believe the strongest frameworks are the ones you make your own. Part 2 will be our honest scorecard on how every deviation performed in practice.

Shaping — The Work Before the Work

Before anything enters a cycle, it must be shaped. This is the most important — and most demanding — part of Shape Up.

A shaped piece of work (called a pitch) lives at a very specific level of abstraction. It’s concrete enough that the team knows what to build, but rough enough that they decide how to build it. Think of it as the difference between handing someone a GPS destination versus handing them turn-by-turn directions. Both get you there. One trusts the driver.

Every pitch has five ingredients:

• Problem — What’s hurting, and for whom?
• Appetite — How much time is this worth? (Not how long will it take — a crucial distinction)
• Solution — A rough sketch of the approach. Breadboards and fat marker drawings, not wireframes
• Rabbit Holes — Traps that could swallow the project whole
• No-Gos — What we explicitly will NOT build

The appetite concept is where Shape Up breaks most sharply from Scrum. Instead of asking “how many story points is this?” and getting a number that’s wrong, you ask “is this problem worth 6 weeks of our team’s time?” That question forces a completely different conversation — one about value, not velocity.

Betting — Not Planning

In pure Shape Up, there’s no backlog. None. Pitches that don’t get bet on are gone. If an idea is important, someone will champion it again — probably shaped better the second time. The philosophy is simple: if nobody cares enough to re-pitch it, it wasn’t worth building.

This is where we diverge.

We keep a backlog. But not the kind you’re imagining — not the 400-item graveyard where feature requests go to haunt sprint planning sessions. We run a curated backlog. Every cycle, it gets actively pruned. Only items that have a champion — someone willing to shape a pitch and argue for it at the betting table — survive. Everything else gets archived. Not carried forward as guilt. Not left to accumulate as “we’ll get to it someday.” Archived. Gone from the active conversation.

The difference between this and Scrum’s backlog is the direction of the burden. In Scrum, items persist by default and require effort to remove. In our model, items expire by default and require effort to keep. That single inversion changes the entire psychology of planning.

Why didn’t we go full “no backlog” like Basecamp? Because at our scale — multiple product lines, cross-team dependencies, enterprise clients with contractual commitments — completely discarding institutional memory creates its own problem. We watched teams re-discover the same customer needs, re-surface the same technical debt, re-debate decisions that were already made and forgotten. A curated backlog with aggressive pruning gives us the benefits of Shape Up’s fresh-eyes approach without the institutional amnesia.

Before each cycle, a small group of senior people holds a betting table. They review the shaped pitches — some new, some carried forward by their champions — and decide which ones to bet on. This is a strategic conversation, not a planning ritual. The question isn’t “how many points fit in the sprint?” It’s “given everything we know right now, what’s the smartest bet we can make with the next six weeks?”

Now, this is important to clarify — because it’s the most misunderstood principle: neither Shape Up’s “no backlog” nor our curated version means “we ignore urgent issues from the field.”

Production bugs, security incidents, SLA-bound fixes — these flow through a separate urgent track, just like in any responsible engineering organization. A P0 at 2 PM doesn’t wait for the next betting table. What both approaches eliminate is the feature backlog as a passive dumping ground — that ever-growing list of “someday” ideas that nobody actively champions but everyone feels obligated to maintain.

In traditional Scrum, a P0 production bug sits next to a feature idea from several quarters ago, and both compete for sprint capacity. In our model, urgent work has its own lane. It doesn’t pollute strategic decisions, and strategic work doesn’t block urgent responses.

Building — With a Circuit Breaker

Once a bet is placed, the team gets six weeks of uninterrupted time. No scope changes. No stakeholder check-ins. No one asking for status updates. The team owns the problem and discovers the tasks as they go — because real tasks only emerge when you start building, not when you’re sitting in a planning meeting imagining what you’ll need.

Progress is tracked with hill charts instead of burndown charts. Every scope sits on a hill: the left side is “figuring it out” (unknowns, exploration, risk), the right side is “making it happen” (execution, known work). A scope stuck on the uphill side for too long is a red flag — even if a burndown chart would show “progress.”

And here’s the most radical rule: if it’s not done in six weeks, it doesn’t get extended. It gets killed. The circuit breaker trips. This sounds brutal, but it’s actually the most humane policy in the entire framework — it prevents the slow soul-crushing death of projects that drag on for months with no end in sight.

Cooldown — The Part Scrum Forgot

Between every cycle, there’s a two-week cooldown. Developers fix bugs, tackle tech debt, explore ideas, or just breathe. Shapers prepare pitches for the next betting table.

This is the thing Scrum teams dream about but never get. Back-to-back sprints create a relentless pace that leads to burnout and mountains of technical debt. Cooldown periods acknowledge what everyone knows but nobody says: you can’t sprint forever. That’s not how humans work.

Where We Fork From Shape Up

We said earlier this isn’t a copy-paste adoption. Here’s the most significant place where we break from the original framework — and why we’re telling you about it now instead of saving it for Part 2.

The curated backlog. We described this in the betting section above, but it deserves emphasis as a deliberate architectural decision. Pure Shape Up says: no backlog. Period. If an idea doesn’t get bet on, it dies. If it matters, someone will re-pitch it.

We tried this during our POC phase. It didn’t survive contact with our reality.

At Basecamp’s scale — a single product, a tight team with deep shared context — the “no backlog” philosophy works because nothing truly important gets lost. The people who care about an idea are the same people at the betting table. Institutional knowledge lives in a small number of heads.

At our scale — multiple product lines, dozens of teams, enterprise clients across different verticals — ideas that don’t get bet on in one cycle can genuinely disappear. Not because nobody cares, but because the person who championed it rotated teams, or the context shifted, or the customer need got buried under three months of other priorities. We watched it happen during the POC. Important patterns re-emerged months later, re-discovered from scratch, as if the original work had never existed.

So we made a conscious choice: keep the backlog, but invert the default. Items expire unless someone actively fights for them. Every cycle, the backlog gets pruned — not groomed, pruned. The difference matters. Grooming is maintenance. Pruning is editing. You’re not asking “is this still accurate?” You’re asking “does anyone still care enough to shape this into a pitch?”

This is our biggest fork. Part 2 will tell you whether it was the right call — or whether we should have trusted the original philosophy and accepted the discomfort.

Why This Methodology + AI-Driven Development Is the Combination Nobody’s Talking About

Here’s where our experiment gets interesting.

Shape Up was designed in 2019 — before AI coding assistants existed. It was built for human-only teams. But something unexpected happens when you combine Shape Up’s principles with AI-augmented development.

The appetite math changes. When your developers are 3–5x more productive with AI tools, a “6-week appetite” feature in 2023 might be a “2-week small batch” in 2026. This means you can bet on more ambitious work per cycle — or ship the same scope with smaller teams. Shape Up’s appetite-based thinking adapts to this naturally. Story points don’t. Story points are calibrated to a fixed human pace that no longer exists.

Shaping gets sharper. AI assistants are extraordinary at executing well-defined work and terrible at navigating ambiguity. This makes shaping more important, not less. A well-shaped pitch with clear boundaries, identified rabbit holes, and explicit no-gos is exactly the kind of input that a developer + AI pair can crush in 6 weeks. A vaguely scoped Jira ticket? The AI amplifies the confusion.

The circuit breaker becomes less scary. One of the biggest objections to Shape Up is “but what if we waste 6 weeks?” With AI-augmented development, the team can explore and prototype faster in the first week, hit the uphill unknowns earlier, and make the “kill or continue” decision sooner. The hill chart becomes even more honest because the downhill execution phase compresses dramatically.

Sprint cycles feel even more absurd. If a developer can prototype a feature in a day with AI assistance, spend two days refining it, and have it production-ready by Thursday — what exactly is the point of a 2-week sprint with Monday planning, daily standups, and Friday demos? The overhead-to-work ratio becomes grotesque.

We’re not adopting Shape Up. We’re not just adding AI tools. We’re building a new methodology — Shape Up’s philosophy as the starting inspiration, our own operational DNA as the muscle, rapid adaptability as the reflex, and AI-driven development as the nervous system. Something that will earn its own name. For now, we’re calling it “the experiment.” By Part 2, we might be calling it something else entirely.

The Missing Piece: Teaching Your Team to Think With AI

There’s a hidden prerequisite that most “AI-driven development” articles skip entirely: your team needs to know how to talk to these models.

I wrote about this in The Philosophy of Prompting — the idea that prompting an AI isn’t just a technical skill, it’s a thinking skill. The way you articulate a problem to a machine reveals how well you actually understand the problem yourself. Garbage in, garbage out isn’t just a cliche — it’s the fundamental law of AI-augmented development. You need to translate your intent clearly and completely, or the output will be technically functional but strategically wrong.

This is where Shape Up and AI-driven development connect at a deeper level than most people realize. Shaping is prompting at the project level. A well-shaped pitch — with a clear problem, bounded appetite, rough solution, identified rabbit holes, and explicit no-gos — is essentially a perfectly structured prompt for a team of humans + AI. The same discipline that makes a good pitch also makes a good AI interaction: clarity of intent, explicit constraints, and knowing what you don’t want.

The teams that get this right won’t just be faster. They’ll be building a fundamentally different relationship with their tools — one where the quality of human thinking determines the quality of AI output, not the other way around.

The Guinea Pig: ByteMasters

We chose ByteMasters for this experiment. They build conversational commerce experiences — the AI-powered shopping assistant that helps users discover, explore, and purchase products through natural conversation.

Why this team? Start with the data: ByteMasters was one of our three POC teams — and the one that delivered the strongest results. During the proof-of-concept phase, they took a feature end-to-end using shaped pitches and appetite-based scoping. No sprints, no story points, no grooming sessions. The feature shipped to production with clean code reviews, no QA regressions, and zero post-release hotfixes. Their POC cycles finished with less scope creep and fewer carry-over items than equivalent Scrum sprints would have produced. They didn’t just test the methodology — they proved it could deliver real, production-quality work. They earned the right to go first.

Beyond the POC results, the team profile fits. They’re autonomous, experienced, and hungry for change. They’ve been running Scrum for years and feeling the same friction patterns we described above. They own a distinct product area with minimal cross-team dependencies — the ideal conditions for piloting a new methodology.

They also had a backlog that perfectly illustrates what we’re trying to fix: an epic that had evolved well beyond its original scope over multiple quarters of active development. A handful of items were actively in progress, but the majority reflected earlier priorities that no longer aligned with current direction — a clear candidate for reshaping rather than continued grooming.

Our First Bet: A Feature That Would Normally Take 5 Sprints

We can’t share the details of what we’re building — not yet. What we can tell you is this:

Under our current Scrum process, this feature was estimated at approximately 5 sprints — that’s 10 weeks of sprint time, plus the overhead of 5 planning sessions, 50 daily standups, 5 sprint reviews, 5 retrospectives, and countless grooming sessions in between. In reality, with carry-overs and context switching, it would probably stretch to 12–14 weeks before it actually shipped. We’ve all seen how “5 sprints” becomes “4 months” in practice.

We shaped it into one 6-week cycle.

Not by cutting corners. Not by removing scope. By shaping it properly — defining the problem with brutal clarity, setting an appetite that reflects the feature’s actual strategic value, sketching a solution at the right level of abstraction, identifying the rabbit holes that could swallow the timeline, and explicitly declaring what we will NOT build.

The same feature. The same team. A fundamentally different approach to framing, planning, and executing the work.

We held a betting table — four people, forty-five minutes. The pitch got bet on. No 200-ticket backlog. No estimation poker. No velocity charts. One well-shaped pitch, one strategic conversation, and a team that knows exactly what they’re building, why it matters, what’s out of scope, and when they’re done.

That’s it. The feature details? You’ll see them in Part 2 — along with whether shaping a “5-sprint feature” into a single cycle was genius or delusion.

How We’re Tracking Progress

No burndown charts. No story points. No percentage-complete theater.

We’re using hill charts. Every meaningful scope of work sits on a hill:

The left side is “figuring it out” — unknowns, open questions, architectural decisions that haven’t been made yet. The right side is “making it happen” — the unknowns are resolved, you’re just executing.

Here’s why this matters more than any Scrum metric: a scope stuck on the uphill side at Week 4 is a visible, specific, actionable red flag. You can see exactly which piece of the project is stuck in the unknown zone and intervene — either simplify the scope or escalate the blocker. In Scrum, the same situation hides behind “75% of story points completed” and nobody realizes there’s a problem until the last day of the sprint.

The hill chart doesn’t just track progress. It tracks honesty.

What We’ll Measure in Part 2

When the experiment wraps, we’re publishing Part 2 with raw results. No spin. Here’s what we’ll track:

Delivery. Did the feature ship in one cycle? Did the circuit breaker trip? How much scope was cut versus the original pitch?

The 5-sprint question. Did shaping a “5-sprint feature” into one 6-week cycle actually work — or did we just compress the pain into a shorter window?

New methodology vs. Scrum. Ceremony hours per week. Cycle time from idea to production. Carry-over rate. Team satisfaction survey — same questions, both methodologies.

AI-driven development. How did AI tools change appetite calculations? Which scopes moved downhill faster? Where did AI NOT help?

Our design choices. Did the curated backlog earn its keep, or should we have gone full “no backlog”? Which of our additions beyond Shape Up’s foundations added value? Which ones created friction? What would we keep, drop, or change for Cycle 9?

The human stuff. How does the team feel? Did the cooldown actually happen, or did we cheat? Did anyone miss standups? (Seriously.)

The Honest Risks

Shaping at full scale is a skill we’re still building. We wrote pitches during the POC phase — smaller-scoped, lower-stakes versions that helped us learn the format. But a full 6-week cycle pitch is a different animal. The appetite is bigger, the rabbit holes are deeper, and the consequences of a badly shaped pitch are six weeks of a team’s time, not a two-week experiment. Our first full-cycle pitches might miss something that blows up the timeline.

The circuit breaker might break us. If the feature doesn’t ship and we have to kill it, that’s a real emotional hit. The policy exists for good reasons, but living through it for the first time will test our conviction.

5 sprints into 1 cycle is an ambitious claim. Maybe the Scrum estimate was inflated. Maybe our shaping cut too much scope. Maybe 6 weeks isn’t enough and we’re about to learn that the hard way. We’ll know when the cycle ends.

We’re combining multiple experiments at once. New framework and AI-driven development. If something fails, isolating the variable will be hard. We’re accepting this risk because we believe they’re complementary — but we might be wrong.

Cross-team sync. Our other teams are still running Scrum. A 6-week cycle doesn’t align with 2-week sprints. If there are dependencies we missed, we’ll feel the friction.

Why We’re Publishing This

Because everyone writes about methodologies in retrospect. “We switched to X and it was great!” Nobody shows you the moment before the jump — the uncertainty, the incomplete plan, the genuine risk of public failure.

We’re showing you that moment. Right now.

The pitch is written. The bet is placed. The team starts building on Monday.

When the experiment is done, Part 2 drops with one of three stories:

It worked. The methodology is the future and here’s the proof. And yes — we gave it a name.

It partially worked. Some borrowed principles were gold, some of our own additions missed, some need tuning. The nuanced answer that’s probably most useful.

It failed. We went back to Scrum — or we evolved into something else entirely. Here’s what we learned.

Whatever the answer is, you’ll get the truth.

See you in Part 2.

We Stopped Sprinting and Bet on Shipping was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The difference between people who get 10x results from AI and those who don’t isn’t talent — it’s how they think about the work.

In 1913, Henry Ford didn’t invent the car. He didn’t even invent the assembly line. What he invented was a way of thinking about work — break it into pieces, give each piece to a specialist, and let the system produce something no individual could.

A century later, we’re watching the same revolution happen again. Except this time, the specialists aren’t people on a factory floor. They’re AI agents. And the assembly line isn’t a physical conveyor belt — it’s the skills and instructions you feed them.

Here’s the uncomfortable truth: most people are still using AI like a fancy search engine. They type a prompt, get an answer, and move on. That’s like hiring four world-class engineers and asking them all to answer emails.

The game is shifting right now. And where we stand today — February 2026 — it’s all about agents and skills. Not prompts. Not chat. Delegation.

What Most People Get Wrong

Here’s a problem we actually had. Every time a candidate applied to an engineering role at our company, someone — usually a team lead or senior engineer — had to stop what they were doing and review the candidate’s code project. On average, we waited three days to get a response. Three days where the candidate sits in limbo. Three days where your best engineers are doing hiring work instead of engineering work.

Now imagine you open ChatGPT and paste in a candidate’s GitHub repo. “Review this project and tell me if they’re good enough.” You get a response. It’s… vague. Generic. It doesn’t know your team’s standards, your tech stack, or what “good enough” means for a backend role versus a QA role versus a mobile role.

That’s what most people do with AI.

They open a chat window, dump their entire problem into it, and expect magic. They prompt. They tweak. They retry. They give up.

The irony is that the more powerful the tool, the worse people use it. Because most of the time, they get something mediocre — not because AI isn’t capable, but because a generalist doing everything will always lose to specialists doing what they do best.

The secret isn’t a better prompt. It’s a better org chart.

The Agent Model: Give AI a Job Title

Instead of one AI doing everything, you define agents — each with a clear role, a specific set of tools, and instructions that match the job.

So we built a candidate review pipeline. Instead of one overloaded chat prompt, we set up:

• A Repo Analyzer — clones the candidate’s project, detects the tech stack, and analyzes the structure. Their job ends when the analysis is done.
• A Team Reviewer — takes that analysis and evaluates the code against that specific team’s standards. The backend team reviews for Go patterns and API design. The mobile team reviews for Flutter architecture and state management. The QA team reviews for test coverage and automation frameworks. Each team has its own agent with its own criteria.
• A Security Reviewer — scans for hardcoded secrets, vulnerable dependencies, and security anti-patterns. Cross-team. Every candidate gets this.
• A Report Generator — calculates the final score, detects AI-generated code, and produces a structured hire/no-hire recommendation with evidence.

Four core agents. Seven teams plugged in. One pipeline.

Each agent is good at their piece because they’re only doing their piece. The repo analyzer doesn’t judge code quality. The team reviewer doesn’t scan for secrets. The report generator doesn’t re-analyze — it synthesizes.

This is not hypothetical. This is running in production at our company right now. HR types one command, and two minutes later they have a structured evaluation. The same review that used to take three days.

Skills: The Instructions That Make Agents Smart

An agent without skills is like a new hire on day one — capable, but directionless.

Skills are the playbooks you give your agents. They’re not vague. They’re specific. They tell the agent:

• What to do when invoked
• What format to produce
• What quality bar to hit
• What tools to use
• What to hand off and to whom

Here’s what makes this powerful: each team at our company defines their own skills. The backend team’s Go review skill checks for proper error handling, clean API design, and concurrency patterns. The mobile team’s Flutter review skill checks for widget architecture, state management, and platform-specific conventions. The QA team even has a completely different scoring system — a 50-point direct scale instead of the standard weighted categories.

You wouldn’t hire a senior engineer and say “review stuff.” You’d say: “Here’s our coding standards. Here’s our scoring rubric. Here’s what a strong candidate looks like for this team. Now evaluate.”

That specificity is the difference between AI output you throw away and AI output you ship.

Here’s what the candidate review pipeline looks like:

Step 1: Clone & analyze the repo       → detects tech stack and structure
Step 2: Review against team standards   → evaluates code quality per team criteria
Step 3: Security scan                   → checks for secrets and vulnerabilities
Step 4: Generate report                 → produces score and recommendation

And here’s another one — the article you’re reading right now was produced by a content pipeline:

Step 1: Research the topic        → produces a research brief
Step 2: Write the draft           → produces a full article
Step 3: Edit for quality          → polishes in-place
Step 4: Optimize for discoverability → adds SEO and structure

Same pattern. Different domain. Each step is a skill. Each skill invokes a specific agent. Each agent has tools and instructions tailored to their job.

No step tries to do another step’s job. And honestly, defining good skills is harder than it sounds — our first versions produced output that needed heavy rework. But each iteration makes the pipeline sharper.

Why This Matters More Than You Think

In 2–3 months, the specific tools will change. The interfaces will evolve. New models will drop. But the pattern — break work into roles, give each role clear instructions, chain them together — that pattern is here to stay.

It’s the same pattern behind every scalable system humans have ever built. Assembly lines. Microservices. Unix philosophy. Org charts.

Pipe small, specialized things together. That’s how you build something bigger than any one piece.

If you’re still using AI as a single chat window, you’re leaving most of its power on the table. It’s like having a Kubernetes cluster (a system designed to run hundreds of specialized containers) and running everything on one pod.

The Real Skill Is Knowing What to Delegate

Here’s the paradox that trips people up: the better AI gets, the more your human judgment matters.

Not less. More.

Because when you can spin up agents that analyze repos, review code, scan for security issues, and generate reports — the bottleneck isn’t execution anymore. It’s direction. It’s knowing:

• What criteria define a strong candidate for this team?
• What scoring thresholds make sense?
• When should a human override the recommendation?
• What’s the quality bar for the review itself?

That’s you. That’s the human in the loop. Not doing the work — directing it.

The people who will thrive in this era aren’t the ones who learn the most prompts. They’re the ones who learn to think like managers of AI teams. Who can break a fuzzy goal into clear tasks. Who can define “done” for each task. Who can look at the output and know whether it hits the bar.

A Practical Framework You Can Use Today

If you want to start working this way, here’s the simplest version:

1. Map Your Workflow to Roles

Take any recurring task. Break it into stages. Each stage becomes an agent.

Reviewing candidates? Analyze Repo → Review Code → Scan Security → Generate Report. Writing a blog? Research → Write → Edit → Optimize. Building a feature? Design → Implement → Review → Test.

2. Define the Skills for Each Role

For each agent, write down:

• What they produce (a brief, a draft, a review, a report)
• How they should produce it (format, tone, length, structure)
• What tools they need (web search, file access, code execution)
• What quality looks like (examples, checklists, constraints)

3. Chain Them Together

The output of one agent becomes the input of the next. Research feeds writing. Writing feeds editing. Editing feeds optimization.

Each handoff should be clean — the next agent shouldn’t need to guess what happened before.

4. Review the Output, Not the Process

Your job is quality control at the end, not micromanagement in the middle. Trust the pipeline. Check the result. Adjust the skills if the output consistently misses the bar.

The Cards Are Being Reshuffled

Until six months ago, the game was about prompt engineering — crafting the perfect input to get a good output. That still matters, but it’s table stakes now.

Today, the game is about architecture. How you structure the work. How you define the roles. What instructions you encode as skills. How you chain agents into pipelines that produce consistent, high-quality output.

Tomorrow? Maybe agents become more autonomous. Maybe they start defining their own skills. But right now, the leverage is in the design — and that design is yours to create.

Henry Ford didn’t build better cars by working harder. He built them by thinking differently about how work gets done — who does what, in what order, with what tools.

That’s the exact same opportunity sitting in front of you right now. The AI models are your specialists. The skills are your playbooks. And you? You’re the one who decides what gets built.

Stop prompting. Start delegating. Define the agents. Write the skills. Build the pipeline. And let the system produce something no single prompt ever could.

Why prompt engineering isn’t just a technical skill — it’s a mirror for human thought itself.

Socrates Never Needed an API Key

Twenty-four centuries ago, a man wandered the streets of Athens asking people uncomfortable questions. He didn’t lecture. He didn’t hand out scrolls. He just… asked. And through those questions, he peeled back layers of assumption until his interlocutors — sometimes painfully — arrived at something closer to truth.

Today, millions of people sit in front of a blinking cursor, trying to get an AI to do what they want. Most of them don’t realize it, but they’re engaged in the same fundamental act Socrates was: the art of formulating the right question.

We call it “prompt engineering.” But strip away the Silicon Valley branding and what you’re left with is something ancient: the struggle to externalize thought into language precise enough to be understood by another mind — except this time, the other mind is artificial.

This isn’t an article about how to write better prompts. There are plenty of those. This is about what the act of prompting reveals about us — about how we think, what we fail to communicate, and why learning to structure your thinking for a machine might be the most valuable professional skill of the 21st century.

You Don’t Know What You Want (Until You Have to Say It)

Here’s a common experience: you open ChatGPT or Claude, type “help me with my project,” and get back something vaguely useful but mostly generic. You frown. You try again. You add details. You specify. By the fifth attempt, you realize something unsettling:

You didn’t know what you actually wanted until you were forced to articulate it.

This is an epistemological problem — a question about the nature of knowledge itself. Philosophers have long distinguished between tacit knowledge (things you know but can’t easily express) and explicit knowledge (things you can clearly state). Michael Polanyi captured this beautifully: “We know more than we can tell.”

Prompting an AI is, in a very real sense, an exercise in converting tacit knowledge into explicit language. And it turns out we’re shockingly bad at it. Not because we’re unintelligent, but because most human communication relies on shared context, body language, tone, implication, and a thousand unspoken assumptions that no prompt can carry.

When you write a prompt, you’re forced to confront the gap between what’s in your head and what you can put into words. That gap — that uncomfortable space — is where philosophy has lived for millennia.

The Wittgenstein Problem: Your Prompt Is Your World

Ludwig Wittgenstein, arguably the most influential philosopher of language in the 20th century, wrote: “The limits of my language mean the limits of my world.”

He meant that we can only think about what we can express in language. If you lack the vocabulary for a concept, that concept effectively doesn’t exist in your cognitive world.

Now apply this to prompting.

A software engineer prompting an AI about system architecture will naturally produce richer, more specific prompts in their domain than a marketing manager would. Not because one is smarter, but because one has the linguistic framework — the vocabulary, the mental models, the conceptual scaffolding — to articulate what they need.

This creates a fascinating paradox: the people who need AI’s help the most are often the least equipped to ask for it effectively. A junior developer doesn’t know enough to describe the architecture they need. A first-time founder can’t articulate the business model they haven’t yet learned to name.

Prompting, then, is not a neutral skill. It’s bounded by your existing knowledge and language. The richer your mental models, the better your prompts. The better your prompts, the more useful the AI’s output. Which then enriches your mental models further.

It’s a virtuous cycle — but only if you have enough to start with. And that’s a problem worth thinking about.

What Do You Mean? The Grice Problem

In 1975, philosopher Paul Grice proposed a theory about how human communication actually works. He argued that successful conversation depends on a set of unspoken rules — what he called “conversational maxims.” Things like: be relevant, don’t say more than necessary, be clear, and be truthful.

But here’s the crucial insight: Grice showed that meaning is not just about words. It’s about intention.

When you tell a friend “it’s cold in here,” you’re probably not delivering a weather report. You’re asking them to close the window. Humans navigate this effortlessly. We infer intention from context, relationship, and a lifetime of social learning.

AI models don’t have this luxury. They process your words — all of them, literally. When your prompt says “make it better,” the AI doesn’t know if you mean more formal, more concise, more creative, or more accurate. It doesn’t have access to the intention behind your words. It only has the words themselves.

This is why the gap between a bad prompt and a good one is so dramatic. A bad prompt assumes the AI can read between the lines. A good prompt makes the lines themselves carry all the meaning. In Gricean terms: a good prompt explicitly encodes the intention that human-to-human conversation carries implicitly.

Every time you rewrite a prompt because the AI “didn’t understand,” you’re essentially discovering — in real time — all the unspoken intentions your original words failed to convey.

The Mirror: Your Prompt Quality Is Your Thinking Quality

Here’s the uncomfortable truth that prompt engineering tutorials rarely mention:

The quality of your prompts is a direct reflection of the quality of your thinking.

A vague prompt doesn’t mean you’re bad at prompting. It means your thinking about the problem is still vague. A disorganized prompt means your thoughts about the task are disorganized. A prompt that produces irrelevant results often means you haven’t yet clarified — to yourself — what’s actually relevant.

This is why the most effective prompt engineers aren’t necessarily the most technical people. They’re the clearest thinkers. They’re the people who can decompose a complex problem into discrete, well-defined sub-problems. They can anticipate ambiguity and preempt it. They know what they want before they ask for it.

In this way, prompting is less like coding and more like writing a philosophy paper. The legendary writing advice from philosophy professors — be clear, define your terms, structure your argument, anticipate objections — maps almost perfectly onto prompting best practices.

Jim Pryor, a philosophy professor at UNC Chapel Hill, tells students: “Be concise but explain yourself fully. Make the structure obvious. Use plenty of examples.”

OpenAI’s prompting guide says: “Be specific and detailed. Split complex tasks into simpler subtasks. Use examples.”

These are not coincidental overlaps. They emerge from the same root challenge: taking the messy, nonlinear, associative chaos inside a human mind and flattening it into clear, sequential language.

The Five-Prompt Journey: What Happens When You Think Out Loud

There’s a pattern that almost everyone who uses AI regularly will recognize, even if they’ve never named it.

Your first prompt reflects what you think you want. Your second prompt corrects what you said wrong. By the third, you realize you’ve been framing the problem incorrectly all along. The fourth is a genuine reframing — you’re no longer editing your words, you’re restructuring your understanding. And by the fifth, for the first time, you actually know what you need. Not because the AI taught you, but because the act of repeatedly failing to articulate it forced your thinking to crystallize.

This is not a flaw of the process. It is the process. And the people who understand this use AI very differently from those who don’t.

But here’s what most people miss: this same dynamic doesn’t just apply to a single prompt in a chat window. It scales — and where it scales most painfully is in the world of AI agents.

The Agent Illusion: When Unclear Thinking Meets Unlimited Delegation

We’re now living in the era of AI agents — systems that don’t just answer questions but execute multi-step tasks, use tools, write code, search the web, and orchestrate entire workflows. The promise is seductive: describe what you want, and let the agent figure out how to get it done.

But here’s what actually happens when you delegate to an agent without first clarifying your own thinking: the agent runs. It consumes context. It makes tool calls. It generates intermediate outputs. And somewhere around the third or fourth step, things start to drift. The agent fills in ambiguity with assumptions — reasonable-sounding but misaligned assumptions. By the time you see the final output, you’ve burned through your context window and what you’re looking at isn’t a hallucination in the technical sense. It’s the inevitable consequence of vague delegation meeting infinite execution capacity.

We blame the AI. We say it “hallucinated.” We say it “went off the rails.” But what actually happened is more uncomfortable: we asked something we hadn’t fully thought through, and the machine dutifully followed our confusion to its logical conclusion.

This is the Mirror Hypothesis at scale. A single vague prompt produces a single vague answer — minor damage. A vague instruction to an autonomous agent produces a cascade of compounding misalignment — each step drifting slightly further from what you actually needed but never articulated.

The teams and practitioners who get the most out of AI agents aren’t the ones with the fanciest tools. They’re the ones who invest in something far less glamorous: defining the architecture of thought before the architecture of execution. They clarify what each agent is responsible for. They define the boundaries of each role — what it should do, what it should never do, what it should escalate. They design the communication protocols between agents the same way a good engineering leader designs communication protocols between teams: with clarity, with constraints, and with an explicit understanding of what “done” looks like.

In other words, they don’t just delegate tasks. They think through the task first — and then encode that thinking into the structure of the system itself.

This is the deepest practical implication of the philosophy we’ve been exploring. Whether you’re writing a single prompt or orchestrating a team of AI agents, the bottleneck is never the AI’s capability. The bottleneck is the clarity of the human thought that set it in motion.

The agents are only as good as the thinking that designed them. The prompts are only as good as the understanding behind them. And both are mirrors — not of artificial intelligence, but of the real kind.

The Recursive Loop: When AI Writes the Questions

Now things get interesting.

We’ve established that prompting is an act of externalizing thought — translating internal cognition into explicit language. But what happens when the AI starts doing this too?

We’re already there. Meta-prompting systems — AI writing prompts for other AI — are becoming standard practice. Frameworks like DSPy automatically optimize prompts. Companies use AI to evaluate AI outputs and refine the instructions that produced them.

This creates a recursive loop:

1. Humans externalize thought into prompts.
2. AI processes those prompts and produces outputs.
3. AI systems analyze those outputs and generate better prompts.
4. Those better prompts produce better outputs.
5. Repeat.

Philosophically, this is fascinating and slightly vertigo-inducing. If a machine can formulate questions better than we can, what does that say about the nature of questioning itself? Is the Socratic method something uniquely human, or is it a pattern — a structure of inquiry — that any sufficiently sophisticated system can learn?

There’s a pragmatic limit here: AI-generated prompts optimize for measurable outcomes. They get better at producing outputs that score well on defined metrics. But the most interesting questions — the ones Socrates asked, the ones that make philosophy philosophy — aren’t the ones with clear metrics. They’re the ones that make you reconsider the metrics themselves.

A machine can learn to ask “What’s the most efficient architecture for this system?” It’s far less clear whether it can learn to ask “Should we build this system at all?”

Prompting as a New Liberal Art

The medieval university organized knowledge into the “trivium” — grammar, logic, and rhetoric. These weren’t just academic subjects. They were the foundational skills of clear thinking: understanding language (grammar), reasoning correctly (logic), and communicating persuasively (rhetoric).

Prompting sits at the intersection of all three.

It requires grammar — not in the pedantic sense, but in the sense of understanding how language structure carries meaning. It requires logic — decomposing problems, structuring arguments, maintaining coherence. And it requires rhetoric — persuading the AI (or more precisely, steering it) toward the output you want by choosing the right framing, examples, and emphasis.

Maybe we should stop calling it “prompt engineering.” Engineering implies a technical skill — something you learn once and apply mechanically. What prompting actually demands is closer to a liberal art: a cultivated capacity for clear thinking, precise expression, and structured inquiry that improves with practice and deepens with wisdom.

Conclusion: The Question Is the Answer

The irony of the AI age is this: we built machines that can generate answers at superhuman speed, and discovered that the hard part was always the question.

A practical note: by the time you read this, the word “prompt” may already feel dated. The interfaces are evolving fast, and six months from now, the friction may be invisible. But the thinking discipline we’ve described here isn’t about prompts — it’s about clarity. And clarity compounds. The people who learn to structure their thinking now, using the tools already in their hands, will move faster today and adapt faster tomorrow. AI is evolving — we’ll see where it goes. But clear thinking never goes out of style.

Every time you sit in front of that blinking cursor and struggle to articulate what you want, you’re not just doing “prompt engineering.” You’re engaging in one of the oldest human activities there is — the attempt to make your own thinking legible, first to yourself, then to another mind.

Socrates believed that the unexamined life is not worth living. In the age of AI, we might update that:

The unexamined prompt is not worth sending.

Not because the AI won’t respond — it will, dutifully and instantly. But because the act of examining it, refining it, and making it precise is where the real value is created. The AI’s answer is just the receipt. The prompt was the work.

And maybe that’s the deepest lesson of all. AI is not broken. It’s not overhyped. It’s an extraordinarily powerful tool that rewards structured thinking. The people who say “AI doesn’t work” are almost always the people who haven’t invested in clarifying what they actually need. Structure your thinking — define your rules, your constraints, your context — and the results will speak for themselves.

AI gave you a mirror. If you don’t like what you see, don’t blame the glass. Learn the tools, follow best practices, structure your thinking — and make sure you’re using the right tools to translate that thinking into AI effectively. Do that, and AI will compound your value exponentially.

References

Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press. — “We can know more than we can tell.” (p. 4)

Wittgenstein, L. (1921/1922). Tractatus Logico-Philosophicus. Translated by C.K. Ogden. Routledge & Kegan Paul. — “The limits of my language mean the limits of my world.” (Proposition 5.6)

Grice, H.P. (1975). “Logic and Conversation.” In P. Cole & J.L. Morgan (Eds.), Syntax and Semantics, Vol. 3: Speech Acts (pp. 41–58). New York: Academic Press.

Pryor, J. “Guidelines on Writing a Philosophy Paper.” Department of Philosophy, UNC Chapel Hill. Available at: jimpryor.net/teaching/guidelines/writing.html

OpenAI. “Prompt Engineering Guide.” OpenAI Platform Documentation. Available at: platform.openai.com/docs/guides/prompt-engineering

Khattab, O., Singhvi, A., Maheshwari, P., Zhang, Z., et al. (2024). “DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines.” The Twelfth International Conference on Learning Representations (ICLR 2024). Stanford NLP. Available at: github.com/stanfordnlp/dspy

Plato. Apology (38a). — “The unexamined life is not worth living.” (Attributed to Socrates.)

The Philosophy of Prompting: How Asking Questions to Machines Reveals How We Think was originally published in Insider One Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.