Cheap Software Still Needs Product Judgment

I can now move from an idea to working software in an afternoon. An agent can create the repository, choose a stack, build the interface, add tests, configure deployment, and leave me with something polished enough to demonstrate. The result may be better than the first version I would have written manually, and it may even be good code.

That speed creates a new failure mode because a repository full of convincing artifacts makes the idea behind it feel more considered than it was. The implementation starts to look like evidence that the idea deserved to exist, even though it establishes only that the idea could be implemented.

The worst agent-generated software is easy to dismiss when the interface is generic or the code is careless. The more interesting problem begins when the first version looks competent, because it becomes tempting to treat idea criticism, incubation, design, implementation, testing, and refinement as one continuous generation task. Slop is often a collapsed product process before it is a code-quality problem.

The Friction We Accidentally Lost

Before agents, building software was expensive enough to force some deliberation. That did not guarantee good decisions: long projects can be badly designed, and hours spent typing code are not evidence of quality. But implementation cost created a practical question before a project began: is this worth building?

I might search for existing tools, explain the idea to someone else, sketch the important boundaries, or reduce it to an experiment. Sometimes I would discover that another product already solved the problem. Sometimes the idea would lose its appeal before I had invested much in it.

Agents remove much of that resistance. When implementation feels nearly free, the easiest response to an idea is to build it immediately, and a few hours later the project has a name, visual identity, architecture, backlog, and deployment. Every artifact increases the sense of commitment, making it harder to ask whether the premise was weak because the answer now threatens work that already looks real.

Some of the old friction was waste. Some of it created useful pauses. The task now is to preserve the pauses without restoring the waste.

This does not mean every repository needs a complete product process. A disposable prototype can answer a question and end. The distinction is whether the implementation is being used to test a premise or being trusted as the beginning of a durable product.

Cheap Features Are Still Expensive

This failure becomes more dangerous inside an existing product. An abandoned experiment may cost little beyond the afternoon spent creating it, while a feature added to a product enters a system that users and a team already depend on and can remain there for years.

On teams I have worked with, engineers regularly find appealing additions along the way. A new dashboard might make an internal metric visible. A terminal interface might make one workflow feel faster. A helper might hide an awkward part of an API. When even small additions competed for meaningful engineering time, that cost forced more of them to be justified before implementation.

That pressure was an imperfect product filter, and agents weaken it. A dashboard, TUI, helper, integration, or settings panel can now appear as a polished pull request before anyone has decided whether it belongs in the product. The implementation looks complete before the product decision has been made.

Even when the marginal implementation cost is small, the feature still has to be understood, documented, tested, secured, supported, and kept compatible with the rest of the system after it ships. It adds another path through the product and another choice for users to interpret. Research on feature fatigue found that people can prefer greater capability before using a product, then place more value on usability after experience reveals the cost of complexity. Each addition can also expand the failure surface, constrain later design, and create migration work when the team eventually tries to remove it. A feature that takes an afternoon to generate can therefore create years of maintenance, and if nobody wanted it, fast implementation has only delivered bloat and technical debt sooner.

Cheap implementation does not remove the need for an accountable product-selection function. Whether that responsibility belongs to a product owner, founder, or team, its purpose is not to protect people from writing code. It is to force comparison between possible work and ask questions that a working implementation does not answer:

• Who needs this, and what evidence do we have?
• What outcome is it expected to change?
• Is that return worth the lifetime maintenance and risk?
• Will it clarify the product or make it harder to understand?
• Who owns it after the person and agent that created it move on?
• What are the long-term consequences if it becomes a contract?

Agents make it cheap to prototype a feature before answering those questions, and something concrete to test can improve the decision. The prototype should not become its own justification for being merged. The time between an approved decision and a tested implementation can collapse, but the judgment about whether a feature deserves to become part of the product should remain.

Code Is An Intermediate Output

The same distinction applies to how AI productivity is measured. Lines of code, pull requests, completed tickets, generated tests, shorter implementation time, and feature count can all show that software production has accelerated, but they do not establish that a product has become more useful. The SPACE framework makes the narrower measurement point that developer productivity cannot be represented by activity metrics or any single dimension. Code is an intermediate output; a product also requires a problem worth solving, evidence that people experience it, a coherent model, distribution, adoption, support, trust, and continued value after the first implementation.

Existing products can absorb enormous amounts of newly affordable code. There are always deferred integrations, migrations, internal tools, compatibility fixes, customizations, and marginal feature requests. Much of that work is useful. It is also easier to authorize than a new product because the users, system, owner, and backlog already exist.

This makes it possible for an organization to report dramatic coding productivity while its rate of validated product improvement changes much less. The implementation metric arrives when the code is merged. The product evidence may not arrive until people use the result repeatedly, contact support, encounter failures, or quietly ignore the feature.

A better measure follows the work beyond production:

• Did it change the user behavior or operational outcome it was meant to change?
• How much review, rework, support, and maintenance did it create?
• Did it reduce uncertainty or merely add another option?
• Would anyone object if it were removed?

Cheap code should shorten the path to that evidence. It should not make code volume its own definition of progress.

Sometimes the best way to buy evidence is to build several bounded alternatives before choosing a direction. The extra implementations are useful only when they support a credible comparison and can be discarded after the decision, which creates a separate problem: deciding what each prototype must reveal and how the alternatives will be evaluated fairly.

Criticism Comes Before Commitment

Evidence should begin before product commitment, not necessarily before code. A disposable prototype can be part of the criticism; the mistake is letting its repository become the product direction before the idea has survived basic questions. What problem does it solve, who experiences that problem often enough to care, and what already exists? Would adapting an established tool be better, what evidence would make the premise look wrong, and what is the smallest experiment that could produce that evidence?

Agents are useful here. They can search for alternatives, generate objections, compare approaches, simulate different users, expose assumptions, and propose cheaper tests, which may be a better use of agentic breadth than immediately asking for an implementation. But generating ten objections is not the same as reconsidering an idea: if the objections appear in one window and the build begins five minutes later, criticism has become another box in the prompt. Some ideas need to sit long enough for the excitement of having them to separate from their actual value.

Rich Hickey describes a deliberate version of this process in Hammock Driven Development. His argument is more demanding than simply sleeping on a decision. Concentrated waking work supplies the background mind with a problem worth processing. Stepping away and sleeping create room to sort the inputs, discover relationships, and return with alternatives that immediate tactical thinking may not reach.

Delay alone does nothing, because a neglected idea does not improve merely because a day passed. The useful sequence is sustained attention, separation, background processing, and renewed conscious criticism. Agents can supplement the hammock, but they should not eliminate it.

A Foundation Is A Bet On The Second Version

Once an idea survives criticism, an agent can produce a strong initial structure. It can identify familiar architectural patterns, propose contracts, compare storage models, and implement the foundation faster than most teams could do manually. Someone still has to decide what kind of system is being built by naming the central concepts, deciding where responsibilities live, defining ownership and lifecycle boundaries, and making failure behavior explicit. That decision also includes choosing what must remain replaceable and what the first version will deliberately refuse to support.

These decisions matter because the first implementation is based on the least experience the project will ever have. Nobody has used it yet. The model has not been tested by awkward requests. Failure paths have not been exercised under real conditions. The architecture is still a collection of predictions.

In AI Has Not Removed the Learning Gap, I argued that working code is a local result while good design reveals itself as a system changes. A generated foundation has the same limitation. Its quality cannot be established only by how quickly the first version comes together.

The purpose of design is not to make the initial generation more elaborate. It is to leave enough coherence for the next version to teach us something without forcing a rewrite of every boundary.

Working Software Starts The Next Loop

A first viable product should begin the next iteration rather than end the project. It needs to be used for real tasks, criticized by someone who did not build it, and stressed beyond the happy path. The result should be compared with the original problem rather than only with the implementation plan, then revised where real use exposes confusion and stripped of generated scope that does not earn its cost.

Agents can accelerate all of this. They can generate adversarial tests, inspect architecture, profile bottlenecks, analyze feedback, propose refactors, and carry out revisions, so an iteration can shrink dramatically when its evidence is available quickly. That speed should let us run more loops, but it often becomes permission to stop after the first one. The repository works, the demo is persuasive, and the agent declares the task complete, so the creator moves to the next idea before the current one has produced any consequences.

Every arrow can become faster, but the sequence still matters. The useful agentic process is longer than idea -> prompt -> repository -> deploy:

1. Start with an idea
2. Criticize the premise
3. Investigate alternatives
4. Let the problem incubate
5. Model the important boundaries
6. Implement a candidate
7. Use it for real work
8. Stress the weak paths
9. Revise what the evidence exposed
10. Simplify, then repeat

Experiments Can End

Cheap implementation also makes experimentation easier, and that is worth protecting. Disposable scripts, prototypes, one-day projects, and speculative interfaces do not need a complete product process. Sometimes the right outcome is a working experiment followed by a decision to abandon it, and a repository left behind after answering a question is not automatically slop.

The distinction is what we ask the result to carry. A prototype can test a premise without promising reliability, a personal script can solve one narrow problem without supporting a community, and an experiment can be valuable even when its architecture would not survive a second user.

The problem begins when a one-shot implementation is described, trusted, or maintained as though it had gone through product development. A polished demo does not establish that the problem is real, the design will hold, or anyone has taken responsibility for what happens next.

Production Speed Should Buy More Evidence

Faster implementation makes it cheaper to skip thought, ownership, and iteration. The response is to spend the saved effort on evidence rather than restore implementation friction. I do not want to spend more time writing boilerplate, searching for method names, or manually repeating changes an agent can perform correctly, because effort is not the goal.

The valuable parts of time are independent criticism, incubation between consequential decisions, feedback from actual use, and revision after evidence arrives. Those activities reveal information that did not exist in the initial prompt. Agents can compress the labor in that process, and the time they save should shorten the path from implementation to evidence while leaving enough capacity to act on what the evidence reveals.

As convincing first versions become cheaper, the scarce discipline is staying with the idea long enough for one of them to become something worth keeping.