The problem

Every team I talk to has the same AI story now: code generation works, it’s fast, and pretty much everyone on the team can produce a working feature in an afternoon. That used to be the bottleneck. It isn’t anymore. What I kept running into, across talks, case studies, and my own client work, is a different failure mode entirely — teams build the wrong thing, fast and cheaply, because nobody did the hard work of figuring out what was actually worth building.

This isn’t a personal productivity problem, it’s an organizational one. One example that stuck with me: at an internal hackathon, a company generated 21 agent ideas. 17 got abandoned — not because the AI couldn’t build them, but because nobody had access to the right data, or a clear business case, or a customer who actually wanted it. Only 4 had real operational impact. The bottleneck was never technical. AI commoditizes the build; it can’t commoditize the conversation you need to have before the build starts.

The approach

This is a research study, not a piece of software — I treat it the way I’d treat a technical investigation: pull primary sources (conference talks, practitioner case studies), extract the concrete mechanism behind each claim, and build a framework out of the pattern that repeats across sources rather than any single anecdote.

Three findings do the real work here. First, a structural explanation for why AI nails coding assistants and chat but keeps failing at “headless” automation: tasks that succeed have “please the human” as the literal training objective (RLHF optimizes for human preference), while tasks that fail — background processing, autonomous decisions — need the human removed from the loop entirely. Different optimization target, not just a harder task. Second, the forward-deployed-engineering argument: once execution stops being the constraint, the bottleneck becomes how deeply you understand a specific business’s undocumented reality — not what the process doc says, but that “Sarah in AP handles it this way, and when it breaks she sends it to Chris, who takes four days to reconcile it.” You can’t extract that from a database; you have to sit with people. Third, a concrete method for replacing generic “give me a product idea” prompting: instead of asking one model one question, run parallel research agents against your own audience’s primary data — YouTube comments, community forums, Reddit, X — and synthesize across them. One practitioner in my source set ran five parallel agents over roughly 48,000 comments/posts in about an hour and surfaced a pricing signal that flatly contradicted his own intuition — the data pointed to a $50/month floor where he’d guessed $5–25.

What this study gives someone, concretely: a checklist for evaluating AI initiatives before committing engineering time to them (does this have real data access? a real business case? a real decision-maker who wants it?), a way to test automation claims properly (headless and unmonitored, not in an interactive demo), and a repeatable research method for grounding a “what should we build” decision in your own audience’s actual words instead of a model’s generic guess.

What I learned

The sharpest thing I took from this is the “pleasing the human” vs. “removing the human” distinction — it reframes a lot of disappointing automation results as expected, not anomalous. If a system was trained to optimize for approval, it will look great in a demo and then fail the moment nobody’s watching to approve of it. That single lens changed how I evaluate any agent pitch now: I ask what the model was actually optimized for before I ask how capable it is.

Where this could go

The natural next step is turning this into something a team can actually run, not just read: a pre-build filter — modeled on the 21-ideas-to-4 pattern — that an engineering org applies before greenlighting an AI initiative, forcing the “do we have data access / a business case / a real stakeholder” conversation before a single line of code gets written. At company scale, this is the forward-deployed-engineering staffing question in disguise: do you keep investing in engineers who write code faster, or start investing in people whose job is to sit inside a department long enough to learn how it actually breaks? The parallel-research-agent method also generalizes cleanly beyond product ideation — any team sitting on a support inbox, a Slack history, or a user community has the same untapped primary-data advantage and the same option to synthesize it with agents instead of guessing.

Takeaway

The tools got fast enough that speed stopped being the differentiator — judgment about what’s worth building is the whole game now, and that’s a people-and-access problem no amount of better prompting solves.