Not the point of a workout? Correct. Genies are being designed as a RoboGym for the mind. What if they weren’t? Wha…

Read more

Features & Futures

Something similar to the structure of the two fields, programming & math, is that there is a (relatively) visible part—features in the case of programming & proofs in the case of mathematics—& a huge (relatively) invisible part. The invisible part is understanding, education, simplification, enabling abstractions.

If all we work on is the visible part, progress on that visible part slows to a crawl. But nobody gets credit for the invisible work, so we rely on an ethos of work to ensure that the invisible work gets done and everyone can continue to make progress on the visible stuff.

I call this hidden dimension “futures”, although “optionality” might be a more accurate word (if less alliterative).

In programming we also call this inverse of this axis “technical debt”, coined by Ward Cunningham. Sometimes you have to pay off your debts to get “interest” payments low enough that you can get back to progress on the principal.

Genies Hate the Invisible

I wonder if the angst among mathematicians is because:

1. The genie is so good at the visible stuff

2. Without the invisible work, visible progress eventually slows to a crawl, genie or no genie

3. Nobody gets credit for the invisible work

Put these together & you have a world where mathematicians no longer get any credit. The visible stuff is better done by machine. The invisible stuff is, well, invisible.

So What?

One constructive response to the identity crisis for programmers is to say hey I’m here to keep the genie on course. With the genie’s help I’m able to learn quicker than ever before. I still get to use my honed intuition to quickly stop useless directions. My reach has just extended. Yes, my work has changed, but my strategic decisions are more valuable than ever because they come more frequently.

I visualize this as taking breaks between visible progress to make invisible progress. I wonder if this way of thinking about their situation will help mathematicians take advantage of the powerful new tools available to them without losing their reason for being mathematicians. Good luck!

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.

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