{"slug": "where-good-ideas-come-from-for-coding-agents", "title": "Where good ideas come from (for coding agents)", "summary": "A developer's essay argues that coding agents excel at 'adjacent possible' work but require users to supply constraints, context, an oracle, and a loop to become reliably useful, applying Steven Johnson's 'Where Good Ideas Come From' framework to AI-assisted coding. The author, who writes from personal experience, notes that large language models act as 'thought completers' and that effective prompting is more about steering than magic words.", "body_md": "# where good ideas come from (for coding agents)\n\n(and the part where users have to level up)\n\nI’ve been thinking about why some people absolutely *cook* with coding agents, and some people bounce off them hard. I had a thought last week: if llms are “next token predictors” in the small (i.e., sentence finishers) then in the large they’re closer to “thought completers.” you give them a few crumbs of context, they infer the genre, then they sprint down the most likely path in idea-space. which makes “good prompting” *feel less like magic words and more like navigation*: you’re steering the model toward a region of the space where the next steps are both plausible *and* useful. I wanted a better map for that, so i used steven johnson’s “where good ideas come from” as a rubric, the seven patterns that reliably produce interesting ideas, and tried applying it to coding agents: where they’re naturally strong, where they reliably drift, and what a user has to supply (constraints, context, oracles, loops) to make the whole thing converge.\n\ntl;dr: a plausible “week in the life” you can map onto your own codebase. the point is to make the user-adaptation story concrete: agents are excellent at adjacent-possible work, but they only become reliably useful when you supply **constraints, context, an oracle, and a loop**.\n\n## the idea-space metaphor (and what the seven ways add to it)\n\nit’s tempting to picture an llm as navigating a huge multidimensional “idea-space”: your prompt lights up certain internal features, which reshapes the probability landscape of what comes next, and generation is basically a trajectory through that landscape. in that framing, context engineering is just steering - adding constraints, examples, and relevant artifacts so the model’s “next steps” stay in the neighborhood you care about. johnson’s seven ways are useful here because they explain which kinds of trajectories llms find naturally, and which ones require help: models are natively strong at smooth, local moves like the **adjacent possible** (small diffs, incremental refinements) and at **platforms** (interfaces, scaffolds, reusable primitives), and they can do **exaptation** well when you explicitly state affordances and constraints. they’re weaker where progress depends on reality pushing back - **error** and **serendipity** - unless you give them feedback channels like tests, benchmarks, traces, and experiments that create a gradient toward truth. and they only approximate **liquid networks** and **slow hunches** when you supply diverse “voices” (prior art, docs, debates) and persist ideas long enough to recombine later. the point isn’t that llms can’t roam the space; it’s that they need mechanisms that *select and validate* the paths worth taking.\n\n## quick sidequest: the seven ways\n\n[steven johnson’s “where good ideas come from”](https://www.amazon.com/Where-Good-Ideas-Come-Innovation/dp/1594487715/) is one of those lists that sounds like it belongs on a poster until you use it as a diagnostic tool. here’s the version that matters for engineering:\n\n**the adjacent possible**- most “new” ideas are the next reachable step from what already exists. stairs, not teleportation.** liquid networks**- ideas show up when partial thoughts collide: people, yes, but also artifacts (docs, code, past debates).** the slow hunch**- many good ideas start half-baked. you keep them around until they meet the missing piece.** serendipity**- luck plus recognition; you notice the useful anomaly when it appears.** error**- failure is information; feedback turns wandering into convergence.** exaptation**- repurpose a thing built for one job into a different job. reuse as invention.** platforms**- stable primitives and standards let lots of people build lots of things faster and safer.\n\nnow: drop an llm coding agent into this picture. what changes?\n\nmy take: the seven patterns don’t go away. agents just amplify some of them and brutally expose where you’ve been relying on implicit human context for the others.\n\nlet’s walk through that with one running example.\n\n## the running example: “make webhook ingestion reliable” (totally plausible, not actually shipped)\n\nimagine a webhook ingestion service:\n\n- handler validates signature\n- stores event\n- enqueues downstream job\n\nand prod keeps reminding you that the world is adversarial:\n\n- partners retry aggressively → duplicates\n- downstream sometimes fails halfway → partial side effects\n- p99 latency is creeping up → every “fix” risks making tail worse\n\nthe goal, as a human would say it: **reliable ingestion with idempotency and bounded retries, without making latency worse.**\n\nthe goal, as an agent hears it: **“write some code that sounds like reliability.”**\n\nthat mismatch is the whole story.\n\nso here’s the one-week simulation.\n\n### day 1: I ask for “reliability.” the agent gives me plausible nonsense.\n\nthe naive prompt is basically:\n\nmake webhook ingestion reliable. handle duplicates and retries. keep latency reasonable.\n\nthe agent does what continuation machines do when you hand them vibes: it fills in the blanks with the most likely reliability narrative it has seen before.\n\nso it might invent a new “reliability module,” add a retry helper (even if your repo already has one), choose a payload-hash idempotency key because it *sounds* right, and sprinkle logging everywhere like it’s free.\n\nand the code might be clean! which is the annoying part. because it can be clean and still wrong.\n\nin this simulation, you catch three problems quickly:\n\n- payload hashes aren’t stable identifiers for retries in the real world\n- retries in the request handler are a p99 tax (and can trigger more retries, which is a fun kind of circular misery)\n- duplicating retry logic is how you end up with a repo that has “one retry policy per mood”\n\nso you don’t merge it. you don’t argue with it. you just learn the lesson: **if you ask an agent for a vibe, it will give you a vibe-shaped completion.**\n\n### day 2: adjacent possible - I stop asking for outcomes and start asking for stairs.\n\nthis is the first user adaptation: take the big thing and turn it into rungs small enough to verify.\n\nthe staircase looks like:\n\n- step 1: idempotency at ingestion (no duplicate enqueue)\n- step 2: bounded retries in the worker (not the handler)\n- step 3: dead-letter path + replay\n- step 4: metrics that tell us if it’s working\n\nthen you create an oracle for step 1. not a paragraph. an actual check.\n\nmaybe it’s a test that says:\n\n- same\n`(partner_id, event_id)`\n\narrives twice → only one enqueue happens - second request returns quickly and doesn’t redo expensive work\n- storage failure behavior is explicit (fail closed vs fail open is a choice, not an accident)\n\nthen the prompt becomes boring on purpose:\n\nimplement step 1 only. keep the diff small. don’t invent new abstractions. make these tests pass.\n\nsuddenly the agent looks competent again, because this is its strength: incremental diffs along a well-lit path.\n\nthe “adjacent possible” isn’t just a creativity concept; it’s also a safety concept. small rungs are harder to misunderstand.\n\n### day 3: liquid networks - I build a context packet so it stops inventing my codebase.\n\neven with good decomposition, agents have a habit: they’ll “helpfully” create new mini-frameworks unless you force them to collide with your existing ones.\n\nso you manufacture a liquid network.\n\nnot by dumping the whole repo, but by curating the collision points.\n\nin this simulation, you assemble a tiny context packet:\n\n- the canonical retry policy already used elsewhere\n- your error taxonomy types\n- logging/metrics rules (especially what not to log)\n- the queue abstraction you must use\n- one prior PR that did retries correctly in your house style\n\nand you tell the agent, explicitly, to reuse what exists:\n\nfor step 2, reuse\n\n`<retry_policy_file>`\n\n, follow`<error_types_file>`\n\n, and cite the prior art you’re copying. do not add new abstractions unless you justify them.\n\nthis is one of the weirdly satisfying moments in agent work: the output starts to look like it came from someone who has actually been in your codebase for a while.\n\nliquid networks aren’t just social. they’re documentary. agents need the documentary version.\n\n### day 4: slow hunch - a real design question appears, and we don’t pretend it’s settled.\n\naround now you hit the question you can’t solve with a patch:\n\ndo you ack the webhook only after downstream succeeds, or ack on ingestion and process asynchronously?\n\nthere are real trade-offs here: partner timeouts, retry behavior, your p99 budget, operational complexity, and what “correctness” means for side effects.\n\nin this simulation you have a hunch, but not certainty:\n\nack quickly, but make downstream idempotent and observable; add replay; make partial failure survivable.\n\nso you do the “slow hunch” move: you write that hypothesis down and you refuse to force closure yet.\n\nthen you ask the agent to help refine it *without floating off into generic advice*:\n\ngiven our constraints (partner retries within ~5s, p99 target X, current failure modes), lay out the trade-offs. then propose one small experiment that reduces uncertainty.\n\nthe useful output isn’t the prose. it’s the experiment. you want something that creates evidence.\n\nslow hunch becomes a workflow: capture partial ideas, propose tests, run tiny experiments, update the hunch log.\n\nagents won’t incubate for you. but they’re quite good at helping you tend incubation.\n\n### day 5: serendipity - I feed it anomalies instead of asking it to “be creative.”\n\nserendipity in software is rarely “brainstorming.” it’s “something weird happened in prod, and someone noticed.”\n\nagents can help with the noticing part if you give them the weirdness.\n\nso in this simulation you bring:\n\n- slow traces\n- error logs (sanitized)\n- a couple incident summaries\n- maybe support-ticket clusters\n\nand you ask for something constrained:\n\ncluster failure modes. tell me the weirdest pattern that might matter. for the top 3, propose a hypothesis and one targeted change or experiment to confirm/deny it.\n\nnow you’re engineering serendipity: exposure plus recognition.\n\nyou’re not asking for originality in a vacuum. you’re asking for hypotheses anchored in reality signals.\n\n### day 6: error - we make the feedback loop the main character.\n\nthis is the turning point where the whole thing stops feeling like promptcraft and starts feeling like engineering again.\n\nthe user imposes workflow constraints that force convergence:\n\n- no patch unless it serves an oracle (test, benchmark, lint rule, property check)\n- diffs must be small enough for a human to review in one sitting\n- after each change: run the suite\n- for reliability changes: add at least one failure-mode test, not just happy path\n\nthe agent’s job becomes a loop:\n\n- propose patch\n- run tests\n- observe failure\n- patch\n- repeat until green\n\nthis is where people’s experiences diverge dramatically. teams with solid verification culture feel like they’ve gained leverage. teams without it feel like they’ve gained a chaos multiplier.\n\nerror isn’t a tax. it’s steering.\n\n### day 7: exaptation + platforms - we stop patching and extract primitives.\n\nby day 7 you could plausibly have “fixed the problem” locally. fewer duplicates, bounded retries, DLQ, metrics.\n\nbut the meta-problem remains: you’ll build ingestion endpoints again. and you don’t want to rediscover the same lessons every time.\n\nso you ask the platform question:\n\nwhat are the smallest primitives we wish existed at the start of this week?\n\nin this simulation you extract a small substrate:\n\n- an\n`idempotency_guard(partner_id, event_id)`\n\nhelper with crisp semantics - one canonical retry policy implementation (and a rule: don’t invent another)\n- DLQ + replay workflow that’s operable by humans\n- a metrics schema that makes reliability legible (duplicate rate, retry rate, dlq depth, replay success)\n\nthen you do exaptation on purpose: reuse an existing outbox-ish or backoff-ish pattern already in the repo, but only after stating the affordances like physics:\n\n- we can tolerate at-least-once delivery, but side effects must be idempotent\n- we cannot add a new datastore\n- p99 at the edge is non-negotiable\n- no payload logging\n- rollback must be safe\n\nwith affordances named, reuse becomes safe and boring (the best kind). without them, reuse becomes clever and fragile.\n\nfinally you ask for the interface before the implementation:\n\ndesign the primitives first. show how a future engineer adds a new handler using them. then implement one reference handler. keep APIs small. document invariants.\n\nagents tend to do well here. scaffolding and boundary drawing are structured composition problems, and models are oddly strong at those… as long as you force them to respect your local laws.\n\n## what changed across the week wasn’t the model. it was the user.\n\nin the simulation, the agent didn’t become smarter. the user became more explicit.\n\n- constraints moved from tribal knowledge to written laws\n- oracles became the interface (“make this test pass without breaking these invariants”)\n- context became curated rather than dumped\n- the loop became non-negotiable: small diffs, run checks, iterate\n\nand once you do that, the seven ways start working *with* the agent rather than against you:\n\n**adjacent possible:** stairs, not leaps**liquid networks:** curated collisions with repo truth**slow hunch:** persistent hypotheses, refined by evidence**serendipity:** anomaly feeds turned into hypotheses**error:** tests and checks as steering surfaces**exaptation:** reuse, but only after affordances are named**platforms:** extract primitives so next week is easier than this week\n\n## the practical punchline\n\nagents make code cheaper. they do not make judgment cheap.\n\n*so the scarce skill becomes: expressing constraints, designing oracles, curating context, and running tight feedback loops*. if you can do that, agents feel like leverage. if you can’t, they feel like accelerating into fog: fast, smooth, and *directly toward the cliff*.\n\n## epilogue: ok, but doesn’t this mostly work for seniors?\n\nyeah, mostly.\n\nthis flow works particularly well for experienced engineers because they already carry the “implicit spec” in their heads:\n\n- the constraints you didn’t write down\n- the failure modes you only learn after being paged\n- the trade-offs you can smell\n- the verification reflex that turns “looks right” into “is right”\n\nagents don’t supply that for free. they amplify whatever objective you actually manage to encode, which means seniors get outsized value early because they can encode better objectives, pick better oracles, and notice plausible-but-wrong output before it ships.\n\nbut juniors can gain the missing “context” faster in this world… if you restructure learning on purpose.\n\nhave them own the **spec + constraints + non-goals + acceptance tests**. let the agent draft implementation. then require them to:\n\n- iterate through the error loop (run ci, fix failures, explain what invariant broke)\n- support changes with “citations” to existing repo patterns\n- write a short “how this fails in prod + what to watch” note\n\nthe exact guardrails vary by company:\n\n**startups:** keep it lightweight (small diffs, a couple tests, basic observability)**growth orgs:** formalize playbooks and perf guardrails**big tech:** emphasize blessed primitives and rollout discipline**regulated/safety-critical:** shift juniors toward evidence and traceability with strong gates**consultancies:** focus juniors on rapid context extraction and runnable harnesses\n\nbut the core idea is consistent: let agents accelerate implementation, while juniors are trained (and evaluated) on objective engineering, verification, and operational judgment, not keystrokes.\n\n## appendix: the context packet (a tight template)\n\na context packet is a small artifact that stops the agent (and reviewers) from guessing. it pins the objective, establishes what “truth” is, and installs an oracle so the work converges instead of meandering.\n\nuse it for anything non-trivial: reliability, perf, migrations, refactors, cross-cutting changes.\n\n### template (copy/paste)\n\n**goal (1 sentence):**\n\nwhat outcome are we trying to produce? (not the mechanism)\n\n**non-goals:**\n\nwhat is explicitly out of scope? (the “helpful creativity” kill-switch)\n\n**constraints / invariants:**\n\nthe laws of physics: budgets, safety properties, compatibility rules, forbidden actions.\n\nexamples: p99 < __, idempotent under retries, no retries at edge, no pii logs, no new deps, backwards compatible.\n\n**authority order:**\n\nwhen sources disagree, what wins?\n\ndefault: tests/ci > current code behavior > current docs/runbooks > old docs/lore.\n\n**repo anchors (3–10 links):**\n\nthe files that define truth for this change: entrypoints, core helpers, types, config, metrics.\n\n**prior art / blessed patterns:**\n\nwhere should we copy from? what must we reuse? what must we avoid reinventing?\n\n**oracle (definition of done):**\n\nthe checks that decide success: tests to add, edge cases, benchmarks, static checks, canary signals.\n\n**examples (if tests aren’t ready yet):**\n\n3–5 concrete input → expected output cases, including failure/edge cases.\n\n**risk + rollout/rollback:**\n\nhow could this fail, what do we watch, how do we deploy safely, how do we undo?\n\n**agent instructions (optional, procedural):**\n\nkeep diffs small; cite anchors/prior art used; don’t add abstractions without justification; run tests each step; stop after step N.\n\n### a filled example (webhook reliability)\n\n**goal:** prevent duplicate downstream effects when partners retry the same webhook delivery.\n\n**non-goals:** no new datastore; no partner-facing response changes; no retries inside the http handler; no large refactors.\n\n**constraints:** idempotent under retries; p99 handler latency < X; worker retries bounded with jitter; no payload logging; feature flag + safe rollback.\n\n**authority order:** tests/ci > code > runbooks > old docs.\n\n**repo anchors:** handler, queue abstraction, retry policy module, error taxonomy, metrics/logging helpers.\n\n**prior art:** link to the existing bounded-retry implementation and any prior ingestion endpoint that’s “done right.”\n\n**oracle:** add tests (duplicate enqueues once; retries bounded; poison → dlq); run ci; run handler benchmark; canary and watch duplicate rate/latency/queue depth.\n\n**examples:** duplicate request; storage timeout; poison payload; downstream transient failure.\n\n**risk/rollout:** flag on at 1%; monitor key metrics; rollback by disabling flag.\n\n**agent instructions:** implement step 1 only; reuse retry policy; keep diff reviewable; run tests; summarize invariants preserved.\n\nwhy it works: it turns “senior intuition” into explicit constraints and executable truth. agents stop guessing, juniors learn faster, reviews become about invariants instead of vibes.", "url": "https://wpnews.pro/news/where-good-ideas-come-from-for-coding-agents", "canonical_source": "https://sunilpai.dev/posts/seven-ways/", "published_at": "2026-08-12 05:49:33+00:00", "updated_at": "2026-08-12 06:11:56.496737+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "ai-agents"], "entities": ["Steven Johnson", "Where Good Ideas Come From"], "alternates": {"html": "https://wpnews.pro/news/where-good-ideas-come-from-for-coding-agents", "markdown": "https://wpnews.pro/news/where-good-ideas-come-from-for-coding-agents.md", "text": "https://wpnews.pro/news/where-good-ideas-come-from-for-coding-agents.txt", "jsonld": "https://wpnews.pro/news/where-good-ideas-come-from-for-coding-agents.jsonld"}}