Writing code used to be the bottleneck. You’d have an idea, and then you’d spend days or weeks turning it into something you could actually try. Most ideas died in that gap – not because they were bad, but because the cost of finding out was too high.
That’s changed. LLMs have made code implementation almost trivial for a huge class of problems. I don’t mean they write perfect production systems – they don’t (who does?) – but they’re astonishingly good at producing “good enough”. The kind of thing you need to try an idea out, show it to someone, see if the shape of it works. A rough dashboard. A prototype API. A quick tool that does the one thing you need. An iOS app to manage substitutions on your kid’s sports team. What used to take a week or two takes an afternoon.
The value has moved
If producing code is cheap, the bottleneck shifts. The scarce resource isn’t implementation any more – it’s knowing what to ask for. Two things feed that: curation and knowledge.
Curation is the strategic bit. Which ideas are worth pulling together? What combination of things, each individually unremarkable, becomes something genuinely useful when you stack them up? An LLM can build what you describe, but it can’t (yet…) tell you what’s worth building. That judgement – knowing which thread to pull, which experiment to run next, which of your twelve half-formed ideas deserves an afternoon – that’s where the leverage is now.
Knowledge is the tactical bit. The more you know exists, the more you can build. LLMs are force multipliers, but they only multiply what you bring to the conversation.
If you know that sparkline charts exist, you can say “put sparklines in the table cells” and get them in minutes. If you don’t know sparklines are a thing, you’ll never think to ask, and they are unlikely to crop up as the LLM explores for you.
This pattern is everywhere:
- Know what a dead letter queue is? You can ask for one by name instead of reinventing retry logic from scratch.
- Seen an optimistic UI before? You can tell the LLM “update the UI before the server responds, roll back if it fails” and get a snappy interface in minutes.
- Heard of feature flags? You can ask for a feature flag system in your prototype and suddenly you’re testing two versions of an idea at once.
- Know what eventual consistency means? You can describe the tradeoff you want and skip the long detour where you accidentally build something that doesn’t scale.
- Familiar with the concept of a circuit breaker? One sentence in your prompt and your API client handles failures gracefully instead of hammering a dead service.
Every piece of knowledge you’ve accumulated over the years is a prompt waiting to happen. Broad technical knowledge has always been valuable, but now it converts directly into working software in a way it never did before. The person who’s seen a lot of things and roughly knows what’s possible will consistently out-build the person who’s deeper in one stack but doesn’t know what’s out there.
Deploy, learn, iterate
When the cost of trying something drops this far, you can run experiments you’d never have justified before. Build the thing. Ship it. See if anyone cares. If they don’t, you’ve lost a few hours, not a sprint.
We’ve talked about rapid prototyping – deploy, learn, iterate – for years, but the cost has finally dropped low enough that it’s genuinely practical for most ideas. Not just the ones that survive a prioritisation meeting. Instead of specifying, building, testing, deploying over weeks, you can have something in front of real users in hours – and that changes which ideas get a chance at all.
So what?
If you’re a builder: lean into breadth. Read widely. Collect patterns and concepts. Your library of “things I know exist” is your competitive advantage, because each one is a card you can play when the right problem shows up.
And if you’re not a builder yet? The barrier just got a whole lot lower.