I feel the same way about AI models right now. I don’t claim to understand the details, not yet, but I’m fascinated by the mechanism of it all. I’m interested in both:

• How models work but also,

• The machinery that makes a model.

It’s this latter topic, how a model gets constructed, that I will begin to explore in this post (& possible followups).

Baking

I love baking. You take ingredients in one form & transform them to a totally different form. The ingredients aren’t palatable in themselves but what you create from them is delicious. Oh and also baking is sensitive to initial conditions—you can make a small change early in the process & it will have a large consequence later.

I’ve been experimenting with cold proofing, where you let the yeast do its work overnight in a refrigerator. As I was working to understand models it struck me that there’s an analogy there to creating models, at least as I understand the process so far (please correct me in the comments if I’ve gotten something wrong).

First, though, a progressively revealed story about what we mean by a model. I’ll over-simplify but then reveal more complexity a little at a time.

Zooming Out

By “model”, we mean a computer system that can converse with a human (see, told you I’d over-simplify—hope you stay with me, this won’t take long).

Actually it’s a little more complicated than that. The model is split into 2 parts:

• A user interface that takes care of formatting inputs & outputs & sequencing & authentication & all that stuff.

• The model proper where the magic happens.

The user interface is built using conventional programming techniques (even though “convention” has changed radically in the last 2 years). The model proper, though (our topic of exploration) is built using radically different techniques.

Model

A model is a bag of numbers. For today’s purposes that’s enough (maybe some day we’ll get to how those numbers are used when the model is producing useful words, but I’d have to understand it a little first).

How did we come up with these numbers? Unlike in programming, where you lay out a sequence of statements the result of which is a program, AI models result from training.

Training bears some resemblance to programming—you change an artifact to modify its future behavior—but also some huge differences.

Pre- & Post-Training

You wouldn’t just magically guess a bunch of correct numbers in one go. Oh no, oh no. First we get some approximately correct numbers & then we tweak them to get even better numbers. The two processes are wildly different.

(Near as I can tell, there’s pre-training, post-training, & mid-training (about which I know nothing), but there’s not “training” except as the composition of pre-, mid-, & post-. Here’s hoping the vocabulary evolves.)

Pre-training is a big batch. The whole team sets up the initial conditions—the data & the blank model. They run the data backwards & forwards through the model a gajillion times. They take snapshots along the way in case of crashes. They check for signs that the pre-training has driven off into the weeds & needs to be tweaked & restarted. Pre-training is a big bet—hundreds of millions of dollars & (more expensively) months of delay.

(I need to learn more about how pre-training folks collaborate.)

Pre-training is the cold proofing of model training.

• You mix some stuff together.

• You put it away somewhere where you can’t mess with it.

• You just have to let it play out.

• The result isn’t usable but it’s the precursor to the process that follows.

Post-training is lots of little batches. Folks (called “researchers” but in my naive bluntness I’d call “model engineers”) look at particular problems the raw model addresses poorly & explore possible tweaks that might improve performance. The result is lots of little chunks of code & data (the surviving experiments) that apply to the model as it currently exists.

Post-training supplements the original model. Apply enough supplements & you have a model that, when paired with a UI & a user & compute can respond to, “Give me 5 unusual focaccia toppings.”

Post-training is the shaping & cooking of model training. You take something with potential & make it delicious for humans. (The analogy doesn’t cover the collaborative, iterative, & reversible nature of post-training—le sigh.)

Conclusion

In a followup I’m going to explore the different teams & roles involved in this whole process. They have some interesting divergences of incentives, tools, rhythm, short-term vs long-term, feature vs future, backgrounds, & culture.

First, though, I wanted to double check my understanding of the process. Let me know if I got something wrong above.

Most teams don’t have a strategy problem. They have an adaptation problem.

Your plan was never going to survive contact with reality. The question is whether your organization bends or breaks when it doesn’t.

I help teams bend. Adapt to Thrive.

Booking a handful of custom talks and advisory engagements now. I interview your people, measure your real software flows, and hand you the truth plus what to do about it.

Curious whether it fits? Tell me about your team.

• Volatility & how it shows up in software development

• What it means to go short or long volatility

Today we’re going to talk about one of the most hidden ways of going short volatility & its counter-intuitive mathematical basis—the Kingman Formula.

The Problem

We’re taking our cue today from queueing theory. In our model of the world we ha…

Read more

Neglectful

The first bias is usually making structure investments too late. You write …

Read more

I’ve started a series of Canon articles where I explain my ideas as plainly & unambiguously as possible—no analogies, no persuasion, just the facts. I started with Canon TDD. I expect to continue with Canon JUnit, Canon XP, and Canon Make-The-Change-Easy.

The growth of anything forms a logistic curve:

Take a software product—throughout the curve we ship changes, attract customers, & bill those customers. However, the smoothness of this curve is a dangerous illusion. The beginning, middle, and final portions of this curve require completely different approaches, even if they look superficially similar.

Emergence

I promised that the Canon series would be no theory, just stuff. One tiny bit of theory is essential to the 3X: Explore/Expand/Extract story. It’ll introduce vocabulary we’ll use in the rest of the explanation.

That S-shaped curve is described by a formula:

​But that doesn’t help much when we’re trying to make young things grow. Instead, we can see S curve curve as a tug-of-war (oops, analogy, sorry) between two feedback loops:

To create the S curve, first you get the reinforcing loop on the left operating. The more your idea (product/company/movement/whatever) grows, the easier it is to grow more. Then later you get the inhibiting loop on the right taking over, slowing & eventually capping the growth.

A successful idea:

1. Explore Finds a new growth loop (it needs to me new or somebody else would already be operating it).

2. Expand Keeps it operating long enough for the idea to scale, avoiding all the potentially-fatal inhibiting loops along the way.

3. Extract Finishes growing as the ultimate inhibiting loop kicks in.

4. (Bonus) Uses the resources from the first curve to kick off the search for new curves with their own growth loops.

3X’s

Schematically, the progression looks like this:

The central thesis of 3X: Explore/Expand/Extract is that each of these phases, no matter how much they resemble each other, actually requires its own approach to:

• Finance

• Team size

• Project management

• Personnel

• Technology

• Risk management

• Implementation

• Marketing

• Sales

Applying the approach from one phase to an idea in another phase kills ideas.

Explore

Risk: Nobody cares. The idea dies for lack of fuel.

Goal: Find the growth loop. You can’t predict a new loop so you have to find it experimentally.

Strategy: Rapid experiments, maximum creativity, conceptual blending.

Tactics: Tiny teams, no dependencies, quickly discard failures.

Exit: One experiment works way better than others.

Expand

Risk: Can’t scale.

Goal: Avoid fatal obstacles while scaling furiously.

Strategy: Intense focus on the next emerging growth bottleneck.

Tactics: Throttle growth, discard non-essential features, good-enough-for-now scaling.

Exit: Cause and effect of growth become predictable.

Extract

Risk: Can’t sustain.

Goal: Growth with profit,

Strategy: Safely optimize while growing.

Tactics: Small, safe experiments; roll out successes; optimize costs.

Exit: No further return on investment.

All Of The Above

The tricky trick of 3X is managing projects in different phases in the matching styles. You have some Extract products that pay the bills & pay for a portfolio of Explore projects. When a project hits Expand, treat it as a priority even over profitable Extract activities. (Simple to say and apparently nearly impossible to execute.)

Most teams don’t have a strategy problem. They have an adaptation problem.

Your plan was never going to survive contact with reality. The question is whether your organization bends or breaks when it doesn’t.

I help teams bend. Adapt to Thrive.

Booking a handful of custom talks and advisory engagements now. I interview your people, measure your real software flows, and hand you the truth plus what to do about it.

Curious whether it fits? Tell me about your team.

Listen and watch now on YouTube, Spotify, Apple, and most other major streaming platforms.

Brought to you by

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Augment Code is the AI coding platform engineering teams use to build in large, complex codebases. Its context engine maps your entire codebase so agents do the real work: deep code review, PR authoring, security triage, incident response, and more. Engineers stay oriented and in the loop while the agents handle the detail. Trusted by fast-growing and enterprise teams, including Adobe, MongoDB, Snyk, and Webflow.

In this episode

Most conversations about AI and software argue about what the machines can do. This one is about what stays with us. Who cares whether the work is good? Who is accountable when it goes wrong? And how people actually learn to do hard things.

For this bonus edition I sat down with my oldest, Beth Andres-Beck — a software engineer who once wrote self-driving-car software for the DARPA Grand Challenge, took a degree in theater, learned to run large groups of people through community organizing, and is now running for Congress in Massachusetts’ 6th district. We start with a cheese pun and end up somewhere serious: why engineers don’t write tests and how you actually get a team to start, what it means that an AI agent has no drive of its own, and why “the computer did it” is never the whole story.

Takeaways from Beth

1. The geek’s real superpower is asking why people do what they do. Beth’s through-line across every interest she’s ever had — chickens, road-grinding, theater, code — is that people always act for reasons. Maybe not reasons you agree with, maybe reasons no one thought through, but there’s always something. Get curious about the reason and you can solve problems you can’t even see otherwise, like why no one on a team is writing tests.

2. Meta-intelligence beats raw smarts. She told me about a kindergarten class that had all learned to count to thirty. One kid gets to the end and says “thirty-one.” Another kid asks: “How do you know that?” The first kid is smart. The second one goes further and faster, because she isn’t just solving the problem, she’s learning how the solving gets done. That skill has a name, it can be taught.

3. People usually don’t skip tests out of laziness. Beth didn’t write tests for the first seven years of her career, and it wasn’t for lack of caring. There was no off-the-shelf test framework, no Stack Overflow, no examples — she was learning frameworks from a book printed in Japanese, working off the English code snippets alone. If you want more of a behavior, first ask what’s actually stopping it.

4. Learn to write testable code before you worry about the tests. The thing that finally unlocked testing for her wasn’t discipline, it was design. Once she was writing code that was easy to reason about, the tests became easy to add later. A colleague came to her about a feature she’d built and said it was beautifully laid out and trivial to test, even though she’d written no tests for it yet.

5. To get a team testing, lead by pretending — then let the dopamine do the work. Her move as a first-time manager was to just start saying “we’re the mobile team, and we write tests,” until not writing one felt like not being on the team. Then, in code reviews, she stopped pointing out bugs and started pointing out the missing test. Every test someone added caught a real bug, and that loop is more persuasive than any lecture.

6. The best moment in testing is the surprise. A test that passes when you expected it to pass tells you nothing. The rush is predicting red, seeing red, and finding a bug you’re grateful never reached production. For engineers straight out of school especially, each test becomes a small discovery.

7. An AI agent has no endocrine system. I asked, half-joking, how we get the model excited about writing a test. Beth’s says it can’t be. A model has no enthusiasm or drive of its own. The thing that actually does the work is “us plus the genie.” A human brain never just sits there; the computer is a lump until we bring the caring. The wanting-it-to-be-good is still ours.

8. The urge to take humans out of the loop is often a flight from responsibility. When people say an agent can prescribe your medication, what they usually mean is that patients will prescribe their own medication as long as they route it through this program and the company that built the program takes no responsibility. Removing the human doesn’t remove the accountability. It just hides who holds it.

9. Calling a system “objective” is how bias hides. Beth’s bugaboo is the “objective” performance review. The moment you tell people a system is objective, they stop scrutinizing it, and you can smuggle in enormous bias. There’s no platonic ideal of a job someone is objectively good at; there’s only this job, and whether they’re good at the thing you actually need done.

10. It gets harder to see who is responsible when nobody is in the car.
We talked about a driverless car that made an illegal U-turn in front of a police car, got pulled over, and had no one to ticket. “The computer is driving” is the easy story. The real one: software a person wrote is driving, under incentives set by an organization, shaped by tax law, venture capital, and whether that engineer had a fight with their spouse that morning.

11. Systems do exactly what you tell them, not what you mean. Writing self-driving software in 2008, her team gave the car a rule: if you’re stuck, relax constraints until you free yourself. It hit a roadblock, thought for a while, and relaxed “don’t drive on sidewalks” — so it climbed onto the sidewalk and drove around. Exactly what she told it. Not at all what she wanted. Anyone working with agents today knows the feeling.

12. Good engineering can get you fired, and the real AI fear isn’t rogue machines. Beth has watched teams do everything right — refactor, test, integrate, collaborate — ship genuinely good software, and get cut anyway, because management didn’t actually want working software. And when I asked what keeps her up at night, it wasn’t machines doing whatever they want. It was machines doing exactly what a powerful few tell them: a “personal army” that no longer needs anyone else’s cooperation to do great harm.

References

Where to find Beth Andres-Beck:

• Campaign: https://bethfordemocracy.com

• Bluesky: @beth4ma.bsky.social

• Instagram: @beth4MA

• Ballotpedia: https://ballotpedia.org/Beth_Andres-Beck

Timestamps

• 00:00 Intro: a very special edition

• 02:13 When did you first know you were a geek?

• 03:02 Computer geekdom: Widget Workshop

• 03:45 Realizing not everyone’s a geek, and learning to read people

• 06:22 A multifaceted geek: the theater degree

• 07:26 The chicken phase

• 08:54 Following curiosity: people do things for reasons

• 10:26 Why people don’t write tests

• 13:33 Learning to write testable code first

• 14:19 Getting a team to test: “we write tests”

• 16:31 Getting the genie excited: the endocrine system

• 17:43 Taking humans out of the loop, and responsibility

• 19:23 The trouble with “objective” systems

• 20:59 Nobody’s in the car: accountability

• 22:43 The self-driving car that drove on the sidewalk

• 23:54 The software someone wrote, and its incentives

• 25:09 The Good Place: decisions inside complex systems

• 26:45 Work to rule, and the forest vs. the desert

• 29:01 Shipping great software and getting fired

• 29:36 Why agents give managers a sense of control

• 30:47 What awakened the geek in politics

• 32:13 Occupy and the logistics of organizing

• 33:51 The Guild of Guilds

• 36:51 “How do you know that?” — meta-intelligence

• 38:55 Failure is just finding what stops you

• 39:13 What keeps you up at night

When folks say negative things to you, it can feel bad. Put…

Read more

Keith Adams has spent his career at the systems layer, with nine years at VMware, the founding of Facebook's HHVM team, and a run as chief architect at Slack. Now he backs frontier-tech founders at his firm Pebblebed. He and Kent sit by the fire to ask what happens when the twenty-year-old playbook for building software suddenly goes blank. They range across the economics of the shift, from Jevons paradox to software as "proof of work" to a future where the real moat is gigawatts of compute, before turning to what it costs us: the flow state that drew us to programming, now traded for something closer to air traffic control.

This season of Still Burning is sponsored by WorkOS and Augment Code.

The audio version can be found here.

Analogies

I’ve always depended on analogy to communicate. Analogies like “XP is driving” have helped get my point across in ways that a bald statement of facts didn’t se…

Read more

Now this guy is writing Smalltalk!

Here’s the quick start:

1. Load the server into a Pharo image.
   Metacello new baseline: ‘Genie’; repository: ‘github://KentBeck/SmalltalkGenie:main/src’; load.

2. Start it.
   GenieServer current

3. Connect an MCP client.
   claude mcp add --transport http genie http://localhost:8087/mcp

4. Clone the repo, which contains the instruct…

Read more

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job, it split it in two. The part we loved, crafting code by hand, has been commoditized like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting. You can find more of Jessica’s thoughts on her podcast at: Machines of Code and Grace

This season of Still Burning is sponsored by WorkOS and Augment Code.

Listen to the audio version here.

Randy Shoup set out to be an international lawyer. He studied in West Berlin when there was still a wall around it, spent a year at Stanford Law, and had what should have been the perfect summer internship on Sand Hill Road. Instead he spent it watching inventors light up whiteboards with brilliant ideas — then being told his job was just to write them down. That summer broke something open. He went back to Oracle that fall and never looked back. Kent and Randy dig into what it means to need to make things, why the people who wrote the original distributed systems playbook aren’t panicking about AI wiping it clean, and how Jevons paradox explains what happens when cognition gets cheap.

This season of Still Burning is sponsored by WorkOS and Augment Code.

Listen to the audio version here.

“We’re accumulating code faster than we are accumulating trust.” Sometimes a phrase just hits. Yes, we can create code faster now, but software is bipedal—code & trust go together. One without the other just hops along awkwardly.

Trust is as tricky as code. Both are asymmetrical. Code works or it doesn’t. One mistake in a long string of good decisions is the same as just a mistake. Trust accumulates slowly & evaporates in an instant. The difference is that in software sometimes you can repair the mistake in time proportional to the time it took to make the mistake. Trust is irreversible. Once gone it’s hard-to-impossible to get it back.

XP offered faster accumulation of functionality than folks were used to, but it didn’t suffer from the lack of trust we see among genie pioneers. I never thought of it this way before but XP manufactured trust. But how? What is a trust factory? We’ll go from practices to principles to values.

Practices

I’m going to go through XP Classic here, not that newfangled XPAI that folks are talking about, since the new set of practices is not yet settled.

Practices build trust:

• Programmer testing. Thorough automated testing demonstrates trustworthiness to the rest of the team. It also builds trust within the programmer.

• Pairing. Pairing builds trust between programmers. The reduced defect count & improved structure build trust with the rest of the team.

• Continuous integration. Integrating small sets of changes, optimized for safety, reduces gotcha moments for the rest of the team.

• Weekly planning. Demonstrating concrete progress to those who depend on it builds trust, as does honestly reporting hiccups.

• Customer on the team. All the little interactions during the day—asking domain questions, getting clarification, offering alternatives—build trust.

• Continuous deployment. Knowing that your code is running correctly in production adds to your own confidence. Knowing that everyone else operates under the same constraint adds to your confidence in each other. Customers seeing small changes appear nearly instantly builds their trust.

• Refactoring. When improving structure reduces defects or reduces future effort, it builds trust.

• Observability. Knowing that you’ll be alerted to malfunctions builds trust, as does the skin in the game of knowing that you’ll be alerted encouraging prudence so you avoid those malfunctions.

What I notice about this list that I didn’t expect is that each practice that creates trust also encourages trustworthiness. If I know I’m going to get paged in the night, I’ll do the work to reduce the chance that I’ll be paged in the night. If I know I’m going to be writing tests, I’ll do the work to make writing tests easier. I wonder if this is a general feature of the trust factory? We’ll find out

Principles

XP builds on a coherent set of principles aligned with producing value with software. Not surprisingly, given the topic of this essay, they also align with producing trust.

• Humanity. Acknowledging that we are all humans with needs creates trust, in part by encouraging folks to be more honest and clear about their needs.

• Mutual benefit. Looking for win/wins let’s everyone relax & quit trying to grab more than their share of the pie.

• Improvement. Acknowledging that today isn’t perfect but it’s better than yesterday & tomorrow will be better still encourages folks to trust each other.

• Flow. Seeing concrete progress frequently encourages trust, even when things are going slower than we’d like.

• Redundancy. When we address difficult problems several different ways we increase the chance that the problem won’t erode trust.

Sure looks like the same effect is at work. Trust encourages trustworthiness. I’ll be treated with human respect so I treat others with human respect. Others benefit me so I’m encouraged to benefit others.

Does the same process work at the level of values?

Values

Values are the vaguest level of describing XP but contain the most purpose. How do values encourage trust?

• Communication. Saying things that need to be said in ways that can be received builds trust.

• Simplicity. I’m getting iffy about simplicity as a value since successful systems always end up complicated, but having pieces that are easily described builds trust.

• Feedback. Knowing that you’ll be listened to encourages honesty, even when the topic is difficult.

• Courage. Acting from vision & purpose in spite of fears encourages the team to trust each other.

• Respect. Seems obvious to me.

Once again, creating trust creates the conditions for creating more trust.

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Build Trust With Enterprise

Vibe Coding Versus Trust

Software development that focuses on trust as much as features has always been rare. We are now shifting to individuals interacting individually with the genie (I call this the single player problem. Trust, as the opening quote points out, lags features. This mismatch is unstable, unsustainable. When it corrects it’s going to be painful. How does single player augmented development as naively practiced erode trust?

• Genies “care” about satisfying prompts, not purposes. Generated software often doesn’t behave correctly in circumstances that are the least unusual. Thinking, “This works,” & then, “Oh no, it doesn’t,” erodes trust.

• Encouraging single player development eliminates most of the little chances to build trust.

• Purely reactive project management, the natural style when on the feature hamster wheel, risks tactical progress but strategic failure.

• The genie ignores optionality & future change. Walking off the end of the productivity pier is a big trust breaker.

So?

I’m not saying trust is all that matters. I’m saying trustworthy behavior resulting in trustworthy software resulting in trust is the path to effective augmented development.

I’ve been guilty of saying, “The program is the truth.” At one level this is true—whatever we think the system does, what the system actually does is what the system actually does. However, the software system is, as points out, a symmathesy, a human-technical system. We are in it, cannot help affecting it, we can only influence not control it.

What would trust-optimized augmented development look like?

• Slow development to ensure that the damn stuff actually works.

• Slow development to include structural improvements that expand options.

• Slow development to encourage frequent person-to-person interaction.

• Slow development to reinforce & update long-term purpose.

That’s how you go faster. More chances to build trust->more focus on trustworthiness->more trust.

Dan Barrett built OpenProse — a framework that lets you write programs in structured English and run them with an AI agent like Claude Code. The description sounds either obvious or impossible depending on your priors. When I told him it sounded impossible, he said: “People were shocked that it works.”

So we installed it and built something live.

The project: a service that would show me tides, weather, sunrise, moonrise — everything I want to know before a walk along the coast. One command. A few minutes. It came back with an hourly tide chart for Montara (I picked a town I don’t actually live in), fog conditions, waxing crescent moon, the works.

Here’s what interested me about the architecture underneath.

Each OpenProse component has a requires block and an ensures block. Requires is what the component expects from its caller. Ensures is what it promises to produce. I said that looks like a function — domain and range. Dan said think more like a service. The distinction matters: when you have many components, an inversion-of-control container wires them together by matching ensures blocks to requires blocks. The same way Spring would wire Java components — except the whole thing is written in structured English and run by an LLM.

The Dijkstra objection comes up immediately: natural language is too ambiguous to be a programming language. Dan’s answer: we don’t know what’s possible until we walk the landscape. Plenty of people would have said nothing is possible with prose. That’s clearly not true. The question is just where the edges are — and you can only find those by trying.

The ensures block is effectively a postcondition. It’s what every sibling component can rely on. When I asked about extract method — you write one of these things, it grows, eventually you pull a piece out and name it — Dan said yes, all the time. Usually just by asking Claude to do exactly that.

The other clever piece: sub-agents pass pointers instead of data. Variable bindings are files. The pointers are file paths. When a sub-agent produces a giant context block — a full PDF analysis, a research output, a tide chart — it writes it to disk and hands back the path. The main thread stays clean. Context management, done at the file system level.

I’m building a Smalltalk VM from scratch right now — yes, literally writing a VM — and watching this I thought about how different it is to build a virtual machine when your primitives are LLM calls instead of machine instructions. My VM is 1000x faster. But the primitives here are so much larger that on the right problems, it’s a wash.

What’s next for OpenProse is interesting. Dan’s thesis is that the whole industry is moving toward declaring outcomes and letting agents figure out the path. Codex has a /goal feature. Anthropic just shipped something called Outcomes in their API. The pattern is: specify what you want to be true, not how to make it true. OpenProse is an early articulation of that idea at the framework level.

One of my many projects from the last 40 years is now actually possible. The genie just got smarter.

Dan is at @IRL_DanB on Twitter and dan@openprose.ai. OpenProse is open source — search it on GitHub and follow along. He loves feedback and means it.

Get more from Kent Beck in the Substack app

Available for iOS and Android

Get the app

This stuck in my craw at the time Patrick published it but I didn’t have the energy to respond. Now, with the ever-increasing, genie-fueled emphasis on speed, it deserves a second look. Among its several flaws as a statement is that it misses one point that XP got right, a point that’s become leveraged.

I’ll start gently, addressing the OP directly.

Responsibility

I don’t like the tone. Who exactly hired The Slow (may as well be honest & capitalize)? Who created the incentive system in which they operate?

Take responsibility for your part in the situation you describe. You’re not above it all. If you’re going to be judgmental, judge everyone. Or follow the not-a-Walt Whitman quote and, “Be curious, not judgmental.”

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Find Out More

Slow & Expensive Do Go Together

There’s reasons slow & expensive go together. I have connections to the design world. If you fly a team of nth generation carpenters in from Paris to build your cabinets on-site, it’s going to be expensive & it’s going to take time.

“Slow+expensive” has become decoupled from “valuable” in the situation you describe. Part of the investment was much more valuable than other parts. If you can just make the valuable investment & defer the rest, yes, you win.

Compressibility

“Lopping a year off the schedule” works until it doesn’t. Here’s your intention:

There’s a second order effect, though. Eventually you cut corners that bite back. When that happens, you lose control of time & cost.

Now The Slow have incentive to lie to you about progress. They’re caught in a Catch-22, no-win situation. The optimal strategy for The Slow is to hunker down, spend most of their time keeping their noses above water, & hope your attention passes on before they get fired.

But wait, there’s more! Nobody likes being in a no-win situation, so The Slow will inflate estimates, estimates they know you will slash. Now nobody knows anything about the project.

Scope

The missing concept is scope. You want a system that meets the following goals? Okay, how much of which goals first?

All of all the goals? Now you’ve created the perfect breeding ground for The Slow. And you did it. They aren’t “The Slow”. They are responding to your incentives.

Okay, how about this much of this goal & that much of that goal & more later. Now you get sooner, cheaper, & better. Nobody is compressing the incompressible. The system remains transparent & in control.

And because we navigate an uncertain & rapidly changing landscape, cutting scope generates more feedback sooner, leading to less waste & higher concentration of value.

Wrap Up

You’re right that sooner & cheaper are connected. You’re right that projects often start over-scoped, that much investment isn’t concentrated on value.

I disagree with your characterization of your intervention as “adding a temporal constraint”. The many times I’ve seen this done well what happens is that folks are forced to make priority decisions they wouldn’t otherwise make. (Lots to say about why this deferral happens.) Tearing out calendar pages is the trigger making those scope decisions inescapable.

Michael Grinich has an unusual vantage point, his company powers enterprise infrastructure for hundreds of companies, so he sees how the AI transition is actually playing out across the industry, not just in the headlines.What he’s noticing: the whole ecosystem is accelerating, not just the AI companies. And most people are misreading what kind of moment this is. Kent and Michael talk about building when the marginal cost of software approaches zero, what the Red Queen theory tells us about AI competition, how engineering leadership is quietly changing, and what drew Michael to the itchy-brained compulsion to make things in the first place.

This season of Still Burning is sponsored by WorkOS and Augment Code.