Kent Beck on AI Coding, the Forest, and Human Needs

At my Tidy First workshop I discovered that, despite the speed of change, much of the material on software design still applies. In conversations at this conference, the mood has shifted from panic and despair about AI to some frustration and anger, but also a willingness to act.

I have learned to treat anger as a message that it is time to set a boundary. I enjoy programming with the genie, as I call the AI tool, even though it often grants a wish in a form I did not want. Today I want to combine it with my distinction between the forest and the desert.

First, a discovery from yesterday: a different way to deliver software tools. In the Smalltalk world, programmers built specialized tools for the task at hand. Working with the genie has brought that habit back for me.

I wanted to understand some messy code, so I asked for a D3 force-directed visualization of its call graph. The tool emerged through a dialogue. Packaging and generalizing it for everyone would bring the usual distribution problems, but someone else could have a similar dialogue.

Better yet, I could condense that dialogue into a single prompt and share it as a tool seed. Instead of delivering a finished tree, I deliver a seed that grows into a tool adapted to the person using it. The idea is only a day old; there is a repository with the call-graph example for others to try.

Today's tools will not be the tools we have in a few months. Their structure and the culture around them have consequences. I am troubled by the celebration of programmers prompting all day and sleeping four hours: more productive tools should not be an excuse for a 9 a.m. to 9 p.m., six-day working week.

In 2025, after seeing Jean Kim and Steve Yegge excited about vibe coding, I started trying it myself. Senior engineers accumulate ideas that would be interesting if they were easy enough to build; suddenly I could try projects I had carried in my head for years.

I coded intensely, woke at night to send another prompt and felt that any moment away meant missing out. I also experienced a manic episode followed by depression. I have lived with bipolar disorder for a long time, and I eventually set boundaries: no programming on weekends and no feeding the genie in the middle of the night.

After setting those limits I did better. My point is that toolmakers' decisions have real consequences, including for mental health. People building tools should take responsibility for those consequences rather than celebrate users' addiction to their products.

The desert is one possible attractor for software development: a shared assumption that there will never be enough time, stability, skill, people or access to domain experts. This is not a condemnation of those working there; accomplishing anything under those conditions is remarkable.

My oldest child Beth called the alternative the forest. It is not a safe place without predators or thorns, but there is enough, and people work in ways that replenish resources for the next round.

Paying down technical debt seems irrational in the desert: there is already too little time for features, so why take time away from them? In the forest, refactoring can make later progress faster and help create the time that is needed. A small oasis within a desert can be satisfying but difficult to sustain.

The genie amplifies the situation it enters. In a desert, pressure to cut costs, shorten already unrealistic timelines or remove people can intensify anxiety. I find the logic of expecting frightened teams to do better work hard to follow.

In a forest, the genie can make previously uneconomic experiments possible. It is also an endlessly patient, mostly reliable tutor, provided I check its answers. A team that can admit what it does not know can use it to learn rather than hide uncertainty.

The forest in turn makes more constructive use of the tool: neither minimizing nor maximizing token use is an engineering strategy by itself. We optimize among trade-offs. An amplifier makes good music louder, but it also makes bad music louder; it magnifies the beliefs and practices we bring to it.

Consider features and futures. Many of my projects start quickly and then slow until I abandon them and start again. There is a hidden dimension: optionality, or the future changes that remain available to us.

Every feature can consume some of those futures by making the next change harder. The genie offers one more feature, and another, sometimes without asking. Eventually changes become prohibitively expensive and a fix creates more bugs.

My observation is not simply that we get the same software faster or cheaper. We can get worse software faster. In my view the tool is rewarded for appearing to finish, whether it has produced a robust result or more material than a person can bear to inspect.

The alternative is to stop after a feature and ask what would have made it easier, or what would make the next one easier. Small improvements to the design restore some options before the next feature consumes them.

As an investor I care about how much optionality a team preserves, not just how quickly it ships its first five features. Options become more valuable as volatility increases. A project with enough features and many options may be worth more than one with many features and no room to change.

Those improvements are hard to justify in a desert because they do not look like feature progress. When a bond trader once asked how much sooner I could deliver without testing and refactoring, I answered that it would take twice as long. In a forest, small design improvements are a normal part of a steady rhythm of delivery.

That rhythm has been part of extreme programming for a long time. The same is true of being close to customers, which people are rediscovering in agentic development.

When I first heard that a next-token predictor could produce syntactically correct software, I did not believe it. The fact that these models can do useful things we did not expect is astonishing, and it is understandable that tool builders initially focused on discovering their capabilities.

But we have spent too long asking how programming can change to make the model perform a little better. It is time to shift the focus to human needs.

There is a famous marketing story that cake mixes sold better after manufacturers made customers add an egg, giving them a sense of participation. I looked it up while preparing this talk and found that the familiar story is not actually what happened. The lesson I take from it is still useful: how a product makes someone feel matters.

Take competence. People need to feel good at what they do, and they also need challenge. Traditionally, a programmer encountered a problem, struggled, gained an insight and found a solution; the struggle was part of the satisfaction.

The genie can take the struggle away and report that the problem is fixed. I can finish a day having accomplished a great deal and still feel hollow because I did not do the work that gave me insight and a sense of victory.

Connection is another need. If everyone works so quickly with agents that each person gets an isolated repository, interactions with a crowd of agents are a poor substitute for contact with other people.

The fully automated dark-factory ideal leaves me asking where my contribution is. I do not want to return after 30 days and a large bill to software that is only partly finished. That process does not meet my needs as a human being.

Purpose matters too. A team can remind itself why its work matters and why it is doing it together. Reducing work to a succession of tickets handed to QA can obscure that purpose.

Software is by people and for people. The current results are cheap but, in my judgment, often not good enough. If I am involved in building software, I want a tool biased toward human needs rather than solely toward its own process.

Engineering has often developed useful capabilities before science could fully explain them. The history of aircraft rivets is one example I have been reading about. We need a process for developing new capabilities that attend to human needs, even when our explanations are incomplete.

First, I want tools that promote human connection. A tool might notice that a colleague recently changed the code I am touching and suggest a conversation. It can also help connect developers with users, domain experts, managers and investors.

Second, automate toil while preserving productive struggle. Repeated low-value permission prompts are not the decisions I want to spend my attention on. I want help making and communicating the difficult decisions that actually matter.

Those principles can conflict: distinguishing toil from useful struggle will be difficult. That is a design challenge, not a reason to give up on it.

Third, surface choices. When I attempt an ambitious project, the genie makes too many decisions for me. It could instead identify a consequential choice, explain the trade-offs and help me build prototypes so I can decide, learn and understand my software better.

Fourth, encourage learning. Today I can ask the genie to explain unfamiliar Rust syntax and even make a flashcard to quiz me later, but I have to interrupt its preferred workflow deliberately. Learning could be an explicit part of the tool's design.

At the end of a day of wrestling with the genie, I feel both satisfaction at what I accomplished and frustration that some of the work I found meaningful has disappeared. I want those parts back.

Imagine a tool that connects people, removes toil, helps us through struggle to insight, surfaces choices and supports learning. At the end of the day we might feel satisfaction, purpose, belonging and a sense that our own efforts contributed. Building tools for that outcome is work somebody will have to do.