Bleeding Edges: Sometimes You Don't Lose Anything When You Move Slow

Every week there's a new engineering discipline I haven't learned, and I check for it the way other people check the weather: with dread. One month it's prompt engineering, the next it's context engineering, and somewhere after that it's MCP servers, which I'm still not sure how to pronounce. If you run a smaller company, you recognize the feeling: the big players are months ahead, every newsletter is a reminder that your stack is behind, and the gap looks like something you have to close by working harder. They call it the bleeding edge, and the bleeding is for the people who chase it.

This post is the opposite of that advice: it's reassurance, not a to-do list. I've gone through this cycle enough times to recognize its shape, and I've spent real time hand-crafting prompts only to watch that work go unnecessary. So before you invest months of your own in the same effort, I'd like to show you what I think is happening, and why I think waiting is a perfectly respectable strategy.

Training Wheels

I think of a model the way you think of a child learning to ride a bicycle. The child gets training wheels, stabilizers, and a parent's hand on the seat, and none of that equipment is kept once the child can ride on their own. The tools exist because the ability doesn't yet. The day the ability arrives, the tools' job is over. They don't get better; they get taken off.

That's what engineering effort around LLMs looks like to me, more and more. Every pipeline we build, the prompt templates, the retrieval layers, the tool wiring, is a set of training wheels for a capability that is still growing up. We build them because the model can't yet ride alone, and we polish them because that part is ours to control. The uncomfortable part is that the models grow up faster than the tools get polished. The work you finish this year can be the work the model stopped needing this year.

The pattern has a name I keep coming back to: capacity eats its own scaffolding. Any system built to patch a model's limit, whether that limit is a small brain or a small memory or a lack of hands, becomes redundant the moment the model grows past it. The scaffolding doesn't have to be bad work, and I'm not here to mock it; I've built plenty of it myself. But waiting gets you the same result for free, while building gets you it early, at the cost of the maintenance and the rewrites that the next generation of models will make you throw away anyway.

Example One: Prompt Engineering

I used to write prompts like a legal contract. You are a customer support agent, the contract would begin, and then it would run for a page: your personality, your tone, your boundaries, the exact order of your questions, and what to do when the customer says something unexpected. I described roles the way you'd brief an actor, with a fallback for every branch I could imagine. It took time, and I was proud of the results.

Then I started using a model that thinks before it answers, and I noticed the contract becoming optional. The model builds its own plan for the question I give it: what to check first, what to ask next, how to respond when the answer is vague. It does the role-playing without being cast, and I still find that surprising.

The surprising part is how often the model's steps are better than mine. I would toggle through questions in an order I had decided on. The model would take a route I hadn't thought of, and every once in a while that route is good enough that I borrow it for the next time. You don't get inspired by your own scaffolding. You get inspired by someone who grew past it.

That gap, to me, is the whole story. Prompt engineering existed to compensate for a model that needed to be told exactly who to be and what to do. As the models got better and cheaper, the prompts only got more elaborate, which I still find strange in hindsight. Now the discipline is shrinking to saying what you want, plainly, which is another pair of training wheels coming off the bike.

Example Two: Context Engineering

Context engineering is the art of fitting a whole problem into a small window. I practiced it for years. Models used to see only a few pages at a time, so if you wanted the model to work with a big document, you had to get clever. You split the document into chunks, you embedded the chunks into vectors, you built a retrieval layer that fetched the right piece on demand, and you wrote summaries so the model never had to look at everything at once. That stack has a name, retrieval-augmented generation, RAG for short, and for a while it was the most impressive plumbing in software.

I tried all of these myself when the windows were small. I did dynamic concatenation, stitching the relevant pieces of a conversation back together before handing them over. I did RAG, embedding documents and retrieving the right chunks on demand. I did distilling, rewriting the material down to its essence before injecting it into the window. Each approach worked, after a fashion. Each one brought its own machinery: token budgets, chunk sizes, embedding versions, a handful of small dials that quietly ate your weekend.

Then the windows grew, and most of my machinery went quiet. A million tokens of context is now common, which is roughly three fat books at once, give or take how you count.¹² When the window is that big, the retrieval layer loses its job for anything that fits, and you don't need to distill when the original fits either. The pipelines I built for the small-window era became the thing I delete, and I can't say I miss the dials.

But let me be careful here: RAG didn't disappear from industry. It moved upmarket, to the places where the window is still the wrong size. Some industries hold hundreds or thousands of documents, and no context window on offer can hold all of them at once. And even where the documents fit, models still drift: attention thins out over long material, and hallucination is a real risk when the answer lives in one precise paragraph of a regulation or a spec. Retrieval exists to point the model at exactly that paragraph, and in industries where precision is the product, that job isn't going away. There, RAG is real plumbing, not training wheels.

For me, that's the line that matters for a small team. The dials I tuned were scaffolding: the capability that made them necessary is now a price tier you can buy, and the small-company version of context engineering shrank to pasting the document. The industry version is different, and the test from later in this post applies: does the work survive the model getting smarter? For thousand-document precision work, some of it does, and that part is closer to product.

Example Three: Tools, Protocols, and the Terminal

MCP stands for Model Context Protocol, which is the current fashionable way to give a model tools. The idea is simple: instead of wiring your systems to the model with one-off integrations, every tool plugs into a standard server and the model talks to the server. Teams that adopted it early spent weeks connecting their databases, their browsers, their internal systems, and to me it felt like the future of software plumbing.

Now let me pause. This example goes differently from the first two. MCP isn't shrinking, and I don't expect it to go anywhere; it's still an important part of how agents work. What has changed is its center of gravity. When the protocol arrived, its job was capacity: giving the model skills it lacked, a way to reach the world. That half of the job is being absorbed; I have watched the models get better at using a terminal. Today's coding agents don't need a custom protocol to reach your systems; they read your files, run your commands, watch the output, and fix what broke, working in the same place you work with the same tools you use.³ And when a step doesn't exist, they write it: a small script, a one-off utility, a tool they didn't have five minutes ago. That's the funniest version of the pattern yet, because the thing that used to need your tools is now making its own.

The other half of the job survives, and it's worth noticing that it isn't training wheels. MCP now functions more like an interface between agents and the systems around them: a standard way to plug a database, a browser, or a ticketing system into any agent, the way USB became the standard way to plug a printer into any computer. Interfaces don't get absorbed by a smarter model; they get more useful as more things agree to speak them. If your business genuinely needs an agent talking to your systems, that work survives, and it's closer to product than scaffolding. More on that in the next section.

• Prompt engineering: now mostly free: thinking models plan their own steps
• Context engineering: mostly free for small stacks: three books fit, but thousand-document shops still need retrieval
• MCP: still here, but as an interface, not as capacity: agents run terminals on their own

The Honest Counterpoint

I hear that. And I will be honest: sometimes it's right. If the pipeline is your product, if customers pay for the thing you engineered around the model, then you build it fast and none of this post applies. That's the exception, though. The test for it is easy. Does the work survive the model getting smarter? If the answer is no, it's scaffolding, not product.

The mistake I want to save you from is spending like it's product when it's scaffolding. For a smaller company the stakes are worse than for the big players, because the effort you spend on the pipeline is the effort you're not spending on the business. The big company can afford to build the training wheels and watch them go obsolete. You can't. Here's the good news: you don't have to.

I believe the capacity that the large companies engineered for years is about to become a default. The same models you can buy today, on the same subscription, do the prompting, hold the context, and run the tools that teams spent years building. In about a year, maybe two, that capability arrives for free, which means the small company that waited gets the same machine without the years.

I can't promise the date. What I can say is what I've lived through: the pattern has repeated twice in the last few years, and each time, waiting cost me exactly nothing. The third example didn't need to be absorbed at all; it simply found a better job.

Slow Is Fine

So here's what I think, stated calmly. The edge moves fast, but nothing important runs off it if you wait. The models are growing up, and the tools we built for their childhood are coming off, one pair at a time.

You don't need the newest engineering discipline. You need a good business and the patience to let the models meet you where they are, which I've watched them do whether you chase them or not.

Moving slow isn't falling behind; it's skipping the training wheels. The bleeding edge only cuts the people who chase it, and nobody needs to bleed.