Kent Beck: Build AI Programming Tools for Human Needs

I recently revisited my Tidy First workshop material. About a third had become obsolete in a year, but much remained relevant. The speed of change makes it natural to ask which practices still help us design software.

Two years ago I spoke here about anxiety over AI and jobs. Last year the mood felt closer to panic and despair. This year, in the conversations I have had, I hear frustration and anger but also a willingness to act. For me, anger can signal that it is time to set a boundary.

I enjoy programming with what I call the genie, though it frustrates me too: it grants a wish but not always what I meant. Today I want to combine that experience with my earlier distinction between the forest and the desert—two ways an organization can approach software development.

In the Smalltalk world, programmers routinely built small tools for their immediate problems. I have begun doing that again with the genie. Recently I asked it to visualize a messy call graph as a D3 force layout, refining the result through a dialogue.

I wanted others to use the tool, but packaging and generalizing software introduces work and assumptions. Instead, I condensed the dialogue into a prompt that another person can use to generate a version for their own context. I call these “tool seeds”: distributing the seed rather than a finished tree.

The current tools will change, but their design already has consequences. I am troubled by celebrating programmers who wake at night to keep prompting and sleep very little. The productivity of a tool should not be measured by how completely it consumes a person’s life.

When I began experimenting with AI-assisted coding in 2025, I suddenly tried projects I had wanted to build for years. As an experienced engineer, I had accumulated ideas that seemed worthwhile if only setup and implementation were easier. The new tools removed enough friction to make those experiments tempting.

I also found myself coding constantly and waking at night to send another prompt. I have bipolar disorder, and I experienced a manic episode followed by depression. Later I deliberately stopped using the tools on weekends and stopped prompting at night; setting those boundaries helped me.

This is why I want tool builders to take responsibility for the consequences of their choices. Mental health effects do not necessarily disappear when a session ends. Encouraging compulsive use is not a neutral design decision.

In the desert, an organization assumes there will never be enough time, stability, skill, people or access to domain experts. People still accomplish remarkable things under those constraints, but scarcity shapes every decision. Paying down technical debt seems impossible when there is already too little time for requested features.

In the forest, the assumption is that there will be enough resources, though the environment is not free of danger. Teams work in ways that replenish resources for the next round. Refactoring can make future progress faster, helping create the time that the work requires.

Organizations can have an oasis of healthy practice inside a wider desert, but maintaining that oasis is difficult. The distinction is not a moral judgment about the people involved; it describes different feedback loops and the choices organizations reinforce.

The genie acts as an amplifier. In a scarcity mindset, teams may shorten already unrealistic timelines or focus narrowly on minimizing token usage, intensifying anxiety. The same technology can instead amplify healthy practices: previously uneconomic experiments become affordable, and people can explore alternatives or learn.

I use the genie as an endlessly patient tutor, though I still need to check its answers. In a desert, not knowing something may feel dangerous to admit. In a forest, a gap in knowledge can be a reason to investigate, and the tool can help with that investigation.

Neither minimizing nor maximizing tool usage is a sensible goal by itself. Engineering is a space of trade-offs. The genie amplifies the beliefs and practices we bring to it: if we were making good music, it can make it louder; if we were making noise, it amplifies that too.

Another way to see the trade-off is through features and futures. Many projects move quickly at first and then become progressively harder to change. I have a collection of restarted projects because each attempt eventually slowed until starting over felt easier.

Every feature can consume some future options by making the next change harder. The genie tends to offer another feature immediately, and sometimes adds one without asking. Eventually a bug fix can introduce more bugs, even though a powerful tool is producing changes quickly.

My concern is not simply that we get the same software faster or cheaper. In my experience, we can get worse software faster. A tool that appears to finish a task may have improved the system—or may have produced more output than anyone can bear to review.

The alternative is to pause after a feature and ask what would have made it easier to add, and what would make the next one easier. Small improvements to the structure replenish options. They do not replace feature delivery; they alternate with it.

As an investor, I care about preserving optionality, especially when conditions change rapidly. A project with many features but few remaining options can be less valuable than one with enough features to survive and more ways to adapt.

Those structural improvements are hard to justify in a desert because they may not look like immediate feature progress. I once explained my testing and refactoring process to a client who asked how much sooner I could deliver without it. My answer was that it would take twice as long.

In a forest, improving future options is a normal part of the rhythm. Do a little at a time and continue delivering features. Extreme Programming has long emphasized this rhythm and close contact with customers; agentic development has not made those needs disappear.

When I first heard that large language models could produce syntactically correct software, I was skeptical. Their usefulness remains astonishing. It made sense for early tool builders to explore what the models could do, because we did not yet know.

But I think it is time to change the focus. Too much attention has gone to adjusting programming around the model. I want tools designed around human needs rather than assuming that producing more code for less money is the whole objective.

I tell a famous story about cake mixes: supposedly, manufacturers made customers add an egg so baking would feel like an accomplishment. When I checked the history, I learned that this familiar version was not accurate; the account I found emphasized frosting and decoration instead.

The story still illustrates a question about experience. People need to feel competent and challenged in their work. Before the genie, a problem could lead through struggle to insight and a solution; that effort contributed to the satisfaction of understanding what happened.

When I outsource the struggle entirely, I may accomplish a great deal yet finish the day feeling hollow. The tool fixed the problem, but I missed the effort and insight that made the work satisfying. Challenge and competence are distinct needs that current tools do not adequately address for me.

Connection is another need. If each person works alone with a private repository and a collection of agents, speed may come at the cost of interaction with other people. More agents are not a substitute for human connection.

The “dark factory” ideal—in which agents build everything while a person returns much later—does not appeal to me. I want a meaningful role in the process, not merely a bill and software that is only partly finished or working.

Purpose matters too. A team can remind itself why it is building something and why it is doing so together. When work is reduced to isolated tickets passed along a process, it can be difficult to see why a particular task deserves a piece of a finite life.

The results I see from the genie are not consistently good enough for me to step out of the process. I want tools biased toward human needs: tools that help people produce useful software while retaining a sense of purpose and contribution.

Engineering such tools will require experimentation. I recommend a book about what engineers know, including the years of practical work needed to develop reliable flush rivets for aircraft. Engineers often discover what works before scientists can fully explain why.

One principle is to promote connection. A tool might notice that a colleague recently changed the same area and suggest a conversation. It could also help developers connect with users, domain experts, managers and investors rather than making those relationships seem like an unaffordable luxury.

Another principle is to automate toil. Repeated low-value prompts, such as asking permission for routine directory changes, can interrupt concentration. Yet removing toil is different from removing every useful struggle; telling the two apart will be difficult.

I do not want programming made effortless. I want important decisions surfaced, assistance in understanding their trade-offs, and help communicating the decision to people who need to know. If the genie makes too many choices silently, I lose opportunities to learn and may get worse results.

Learning should be encouraged throughout the work. Today I can stop the agent and ask it to explain unfamiliar Rust syntax, then ask for a flash card and a later quiz. But I have to interrupt the tool’s preferred process to make that learning happen.

Imagine finishing a day with a tool that promoted connection, removed toil, supported the struggle toward insight, surfaced choices and encouraged learning. I would expect a stronger sense of satisfaction, purpose and belonging. Building tools like that will require deliberate effort and incentives beyond simply consuming more tokens.