Same Ideas, Shorter Distance

Before

For years, writing code meant a specific kind of research work before any actual building. You had an idea, or a problem, and the first task was never to type — it was to find out how.

There were really only two ways this could go. Either you'd hit this exact wall before — you remembered the fix, or at least remembered where you'd found it, and could go straight to it — or you hadn't, and you were starting from zero. There was no in-between, no way to shortcut unfamiliar territory except by having already been there. Experience was the only cache you had, and it only covered what you'd personally run into.

And the time this took was never fixed. It depended on how deep your own experience with the issue went, and it depended on the internet's — how much had been written about this particular problem. A common error with a popular framework might have fifty threads discussing it, a clear consensus, an accepted answer with hundreds of upvotes: minutes, if you were lucky. An obscure edge case in a niche library might have one forum post from 2014, half in a language you didn't read, with no reply. That could take an afternoon, or it could take days, or it could simply never resolve — you'd end up working around the problem instead of solving it, because the answer didn't exist anywhere to be found.

When you hadn't been there before, and the research had to start, that meant opening a dozen tabs. Official documentation, when it existed, was often written for people who already understood the system — dense, formal, assuming context you didn't have. It answered the question you hadn't asked and left the one you had unanswered. So you'd close it and go looking elsewhere.

The real work happened in Stack Overflow threads, GitHub issues, half-finished blog posts. You'd find an answer — sometimes exactly the right one, sometimes close enough to adapt — and it would carry a date stamp of 2016, or 2019, referencing a library version three majors behind the one you had installed. You'd try it anyway. It would half-work, or not work, or work but throw a deprecation warning that sent you down a second search. Then a back-and-forth: adjust the syntax, check if the API had changed, find someone in the comments saying "this doesn't work anymore, use X instead," follow that thread, find that X also had a caveat.

Choosing an architecture meant the same kind of diffuse research — reading opinions scattered across blog posts and conference talks, weighing tradeoffs described in someone else's context, not yours, and trying to translate that into a decision that fit your actual problem. There was no one to ask "given exactly this constraint, what's better" — only a pile of general advice you had to specialize yourself.

None of this was necessarily bad — you learned the terrain by walking it. But it was slow, and a lot of the time wasn't spent thinking about the problem. It was spent either recalling whether you'd already paid this toll once before, or paying it for the first time — and how long that toll took was mostly out of your hands.

What this built

This situation shaped something bigger than individual frustration. For the people who started a career in this — back when there were no schools for it, no established curriculum, just people figuring it out — it was an experimental path, and an interesting one. You were inventing the road as you walked it, because nobody had walked it yet.

And the entire industry was built this way: a mix of failures and successes, attempts at finding the best way to do something, tried in public, corrected in public, sometimes never corrected at all. Some of those failures are still with us — not as forgotten mistakes, but as foundations. Design decisions made in a rush, languages and patterns born under the pressure of winning a race into what would become a massive, profitable, and — once it matured — often boring industry. Weak choices made when speed mattered more than correctness, now so deeply embedded in what everyone builds on top of that removing them is no longer realistic. You don't fix them. You work around them, forever, the same way you work around a bug that shipped a decade ago and is now load-bearing.

But that same messy history is also the resource. All that trial and error, all those posts, all those questions asked and half-answered and re-answered five years later by someone else — that enormous accumulation of data is the actual source of truth the field runs on. Not the official documentation. Not a clean specification. The scattered, contradictory, time-stamped record of everyone who hit the same wall before you. It's what solutions get found from, and — as it turns out — it's also what a new generation of tools would eventually be built from.

What showed up

These same ingredients — the trial and error, the deep archive of fixes and failures — were bound to amplify whatever the industry already was, good and bad both. More data, more history, more entrenched shortcuts. Nothing about accumulation alone was going to fix the tangle. What was missing was a way to sort through that source of truth faster than one person, one search, one thread at a time.

That's what showed up. A way to simplify the documentation of an entire stack, to strip out the assumptions that used to stand between you and the answer. Because that's what an agent actually does, underneath everything else — it looks through the same source of truth you always had access to, and it thinks through it for you, at a speed no single search session ever could. It knows which commands to reach for. It's already read the thread from 2016 and the one from 2023 that corrected it, and it's already reconciled the two.

The distance between having a problem and holding a candidate solution — a real one, not a fragment to be adapted — got shorter. And more often than not, it arrived close to optimal on the first try.

Today

The workflow now looks different, and it starts before any prompt is written. It starts with me summarizing what's worth keeping from my own experience — what I already know works, what I've learned the hard way, what shouldn't be reinvented. That's the part no agent does for me; it's still mine.

From there, the work is building a toolbox: a series of tools and skills, tailored to the particular project I'm in, that become part of how I work going forward. Not generic helpers — specific ones, shaped by what this codebase, this stack, this problem actually needs. Each one is an investment that pays back the next time a similar wall shows up.

Then comes the part that matters most: explaining the problem as precisely as I can. Writing the best possible prompt at the start, and refining it, prompt by prompt, until the result gets close to what's needed. And often, what comes back isn't what I would have written myself. That's not a failure of the process — it's the interesting part. A dialogue gets established, between what I meant and what the agent returns, and the real skill is in recognizing what's best in that response and amplifying it, even when it took a shape I hadn't anticipated.

It's less "find the answer" and more "converge on it, together, a few exchanges at a time."

The real shift

This is the actual paradigm shift — not the speed, not the convenience, but the nature of the exchange itself. It stopped being a cold question and a cold answer, the way a search engine or a static doc gives you one. It became a back-and-forth between two experts, each bringing something the other doesn't have.

On one side, a human with goals, with the accumulated judgment of having built things before, with a discerning filter for what actually fits this project, this constraint, this moment — and what doesn't. On the other, something extraordinarily fast at sorting through possibility, at holding in mind every alternative a solution could take and what each one would cause downstream, at thinking through branches a person would take an hour to even enumerate.

Neither side is doing the whole job. The agent doesn't have the goal, doesn't have the taste, doesn't know which tradeoff actually matters here versus in the abstract. The human doesn't have the speed, or the exhaustive recall of every pattern and pitfall the industry has ever produced. What happens between them — prompt, response, refinement, response again — is closer to a conversation between two colleagues with very different strengths than to a lookup.

That's the difference from before. Before, you searched for an answer someone else had already found. Now, you build the answer, in dialogue, with something thinking alongside you at a completely different pace than your own.

What changes because of this

The first consequence is efficiency — but not efficiency in the narrow sense of typing faster. It's efficiency in how quickly an idea can become real. And that changes the order of operations in my own head.

Before, the starting question was always inward: what do I know, what are my limits, and how do I shape my idea to fit inside them. The idea got modulated by the constraint before it ever got built. Now the starting question is outward: what is the idea, actually — and I build it through the dialogue, rather than through what I personally know how to type. The limit stopped being the first filter. The idea gets to exist on its own terms first, and the how gets solved afterward, together with the agent, instead of before, alone.

The second consequence follows from the first: I don't write code from scratch anymore, not the way I used to. What used to be hours at the keyboard, building something line by line from an empty file, is now something I ask for. I still write — but what I write now is the explanation of the problem, the shape of the solution, the constraints that matter. The code itself, the part that used to be the entire job, is what comes back from that conversation. The job moved up a level: from writing the answer to defining the question well enough that the right answer can come back.

Conclusion

So maybe the real paradigm shift isn't the tool at all — it's what tools now let intent do. We've gained something that makes ideas come alive faster. And in that speed, a pattern becomes visible: the more original and simple an idea is, the more it tends to succeed.

But wasn't that true before AI, too? The best ideas were always the simple ones, executed well. What actually changed, then? The source of knowledge is the same archive it always was — the same successes, the same entrenched failures, the same accumulated record of a messy industry. The underlying technology hasn't transformed into something unrecognizable. And the ideas themselves still come from the same place they always did: a person's head, shaped by what they've seen, what they need, what they imagine could exist.

What changed is narrower than it first appears, and maybe more honest for being narrow: we didn't get better ideas, or a new source of truth, or a different technology underneath. We got a faster way to make the idea alive. The distance between having something in your head and holding something real got shorter. That's not nothing — for years, that distance was where most ideas quietly died, worn down by the research, the version mismatches, the tedious documentation, the sheer time it took to find out how. Now more of them survive the trip.

Everything else — the judgment, the taste, the sense of what's worth building — was always the human part. It still is. What's different is only that it now gets to matter earlier, and the burden of how mostly comes after, instead of before.