Twenty Hands That Never Tire

There is a particular kind of deadline where everything feels slow. You know what needs to happen and roughly who should do it, yet you are on the third reminder of the week, watching the calendar advance while the work does not. Then you open a tool, describe what you need, and something usable appears within minutes. The relief is considerable, and for a moment it seems that the problem of getting things done has been solved. My position, which I will try to defend in the rest of this piece, is that the relief is real but the conclusion drawn from it is often premature. Agents do change how work gets done. They do not change who is responsible for the result, and they do not remove the need for a standard that someone has to hold.

I understand the pull toward agents better than most, because I have been on both sides of the arrangement. As a college student experimenting with projects, I had to ask friends to help with things I could not do alone. I spent a great deal of energy reminding them, following up, and trying to work out why a commitment had quietly stopped moving. Later, as a founder, I found myself in a similar position again, except that the stakes were higher and the people depending on the outcome were not all friends. When you have lived through inconsistent effort, a tool that never sulks, never needs encouragement, and never has a bad week looks almost like a mercy. I do not think that feeling should be dismissed as naive. I do think it deserves a closer look.

The strongest version of the case for working alone with agents deserves to be stated fully before I question it. A single capable person equipped with agents can move quickly across many kinds of work. Someone who has no training in a particular area can ask an agent to draft, research, or prototype in that area, and in doing so can learn the subject while producing something tangible. There is no ego to manage, no reluctance to overcome, and no slow ramp-up period for a new colleague to pass through. The person in charge can experiment freely, make mistakes cheaply, and adjust course without needing to persuade anyone. For exploration, for testing ideas, and for building the first version of something, this arrangement can be remarkably effective. I would not want to argue against that, and I expect that I will keep relying on it.

What the argument tends to leave out is where the work goes once the agents have produced it. Agents do not eliminate work. They relocate it. Someone still has to define what a good result looks like, and that definition is harder to write than it first appears. Someone has to write instructions precise enough that an agent will follow them without drifting. Someone has to check the output, which is the part that gets neglected most often. An agent will produce a result that reads well and looks plausible, and a confident mistake can be far more dangerous than an obvious one, because it passes a quick glance. Someone also has to decide which of the many things that could be done are worth doing at all. Each of these tasks requires judgment, and judgment is not something that can be delegated in the same way a drafting task can.

The practical consequence is that the bottleneck moves. Before agents, the constraint was usually the time it took to produce output. With agents, production becomes cheap and fast, and the constraint becomes review, direction, and decision. Reviewing the output of a single agent on a single task is manageable. Reviewing the output of twenty agents across many tasks, every day, while also making the decisions that only you can make, is a different kind of job. It consumes attention in a way that is easy to underestimate, because each individual review looks small. The accumulated effect is that the person at the center of the system becomes tired in a specific way, often more tired than they would have been managing three people who could take on real responsibility. Fatigue of this kind tends to show up as slower judgment, and slower judgment is the thing a solo operator can least afford to lose.

There is also a question about learning, which the argument presents as one of its clearest benefits. It is true that working with agents on unfamiliar material can teach a great deal. A person who tries things outside their expertise will often discover a surprising amount, and will ask better questions as a result. But learning to direct an agent is not the same as learning the subject deeply enough to tell when the agent is wrong. Someone who has not yet built that depth may find that the agent's fluent answers are persuasive precisely because the person cannot evaluate them. Experimentation is valuable, and I would not discourage it. The caution is that the experimenter should be honest about when they are learning and when they are relying on output they are not yet equipped to judge.

Underneath all of this is an ethical question that deserves more than a passing mention. When work that once went to people is handed to software instead, someone bears the cost. It is frequently the person who needed the income, the experience, or the opportunity to grow into a more senior role. That cost is real, and it does not become smaller because the replacement is cheaper or more reliable. I do not think this means that everyone who uses agents is acting unethically. Many people have no realistic choice, and many tasks would never have been done by a person at all. But the ethical weight of a decision should be acknowledged rather than assumed away, particularly when the decision is being made because it is convenient.

There is a quieter cost as well, and it is easy to miss while under pressure. A team is not only a set of tasks being completed. It is also a pipeline of people who learn, challenge, and eventually take on responsibility for things that matter. The people who would have caught mistakes, pushed back on weak ideas, and grown into leaders are part of what makes an organization durable. A team made only of tools and one overloaded person has no such bench. That loss does not appear in the first month, when things look fine. It appears later, when the founder needs a second opinion and no one has earned the standing to offer one, or when the one person carrying everything becomes unavailable.

When I look back at my own experience with teams, the failures I remember most clearly are not dramatic. Work arrived late, or arrived inconsistently. Effort rose and fell with the week in ways that were hard to predict. I kept reminding people, following up, and quietly doing parts of the work myself, and I told myself that the root problem was motivation. Some of it probably was. But I have come to believe that much of what I attributed to motivation was actually something more basic: unclear ownership, and a standard that was never stated plainly or applied evenly. When people do not know exactly what is expected, or when they can see that expectations are applied unevenly, consistent effort becomes very difficult to sustain, and it is unfair to blame them for that.

I learned this most painfully while building ibbe, a company I helped create and that eventually came to an end. The lesson I took from it was not that people were unreliable. It was that I had allowed closeness to influence the standard, and that this had consequences I did not fully see at the time. When effort became optional for someone I was close to, the people who were working hardest noticed. They did not usually complain. They adjusted. Some lowered their own bar to match what was tolerated, and others eventually left for places where the standard still meant something. The cost of that double standard never showed up in any single decision, which is exactly what made it so damaging. It accumulated quietly, and by the time it was visible, it had already shaped how everyone understood what was expected of them.

A related pattern appeared in how we approached scale. We acted at times as though we were already the established company we hoped to become, rather than a small group still working out whether the idea deserved to exist. That gap influenced decisions about who should attend important meetings, how much of the work the founder should do directly, and how much energy should go into work that was genuinely central rather than merely interesting. Early on, a founder carries a real obligation to do important work directly, because there is often no one else who can do it with the necessary conviction. Delegating too early, while the company is still finding its footing, can leave the most important tasks in the hands of people who have not yet been given the context or the authority to succeed.

Distraction was another part of the picture, and I think it is especially relevant to anyone working with agents today. Tools that make building easier also make building feel productive, and the feeling of progress is not always the same as progress on the thing that matters. I kept building secondary tools and small projects alongside the core work. Some of them had genuine value, but a fair share of that time was spent satisfying the pleasure of making something new rather than advancing the company. Agents make this trap considerably easier to fall into, because the cost of starting something new has fallen so sharply. A person with twenty agents can build a great many things quickly, and the question of which of those things deserve attention becomes more important, not less.

Agents do not address any of these problems. They make them less visible, which is a different thing and in some ways a worse one. A tool does not complain when the standard is unclear, and a tool does not leave when the work is inconsistent. A founder who replaces inconsistent people with consistent software may find that the immediate friction has disappeared, and may conclude that the underlying problem has been solved. In reality, the standard may never have been defined in the first place, and the absence of that definition will continue to shape outcomes in ways that are harder to observe. The problem has not been removed. It has only been moved somewhere quieter.

My own position, after considering these experiences and the argument for agents, is fairly simple. Working alone with agents is excellent for exploration, rapid iteration, and learning areas outside one's expertise, and I would use it without hesitation for those purposes. But work that depends on ownership, accountability, and a second mind willing to disagree still needs people. A solo operator can produce a great deal, and can produce it well, but the decisions that determine whether that output is good enough, consistent enough, and aimed at the right problem are the ones that most need a second perspective. Relying entirely on one person's judgment, supported by tools that cannot challenge that judgment, is a narrow foundation for anything that needs to last.

I should also acknowledge that I may be wrong about some of this. There are people who will work alone with agents and do exceptionally well, and their success may come from a clarity of standard and a discipline of review that I have not yet fully developed. The difference, as I see it, is not whether the work is done by a person or by software. The difference is whether someone has defined the standard, applies it consistently, and is willing to notice when it is not being met. A solo operator who does this may well outperform a larger team that does not. The question is less about headcount than about whether the standard is real.

For that reason, the question I would ask before adding anyone, or adding any new agent to the work, is what standard that person or tool will be held to, and whether I can state that standard clearly enough that they could meet it without my standing over them. If the answer is vague, then the problem is not the lack of help. The problem is that the work has not yet been defined well enough for anyone, human or otherwise, to do it reliably. Hiring a person into an unclear situation will not solve that, and neither will delegating to a tool.

It is also worth being specific about what a good standard looks like in practice, because the phrase can sound abstract. A clear standard usually means that everyone involved knows what done looks like, knows who is responsible for checking it, and knows what happens when the work falls short. It means that the same expectations apply to a close friend and to a stranger, and that the people doing the best work can see that the bar is real. It means that review is not treated as optional when the output looks plausible. These are not glamorous qualities, and they do not make for dramatic stories. They are, however, the qualities that determine whether consistent effort is possible at all.

Going back to the deadline that started this piece, I think the honest conclusion is that agents will make you faster, and that speed will feel like evidence that the problem has been solved. Sometimes it will be. Many tasks genuinely do not require the kind of accountability that people provide, and using tools for them is a reasonable choice. But the questions that decided how things went in the projects I have been part of were rarely about whether the work could be done. They were about who was accountable for the result, what standard was held every day, and whether the effort was steady enough to matter over weeks and months rather than only in the rush before a deadline.

So the next time you feel the pull to hire or to automate, it is worth asking a different question first. What would I need to see every day from whoever, or whatever, is doing this work, and would I be able to tell if it stopped happening? If the answer is unclear, then no tool and no new person will supply the clarity for you, and the deadline will simply arrive again in a different form. Twenty hands are only useful when someone knows what they are for, and the most valuable thing a founder can do with them is to decide that first.