Claude Did Not Break Wall Street, A Straight Line Did

Less than a year ago, the biggest publications in the world were confident that AI was a bubble with no clear path to profit. Now the same outlets are quietly walking it back and calling it a turnaround. Here is the uncomfortable truth that makes the reversal look silly: nothing actually changed. The capability of these models has tracked the same straight line the entire time. The people calling it a bubble and the people now calling it a turnaround are both just reacting to a trend they never learned to read. This playbook is about reading it, and then doing something useful with what it tells you.

Step 1: Learn to read the straight line before you plan anything

The first move is not technical. It is a way of seeing. Plot how much expert-level work these models can complete over time, and on a log scale you get a clean, straight line that has not bent. Capability has been climbing at a steady, predictable rate for years. The bubble headlines and the reversal headlines are both noise laid over the same signal.

Why start here? Because extrapolating a straight line on a graph gives you a better model of the future than most domain experts do. You do not need to be a genius to beat the analysts calling for a crash. You need to follow the line and project where it lands. The common error, the one that traps smart people, is watching a model make a dumb mistake today and concluding it will never reach human level. The straight line exposes that error for what it is, a snapshot mistaken for a trajectory. So before you build anything, adopt the assumption that capability keeps climbing, and plan ahead of it rather than behind it.

Step 2: Choose a model and a harness, because the scaffolding decides the outcome

The second step is to stop thinking of the model as the whole product. The tools you have heard of, Claude Code, Codex, and the rest, are not the intelligence. They are scaffolding, a harness wrapped around a model. The clean way to picture it is racing. The model is the Formula 1 driver and the harness is the car. Put a great driver in a mediocre car and the result is mediocre. Put the same driver in a better car and the result changes completely. Both the driver and the car set a ceiling on what you can achieve.

So the real question for any business is never just which model. It is which model plus which harness, because the two together decide what your AI can actually do. A brilliant model bolted to a clumsy harness produces clumsy work. When you plan a project, you are choosing both, and skipping the harness question is how people end up disappointed by a model that was never the problem.

There is history behind this idea worth knowing. Years ago, a research project wrapped a model in a harness and set it loose inside a game, learning skills continuously through nothing but text, and it kept improving instead of plateauing. That was an early proof that the scaffolding around a model is where a lot of the magic lives. The lesson held. The harness is not a detail, it is half the machine.

Step 3: Find the one weird, high-stakes workflow only you understand

Now you get specific about where to point all this. If AI is so powerful, why is it not already everywhere? Because implementing it inside a real business is legitimately hard. Frontier labs prove a technique works in a simple, clean setting, and then it can take twelve or more months to turn that proof into something a real company can actually run. The gap is not capability. The gap is deployment.

That gap tells you exactly where to aim. Do not point AI at the generic tasks that off-the-shelf software already handles. Point it at the one weird, high-stakes workflow that generic software never quite gets right, the process that runs on your own hard-won judgment. Those are the problems that reward the effort, because they cannot be bought in a box. Hospitals, banks, and governments live on these custom, high-stakes needs, which is why serious money is flowing toward solving them. Your business has a smaller version of the same thing. Your job in this step is to name it.

Step 4: Deploy like a forward-deployed engineer, on site, against real data

The fourth step borrows the pattern that made the hardest AI deployments work, the forward-deployed engineer. The idea, pioneered in the enterprise world, is to embed your best engineer directly inside the business and ship real code on site, against the real workflow, not in a lab. That pairing of model expertise with the customer's own domain knowledge is where results actually appear.

For a small business, you run the same pattern at a smaller scale. You do not build the tool against a tidy sample. You build it against the real calls, the real schedule, the real invoices, iterating on the messy inputs the workflow actually produces. And you treat it as a project, not a switch you flip overnight, because the first version will be rough and the value shows up through iteration.

The structural news confirms this is where the industry is heading. Anthropic announced a roughly 1.5 billion-dollar joint venture with Blackstone, Hellman and Friedman, and Goldman Sachs to deploy enterprise AI, while OpenAI is raising around 4 billion for a similar effort at a 10 billion valuation. The smart money is not funding more research. It is funding deployment, the exact bottleneck this playbook is built to cross.

Step 5: Let the installed system get sticky

The final step is to keep the tool running until it becomes part of how the business operates. Once a system is installed and someone relies on it every day, it gets sticky in the best sense. It stops being a novelty you show people and becomes infrastructure you would miss if it disappeared. That stickiness is the goal, because it means the value compounded instead of evaporating after the demo.

The playbook applied: an HVAC dispatch tool

Let me run the whole sequence through one concrete example. Picture the owner of a small HVAC company. Step one, the owner stops debating whether AI is overhyped and accepts that capability keeps climbing, so building now is early rather than late. Step two, the owner picks both a model and a harness, understanding that the scaffolding matters as much as the model. Step three, the owner names the one weird, high-stakes workflow that generic software never nails, dispatch. On a hot summer morning when twenty calls come in at once, deciding which technician goes to which job, based on skill, location, and the parts already on each truck, runs entirely on the owner's judgment. No off-the-shelf scheduler encodes that.

Step four, the owner builds the tool the forward-deployed way. Not against a sample. Against this morning's actual twenty calls and the actual truck inventory, pairing the model's capability with the owner's dispatch instinct, iterating over a few weeks until the suggestions match what a veteran dispatcher would do. Step five, the dispatcher leans on it every single morning, and it becomes part of how the company runs. Say it shaves twenty minutes off the morning scramble and prevents two mis-routed trucks a week. That is real money and real customer goodwill, from one narrow tool built against real data.

The same deployment discipline pays off well beyond dispatch. The demand that fills the schedule comes from Facebook and Instagram ad campaigns and Google Ads, and every one of those leads should land in a CRM and website stack where follow-up runs automatically instead of living in someone's memory. The internal tool and the demand engine are two halves of the same operation, and both reward being deployed against the real workflow rather than a tidy demo.

Step 6: Budget for iteration, and expect the first version to be rough

The step that separates the owners who cross the deployment gap from the ones who give up is this one, and it is the least glamorous. You have to plan for iteration, because the first version of any of these tools will be underwhelming, and if you treat underwhelming as failure, you will quit exactly one week before it would have started working.

Remember the reason the gap exists at all. Frontier labs prove a technique in a clean setting, and it takes a year or more to turn that into something a real company runs. That lag is not incompetence. It is the honest cost of adapting a general capability to the specific mess of a real workflow, with its edge cases and its exceptions and the twenty little rules that live only in the owner's head. Your small version of the same project has its own small version of that lag. The first draft of the dispatch tool will misroute a truck. The first draft of any tool will get something wrong that a human would have caught. That is the process working, not the process failing.

So scope the project like a project. Pick a window, a few weeks, where you expect to iterate rather than ship. Decide up front how you will judge whether it is improving, ideally by testing it against real cases where you already know the right answer, so you can see the suggestions getting closer to what a veteran would do. Keep a human firmly in the loop the whole time, both to catch the confident mistakes and to feed the tool the corrections that make the next version better. The corrections are not overhead. They are the training signal that closes your version of the deployment gap.

There is a discipline question hiding here too. The forward-deployed approach works because the engineer stays embedded until the tool is genuinely useful, not until the demo looks good. The demo is the trap. A tool can look impressive in a controlled walkthrough and fall apart on the real Monday-morning chaos it was built for. So resist the urge to declare victory at the demo. Declare victory when the person who does the job every day reaches for the tool without being asked, because that is the only signal that the value survived contact with reality.

And budget attention, not just time. The most common way these projects die is not a technical wall. It is the owner getting busy, drifting away during the rough first version, and never coming back to push it over the line. If you cannot give a project the few weeks of attention it needs to get past rough, that is exactly the situation where handing it to someone whose whole job is to stay embedded until it works pays for itself. The technology is not the bottleneck. Sustained attention through the awkward middle is.

One more reframe helps here. Think of the first rough version not as a product but as a conversation starter with your own workflow. Every time it gets something wrong, it is showing you a rule that lived only in your head and never got written down, the exception you always make on a hot Friday, the customer you always prioritize, the judgment call that felt too obvious to say out loud. Capturing those rules is the actual work of deployment, and the rough version is what surfaces them. Owners who see it that way stop being frustrated by the early mistakes and start treating each one as a useful discovery, which is exactly the attitude that carries a project through the middle and out the other side.

Where this leaves you

The whole lesson from Wall Street locking arms with the labs is that deployment is the hard part, and deployment is precisely the part you can hand to an expert. Read the line and assume capability keeps climbing. Choose a model and a harness together. Find the one weird, high-stakes workflow only you understand. Build the fix on site against real data, treating it as a project with iteration. Then keep it running until it is sticky.

You can learn to build these tools yourself, and plenty of owners do exactly that. If you would rather have someone embed in your workflow, pair the right model with the right harness, and ship the tool against your real data, that forward-deployed approach is the fastest way across the deployment gap without waiting out the twelve-month lag.