Two in the morning, and a task named capture_training_data has been sitting in pending for six hours. No error. No stack trace. Just... nothing. The queue looks healthy. The logs are clean. The task simply refuses to move.
You could stare at it. Instead you dispatch a fresh subagent, hand it the systematic-debugging skill, and walk away from the terminal for ten minutes.
That stuck task is where the next feature idea usually comes from. Not a whiteboard. Not a brainstorm. A thing that broke.
The Idea Marketplace Myth
There's a whole industry built around the idea that inspiration lives somewhere out there -- scroll Product Hunt every morning, see what's trending, take notes, build something adjacent. Some founders keep a running document of quotes and prompts, treating each morning's reading as fuel -- one writer described it as pulling from an endless source that never runs dry.
That works fine for a certain kind of creative practice. It works less well for engineering. If your roadmap is "what's trending on a discovery feed today," you end up building features nobody asked for, tuned to somebody else's users. The professional version of this question isn't "where do interesting ideas come from" -- it's "where do the ideas that are actually worth building come from." Those are different sources, and they don't overlap much.
Where We Actually Find Ideas
At Glad Labs, almost every feature we've shipped started as friction, not inspiration. A subagent got stuck. A review pass flagged a spec mismatch. A CLAUDE.md file drifted out of sync with what the codebase actually did, and an agent quietly started hallucinating file paths that didn't exist anymore.
We run a subagent-driven workflow -- dispatch a fresh subagent per task, run it through a two-stage review (spec compliance first, code quality second), and log whatever breaks as a task, not a Slack message that evaporates. When something goes sideways, it gets a GitHub issue number and a paper trail, the same way issue #693 captured a spec bug that came out of one of these stuck-task investigations.
That issue is the idea. Not "wouldn't it be cool if." A concrete failure, reproduced, written down, assigned to someone -- or some agent -- to fix.
From Friction to Fix
Here's the pattern, roughly the same every time:
A task stalls or a subagent produces output that doesn't match the spec. We invoke systematic-debugging rather than guessing. The debugging pass either finds a code bug or finds a documentation bug -- the two show up about equally often. If it's a doc bug, claude-md-improver gets invoked to fix the instructions the agent was actually following. If it's a code bug, it becomes a task with a description precise enough that a brand-new subagent, with zero memory of the investigation, could pick it up cold and fix it correctly.
That last part matters more than it sounds. Fresh subagents have no context bleed-in from the debugging session that found the problem. So the task description has to carry the whole idea -- what broke, why, what "fixed" looks like. Writing that description is where the vague notion of "something's wrong with the training data pipeline" turns into an actual, buildable idea. The constraint of having to hand it off cleanly is what forces the idea into a shape you can act on.
We wrote about the reliability side of this in Addressing Hallucinations and Security in Open-Source LLM Agents -- a lot of what looks like "the agent made something up" is actually stale documentation the agent was trusting. Fixing the source of the idea (the CLAUDE.md, the spec, the context window) fixes the hallucination downstream. The idea and the bug report are usually the same document.
Closing the Loop
The part that took us longest to get right: making sure an idea, once captured, doesn't die in a task queue. A stuck task gets debugged, the fix gets reviewed twice, and then the lesson has to go back into the system's memory -- the CLAUDE.md file, a runbook, a skill definition -- so the same failure mode doesn't get rediscovered from scratch three weeks later.
That's the same problem we covered in Breaking the Memory Wall: How to Give Any Open-Source Agent Claude-Level Recall. An idea that only lives in one person's head, or one agent's context window for one session, isn't really captured. It has to persist somewhere the next dispatch will actually read.
Practically, this looks unglamorous. Someone (or some agent) updates a migration note about backfilling word_count and reading_time on existing rows, because the SEO generator downstream needed those fields and nobody had traced the dependency before. Small, boring, exactly the kind of idea that never shows up on a product-discovery feed -- and exactly the kind that keeps a pipeline running.
The Professional Take
The trend we described in The Expanding Role of Open-Source LLM Agents in Autonomous Workflows is agents increasingly generating their own next steps -- filing their own issues, proposing their own fixes, closing their own loops. That only works if the source feeding those ideas is real signal: stuck tasks, failed reviews, drifted docs. Feed an autonomous system a diet of "what's trending" and you get an agent chasing the same noise a human would.
If you're building on your own stack -- indie, small team, whatever -- the practical advice is the same one we follow internally. Stop looking for ideas somewhere else. Instrument your own friction. Log the stuck task. Write down what broke and why, precisely enough that someone with zero context could fix it. That log is your actual backlog, and it's a lot more honest than any discovery feed will ever be.
Top comments (0)