In October 2010, at the first Clojure/conj, Clojure's creator Rich Hickey gave a talk with two titles, Step Away from the Computer and Hammock-Driven Development. Its argument was that hard problems need time to think as well as time to code, and sixteen years later, with agents that research, plan, code, test, and deploy software, it describes the part of the job those agents leave to you.
Writing code keeps getting cheaper, and you can hand whole implementations to an agent, but the handoff still assumes you know what you want to build and why, which is the assumption Hickey spent forty minutes examining.
The illusion of progress
There is a familiar pattern when you build with agents. You describe an idea in the editor, an agent starts working, and the result is not quite what you expected, so you write another prompt and then another, changing the architecture, adjusting components, and reworking the design while the agent keeps generating code and proposing solutions. By every visible measure the work is moving, and eventually frustration sets in anyway.
Sometimes the model, the context window, and the instructions are all fine, and the gap is that you have not yet worked out what you are trying to accomplish. Without that clarity each iteration can carry you further from what you wanted, because you are optimizing a solution before you understand the problem. Agents let you make that mistake faster than before: a poor architectural decision that once took weeks to turn into a problematic implementation can now become a whole application built on the wrong assumptions in an afternoon, and the speed of the build is no evidence that the direction was right.
What Rich Hickey understood
Hickey called the talk an experience report with little methodology in it, and its central claim is about where software goes wrong: "most of the big problems we have with software are problems of misconception." Testing and type systems catch defects in an implementation, and as he put it, "there aren't really type systems that can tell us if we've got a good idea." You can write correct code, pass every test, and build a sound architecture that solves the wrong problem.
His remedy starts before any code. State the problem out loud or in writing, because he had seen whole systems built where nobody ever wrote down what problem they were supposed to solve. Then understand it: the facts, requirements, and constraints you know, the things you know you do not know, and the solutions other people have already built for similar problems. Be critical of your own proposal, and compare at least two solutions before you claim a tradeoff, since a tradeoff only exists between alternatives.
Then he asks you to step away from the computer. Hickey describes a waking mind that is good at analysis and tactics but tends to climb toward the nearest local maximum, and a background mind, with sleep as its main instance, that makes connections and does the strategic thinking abstractions need. The listing and analysis you do while awake exist to give that background mind an agenda, which is why he suggests sleeping on any important decision for at least one night.
Psychologists call the effect of setting a problem aside incubation. Ut Na Sio and Thomas Ormerod's 2009 meta-analysis found a positive incubation effect that was larger for divergent-thinking tasks, the kind with many acceptable answers, than for linguistic and visual insight problems, and larger after a longer preparation period. The preparation finding is the measured version of Hickey's warning that a problem you looked at for ten minutes before going to the movies will not get solved in your sleep.
When code becomes cheap
In Engineering in the AI Era I wrote that as agents take over implementation, an engineer's time moves to constraints, review, and deciding what should exist. AI coding factories carry that shift further, with agents moving work from specification through implementation, verification, and release. Exploring alternative architectures, generating the interfaces for each, and automating large parts of the lifecycle are ordinary uses of an agent now, which puts more weight on the step before the first prompt, because everything downstream runs at machine speed on whatever that step decided.
Code is not free, though. Integration, verification, maintenance, and operations still carry real costs, and what has become far cheaper is the first implementation. As that stops being the bottleneck, the value moves to defining problems, designing systems, and exercising judgment, which takes more than better prompts: reading systems, recognizing patterns, evaluating tradeoffs, setting constraints, and knowing what a good solution looks like.
Vocabulary is leverage
Directing agents well depends on a strong conceptual foundation and a precise technical vocabulary. Models draw on far more information than any engineer can hold, and how well they follow you still depends on how precisely you can state what you intend.
Make this interface look better leaves the agent to infer what better means, and the candidates include visual hierarchy, cognitive load, consistent spacing, accessibility, and information architecture. If you know design engineering, composition, typography, design systems, and user experience principles, you can name the one you mean. Architecture works the same way: scalable and maintainable hands the agent two adjectives, while system boundaries, contracts, responsibilities, data models, and operational requirements give it decisions to respect.
Separation of concerns, information hiding, loose coupling, deep modules, and API-first design each compress an architectural intention into a few words, which is what lets you delegate implementation decisions inside a well-defined boundary instead of prescribing every detail. Technical knowledge is becoming less about knowing how to execute every solution and more about knowing which solutions exist, when they fit, and why. Each of those terms stands for a model of how systems behave, and Hickey's advice for building such models is the one he gives for any hard problem: read widely, down to research papers you only partly understand, because more input gives your mind more to connect.
Old principles, new relevance
Much of what the field knows about modularity, abstraction, software design, and systems architecture was worked out between the 1960s and the 1980s, and agents make that work more relevant. In 1972, David Parnas published On the Criteria to Be Used in Decomposing Systems into Modules, which treated a module as a work assignment and counted among its benefits that separate groups could work on each module with little need for communication. Those benefits, he argued, depend on the criteria used to divide the system. He compared two decompositions of a small indexing program, one that followed the steps of the processing and one in which each module hid a design decision likely to change, and in the first, a change such as no longer keeping every line in memory touched every module.
Swap the groups for agents and that benefit reads like a brief for multi-agent work. An agent can implement a module in a single session, and if the work is split along the steps of a task instead of around the decisions likely to change, every agent builds on the same shared assumptions, so one wrong assumption spreads across all of their changes at once. Parnas's conclusion, to begin with "a list of difficult design decisions or design decisions which are likely to change" and design each module to hide one of them, is the instruction I would give before splitting work across agents.
That is why I think systems engineering, design engineering, software architecture, and design systems matter more now: they supply the concepts needed to direct a large implementation coherently when several agents write it. Two of the engineering principles I work from, less code over more and the Unix rule of small parts connected by clean interfaces, gain weight for the same reason, since the interface is the part you review and keep while the code behind it is the cheapest part to regenerate.
None of this calls for heavy process or endless specifications before the first line of code. Hickey said plainly that he was not advocating the waterfall model, and he told the audience not to reach for a UML tool for their notes. What he asked for was the discipline of thinking before building, and agents help with the research half of it: you can ask one to find other solutions to the same problem, which he calls the fastest way to get up to speed, and ask another to pick your proposal apart, the way he asks you to look for defects in your own solution.
Intelligence, intent, and taste
Choosing among the options an agent explored is where human and artificial intelligence differ most. Current models reason through complex problems, recognize patterns, form hypotheses, and propose solutions you might not have considered, and underestimating that would be a mistake. Human judgment is also grounded in lived experience, goals, motivations, values, and the consequences of a decision, context an agent does not carry into your product.
An agent can propose ten excellent designs for a product, and choosing the one that represents what you want to build takes priorities, constraints, and preferences, including the hardest of them to write down, which is taste. Hickey lists errors of taste and judgment next to technical errors and errors of logic among the defects to look for in your own solution, and that is how I use the word: noticing when an architecture is more complex than its problem, when an interaction feels unnatural, when an abstraction makes the system harder to understand, or when something is technically correct and still not right.
You can teach agents much of that. Preferences, references, and design principles can live in instructions and skills that agents apply consistently, and you can delegate a substantial amount of judgment along with them. Delegating a decision does not delegate responsibility for its consequences, though, so as agents become more autonomous, the work is to state the intent, the boundaries, and the success criteria clearly enough that they can operate inside them without guessing, instead of supervising every implementation detail.
Step away from the computer
One risk of working with agents is confusing activity with productivity. Agents are available around the clock, so you can keep changes generating continuously, run several tasks in parallel, and leave runs going for hours, until every minute without an agent executing something starts to feel like a missed opportunity. Some of the best engineering decisions in that setting are stops: cancelling a run, reconsidering an assumption, abandoning an approach, or closing the editor and going for a walk.
Hickey's case for the hammock was partly about focus. He called computers "bad, bad sources of distraction" and said "it's almost impossible to focus sitting at a computer." The meta-analysis adds a detail that matters for agent work, because filling the incubation period with a high-demand task shrank the effect, and reviewing another agent's pull request while the first problem sits is exactly that kind of task.
In Touch Grass, Activate Clarity I described my Grass Hour, a two-hour morning hike with no screens. Hickey's talk gives the same habit an engineering argument: the background mind works on what you loaded into it, and it needs time away from input to do that work.
Hammock-driven agentic development
I would apply Hickey's ideas to agent work as a habit in five steps, which stays closer to his experience report than to a methodology:
- Understand the problem. Write the problem down before any feature list or technology choice, and separate it from your first idea of the solution. List the facts, the constraints, and what you know you do not know, then apply Hickey's test: "If there are no question marks, you're missing a step."
- Explore the solution space. Ask agents to research other solutions to the same problem, analyze constraints, and identify risks, then compare at least two approaches with their tradeoffs and critique your favorite before you commit to it.
- Step away. When you are prompting in circles without meaningful progress, stop generating code and take the problem somewhere without input, whether that is a walk, a sketch, or a conversation, and ask whether you are solving the right problem. An important decision gets the night Hickey asks for.
- Make decisions explicit. Write the decisions, architectural constraints, design principles, and acceptance criteria into the repository where agents read them, so they can work autonomously without repeatedly guessing your intent.
- Delegate execution. Let agents implement, test, review, and iterate, and evaluate the result against the problem statement from the first step as well as against whether the code works.
Thinking before implementation does not mean designing a perfect system up front. Hickey closes the talk by telling the audience they will be wrong and the facts will change, and his advice for that moment is not to dig in but to redo the analysis and check whether the answer still holds. Software development stays iterative, and the difference is that each iteration should reduce uncertainty instead of only producing more code.
On the next feature I hand to an agent, I would put the problem statement at the top of the spec with its question marks still on it, and keep the two approaches I compared underneath with their tradeoffs, so the run starts from the decision I made. When a session turns into rewriting the same prompt, I would close the editor, go back to that statement, and rewrite it before writing another prompt.