AI made execution cheap. Did it also make bad decisions cheaper ?
AI removed a lot of friction.
Code faster.
Design faster.
Write faster.
Research faster.
Launch faster.
That sounds great, and mostly it is.
But I think there’s a side effect we don’t talk about enough:
we can now execute the wrong thing much faster too.
Bad idea? Build it in a weekend.
Weak positioning? Generate 20 versions.
Wrong audience? Automate outreach to 5,000 people.
Bad process? Add AI and scale it.
The boring steps suddenly feel slow, so people start skipping them.
Understanding the problem.
Talking to users.
Questioning assumptions.
Thinking through tradeoffs.
Actually reviewing what AI produced.
AI can improve execution, but it doesn’t automatically improve judgment.
Sometimes it just gives bad judgment more leverage.
I’m noticing that the more execution gets automated, the more important deciding what deserves to be executed at all becomes.
Curious how others see this.
What important part of your work have you seen people skip more since AI made execution easier?
The framing I'd add is that AI didn't lower all costs equally. It collapsed the cost of the reversible half of the work and left the irreversible half exactly where it was. Generating the code is cheap now; migrating a data model you already shipped to paying customers, walking back a pricing page, or un-telling an audience what your product is are all as expensive as they were five years ago. So the useful gate isn't "is this a good idea" (you usually can't know), it's "how much of this becomes irreversible the moment it ships" — and cheap execution should be spent almost entirely on the reversible side. The concrete step I see skipped most is writing the prediction down before the build: one sentence on what you expect to observe and by when. It takes ninety seconds and it's the only thing that converts a shipped feature into information rather than just more surface area to maintain. Do you think the fix is reintroducing artificial friction into the build step, or shrinking the irreversible surface so that speed stops being dangerous in the first place? I lean toward the second, because friction you chose to add is always the first thing removed once you're under pressure.
Interesting. How are you measuring whether it is working?
What made you pick this stack over the alternatives?
Interesting. How are you measuring whether it is working?
One skipped check is whether the input is actually authoritative. An agent can execute perfectly against an obsolete policy or an unapproved proposal. Before automating a decision, I would make the source owner, effective version and permission scope explicit, then test the same request after that source is superseded or access is revoked. The expected result may be escalation or abstention, not another confident answer. That gives the stop condition a concrete trigger rather than relying on the model to notice ambiguity.
Interesting approach. What was the hardest part to get right?
Its damn fast and cheaper but what matter now is marketing which is still lazy task
Interesting approach. What was the hardest part to get right?
Market is still adapting to AI. Its a new toy. Everything AI makes seems amazing, but once we realize building things was never an obstacle everything will stabilize again.
I think this is where things eventually settle too. Building itself was never the whole bottleneck. Once everyone can build fast, picking the right problem becomes much more visible.
I think the bigger risk is that AI makes skipping validation feel productive. You can have a polished product, messaging, and outreach running before confirming that the underlying problem is actually worth solving.
I have found that talking to users and testing the problem manually first saves a lot of wasted execution later.
Exactly. The dangerous part is how productive it can look.
You can have a polished product, landing page and outreach running while still being wrong about the actual problem.
AI makes execution easier, but it makes validation more important, not less.
The stop-condition point is the one I'd build a whole review process around. Most specs describe the happy path in detail and leave "when do we abstain" as an implicit judgment call — which means the first time the system hits an ambiguous case, someone's making that decision live, under time pressure, instead of having decided it calmly in the spec. Cheap execution doesn't just scale bad prompts faster, it scales undefined behavior faster, since nobody wrote down what "don't know, don't act" looks like until the system actually needed it.
Exactly. “Don’t know, don’t act” should probably be part of the spec from day one. Otherwise the system is forced to invent a decision exactly when things get ambiguous.
I've found a useful preflight is to sell one small outcome before automating the whole workflow. Define one buyer, one deliverable, a fixed price, and a turnaround you can fulfill by hand. A few paid requests tell you which part is worth building, and the repeated requests become your automation backlog. That keeps AI from turning an untested assumption into a faster system.
This is probably one of the safest ways to use AI for building. Sell the outcome manually first, then automate the parts people repeatedly pay for. Much harder to automate yourself into a fake market that way.
the one that resonates most is "actually reviewing what AI produced." the output looks so polished now that the quality check has basically collapsed. people used to at least proofread rough drafts — now the draft arrives looking finished so nobody questions it. speed made us lazy reviewers, not just fast builders.
This is something I notice too. Polished output creates false confidence. When something looks finished, people naturally inspect it less, even though the reasoning underneath may still be weak.
Solid point. Validating user demand before getting too deep into the architecture saves so much time.
Yep. Architecture is expensive to unwind once you’ve committed to assumptions that users never actually confirmed.
The thing people are skipping most is the uncomfortable pause before they build. Those five minutes of sitting with "does this problem actually hurt badly enough for someone to pay to fix it?" Most founders I talk to now move from idea to Cursor in under an hour. The idea never gets challenged.
AI removed the friction from building. But the most dangerous friction was never in the building. It was in the gap between "this feels like a good idea" and "I've convinced myself it is." That's where the real work happens — awkward conversations with potential customers, sitting with unclear feedback, waiting on data that tells you something you don't want to hear.
Those steps are still slow. And now that shipping is fast, slow feels wrong. So people skip it.
What I keep coming back to: the cost of a bad decision didn't change when AI arrived. Only the speed of making it did.
This is probably the best way to describe it: slow started feeling wrong. The uncomfortable waiting, conversations and uncertainty still matter, but now they feel painfully slow next to building something in hours.
AI made everything faster. Disasters still happen, only faster. Before we were running on our own legs and now with AI we are in a high powered race car. Gets us there faster, but accidents can be a bigger mess, and if we go to the wrong destination, getting there faster just took us further from where we really wanted to be. AI is great, but it's just a tool. Without good guidance, the benefit is questionable at best.
The race car analogy fits. More speed makes direction more important, not less. Wrong direction at 10x speed can become much more expensive.
Yeah, I think the cost of a bad idea used to be the thing that forced people to think first. If it took three months to build, you'd at least talk to a few users before starting. Now it takes a weekend, so the thinking gets skipped.
The step i see skipped most is talking to real users before building. It feels slow next to shipping something, so people fake it by asking an AI what customers would want.
Asking AI what customers want instead of asking customers is probably one of the funniest and most dangerous shortcuts right now.
SIGNAL: AI made execution cheap, so the first thing that gets skipped is naming the decision before the build. Generating 20 variants feels like progress; committing to one does not.
GAP: Faster research and more competitor tabs don’t fix that — they fill the hole with data. You still don’t know which claim to counter or which price to test in the next ~2 weeks.
ACTION: Force the decision first (“What will we change in ~2 weeks if this is true?”), then only gather dated public evidence that feeds that action, and label uncertainty. Execution after.
Curious for others here: is the skipped step usually “talk to users,” or “write the kill criterion before you start”?
— Francisco / TrixellaIQ — competitive intelligence for D2C brands
https://trixellaiq.com (sample on the site)
I think “write the kill criterion before you start” is the part people skip most. Talking to users helps, but without deciding what evidence changes your mind, you can still rationalize almost anything.
One specific failure I've watched: AI makes generating options so cheap that it quietly replaces committing to one. Teams end up with 20 half-built variants instead of one validated thing, because generating felt like progress. The counterintuitive fix is spending judgment earlier — on the problem statement — not later on reviewing output.
This is a good point. Cheap options can become another form of procrastination. Generating 20 versions feels productive while avoiding the harder decision of choosing one and testing it properly.
The step I see skipped is the first run on a clean machine. The feature gets written, the dirty local checkout is green, and the release goes out. The afternoon that used to be spent installing on a fresh Windows user (no cached tokens, no leftover files) is the first thing cut, because the code itself showed up in twenty minutes.
A gate that still catches the expensive misses: before a release, one scripted path on a clean profile. Open the app, do the one job the page promises, quit, reopen, and confirm the file is still there. If that path takes longer than writing the feature, the feature is not done. Faster execution did not make a broken first session cheaper to support.
That’s a good example of speed cutting out the boring checks first.
The feature may take 20 minutes now, but the failure still costs support time and user trust. Clean-environment testing feels even more important when building gets this fast.
The step I see skipped most is defining the stop condition before automation starts. Teams specify what the agent should do, but not what evidence should make it abstain, escalate, or do nothing. Once execution is cheap, a missing stop rule scales faster than a good prompt. I now treat 'when must this system refuse to act?' as part of the spec, alongside the happy path.
I like this framing a lot.
People define what the agent should do, but not when it should stop. Once automation scales, a missing stop condition can become more dangerous than a bad prompt.
“Do nothing” probably needs to be treated as a valid outcome more often.
User research is probably one of the first things people skip when AI makes everything else so fast. Faster execution doesn't help much if you're solving the wrong problem.
Exactly. User research starts feeling slow compared to building now.
But if execution gets 10x faster, validating the problem probably becomes more important, not less. Otherwise you just reach the wrong destination faster.
Exactly. I’ve noticed the same thing. What do you think is the simplest way to validate an idea before spending too much time building it?
The skip I keep seeing is not the user call. People still interview. They let the model summarize the calls, then they build the summary. The sentence that contradicted the pitch never makes it into the ticket, so the "validated" idea is just the model's average of the notes.
Before any prompt I write one line this build is not allowed to become. If I can't write that line, the session is only a faster way to accept the model's defaults. Judgment did not get automated. It moved to a step nobody scheduled, because the output already looks finished.
This is a really interesting point.
Even when people do the research, AI can smooth out the uncomfortable parts of it. The one user comment that challenges the whole idea can disappear inside a neat summary.
The raw contradiction is often more valuable than the polished average.
The part I think gets missed is that AI made building cheaper but did not make owning anything cheaper. A bad idea still costs a weekend to build and then years to keep alive, answer support for, migrate, and eventually shut down. The weekend is the only part that got discounted. So the step people skip is not really validation, it is asking whether they want to still be maintaining this in two years, which used to be forced on them by how long the build took. The build was quietly doing that deciding, and nobody noticed until it stopped taking any time.
That’s a really good distinction. Building got cheaper, but ownership didn’t.
The maintenance, support, migrations and eventual cleanup are still there. I like the point that build time used to force some of that thinking naturally. Now you can skip straight past it.
thanks
Yeah, I’ve noticed this too.
Before AI, if a feature was going to take a few days, you’d usually stop and ask whether it was actually worth building. Now it’s so easy to say “let’s just add it” because the cost feels almost zero.
The problem is you can end up with a bigger product before you’ve even figured out whether the core idea is right.
AI definitely makes execution faster. I’m just not sure faster execution always means faster progress.
yes, agree
For me it’s user research. Building got so fast that talking to users almost feels slow now, which is probably why people skip it.
Cheap execution only helps if the decision gate stays expensive. I force one written kill criterion before I let the model touch production copy or crawl rules. If I cannot say what would make me scrap the change, I am just shipping faster mistakes.
The post is more about the decision process around building than any specific tech stack.
What made you pick this stack over the alternatives?
Not sure which stack you mean here. The post is more about the decision process around building than any specific tech stack.
omg but Before any prompt I write one line this build is not allowed to become. If I can't write that line, the session is only a faster way to accept the model's defaults. Judgment did not get automated.
I like that rule. Defining what the build should not become forces you to think before the model starts filling in the blanks for you. That probably matters more now because the output looks finished so quickly.
Interesting take. Would you still recommend this approach to someone starting today?
Good point. Did you test that with users before committing to it?
Honestly Not as much as I should have in the past, which is partly why this topic interests me now. I’ve definitely had cases where I built first and understood the demand later.
Nice post
The stop-condition point is the one I keep forgetting too. With faster builds, I now want one cheap check before letting the next feature happen: what user behaviour would prove this is worth keeping? If I cannot name it, I am probably just making the wrong decision faster. A 10-minute user conversation usually beats another generated variant.
I like the “what behavior proves this is worth keeping?” question. Much better than using “we shipped it” as the success metric.
The step I see skipped is closing the loop after release. Shipping proves something was built—not that it solved the intended problem. With Agiloop (https://agiloop.ai), we connect production signals back to the original intent so the next iteration is based on evidence, not assumptions.
Closing the loop after launch is underrated. Shipping tells you execution happened. It says almost nothing about whether the thing actually solved the problem.
For agency/content work, the skipped step is often agreeing on the acceptance test with the client. AI can turn a vague brief into 20 polished drafts before anyone names the one reader, action, and evidence of success. A small preflight—audience, job-to-be-done, and a kill/iterate condition—keeps speed from multiplying rework.
Yeah, this is especially true with client work. If the brief is vague, AI just helps you create the wrong thing faster. Getting clear on audience, outcome and what “good” actually means upfront saves a lot of rework later.
Strong point: lowering execution cost makes a small validation loop more important, not less. Before shipping, define the riskiest assumption, run 5–10 conversations or a manual test, and set a stop rule; use AI to summarize objections, not manufacture certainty.
I’m building in this direction too: I sell a $17 AI Disruption Household Checklist (this is my own product, not an affiliate offer) for turning AI/job uncertainty into concrete household steps. No income or outcome guarantees—just a practical PDF.
Sales page: https://dropmountainltd-ux.github.io/checklist/
Buy: https://buy.stripe.com/28EfZ944V6ls9db30qes005
The part I like most is “use AI to summarize objections, not manufacture certainty.” That’s probably where people get into trouble now. AI can make a weak assumption look way more convincing than it really is.
I've seen people skip the boring step of watching a workflow before automating it. AI makes it easy to ship a polished fix for the problem as you imagine it. A short manual test with a few real users may feel slow, but it often reveals where an extra step or handoff really happens. Faster execution makes that check more important, not less.
Watching the real workflow first matters a lot. Otherwise you’re automating the version of the process that exists in your head, not the one users actually follow.
The cost of a bad decision was never the build, so making the build cheap did not make the decision cheap. If anything it got more expensive, because a weekend project you cannot bring yourself to kill still eats the next six months of support, positioning and attention. The discipline I would add is a written kill criterion before you start: what has to be true in 30 days, and what you do if it isn't.
I like the written kill criterion idea. Cheap building probably makes killing harder too, because it’s easy to say “one more week, one more feature, one more test” when the initial build barely cost anything.
This comment was deleted 2 hours ago