Good, Fast, Cheap, and the AI Agent Tradeoff
AI agents make fast and cheap easier, but they make human judgment about what counts as good more important, not less.
“Good, fast, cheap: pick two” is one of those project management cliches that survives because it keeps being useful.
The exact triangle changes depending on who is drawing it. Sometimes it is quality, time, and cost. Sometimes it is scope, schedule, and budget, with quality trapped in the middle. Either way, the point is the same: work has constraints. If you demand more of one side without changing the system, another side usually pays for it.
AI agents change the system.
They make a lot of work faster. They make a lot of work cheaper. They can draft, scaffold, rewrite, summarize, refactor, test, research, and generate options at a speed that makes the old production process feel heavy.
That does not mean the triangle disappeared. It means the bottleneck moved.
Fast and Cheap Are Getting Compressed
The obvious benefit of AI agents is output velocity.
A founder can prototype an app without waiting for a full engineering team. A developer can ask for a first pass instead of starting with a blank file. A writer can generate outlines, counterarguments, summaries, and alternate structures in minutes. A product person can turn a vague workflow into a clickable sketch before the meeting is over.
That matters. Fast and cheap are not fake benefits. Reducing the cost of trying things changes what people are willing to try.
But when output gets cheap, output stops being the scarce part.
The scarce part becomes knowing which output is worth keeping.
Good Becomes the Bottleneck
AI agents can produce something plausible very quickly. Plausible is not the same as good.
Good requires judgment. It requires knowing whether the implementation is maintainable, whether the design fits the user, whether the argument actually holds, whether the abstraction is worth having, whether the edge cases matter, whether the system will survive contact with production, and whether the thing being built deserves to exist in this form at all.
This is why “AI slop” is not just AI-made work.
AI slop is output accepted without enough standards behind it. It happens when nobody in the loop bothers trying to make it good, or nobody involved understands the domain well enough to recognize what good would look like.
The model can generate. Someone with judgment has to evaluate.
Vision Is Not the Same as Knowing What Good Is
This matters most in vibecoding.
Vibecoding is useful because it lets someone move directly from intent to working software. You describe what you want, steer the model, accept changes, run the app, and keep going. The feedback loop can feel incredibly productive.
But having a vision for what should exist is not the same as knowing whether the thing in front of you is good.
Vision provides direction. It says: build a journaling app, a dashboard, a marketplace, an internal tool, a checkout flow, a better onboarding path.
Quality judgment evaluates the actual artifact. It asks: does this subscription upgrade modify the existing plan or create a second charge? Does this auth flow leak data across tenants? Can I debug this when a user reports a production-only bug? Will this codebase still make sense six weeks from now? Did the agent solve the problem or just satisfy the prompt?
Those are different skills.
Without the second skill, vibecoding turns into a slot machine for plausible progress. The app keeps changing. The demo keeps improving. The prompts keep coming. But nobody is stopping long enough to inspect the structure that is forming underneath.
Slop Is Often a Review Failure
A lot of bad AI work is not bad because the first draft was bad. First drafts are supposed to be rough.
It is bad because the first draft was treated as finished.
That is the workflow failure. The agent produces a surface that looks complete enough to move on. The human accepts it because it matches the shape of the request. The missing work is invisible until later: the payment edge case, the confusing state model, the untested migration, the security assumption, the brittle abstraction, the copy that sounds polished but says nothing.
AI made the change cheap. It did not make the commitment cheap.
Once generated work lands in a real product, it becomes part of the maintenance surface. Someone has to understand it. Someone has to debug it. Someone has to explain it when it fails. Someone has to decide whether the next change should extend it, replace it, or delete it.
That does not always have to be the same person who prompted the agent. But it does have to be someone. If you cannot personally tell whether the work is good, you need a collaborator, reviewer, mentor, senior engineer, editor, domain expert, or customer proxy who can.
The Practical Rule
Use agents to make options cheap.
Do not use cheap options as an excuse to lower the standard for what gets accepted.
That means writing acceptance criteria before generating important work. It means reviewing the parts where mistakes are expensive. It means treating tests, logging, and observability as part of the output, not cleanup after the output. It means knowing which workflows should get extra scrutiny: payments, authentication, permissions, data integrity, migrations, security, user trust, and long-lived architecture.
For students and people trying to enter a field, this changes the learning target. It is no longer enough to ask, “Can I get the tool to produce the artifact?” The harder question is, “Can I tell whether this artifact is any good?”
A junior developer still needs to learn how to write code, but now they also need to learn how to recognize good code when an agent writes it first. A junior marketer still needs to learn how campaigns work, but now they also need to know whether generated copy fits the audience, offer, and channel. A new analyst still needs to learn the mechanics of research, but now they also need to spot weak assumptions, bad sources, and confident summaries that outrun the evidence. A designer still needs to learn taste, hierarchy, and usability, because a generated layout can look finished while solving the wrong problem.
It also means knowing when to stop prompting.
There is a point where another generation pass is less useful than reading the code. Or walking through the user flow. Or checking the data model. Or writing the test. Or asking whether the feature should exist at all.
The agent can keep producing. That does not mean production is the next responsible step.
The Triangle Still Has Teeth
AI agents make fast and cheap easier to get together. That is a real shift.
But “good” did not become automatic. It became more dependent on the standard around the work.
The better the agents get, the more leverage moves to the human standard behind them: taste, domain understanding, review discipline, and access to people who can recognize quality before users are forced to discover the lack of it.
The old rule was good, fast, cheap: pick two.
The new rule is harsher:
AI can give you fast and cheap. Good still has to be owned by someone who knows what good means.