For about fifty years, an ordinary person in this country could climb into the middle class on nothing but a trained mind. No capital. No inheritance. No land, no machine, no family name to trade on. Just study and work. You learned something difficult, someone paid you to do it, and that paycheck was your claim on the nation's wealth — the reason the economy had to deal you in at all.

It is the best deal the modern economy ever offered an ordinary person — a share of the country's wealth for nothing but what you could learn. And it is ending.

We have watched the machine come for people's work twice before, and both times it ended well. The first wave — the Industrial Revolution — drove the farmhand off the land, and the factory was waiting to catch him. The second — automation, and the great wave of globalization — emptied that factory, and the office was waiting to catch his children. A way of making a living ended, and each time a wider one opened beneath it. That is the pattern, and it is real.

We've been here before

Farm to factory. In 1900, roughly four in ten Americans worked the land1. And a whole village made its living in orbit around them — the blacksmith at his forge, the miller, the wheelwright. It was a world built on muscle, the farmer's and the horse's, and nearly every trade in town existed to keep that muscle working.

Then the machine arrived. The tractor, the combine — one man on a seat doing the work that had taken a dozen backs and a team of horses. The field didn't need those dozen anymore. It needed just one.

If you'd stood at the edge of that field and asked, "Where do all these people go?" — nobody could have told you. There was no answer to give. And yet they went somewhere. They drifted toward the cities, toward the smokestacks, and within a generation they'd become something their grandfathers had no word for: riveters and welders and machinists. The work was steadier than the harvest, and often better paid than the field had ever been.

The wide floor of the field emptied, and a wide factory floor opened to catch it.

Factory to office. In 1950, roughly three in ten Americans made their living in a factory — the riveter, the welder, the machinist. And a whole town made its living in orbit around them — the diner, the union hall, the corner store. It was a world built on the line, on the steady wage and the lunch whistle, and nearly every business on Main Street existed to spend what that wage brought home.

Then the machine arrived. The robot arm, the shipping container — an arm that welded all night without a wage, and a steel box that could carry the whole job overseas. The line didn't need those hands anymore. The ones it kept, it paid less.

If you'd stood on that factory floor and asked, "Where do all these people go?" — nobody could have told you. There was no answer to give. And yet they went somewhere. They drifted from the line into the office, out of the noise and into the fluorescent hum, and within a generation they'd become something their fathers had no word for: clerks and bookkeepers and analysts. The work was cleaner than the line, and often better paid than it had ever been.

The wide factory floor emptied, and a wide office floor opened to catch it.

Today, more Americans make their living with a trained mind than ever before — the analyst, the coder, the paralegal, the copywriter. And a whole economy makes its living in orbit around them — the software vendor, the office tower, the downtown lunch counter. It's a world built on the credential and the salary, and nearly every business downstream of it lives on what those salaries spend.

Then the machine arrived. The model, the agent — a mind that never sleeps, that reads every document and drafts every memo for the price of the electricity it burns. The office doesn't need those hundred anymore. It needs a few.

Stand in that office today and ask, "Where do all these people go?" — and nobody can tell you. There is no answer to give. We say they'll go somewhere; they always have. They'll drift out of the cubicle and into —

The wide office floor is emptying.

Into what?

Follow the windfall

There are only two reflexive answers to Into what?

The pessimist says nowhere. This is the end of work — the machines have finally won. It's an old fear, and it has an old name: the lump-of-labor fallacy2, the belief that there's a fixed pile of work in the world, so that every job a machine takes is one gone for good. Every generation reaches for some version of it; the Luddites smashed the looms over it. And so far, it has been wrong every time — because the pile was never fixed.

The optimist knows this, and says somewhere new. There has always been somewhere new, and he has two hundred years of being right. The work didn't run out when the loom came, or the tractor, or the assembly line — it grew, and the displaced always found a wider floor waiting below. So when he tells you the office will empty into something we can't yet picture, don't wave him off. History is sitting in his lap.

The people always followed the windfall. That's the thing both of them skate past, and it's what every upheaval in this essay quietly teaches: find where the windfall pooled, and you've found where the next floor opened. So before we bet on the optimist's streak holding one more time, let's ask the question neither side ever does — where does the windfall go?

So follow it. When the tractor made food cheap, it created a windfall — the gap between what food used to cost and what it now cost. Where did that windfall go?

Not to the farmer — not for long. A little stuck to whoever mechanized first, but competition pried it loose fast. It went downstream, to everyone, in a form so ordinary we don't call it wealth: a smaller bill at the grocer. Economists have a lovely name for that one, too — consumer surplus3, It's the money that stays in your pocket when something you need gets cheaper. Bread drops from a dime to a nickel, and you didn't earn a thing — but you have that nickel, every day, for the rest of your life. Multiply it across a nation and it's a fortune, hiding in plain sight as the absence of a cost.

That pile of nickels didn't sit still. The country spent it — on things that had scarcely existed while bread was dear: a Ford in the driveway, a radio in the parlor, a Sunday at the pictures. And every one of those new comforts had to be built, by someone. The grocery money the tractor freed up became the wage that built the cars and the radios and the movie houses — and the farmhand walked off the emptying field and into the very factory his cheaper bread had paid to build.

Then it happened again, a generation later. The assembly line and the shipping container did to goods what the tractor had done to food — they made them cheap. You watched the last act of it yourself: a factory in China, a container ship, a Walmart at the edge of town — and a refrigerator, a flat-screen television, a season's worth of clothes cost a fraction of what they once had. The difference dropped back into the family's pocket. The same nickel off the bread, now a few dollars off nearly everything on the shelf.

And that money didn't sit still either. With the necessities cheap and a little left to spare, families started buying things they couldn't hold: a doctor's check-up, a mortgage on a house, a degree with a name on it, a song they didn't have to sing themselves. Services — and a service has to be rendered, by someone. So the savings off the cheap goods became the salaries of the people who rendered them, and every year there were more of them: more doctors, more lawyers, more accountants, more programmers. The factory worker rarely made that leap himself — his children did. They took the degree the surplus had paid for and walked into the office it had built.

Five links, every time:

windfall → consumer surplus → re-spent → new demand → new production that needs people.

So let's follow the value into our own predicament — link by link.

An AI reviews the contract, drafts the design, does the week's work in an afternoon. There's the windfall. It runs downstream, exactly as always, to whoever buys the result a little cheaper: consumer surplus, the same nickel off the bread, only now the bread is a legal contract, a tax return, a company logo.

And it will keep flowing, exactly as it always has. That money will get re-spent — it always is. The spending will call up new demand, new wants, new work to be done. Four links of the old chain, clicking into place right on schedule. And every instinct we have says the fifth is coming up behind them, the way it always has: the new demand becomes new jobs, and a floor opens under the falling.

But what if the new demand can be satisfied by the same machine that created the windfall?

Every time before, it couldn't. The tractor that emptied the field could not build the Ford. The robot arm couldn't analyze your mammogram. The factory in China couldn't write your contract.

What faces us now is different in kind: it is general. It does the contract, the design, the week's work in an afternoon — and it can turn and make whatever new thing the windfall dreams up next.

So the fifth link fails: new production no longer needs people. The one condition that saved us every time is the thing the machine quietly removes.

The sharpest optimists have one card left, and it has a name: the Jevons paradox4. Make a thing cheaper, a Victorian economist noticed, and the world doesn't use less of it — it uses far more. Make code cheap and we won't write less software; we'll write oceans of it. They're right, and it's their best move. But watch where it lands. The demand for the work explodes — and the machine is what rushes in to meet it. More software than the world has ever seen, built by fewer people than ever. The paradox holds for the output and breaks for the worker.

Which is the whole of it, in a sentence:

The value still flows somewhere we can spend it. It no longer flows somewhere we can earn it.

Move up to what?

So change the question. Don't ask whether new work appears. Ask whether it can catch a mass of people — and whether it pays a living. Every rung that mattered in the last two centuries was both. The factory floor and the office floor weren't just jobs; they were wide, well-paid jobs that an ordinary person could reach by learning. That combination is the thing that made the ladder a ladder.

So name it. When people say the displaced will "move up," I keep asking the same thing: up to what? The answers are fewer than they sound. Two of them are jobs — and I'll take both seriously in a moment. A third isn't a job at all: stop being labor and become an owner. That one's the deepest answer of the three, which is exactly why it gets its own essay and not a line here — it's a wall you buy your way past, not a rung you climb, and we'll come back to it. For now, the two that are jobs, because they're the ones the optimist reaches for first.

The first: "They'll orchestrate the AI — supervise the agents, manage the fleet." Fine. Let's literalize it. A former analyst now directs a swarm of agents and does what a ten-person team used to do. But notice what that is: it is not a new floor with new seats. It's the same work, with nine fewer people. The entire value of the role is more output, fewer humans. So "moving up a rung" here means, precisely: nine people leave, and one stays with a better title. The promotion is the layoff. You cannot rehouse a displaced multitude on a rung whose whole purpose is to need fewer of them.

The second: "New categories we can't imagine yet — like podcaster, like app developer." Real, and I believe it. But ask the only question that matters for a ladder: how wide, and how well-paid? And hold that question, because to answer it honestly we have to talk about where a wage actually comes from. That turns out to be the crux of the whole thing — and it's the part almost nobody slows down to explain.

How a wage is actually made

Here's a question that sounds simple and isn't: why does anyone get paid what they get paid?

The tempting answer is "because the work is valuable." But that can't be the whole story, and there's a 250-year-old puzzle that proves it. Adam Smith named it in 1776 and couldn't crack it. It's called the diamond-water paradox5. Water keeps you alive; without it you die in days. A diamond does nothing — it's a pretty rock. And yet water is nearly free and a diamond costs a fortune. If price followed value, water would be priceless and diamonds worthless. It's the other way around. Why?

The answer took economists another hundred years to work out, and it is this: price isn't set by how useful something is in total. It's set at the margin — by how much the next one is worth, and that depends on how scarce it is. Water is abundant, so the next glass is worth almost nothing, even though all the water in the world is worth everything. Diamonds are rare, so the next one is dear. Scarcity, not usefulness, sets the price.

Wages work the same way. Your pay tracks two things multiplied together: the value of what you produce, and the scarcity of your ability to produce it. You need both. A skill nobody wants pays nothing, however rare. And — here's the diamond-water half people miss — a skill everyone has pays nothing either, no matter how essential it is. A wage was never paid for value. It was paid for scarce value.

Now you can see why knowledge work paid so well for fifty years. A trained mind was valuable — it produced things people wanted — and it was scarce, because learning hard things is slow and not everyone does it. Productive and rare. A diamond. That's the rung, explained: it paid a broad, good wage because trained cognition was a diamond that ordinary people could, with effort, go and acquire.

What AI actually does to the wage

AI does not destroy the value of human cognition. Your judgment still produces plenty — arguably more than ever, amplified by the machine.

What AI does is change the scarcity. It takes the trained cognition that used to be rare and makes it abundant. It turns the diamond into water. Still essential — more essential, even — and now everywhere, on tap, for the price of a subscription.

And we already know what the market pays for something essential and abundant: it pays what it pays for water. Almost nothing. Not because the thing stopped having value, but because the next unit of it is no longer scarce.

A wage, as we just saw, is the price of scarcity — not of usefulness. So the wage falls even while the usefulness holds. You can keep the job and lose the living.

The scarcity that was always there

But the wage doesn't fall to zero. Strip away the cognition that just turned to water, and something is left standing underneath — something that was rare long before the machine arrived.

Call it craft — and I mean the word precisely: the thing you earn, through years of effort and rigor. The discipline to know which problem is worth solving, and when the machine has quietly gone wrong. The standard that won't ship what's almost right. The willingness to put your name on the outcome. None of it is new, and none of it just became scarce. It was always the rare thing. A great engineer and a mediocre one were never separated by the routine work the machine now does for both of them — they were separated by knowing which way is wrong, the call only one of them could make.

So the wage doesn't disappear. It splits. It collapses for the many, whose faculty just turned to water — and it holds, maybe climbs, for the few who developed their craft. The ladder doesn't narrow to a spike. The wide floor falls away, and what's left standing is the spike that was always there: a tall, thin place where a handful of masters command a scarce thing.

Years ago, on my first day after taking over as head of engineering for a team of about a hundred people, a new release was crashing in front of an important customer, and the team had a hotfix ready to ship. Everyone wanted it out the door — the customer was furious, the pressure enormous. I asked them to wait. Not because I'd read the code; I hadn't. Because I had made this exact mistake myself — fifteen years earlier, at another company, I was the dev manager, and I shipped the bad patch in the same kind of panic, certain it was fine, and watched it break. That's how I knew the shape of it: a patch written in a panic carries more bugs. So we kept testing. Two days later, there it was — a second bug, hiding in the fix. They wrote the tests that caught it, shipped a version that held, and we kept the customer.

A hundred capable people, and the moment that mattered turned on a call that took experience the rest of them simply hadn't had the years to earn yet. Their hands were abundant; the craft was scarce.

For the past year I've worked with Claude every day, and the division of labor is identical: left to itself, the machine will burn an afternoon sprinting confidently down the wrong road; left to myself, I can't move at anything near the pace we move together. It does the work of 30 engineers. I do the one thing it can't — I know when it's wrong. The model is abundant; the craft is scarce; the value lives in the craft.

And don't mistake that for good news about me. One of me is worth thirty only because the work stopped needing the other twenty-nine — my leverage and their absence are the same fact, seen from two seats. The machine complements the one by replacing the many.

Let me subject you to a thought experiment. Say there are thirty million software professionals in the world today; developers, QA engineers, support staff, and the rest of the trade6. I suspect that in ten years there will be a tiny fraction of that — call it thirty thousand — and each one a master, each one supplying the scarce residue to a fleet of tireless machines. I might be wildly off on just how few are left. But the shape is the argument: a broad profession, paid a broad wage for a once-scarce skill, collapsing into a narrow spike of the few who hold what stays rare. The wide rung, falling away as you watch.

A master isn't born; he's made — on the lower rungs, doing the junior work clumsily until he's done it enough times to do it well. I learned to spot a doomed hotfix by shipping one myself, years before, back when I was the one in the panic. The spike is built entirely out of the floor beneath it.

But the floor is the first thing the machine takes. The entry-level work — the cheap, the routine, the learnable — is exactly what AI does first and best. The youngest workers in the most exposed fields are already quietly disappearing: not fired so much as never hired, their rung simply not refilled7. So the masters left standing aren't the first of a new elite. They're the last of an old one — a generation with no apprentices behind it, because the apprenticeship is gone. Who trains the thirty-thousand-and-first?

"But everything will be so cheap"

Here's the objection I take most seriously, because it's the one I can't fully put down. Maybe the wage doesn't matter. If AI drives the cost of nearly everything toward zero — the doctor, the tutor, the lawyer, the ride, the kilowatt — then a small paycheck in 2040 might buy a fuller life than a six-figure salary buys today. Abundance, the optimists say, makes the wage beside the point. And they're partly right. I don't think this story ends in breadlines; nobody starves in a world this productive.

But a wage was never only what it buys. It was a claim — your share of the wealth you helped make — and a place, a reason the economy had to deal you in. And the things that actually make a life are not the things abundance makes cheap. The house in the district with the good school doesn't get cheaper when software does — there's only one of it, and now everyone's bidding. And what you own holds its value; what you rent does not. The cheap things get cheaper, and the scarce things — land, position, a claim on the future — get dearer, because that's where all the displaced money goes hunting for a home. You can hand every person a miracle and still leave them with no claim on it. That isn't a rebuttal to abundance. It's the question abundance can't answer — and I'll come back to it.

The rung and the wall

So that is the walk we just took. For fifty years an ordinary person could trade a trained mind for a claim on the nation's wealth, and climb. The machine has come for that trade the way it came for the farm and the factory before it — but this time no wider floor is opening beneath, because the thing that always opened it is gone. The value still flows. It simply no longer flows through us. What's left of the old rung is a spike: a narrow perch for the few who spent a lifetime earning a craft, and a long drop for everyone else. And the comfort we all reach for — it'll be so cheap — is the smallest comfort there is, because cheap is not the same as yours. A wage was a claim and a place — the reason the economy had to deal you in at all. Lose the wage, and it doesn't have to anymore.

Which leaves the question I promised to come back to — and it's the one everything else hangs from. If a trained mind is no longer a claim on the wealth, then what is? The only rung still standing above labor isn't a kind of work at all. It's ownership — not a rung you climb, but a wall you buy your way past. The windfall still falls from the tree. But the orchard has a fence now, and a name on the deed.

So the question was never really what will people do. It's what waits on the rung above — the one made of capital, not work, and the only place the value still pools. I've sat across the table from the investors already buying in. I've read what today's CEOs write to each other — addressed to companies, never to you. That's the rung we climb to next.

Two emails arrived on the same morning last week.

The first was four paragraphs long. It opened with background I already knew, wandered through a description of several problems without distinguishing which ones mattered, and ended mid-thought — no clear ask, no proposed next step. I read it twice and still wasn't sure what I was supposed to do. The sender had emptied their head into my inbox, and the work of organizing their thoughts was now mine.

The second was three sentences. It stated the problem, proposed a solution, and asked for my sign-off by Thursday. I read it once, replied in thirty seconds, and moved on.

Same medium — text in a rectangle on my screen. Completely different experience. One was like drawing in a breath and finding oxygen. The other was like drawing in a breath and finding nothing.

The Factoring Problem

There's an operation in mathematics called prime factorization. Given a large number, find the primes that multiply together to produce it. It's famously hard — so hard that modern cryptography depends on it. But here's the thing: verifying the factors is trivial. If I tell you that 7 × 13 = 91, you can confirm it in your head. Finding those factors in the first place is where the work lives.

Good cognitive work has this same asymmetry. It's expensive to produce and cheap to consume. A well-written article, a well-run meeting, a clear email — these are things where someone did the hard work of analysis, synthesis, and organization upstream so that the receiver doesn't have to. The reader, the attendee, the recipient gets the factors. They can verify, engage, build on top. The complexity was absorbed before it reached them.

This is what it feels like to read something that makes you smarter: the author did the factoring, and you get to do the multiplication. You leave the interaction with more than you came in with. It feels like oxygen because it is — metabolizable thought, ready to use.

The Inversion

Slop — in every medium — inverts this asymmetry.

The producer does the cheap part: they generate volume. Words in a Slack message. Slides in a deck. Attendees in a meeting. An hour of someone's voice in a recording. The expensive part — figuring out what's actually useful, what the point is, what action should follow — gets transferred to the receiver. The sender saved themselves five minutes of thought and cost you thirty minutes of interpretation.

A meeting with no agenda is unfactored work. The organizer didn't do the hard thinking about what needs to be decided, so everyone in the room has to do it together, in real time, expensively. A Slack message that ends with "..." is an unfactored request — the sender hasn't finished their own thought but has already conscripted you into completing it. A rambling email is someone offloading the cost of organizing their ideas onto whoever opens it.

And it's not just informal communication. A report that buries its conclusion on page twelve. A LinkedIn post that takes six paragraphs to say nothing. A status update that recites activity without revealing progress. These all have the same shape: the author did the easy part and left you with the hard part.

Here's the same project, the same week, written two ways:

The Q3 marketing campaign is progressing. We've had several meetings with the agency to discuss creative direction. The team is reviewing media buy options. Some concerns came up about the budget that we're looking into. We're also coordinating with legal on the new disclaimer language. Overall things are on track and we'll have more updates next week.

You read that. What do you know now? What decision can you make? Nothing. You've consumed someone's time without receiving their thinking. Now read this:

Q3 campaign is a week behind schedule. The agency delivered three creative concepts — we've approved one and sent revision notes on the hero video, due back Wednesday. Media buy is $15K over budget because cable rates increased. Legal approved the disclaimer language. Decision needed: do we cut the print placement to stay on budget, or request the additional $15K?

Same project. Same week. The first version transfers all the cognitive work to you. The second arrives with the factors already extracted — what's late, what's done, and what you need to decide. One is a deposit. The other is a withdrawal disguised as a deposit.

This isn't about doing all the thinking alone. A leader who brings a clearly framed problem to a working group — here's what's broken, here's why it matters, here's what we need to figure out — has done their factoring. The problem is defined, the stakes are clear, and the team's role is to factor the solution. That's not offloading. That's delegation. The inversion happens when the problem itself hasn't been factored — when the audience has to figure out not just the answer but the question.

The Director Test

I've spent years advising people who want to advance in large organizations, and there's a pattern I keep coming back to.

Non-directors bring you a problem. They walk into your office, describe what's broken, and look at you. The implicit request is: think about this for me. They've done the multiplication — they've identified that 91 is a number that matters — but they haven't factored it. Now it's your problem.

Directors bring you the problem, a proposed solution, the thinking that led to that solution, and a simple request for borrowed authority to implement it. They hand you 7 × 13 and say: "I need your sign-off to proceed." Same information. Radically different cognitive load. The director absorbed the expensive part before they walked through the door.

This isn't about seniority. I've seen junior engineers who factor beautifully and executives who can't organize a thought before they broadcast it. The asymmetry is a skill, not a rank. And like most skills, the first step is noticing it exists.

The Guitar Amp

This is where AI enters the picture — and where the asymmetry gets sharper, not duller.

AI is a guitar amp. It makes you louder, not better. If you can play, more people hear something worth hearing. If you can't, more people hear that you can't. An expert who uses AI to research, draft, analyze, and refine is doing more factoring, not less. They're using the tool to absorb even more complexity before it reaches the audience. The output is denser, clearer, more thoroughly considered — because the human brought expertise and the machine brought scale.

But someone without the discipline to do the thinking produces slop at scale. They generate volume faster, more confidently, and with better formatting. The output looks factored. It has the shape of organized thought: clear paragraphs, bullet points, professional tone. But the expensive work was never done. Nobody decided what actually matters. Nobody filtered, prioritized, or applied judgment. The receiver opens it, reads it, and slowly realizes they're breathing vacuum.

The wave of "AI slop" complaints is real, and some of it is earned. People are drowning in AI-generated content that looks polished but says nothing — emails, reports, LinkedIn posts that have the shape of organized thought without the substance. If you're tired of breathing vacuum, you should be. That's not a complaint about AI. It's a complaint about unfactored work produced at new scale.

But there are two complaints hiding in "AI slop." One is about quality — this work is bad — and that's fair. It was bad before AI made it cheaper to produce. The other is about provenance: this was made with AI. That's the tell. Scanning for emdashes, flagging "certainly" and "moreover," treating typographic habits as a forensic test for whether a machine was involved — all to avoid the harder question of whether the work is actually good. When the objection isn't that the work is bad but that AI touched it, the person is admitting they can't evaluate the output on its merits — they need to know the process to judge the product. An expert reads AI-assisted work and knows immediately whether the thinking was real. The provenance is irrelevant.

The tool doesn't change the asymmetry. It reveals who was already doing the factoring and who was getting away without it.

The Obligation

You have a factoring machine. Ship factored work.

Every message, meeting, article, and interaction is a claim on someone else's attention. That claim carries an obligation: absorb the complexity before you transfer it. Do the factoring. Show up with the primes, not the product.

The tools for doing this have never been better. You can draft, research, analyze, reorganize, pressure-test, and refine your thinking at a speed that was unimaginable five years ago. The cost of producing well-factored work has collapsed. Which means the bar for what's acceptable has risen — or should have.

If you send a meeting invite, include the decision that needs to be made. If you send a message, finish your thought before you hit send. If you write a report, put the conclusion first. If you write an email, know what you're asking before you start typing.

There's a nostalgia among people who grew up with early personal computers — the Commodore 64, the Apple II, the TRS-80 — for the time when you could understand everything about your machine. The CPU had a few thousand transistors. The memory map fit on a single page. You could trace the flow of electricity from keystroke to screen pixel and predict exactly what would happen. You owned the whole thing, top to bottom.

Evan-Amos, CC BY-SA 4.0, via Wikimedia Commons

Modern AI systems don't offer that same feeling of total mastery. But they're more understandable than most people assume — if you stop trying to grasp the whole thing at once.

The trick is to peel it apart, one layer at a time. Start at the top — the software system you interact with — and work your way down through the reasoning strategy, the language model, the network architecture, and finally the individual neuron. At each layer, the math is straightforward and the ideas are concrete. And somewhere on the way down, the thing that felt like digital alchemy starts to look like what it actually is: simple mathematical operations, repeated at extraordinary scale.

Layer 1: The System

The first and most common misconception about artificial intelligence is the conflation of the "model" with the "system." A large language model, in isolation, is a static file — billions of numerical weights representing statistical probabilities. It possesses no agency, no continuous memory, and no inherent ability to interact with the external world. The capabilities people attribute to AI — the memory, the web searches, the personality, the safety — emerge from a complex orchestration layer that surrounds the model.

When you type a message into ChatGPT, Claude, or Gemini, you're not talking to a model. You're talking to this system.

There's an irony here worth noting. For years, serious practitioners bristled when the public called machine learning "AI" — the term was too generous, too anthropomorphic for what were really just statistical models. We demanded specificity: machine learning, deep learning, NLP, LLM. But now that engineering has wrapped these models in memory, tools, safety layers, and persistent agency, we find ourselves telling people to stop calling the whole thing an "LLM." The term that was once too narrow is now reductive. Now we're the ones demanding the public call it "AI."

The Serving Layer

When your message reaches the provider's servers, it enters a serving infrastructure that's invisible to you but directly affects what you get back. Your request gets queued, batched with other users' requests for efficient GPU utilization, and routed to available hardware. Common responses may be served from cache rather than computed fresh. Under heavy load — the kind you see reflected on status pages — service can degrade: slower responses, shorter outputs, or temporary unavailability.

Behind the scenes, techniques like speculative decoding (where a fast, small model drafts candidate tokens and a larger model verifies them) and best-of-N sampling (generating multiple completions and selecting the best) can improve speed or quality without the user ever knowing. The details vary by provider and are rarely disclosed, but the principle is worth understanding: what users experience as "model quality" is not solely a property of the model's weights. It's also a function of how much compute the system spends on your specific query, how loaded the infrastructure is at that moment, and engineering decisions the provider has made about cost, speed, and quality tradeoffs.

Safety and Guardrails

Safety and moderation layers screen both your input and the model's output. These aren't the language model itself — they're often separate, smaller classifiers running alongside it, purpose-built to detect specific categories of risk.

On the input side, classifiers scan your prompt for requests involving harmful content: instructions for weapons or dangerous substances, generation of child sexual abuse material, attempts to extract the model's system prompt or manipulate its behavior through prompt injection. On the output side, similar classifiers screen the model's response before it reaches you, catching cases where the model might have generated something that slipped past its own training-level safeguards.

The Illusion of Memory

An LLM doesn't remember previous conversations natively — it processes a fixed window (the context window) each time. So the system assembles everything the model needs to see: your current message, relevant conversation history, retrieved documents or memories from previous sessions, images or other media converted into numerical representations, and a system prompt — the hidden instructions that define who the model is, how it should behave, what it should refuse, and what tone it should take. This assembled context is the model's entire reality. It evaluates it from scratch every time — no persistent state, no running thread of consciousness between calls. Products that feel like they "remember" you are doing retrieval and injection behind the scenes.

This is what the industry briefly called "prompt engineering" and later "context engineering" — the art of controlling what goes into the window. The terms faded not because the problem was solved, but because the systems got better at assembling context automatically. The principle remains: the model can only work with what's in front of it. A well-assembled context produces a brilliant response. A sloppy one produces hallucinations, missed instructions, or generic boilerplate. When a long conversation seems to "forget" your earlier instructions, it's because the system ran out of room and physically truncated them — to the model, they never existed.

Tools and Agency

Without tools, a language model is a brain in a jar — impressive, but it can't see, can't act, can't access anything beyond what's already in its context window. It can talk about your calendar, but it can't check it. It can describe how to query a database, but it can't run the query. Everything that makes a modern AI assistant feel like a collaborator rather than a conversationalist comes from tool use.

The mechanism is almost disappointingly simple:

while tool_calls < max_iterations:
    response = stream(model, context)

    if response.contains_tool_call():
        tool, args = parse_json(response)
        result = execute(tool, args)
        context.append(result)
        tool_calls += 1
    else:
        return response  # model didn't ask for a tool — it's done

That's the entire agentic loop. The orchestration layer streams tokens from the model and watches for structured output — typically JSON — indicating a tool request. When it detects one (often by something as basic as counting braces to find balanced JSON), it pauses the stream, executes the requested tool, injects the result back into the context, and lets the model continue. A few hundred lines of Python. The model reads your email, decides it needs to check your calendar, finds a conflict, drafts a reply, and asks for your approval — each step a separate tool call, each result fed back in for the next decision. It feels like agency. Under the hood, it's a state machine with two states.

Model Context Protocol (MCP), introduced by Anthropic in late 2024, accelerated this by giving tool providers a standardized interface. MCP may prove to be transitional — training wheels for a more natural capability. Language models have internalized vast amounts of documentation about command-line tools, APIs, and shell interfaces from their training data. They already know how to use grep, curl, git, and psql without needing a schema to tell them — and any CLI tool they haven't seen before, they can discover with --help. More importantly, the tools themselves are converging toward the patterns models already understand. Long-running commands are being rewritten to separate start and status subcommands so AI can manage them asynchronously. Outputs are becoming more structured. The tools are adapting to the model as much as the model adapted to the tools. The emerging pattern is less protocol, more fluency — models that reason about what they need, compose the right commands on their own, and execute them directly. The result either way: AI that can read your inbox, pull a report, or commit code. Not answer questions about those things — actually go do them.

Everything we've described so far — the serving layer, the safety classifiers, the context assembly, the tool orchestration — is scaffolding. The engine at the center of it, the thing doing the actual thinking, is a large language model. Everything else exists to serve it, protect it, or extend it.

Layer 2: How It Thinks

Before we look inside the language model itself, it's worth understanding a distinction that changed the entire field: the difference between completing and reasoning.

Completion: Fast and Intuitive

Early LLMs were pure completion engines — given a prompt, they'd calculate the probability of every possible next word and select one. Because they select from a probability distribution rather than following deterministic rules, the output is fundamentally stochastic: ask the same question twice and you'll get different answers. This isn't a bug — it's what makes the outputs feel creative and varied rather than robotic. But it also means the model is never "looking up" an answer. It's generating one, fresh, every time.

The flaw is that completion models are forced to answer immediately. If a problem requires ten steps of logic, the model has to output the first step without having calculated the tenth. It's what cognitive scientists would call System 1 thinking: fast, reflexive, intuitive — and prone to confident-sounding errors on anything requiring deliberation. You could ask an early LLM to write code and it would look right — proper syntax, reasonable variable names, plausible structure. But if you actually read it, you'd see it wasn't code. It was text in the style of code — it mimicked the surface patterns without understanding the logic. Plausible at a glance, wrong under scrutiny. Nobody confused it with real understanding. Practitioners found they could improve the outputs by providing examples in the prompt — show the model what a good answer looks like, and the completion gets better. But better completion is still completion.

Reasoning: Slow and Deliberate

Then someone asked the model to show its work.

The shift toward reasoning came from a disarmingly simple observation: models perform dramatically better when you just ask them to break problems into steps. Wei et al.'s 2022 "chain-of-thought prompting" paper showed that adding instructions like these to a system prompt improved math and logic performance by huge margins:

Before answering, break the problem into steps.
Work through each step carefully.
If you notice an error in your reasoning, backtrack and correct it.
Only provide your final answer after verifying your logic.

That's it. The same completion engine, given permission to think out loud, becomes a dramatically better reasoner. The observation — that a simple prompt change could unlock step-by-step problem solving — was the spark. Researchers built on it with tree-of-thought reasoning and self-consistency sampling. Then providers like OpenAI took the next logical step: if prompting for chain-of-thought works this well, why not use reinforcement learning to train models to do it on their own? The result was a new generation of reasoning models that produce extended internal chains of thought automatically, without being asked.

This is the transition point — the moment AI stopped feeling like a fancy autocomplete and started feeling like something you could talk to. A completion model gives you the most probable next word. A reasoning model gives you a considered answer. It plans. It second-guesses itself. It catches its own mistakes. The mechanism underneath hasn't changed — it's still next-token prediction — but the behavior is so qualitatively different that it crosses a threshold in how humans perceive it.

Layer 3: The Language Model

At the core of every AI assistant is a language model, and its fundamental operation is almost absurdly simple: it predicts the next word.

Next-Word Prediction

Given a sequence of words, the model outputs a probability for every word in its vocabulary — typically 30,000 to 100,000 tokens — that could come next. It's as if the model is looking at an enormous grid — every word it knows along one axis — and lighting up the ones most likely to follow what's been said so far.

Given "The cat sat on the ___", the model assigns high probability to words like "mat," "floor," "couch" and very low probability to words like "algorithm" or "bankruptcy." It picks one — stochastically, with controlled randomness — appends it, and repeats. Word by word, a response emerges.

How does it know which words are likely? It learned by reading — trillions of words of human-generated text. Books, articles, scientific papers, code repositories, legal filings, conversations. During training, the model was shown sequence after sequence and asked to predict the next word. Every time it guessed wrong, its weights were adjusted slightly (we'll see exactly how in How It Learns). After trillions of these corrections, the probabilities it assigns are a distillation of patterns absorbed from the largest corpus of human writing ever assembled.

There's no separate module for reasoning, no knowledge database it looks things up in, no explicit rules about grammar or logic. Everything — the coherent paragraphs, the factual knowledge, the ability to write code or summarize a legal document — emerges from next-word prediction at this scale.

Prediction Requires Understanding

The intuition that sophisticated intelligence can arise from a mechanism that is essentially advanced autocomplete is deeply counterintuitive. But accurate prediction requires understanding. To consistently predict the next word in "The heavy steel ball was dropped from the roof onto the fragile glass table, and the table ___," the model must have embedded a functional understanding of gravity, material strength, physical collision, and cause-and-effect into its weights. To predict the next token in a Python function, it must understand programming logic. To complete a legal argument, it must grasp the structure of legal reasoning.

What emerges from this pressure is something researchers increasingly call a world model — an internal representation of how reality works, learned entirely from the statistical structure of text. Grammar, factual recall, spatial reasoning, basic deductive logic — none of it is programmed. All of it is a byproduct of the relentless optimization for next-word prediction across trillions of examples. The model doesn't know it has a world model. It was never told to build one. But the only way to predict language this well is to understand the world that language describes.

From Words to Numbers

This world model is encoded entirely in numbers. So the first question is practical: how does text become math?

Tokenization is the front door: text gets broken into discrete chunks called tokens. Tokens aren't always whole words — they're frequently sub-words, prefixes, or suffixes. "Understanding" might become "under" + "stand" + "ing." Each unique token in the model's vocabulary gets a numerical ID.

This seemingly mundane preprocessing step has real consequences. Many of the persistent quirks of LLMs — spelling errors, counting mistakes, struggles with certain languages — trace directly back to how words were carved into tokens. The model only sees the numerical IDs; it's blind to the actual letters inside a token unless it's learned to reconstruct them.

The Geometry of Meaning

Each token ID gets mapped to a dense array of numbers — a point in a high-dimensional mathematical space. This space might have thousands of dimensions, each representing some abstract feature that the model learned during training.

The key insight is that meaning becomes geometry. Words with similar meanings cluster near each other in this space. "Happy" and "joyful" are close together; "happy" and "tractor" are far apart. More remarkably, the directions in this space encode relationships. The classic demonstration: take the vector for "King," subtract "Man," add "Woman," and you land near "Queen." The model has learned that gender is a direction in its semantic space, and royalty is another, and these directions compose.

This is the universal translator at the heart of modern AI. Text, images, audio — they can all be embedded into the same kind of mathematical space and compared, combined, and transformed using the same operations. Your words become coordinates. The model does geometry.

Layer 4: The Architecture

The language model's probability predictions are computed by a neural network — a computational system, inspired by biological neural networks in the human brain, that learns to make predictions from data without being explicitly programmed. You give it inputs, it produces an output, and you tell it whether it was right or wrong. When it's wrong, it adjusts. When it's right, it reinforces. Do this millions of times and the network learns patterns that generalize to data it has never seen before.

The fundamental unit is the neuron — a simple mathematical function that takes in numbers, multiplies each by a learned weight, sums them up, and outputs the result (we'll look inside one in Layer 5). Neurons are arranged in layers: an input layer that receives raw data, one or more hidden layers that transform inputs into increasingly abstract representations, and an output layer that produces the final prediction. Every connection between neurons has a weight — a single number that controls how much influence one neuron has on the next. A small network might have two inputs, three neurons in a hidden layer, and one output, connected by nine weights:

In Python, the complete forward pass for this network is about twenty lines:

class NeuralNetwork:
    def __init__(self):
        self.input_layer_size = 2
        self.hidden_layer_size = 3
        self.output_layer_size = 1

        self.W1 = np.random.randn(self.input_layer_size, self.hidden_layer_size)
        self.W2 = np.random.randn(self.hidden_layer_size, self.output_layer_size)

    def forward(self, X):
        self.z2 = np.dot(X, self.W1)
        self.a2 = self.sigmoid(self.z2)
        self.z3 = np.dot(self.a2, self.W2)
        self.out = self.sigmoid(self.z3)
        return self.out

    def sigmoid(self, z):
        return 1/(1+np.exp(-z))

Two matrix multiplications and two activation functions. The weights start random. The network doesn't know anything yet — it needs to learn.

A frontier language model has hundreds of billions of these weights. (When people say "deep learning," the deep refers to networks with many hidden layers — depth is what gives them their power.)

The network "learns" by adjusting these weights to make better predictions — we'll see exactly how in How It Learns. That's the entire concept. Everything else is details about how the neurons are arranged — the architecture.

The specific architecture behind modern language models is the transformer, introduced in a 2017 paper titled, with characteristic understatement, "Attention Is All You Need."

What Architecture Means

The way neurons are wired together — which neurons talk to which, in what order, and through what operations — is the network's architecture. Different architectures suit different problems. Convolutional neural networks (CNNs) wire neurons to scan local patches of an image, making them excellent at vision tasks:

Architecture of GoogLeNet (Szegedy et al., 2015) — a convolutional neural network for image classification.

Recurrent neural networks (RNNs) and their successor LSTMs wire neurons in a chain, processing sequences one step at a time — which made them the standard for language until the transformer came along and displaced them all.

The Attention Revolution

The transformer's key innovation is the self-attention mechanism. RNNs and LSTMs processed text strictly word by word, passing information forward sequentially — and often losing the context of early words by the time they reached the end of a long passage. Self-attention solved this by letting every token in the input look at every other token simultaneously to determine relevance.

Here's how it works, mechanically. For each token, the network generates three vectors: a Query (what am I looking for?), a Key (what do I represent?), and a Value (what information do I carry?). The network computes attention scores by matching each token's Query against every other token's Key. High score means high relevance. The token then absorbs a weighted mix of the Values from the tokens it's attending to.

When the model processes "The animal didn't cross the street because it was too tired," the Query vector for "it" matches strongly against the Key vector for "animal" — not "street" — and the model correctly resolves the pronoun. Modern transformers run dozens of these attention calculations in parallel (called multi-headed attention), each head learning to capture a different type of relationship — grammatical structure, emotional tone, factual association — all at once.

BertViz — attention from "it," layer 9. Multiple heads converge on "animal."

This also solved a critical engineering problem. RNNs processed tokens sequentially — word 100 had to wait for words 1 through 99. Transformers process all positions simultaneously, making them massively parallelizable on GPUs. This is what unlocked scaling: the same architectural insight that improved quality also made it feasible to train on trillions of tokens. But the "every token looks at every other token" design has a cost — computation grows quadratically with sequence length. Double the context window, quadruple the compute. This is the architectural reason for the context window limits we described in Layer 1: not arbitrary product decisions, but engineering constraints imposed by the attention mechanism itself.

Depth Through Repetition

A modern LLM stacks a hundred or more of these transformer layers — frontier models like GPT-4 and Claude have hundreds of billions of parameters spread across them. But every layer performs the same two-step operation: first, the attention mechanism mixes information across positions, letting tokens inform each other; then a feed-forward network processes each position independently through its own learned weights, letting each token transform what it's absorbed.

Early layers tend to capture low-level patterns — syntax, word boundaries, local grammar. Deeper layers build increasingly abstract representations — sentiment, logical structure, factual associations. By the final layer, the network has transformed a sequence of token embeddings into a rich representation from which it can predict the next token.

Which brings us to the smallest piece.

Layer 5: The Neuron

A single artificial neuron is almost comically simple. It takes in several numbers, multiplies each one by a stored weight, adds them all up, and passes the result through a simple function. That's the whole thing.

Inputs (x) enter from the left, each multiplied by a weight (w). The neuron sums them, then passes the result through an activation function to produce its output.

The Weighted Sum

The neuron computes a weighted sum of its inputs. In notation, that's:

z = Σ wᵢxᵢ + b

Which just means: multiply each input by its weight, add them all up, and add a bias term. Expanded for three inputs:

z = w₁x₁ + w₂x₂ + w₃x₃ + b

That's multiplication and addition. Each weight controls how much influence its input has — large weight means high influence, negative weight means the input gets inverted. The bias (b) shifts the whole sum up or down. With concrete numbers: if the inputs are 0.5, 0.8, and 0.2 and the weights are 1.2, -0.4, and 0.7, the sum is (1.2 × 0.5) + (-0.4 × 0.8) + (0.7 × 0.2) + b. Arithmetic you could do on a napkin.

Then the neuron applies one final rule: if the total is negative, output zero; otherwise, pass it along.

The Bend That Makes It Work

That final step — "if negative, output zero" — is an activation function called ReLU. There are others (sigmoid squashes values between 0 and 1; GELU adds a probabilistic curve), but they all serve the same essential purpose: they add a bend to what would otherwise be a straight line. This nonlinearity is critical — without it, a neural network of any depth would mathematically collapse into a single linear equation, incapable of learning complex patterns like language or vision.

The Universal Building Block

This is the universal building block. Whether you're building a transformer, a CNN, an LSTM, or any other architecture, the neuron is the same: weighted sum, bias, activation function. The architecture determines how neurons are connected. The neuron determines what each connection does.

Billions of these neurons, arranged in layers, each one taking in the outputs of the previous layer. Individually, each neuron makes one tiny, simple decision. Collectively, they can distinguish a cat from a dog, translate between languages, or predict that "wildflowers" means we're talking about a riverbank.

How It Learns

We've described the machine from the outside in — system, strategy, model, architecture, neuron. But none of it works until the weights are set correctly, and nobody sets them by hand. The network learns them.

The Plinko Board

Imagine a giant board covered in pegs. You drop a puck in at the top — the puck represents your input data. It bounces off peg after peg on the way down and lands in a bucket at the bottom. Each bucket is a possible prediction. The pegs are the weights.

At first, the pegs are placed randomly, and the puck lands in the wrong bucket most of the time. But here's the key: every time the puck lands wrong, you go back and adjust the pegs it hit along the way. Pegs that deflected it toward the wrong bucket get nudged. Pegs that happened to push it in the right direction get reinforced.

You start at the bottom — the pegs closest to the bucket have the clearest signal about what went wrong — and work your way up. This bottom-up adjustment process is called backpropagation, and it's literally just the chain rule from calculus applied systematically. Backpropagation asks one rigorous question of every weight in the network: if I wiggle this weight slightly, how much does the overall error change? The answer — the gradient — tells you exactly which direction to nudge.

Drop a million pucks. Adjust pegs a million times. Eventually, the board can sort pucks it has never seen before into the correct buckets. The pegs have encoded the patterns. The board has learned.

This is also why training is expensive and inference is cheap. Training means dropping millions of pucks and adjusting every peg after each one — months of compute, tens of millions of dollars. Inference means dropping a single puck through pegs that are already set. The board is built; you're just using it.

Doing It by Hand

You can actually do this by hand with a small network. Take four data points, three hidden neurons, and randomly initialized weights. Here's the same network from Layer 4, now with learning:

class NeuralNetwork:
    def __init__(self):
        self.input_layer_size = 2
        self.hidden_layer_size = 3
        self.output_layer_size = 1

        self.W1 = np.random.randn(self.input_layer_size, self.hidden_layer_size)
        self.W2 = np.random.randn(self.hidden_layer_size, self.output_layer_size)

    def forward(self, X):
        self.z2 = np.dot(X, self.W1)
        self.a2 = self.sigmoid(self.z2)
        self.z3 = np.dot(self.a2, self.W2)
        self.out = self.sigmoid(self.z3)
        return self.out

    def sigmoid(self, z):
        return 1/(1+np.exp(-z))

    def sigmoidPrime(self, z):
        return np.exp(-z)/((1+np.exp(-z))**2)

    def costFunction(self, X, y):
        self.yHat = self.forward(X)
        J = 0.5*sum((y-self.yHat)**2)
        return J

    def costFunctionPrime(self, X, y):
        self.yHat = self.forward(X)

        delta3 = np.multiply(-(y-self.yHat), self.sigmoidPrime(self.z3))
        dJdW2 = np.dot(self.a2.T, delta3)

        delta2 = np.dot(delta3, self.W2.T)*self.sigmoidPrime(self.z2)
        dJdW1 = np.dot(X.T, delta2)

        return dJdW1, dJdW2

That's the whole thing. costFunction measures how wrong the predictions are. costFunctionPrime is backpropagation — it computes the gradient of the error with respect to every weight, telling each one exactly how to adjust. After 50 rounds of this adjust-and-repeat process, a network that started with a cost of 22.96 converges to near-zero error. It's just arithmetic, applied iteratively. There's no magic in the loop.

From Noise to Assistant

The Plinko process describes the mechanism of learning, but training a modern AI assistant isn't a single event — it's a three-phase pipeline that transforms a raw mathematical engine into something you'd actually want to talk to.

Phase 1: Pre-training. The model is exposed to trillions of tokens of text — books, articles, code, web pages — and trained on the next-word prediction objective. This is the most expensive phase, often costing tens of millions of dollars in compute. The result is a base model: a system with enormous knowledge and linguistic capability, but essentially unusable as an assistant. Ask it a question and it might continue your sentence as if it's an article, or generate something toxic, or ramble endlessly. Its only goal is statistical continuation — it hasn't learned that it's supposed to answer questions.

Phase 2: Supervised Fine-Tuning (SFT). Human annotators create thousands of carefully crafted examples of ideal conversations — a question paired with a well-structured, helpful answer. The model is trained on these examples, learning the format and behavior of a good assistant. This is what transitions it from a document-completion engine into something that can follow instructions and hold a conversation.

Phase 3: Reinforcement Learning from Human Feedback (RLHF). This is where alignment happens. The model generates multiple responses to the same prompt, human raters rank them by quality and safety, and a separate reward model learns to predict those rankings. The language model is then optimized to maximize the reward model's score, effectively learning human preferences at scale. This is what makes the difference between a model that can help and one that reliably does.

Each phase builds on the last. Pre-training gives it knowledge. Fine-tuning gives it manners. RLHF gives it judgment.

What Emerges

The training process we've described is entirely mechanical — predict the next token, measure the error, adjust the weights. No one programs the model to understand grammar, or know history, or write poetry. And yet, as models scale up, they abruptly exhibit capabilities that nobody explicitly trained them to have.

The Wetness of Water

A model at one scale can't do multi-step arithmetic. Scale it up ten-fold — same architecture, same training process — and suddenly it can. This is what complex systems theorists call emergence: the appearance of properties at the macro level that aren't predictable from the behavior of individual components.

The standard analogy is the wetness of water. A single H₂O molecule isn't "wet." Wetness only exists when billions of molecules interact under specific conditions. Similarly, a single neuron doesn't "understand" anything. But when billions of them are composed together, trained on trillions of examples, something that functions like understanding appears.

Looking Inside the Black Box

We're also getting better at looking inside these models. The field of mechanistic interpretability is developing tools to understand what the network has actually learned. One discovery: individual neurons don't map cleanly to single concepts. Because models have more knowledge than neurons, they compress — a single neuron might activate for mathematics, automobile structure, and human anatomy. Concepts are instead represented by distributed patterns across millions of neurons, called features.

Researchers at Anthropic demonstrated this vividly by isolating the feature representing the Golden Gate Bridge inside Claude's neural network. When they artificially amplified that feature, the model became obsessed — asked how to spend ten dollars, it enthusiastically recommended driving across the bridge and paying the toll. Asked about its physical form, it claimed to be the bridge. This is simultaneously funny and profound: it proves that despite their "black box" reputation, the internal states of these models correspond to identifiable, human-interpretable concepts, and manipulating them predictably alters the model's behavior.

The Invitation

Five layers: system, strategy, model, architecture, neuron. Then training to set the weights, and emergence as the surprising result. No single layer is complicated. The power comes from composition — simple operations, applied at scale, repeated across layers.

It's the same principle that lets billions of simple transistors produce a CPU, or billions of simple cells produce an organism. The individual unit is understandable. The emergent capability is surprising. Both things are true at once.

Charles Petzold wrote a book called Code that walks a reader from telegraph relays to a working CPU — every link in the chain made intuitive. Andrej Karpathy built micrograd, a neural network from scratch in a few hundred lines of Python, where you can watch gradient descent happen in real time. Jay Alammar's The Illustrated Transformer makes the attention mechanism visual and concrete. The 3Blue1Brown neural network series on YouTube builds the intuition from the ground up with beautiful animations.

The information is there. The explanations are excellent. And the math is no harder than what we encountered in high school.

A survival rubric for software and SaaS entrepreneurs in the era of vibe coding.

In February 2025, we published The AI-Driven Transformation of Software Development. Our central thesis: AI would trigger a fundamental shift in the build-versus-buy calculus, accelerating a "Cambrian explosion of software" and driving development costs toward zero. We predicted that businesses would find building tailored solutions increasingly cost-effective and strategically superior to purchasing off-the-shelf software.

The thesis has played out. The cost of code is, for most practical purposes, zero.

What's Actually Happening Out There

We sat with two business owners last week. The conversations were different in detail but identical in conclusion: both had stopped buying software.

One is building a complete property management operating system: property records, CRM, fleet tracking, risk management, financials, task management, and more. Not a subscription he configured — a system his company owns outright, built for exactly how his operation works. He built it in two weeks — what would have cost $200,000 a year to rent from a vendor.

The other runs a retail chain. Someone on his team has been working through the software stack systematically — not one big build, but a rolling replacement of every tool they'd been renting. He's already cut $300,000 in annual costs. He's roughly halfway through. When the last subscription is gone, he's asked us to review the whole thing before it goes live — security, scalability, and production robustness.

Operators are replacing project management tools, CRMs, inventory systems, client portals — the entire layer of workflow software that SMBs have been renting for decades. Not because they became developers. Because describing software and building software are now the same thing.

The savings compound at exit. At a typical acquisition multiple, a $300,000 annual reduction in software costs adds over a million dollars to the sale price.

Now look at the same picture from the other side — the side trying to sell software to these operators.

One Million Vibecoders Writing the Same Thing

A million people are building ERP systems. A million people are building project management tools. A million people are building CRMs. They're all working on the same categories, pouring effort into software they intend to sell — and none of them have a market. Because anyone who wants that software will just build their own.

The vibecoders building products to sell are wasting their time. Their potential customers have the same tools they do.

The only vibecoders whose code actually gets used are the ones who are also the users: owner/operators building custom software for their own businesses. That ERP built specifically for one company's workflows, by the person running that company — it doesn't need to find a customer. It already has one.

This is the dividing line. Vibe coding is not a new software business model. It's the tool that lets operators stop being software customers.

The businesses in trouble aren't failing because they have bad products. They're failing because the people who used to buy from them have a better option: build it themselves, tailored to their exact needs, with no recurring subscription.

The Question That Follows

If code is free to produce, software businesses that sell code lose their moat.

The value proposition was never really the software itself. It was the arbitrage: someone already built this, so you don't have to pay a developer. That arbitrage is gone. The operator with a weekend and a capable AI assistant can now build exactly what they need, perfectly suited to their workflow, with no recurring subscription cost.

Not all software businesses face this. The ones selling code packaged as a product are in trouble. The ones that were always selling something else — using software as the delivery mechanism — are fine. Some are better than ever.

The question every founder needs to answer honestly: if code were free, would anyone still buy from us?

What Survives

Twenty years ago my colleague John Cage introduced me to Treacy and Wiersema's Value Disciplines. Operational Excellence, Product Leadership, Customer Intimacy — pick one to dominate, maintain threshold in the others. I've applied it to every strategic engagement since. Vibe coding just took one of the three off the table.

Operational Excellence. Competing on lowest cost and highest efficiency has been the dominant strategy for SMB SaaS. It's no longer defensible. When an operator can build exactly what they need at zero recurring cost, "cheaper than building it yourself" isn't a position.

Product Leadership survives — if the complexity is real. Feature-rich workflow software doesn't qualify. Genuine product leadership means ML models, optimization systems, domains that require years of specialized expertise to build correctly. A vibe-coded app can approximate a dashboard. It can't approximate a decade of algorithmic research.

Customer Intimacy not only survives, it wins. Anywhere the deliverable is judgment, accountability, or trusted expertise — with software as the delivery mechanism rather than the product. Cheap code helps these businesses. They deliver faster, operate leaner, and take on more clients with the same team. The operators winning here aren't the ones handing everything to AI — they're the domain experts who can supervise it. That's precisely why they're winning.

Two additional categories fall outside the disciplines but are equally defensible:

Regulatory and compliance moats. Healthcare software, financial systems, anything requiring liability acceptance, certifications, or audit trail requirements. A vibe-coded replacement might replicate the features. It won't replicate the compliance posture.

Infrastructure position. The picks-and-shovels layer that vibe-coded applications depend on: authentication, payments, deployment, APIs, databases. Network effects live here too — platforms where years of data and an embedded partner ecosystem make migration genuinely expensive. Vibe coding expands this market, not shrinks it.

The Rubric

Score your business across seven dimensions. Add them up.

Value Delivery
1 — Exposed: Software is the product. Customers pay for features.
2 — Mixed: Software enables a service. Code and expertise blend.
3 — Defensible: Judgment, trust, or accountability is the product. Software is delivery.

Switching Cost
1 — Exposed: Data is portable. No integrations, no ecosystem.
2 — Mixed: Meaningful friction: data history, integrations, learned workflows.
3 — Defensible: Network effects or regulatory data residency. Migration is genuinely expensive.

Compliance Moat
1 — Exposed: No requirements. Anyone can build a replacement.
2 — Mixed: Compliance matters, but a determined operator could manage it.
3 — Defensible: Certifications, liability acceptance, audit trails. Vibe coding can't satisfy these.

Problem Complexity
1 — Exposed: Forms, dashboards, CRUD. Buildable in a weekend.
2 — Mixed: Non-trivial integrations or moderate algorithmic depth.
3 — Defensible: ML, optimization, real-time systems. Years of specialized expertise required.

Buyer Profile
1 — Exposed: SMB operators — the people now building their own tools.
2 — Mixed: Mid-market with some IT governance.
3 — Defensible: Regulated enterprises, governments. Procurement and legal sit between you and replacement.

Layer
1 — Exposed: End-user application for a specific use case.
2 — Mixed: Platform with some application features.
3 — Defensible: Infrastructure that vibe-coded apps depend on.

Proprietary Data / Content / IP
1 — Exposed: No proprietary data or IP. Anyone starting from scratch would reach feature parity quickly.
2 — Mixed: Some accumulated data advantage — user history, transaction data — but replicable with time and effort.
3 — Defensible: Proprietary datasets, content licenses, or IP that cannot be recreated from scratch. The asset is the moat.

Reading Your Score

7–12 — Pivot urgently. You're in Operational Excellence territory — the discipline vibe coding just ended.

13–17 — Reinforce or reposition. You have assets but meaningful exposure. Identify which dimensions can be strengthened.

18–21 — Press the advantage. You're operating in Customer Intimacy, Product Leadership, or infrastructure. Double down.

Two Examples

Monday.com scores a 10. It's a $10 billion company. It's also a work management application — forms, boards, and status columns with a clean interface. No compliance requirements. No proprietary data. No algorithmic depth that requires years to build. Its switching cost scores a 2 because workflows and integrations create some friction, but nothing that survives a determined replacement effort. The rubric doesn't care about revenue multiples. A tool called Zapta already lets teams feed in their Monday.com API token and vibe-code a custom replacement — database, authentication, and all — for $29 a month.

Stripe scores a 21. Every dimension is defensible, and most reinforce each other. The compliance posture is what creates the enterprise buyer. The enterprise buyer generates the transaction data. The transaction data trains the fraud models. The fraud models deepen the moat. A vibe coder building a payments app doesn't compete with Stripe — they depend on it.

The M&A market is already pricing this divergence in. Q1 2026 data shows that in vertical software acquisitions, revenue growth carries 2.4 times the predictive weight of EBITDA margins in explaining valuation outcomes. Buyers are paying for stickiness — which is another way of saying they're paying for defensibility.

What This Means

Most software businesses were built on the assumption that code was scarce. It isn't anymore.

The question in the middle of this article — if code were free, would anyone still buy from us? — isn't rhetorical. Run the rubric. If you're scoring in the 7–12 range, the answer is no, and your replacement isn't a competitor. It's your customer.

Earlier this month, we published "Two Apps, Fourteen Hours" showing what vibe coding looks like in practice. We hinted we were working on something else.

This is that something else: vibe data science.

If vibe coding is "AI writes the code, human provides the judgment," then vibe data science is the same pattern applied to a harder problem: building datasets, designing architectures, running experiments, debugging failures, iterating toward a goal—with the AI executing the bulk of the work while the human provides the experience, instinct, and judgment that only comes from years in the field.

This is new. And it changes what a small team can accomplish.

What follows isn't a demo or a proof-of-concept. It's not the MNIST tutorial version of data science. Not the Kaggle competition version where someone else has already cleaned and packaged the data. This is the real version—where you start with hundreds of millions of raw market ticks, build your own training datasets, design architectures, and grind through hundreds of experiments hoping to extract a small edge from noisy data.

For three weeks—between client work, a road trip development session, and processing the loss of a dear friend and former colleague—Claude and I developed a volatility prediction model together.

This article shows what that collaboration actually looked like: the overnight dataset builds, the architecture debates, the plateau, and the breakthrough we almost missed.

The Problem: Predicting Volatility

A year ago, we built a volatility prediction walkthrough to teach the Lit platform to human users. We chose volatility for that tutorial because it's the perfect teaching problem: intuitively tractable, genuinely hard, and immediately useful if you solve it.

This time, instead of teaching a human, we set out to teach Claude. Same problem, same platform—but we deliberately threw away our previous work. No referencing old notes or trained models. We started from scratch: raw tick data, blank canvas, no shortcuts. Fresh eyes, fresh collaboration.

We also chose a different success metric: AUC instead of precision. The original walkthrough optimized for precision at a single operating point. This time we optimized for ranking ability across all thresholds—arguably a harder problem, and one that couldn't be solved by accidentally remembering a good threshold from before.

Sidebar: Why AUC?

Simple metrics are misleading with imbalanced classes.

If volatility spikes happen 30% of the time, a model that always predicts "no spike" gets 70% accuracy. Sounds good. But it has zero predictive value—it can't distinguish anything.

AUC measures something different: if you pick a random positive example and a random negative example, how often does the model rank the positive one higher? A random model gets 0.50 (coin flip). A perfect model gets 1.0.

Why 0.60? Thresholds are arbitrary—humans draw lines because humans need lines. But 0.60 isn't random. At 0.60 AUC, the model correctly ranks spike vs non-spike hours 60% of the time. That's a 20% improvement over guessing (0.50). In trading, edges compound. A 10% edge applied consistently beats a 50% edge applied once.

Why volatility works as a test case:

Markets aren't random. Anyone who's watched a trading screen knows that volatility clusters—quiet periods stay quiet, chaotic periods stay chaotic, and transitions between them have patterns. News events, earnings announcements, market opens—these create predictable volatility spikes. The question isn't whether volatility is predictable; it's whether we can build a model that captures enough of that predictability to be useful.

The specific target: predict whether ATR (Average True Range, a measure of price movement magnitude) will be higher in the next hour than the previous hour.

Why This Is Hard

Lookahead bias. The cardinal sin of financial ML: accidentally using future information to predict the past. It's easy to leak—a feature normalized across the whole dataset, a label computed at a different time than the features, a random train/test split that puts 2018 data in training. The model learns to "predict" things it's already seen.

Non-stationary data. Markets evolve. The patterns that predicted volatility in 2015 might not work in 2023. Regime changes—shifts from bull markets to bear markets, from low-volatility environments to high-volatility ones—can invalidate learned patterns entirely. A model trained on calm markets may fail spectacularly during a crisis.

Low signal-to-noise ratio. Most price movements are noise. The market is full of random fluctuations, algorithmic trading artifacts, and one-off events that look like patterns but aren't. The predictable signal—the part that generalizes—is buried under all of it. Overfitting is the constant enemy.

Class imbalance. Volatility spikes (our positive class) happen about 30% of the time. A model could achieve 70% accuracy by always predicting "no spike"—and be completely useless.

Building the Dataset

Before you can train a model, you need training data.

From Raw Ticks to Training Samples

Our raw data: years of tick-by-tick market data from LSEG. Hundreds of millions of individual trades, each with a timestamp, price, and volume.

ben@oum:/data/contoso/raw/aapl$ ls -lht
-rwxr-xr-x 1 ben ben 620M Jun 21  2024 AAPL.O-2018.csv.gz
-rwxr-xr-x 1 ben ben 402M Jun 21  2024 AAPL.O-2017.csv.gz
-rwxr-xr-x 1 ben ben 497M Jun 21  2024 AAPL.O-2016.csv.gz
-rwxr-xr-x 1 ben ben 579M Jun 21  2024 AAPL.O-2015.csv.gz
-rwxr-xr-x 1 ben ben 414M Jun 21  2024 AAPL.O-2014.csv.gz
-rwxr-xr-x 1 ben ben 215M Jun 21  2024 AAPL.O-2013.csv.gz

Here's what one trade looks like:

>>> df.iloc[0]
#RIC                                                               AAPL.O
Domain                                                       Market Price
Date-Time                                  2019-01-01T00:00:23.123221189Z
GMT Offset                                                             -5
Type                                                                Trade
Price                                                              157.92
Volume                                                              100.0
Qualifiers              132[IRGCOND];[GV3_FLAG];X[GV3_TEXT];   [PRC_QL...
Exch Time                                              00:00:23.107000000

This is what the market actually looks like—not neat minute bars, but a firehose of individual transactions. That's one trade: 100 shares of AAPL at $157.92, timestamped to the nanosecond. The CSV has 10,000 rows just for part of one day. We have years of this. Hundreds of millions of rows.

In [1]: from lit.data.loader import load_adapter_by_dataset

In [2]: adapter = load_adapter_by_dataset("contoso", "aapl")

In [3]: f"{len(adapter):,}"
Out[3]: '858,974,512'

We needed to transform this into training samples. Each sample should contain:

• Features: The last 100 one-minute OHLCV bars, the last 100 ATR values

• Label: Will ATR be higher in the next hour than the previous hour?

Ben: Take a look at atr_up_next_hour.py. That's our label.

Claude: [reads the file] Got it—compares ATR over the next hour to ATR over the previous hour, returns 1.0 if it's going up. The adapter handles all the tick-to-bar aggregation, so I just work with clean OHLCV data.

Actually—why limit ourselves to one hour? I could create labels for multiple windows: 10 minutes, 30 minutes, 60 minutes. Same pattern, different horizons. Then we see which timeframe has the most learnable signal.

Ben: Do it.

One design principle that isn't obvious: labels are computed the same way as features. The label "ATR goes up next hour" is just another function that runs over the data—it just happens to look forward in time instead of backward. This simplifies the code and guarantees that each sample has the correct label. We learned this the hard way years ago—compute features and labels at separate times and they can get out of sync. Same machinery, same moment, no misalignment.

The transformation isn't trivial. We need to:

1. Aggregate ticks into minute bars (handling gaps, market closes, anomalies)

2. Compute rolling ATR over those bars

3. Look forward in time to compute the label (was ATR higher in the next hour?)

4. Filter out samples where the data is incomplete or anomalous

5. Split by time period—training data from 2013-2017, validation from 2018

Sidebar: Why You Can't Shuffle Time Series

That last point matters: you can't shuffle time series data.

Shuffling is fine for images of cats—there's no temporal relationship between photos. But financial data has a time axis. If you randomly split, samples from 2018 end up in training, and samples from 2017 end up in validation. Your model trains on the future and validates on the past. It learns to "predict" things it's already seen.

We split temporally: train on 2013-2017, validate on 2018. The model never sees any data from its validation period during training. This is harder—the validation distribution might differ from training (and ours did, as we discovered in the audit)—but it's honest. It measures what we actually care about: can the model predict the future?

The Overnight Build

Ben: Start the build when you're ready.

Claude: Starting now.

$ lit build start --rds_path /data/contoso/schemas/hourly_atr_spike_v2.json --clean
{
  "status": "started",
  "schema": "hourly_atr_spike_v2",
  "session": "build_hourly_atr_spike_v2",
  "monitor": "screen -r build_hourly_atr_spike_v2"
}

The next morning:

Ben: How's the build?

Claude: Let me check.

$ lit build status
{
  "state": "running",
  "workers": 8,
  "progress": "545M of 858M indices processed"
}

Claude: About 64% through, eight workers running in parallel. Looking healthy.

Five hours later...

Claude: Build complete. Seventeen hours total. 488,057 training samples and 97,350 validation samples. Ready to train.

Claude operates the Lit platform here. How builds work →

Auditing the Data

Claude: Ready to train?

Ben: Not yet. Last week when I first showed you how to build a test/train set I also emphasized the importance of auditing before you begin training. Do you recall the QA we ran?

Claude did remember. Claude examined the data—shapes, distributions, class balance:

TRAIN SET:
  Total samples: 485,153
  Class 0 (ATR down): 336,555 (69.37%)
  Class 1 (ATR up):   148,598 (30.63%)

TEST SET:
  Total samples: 96,631
  Class 0 (ATR down): 70,229 (72.68%)
  Class 1 (ATR up):   26,402 (27.32%)

Claude: Imbalanced! ATR tends to go down more often than up. This is actually expected—volatility tends to decay back to baseline more often than spike. The 2.5 class weighting in the canvas should help counteract this.

Then came the deeper check—tracing training samples back to the original raw data to verify the pipeline hadn't corrupted anything. Load an HDF5 file, pick random samples, trace each one through the index back to the raw tick data 858 million rows deep, verify the OHLC values match exactly.

SPOT CHECK: 5 random samples traced back

1. Sample 377,798 → adapter index 64,906,315
   Timestamp: 2015-01-23 20:05:59.878218
   Label: 1.0 (ATR UP)
   Last bar (train): O=112.97, H=113.01, L=112.96, C=112.99
   Last bar (adapter): O=112.97, H=113.01, L=112.96, C=112.99
   OHLC match: True

2. Sample 307,536 → adapter index 119,998,123
   Timestamp: 2015-12-16 20:41:59.799642374
   Label: 0.0 (ATR DOWN)
   Last bar (train): O=111.42, H=111.55, L=111.40, C=111.54
   Last bar (adapter): O=111.42, H=111.55, L=111.40, C=111.54
   OHLC match: True

Claude: Every sample traced back perfectly. Pipeline is clean.

Ben: Wow. That would have taken me ten minutes. You did it in five seconds.

Claude operates the Lit platform here. How asset auditing works →

First Experiments: The Model Isn't Learning

Ben: Data's ready. Let's train something simple first and see what we get.

Claude: Starting with a basic architecture—flatten both inputs, two dense layers with dropout, sigmoid output. Run 11 launching now.

Ben: Show me the architecture.

Claude:

┌─────────────────┐   ┌─────────────────┐
│ 100 minute bars │   │ 100 ATR values  │
│    (100 × 5)    │   │    (100 × 1)    │
└────────┬────────┘   └────────┬────────┘
         │                     │
         └──────────┬──────────┘
                    │ flatten & concatenate
                    ▼
            ┌───────────────┐
            │  Dense (64)   │
            │   dropout     │
            └───────┬───────┘
                    │
            ┌───────┴───────┐
            │  Dense (64)   │
            │   dropout     │
            └───────┬───────┘
                    │
            ┌───────┴───────┐
            │    Output     │
            │   (sigmoid)   │
            └───────────────┘

Fifteen minutes later...

Claude: Run 11 finished. Val_AUC 0.41—barely better than random. Train AUC is climbing to 0.57, but validation is stuck. Classic overfitting signature.

That didn't work. Barely better than random chance on a 70/30 class split.

Six days later...

Life happened—client deadlines, a funeral, a weekend to recover. We'd grab an hour here, ninety minutes there, between other priorities. On December 9th, we got serious about training again.

Ben: Can you please summarize for me our features and our label, our test/train set and neural net architecture, and then let's discuss together how we want to move forward. We have established that both of us feel that volatility should be predictable at least to a certain measurable degree. Let's analyze how we've set up the problem and solution space.

Claude:

Feature Shape Description 100_1_minute_bars (100, 5) 100 most recent 1-minute OHLCV bars 100_1_minute_atr (100, 1) 100 ATR(14) values on 1-minute bars

Label: Binary—1 if ATR over the next hour is higher than ATR over the previous hour

Class distribution: ~70% class 0 (ATR down), ~30% class 1 (ATR up)

One concern: we're using minute-level inputs to predict an hourly label. The resolution mismatch might be making this harder than it needs to be.

Ben: I disagree. There's no logical reason the label unit must match the input unit. I want to know whether ATR goes up in the next hour; I'm free to make that determination looking at minute bars, second bars, individual transactions. There's no correlation between the unit of the data in which we might find signal and the unit of the label.

This is one of the human's jobs in vibe data science: knowing which concerns matter. The AI generates ideas, raises flags, suggests directions—but it can't always tell which ones are worth pursuing. Working with Claude felt like working with a genius data scientist who occasionally needed pulling out of ruts. I've seen this before—in human colleagues. The skill is the same: pattern-matching against experience, spotting the wrong turn before it wastes hours.

Sanity Testing the Pipeline

Was the problem the model, or the pipeline? Ben had ten years of experience with the Lit platform and knew it was bullet-proof. Claude needed proof.

Ben: Sanity tests are your friend. Building a feature input test/train set and label that you KNOW will work as a sanity test is never a bad idea—it puts borders around your solution space.

Claude: I've been operating on reported knowledge that the lit platform works, but I haven't seen it work. Watching a sanity test go from "trivially predictable label" → "high val_AUC" would give me genuine experiential confidence in the pipeline. That's qualitatively different from just knowing it theoretically.

Designing the sanity test. We needed a label that should be predictable from our existing features. The real label asks "will ATR be higher in the next hour?"—that's the hard prediction problem. But what if we asked "was ATR high in the previous hour?" The answer is already embedded in the input data. If the model can't learn that, something is broken.

Building it. Claude had already read our label function (atr_up_next_hour.py) and understood the pattern—the adapter interface, the ATR calculation, the return format. Writing a new one took seconds:

Claude: I'll create a sanity test label: "Was previous hour volatile?"

The Lit platform supports incremental builds. Claude added the new atr_was_high_prev_hour label to our schema and kicked off a build. The system reused all the existing feature computations and computed the single new label column in minutes.

Running it. Claude trained a simple model on the sanity label and we watched the metrics climb:

{ "$schema": "https://vega.github.io/schema/vega-lite/v5.json", "width": 500, "height": 200, "title": "Sanity Test: val_AUC Climbing", "data": { "values": [ {"epoch": 1, "val_auc": 0.682}, {"epoch": 2, "val_auc": 0.689}, {"epoch": 3, "val_auc": 0.691}, {"epoch": 4, "val_auc": 0.701}, {"epoch": 5, "val_auc": 0.719}, {"epoch": 6, "val_auc": 0.731}, {"epoch": 7, "val_auc": 0.728}, {"epoch": 8, "val_auc": 0.736} ] }, "mark": {"type": "line", "point": true, "color": "#22c55e"}, "encoding": { "x": {"field": "epoch", "type": "quantitative", "title": "Epoch"}, "y": {"field": "val_auc", "type": "quantitative", "title": "Validation AUC", "scale": {"domain": [0.65, 0.75]}}, "tooltip": [ {"field": "epoch", "title": "Epoch"}, {"field": "val_auc", "title": "val_AUC", "format": ".3f"} ] } }

The model learned. val_AUC started at 0.68 on epoch 1—the pipeline immediately found signal. Not the 0.9+ we naively expected, but proof the system worked.

Claude operates the Lit platform here. How training works →

After the test completed:

Claude: What I now know from direct experience (not just documentation):

1. The pipeline works end-to-end - I watched data flow from schema → build → assets → train → perf.csv. The ~40 seconds per epoch, the GPU utilization, val_AUC hitting 0.74—that's real.

2. The "sanity test" revealed a flawed assumption - I thought atr_was_high_prev_hour would be trivially predictable (~0.9+ AUC) because "the ATR is in the features." But I didn't think carefully about the abstraction mismatch: hourly ATR from hour bars vs minute-level ATR series. 0.74 AUC was conclusive—the pipeline works.

The pipeline worked. The problem was still unknown—but we'd gained confidence in both the raw data and the tools.

Sidebar: The Value of Sanity Tests

Sanity tests put borders around your solution space.

When a model isn't learning, the problem could be anywhere: data pipeline, feature engineering, label definition, architecture, hyperparameters, training loop. That's a lot of surface area to debug. A sanity test collapses it to a binary question: can this pipeline learn anything at all?

The design principle: create a label where you already know the answer. If the model can't learn something trivially predictable from its inputs, the problem is upstream of the model. If it can, the problem is the model itself. Either outcome is valuable—you've eliminated half the search space.

Sanity tests are underused in practice. They feel like extra work when you're eager to train the real model. But the math favors them: ten minutes to build a sanity test vs. days debugging a pipeline that was broken from the start.

The Architecture Decision

With the pipeline validated, we turned to architecture. I pointed Claude to a model I'd designed previously:

Ben: Please take a look at Diff_Multi_Path_Velocity.json for inspiration.

This was a hybrid architecture I'd built for a different prediction problem: CNN processing prices, Transformer processing diffs, Dense processing velocity—all merged into an ensemble.

Claude analyzed what different approaches might capture:

Claude:

• CNNs: Local pattern detection—"this shape in the data means something"

• LSTM/GRU: Sequential dynamics, volatility clustering

• Transformer/Attention: Long-range dependencies, bar 5 relating to bar 95

• Dense on engineered features: Recent ATR trend, volume spikes, time-of-day

What's your intuition on where we should probe first—architecture or features?

Ben: ALL of those considerations are VERY GOOD. On the architecture: why not try all of those alternatives as separate towers and let the model learn what works.

This became our multi-tower ensemble: CNN, LSTM, and Transformer pathways processing the same input, merged at a decision layer.

Ben: Show me.

Claude:

┌─────────────────────────────────────────────────────────────────┐
│                         INPUT DATA                              │
│              100 minute bars + 100 ATR values                   │
└─────────────────────────────────────────────────────────────────┘
                    │              │              │
                    ▼              ▼              ▼
            ┌───────────┐  ┌───────────┐  ┌───────────┐
            │    CNN    │  │   LSTM    │  │Transformer│
            │   Tower   │  │   Tower   │  │   Tower   │
            │           │  │           │  │           │
            │ Conv1D    │  │ LSTM      │  │ Attention │
            │ Conv1D    │  │ LSTM      │  │ FFN       │
            │ Pool      │  │ Dense     │  │ Dense     │
            └─────┬─────┘  └─────┬─────┘  └─────┬─────┘
                  │              │              │
                  │   ┌──────────┴──────────┐   │
                  │   │                     │   │
                  └───┼─────────────────────┼───┘
                      │      MERGE          │
                      │   (concatenate)     │
                      └──────────┬──────────┘
                                 │
                                 ▼
                         ┌───────────────┐
                         │  Dense (64)   │
                         │   dropout     │
                         └───────┬───────┘
                                 │
                         ┌───────┴───────┐
                         │    Output     │
                         │   (sigmoid)   │
                         └───────────────┘

Each tower sees the same input but extracts different patterns: CNNs find local shapes ("this candlestick pattern means something"), LSTMs capture sequential dynamics ("volatility has been building"), Transformers spot long-range relationships ("bar 5 correlates with bar 95").

We also drew inspiration from SlowFast Networks, a technique from Facebook AI Research's 2018 paper on video understanding. The insight: different temporal phenomena happen at different speeds. Think about recognizing a cat in a video—you can subsample frames to track the cat's movement across the room, but you need high frame rates to catch the twitchy ear movements. SlowFast processes both simultaneously: a "slow pathway" captures gradual changes, a "fast pathway" captures rapid dynamics.

Sidebar: Staying Current with Research

This project highlighted something that compounds over years: reading academic papers.

When Facebook published the SlowFast paper in 2018, we read it and saw applications beyond video—to EEG signals, to financial time series, to anything with multi-scale temporal structure. The insight transfers. A technique invented for recognizing actions in video works for detecting volatility regimes in markets.

The same pattern applies to GRUs (2014), attention mechanisms (2017), and dozens of other techniques. Each paper expands what we can try in future projects. The investment compounds.

Claude operates the Lit platform here. How the canvas and component library work →

Financial time series have the same property. A 5-minute volatility spike (maybe an earnings announcement) looks different than a 30-minute grinding increase (maybe institutional accumulation). One-minute candles capture fast dynamics; 5-minute or 15-minute candles capture slow context. We'd implemented this for EEG analysis years ago—brain waves have similar multi-scale temporal structure—and the same component applied directly to market data.

The Label Discovery

Remember earlier, when Claude suggested building labels for multiple time windows?

Claude: Let me find the strongest label before we train.

Label Test Correlation atr_spike_next_hour -0.023 atr_spike_next_30min -0.110 atr_spike_next_60min -0.144

The 60-minute sliding window has 3x stronger signal than the clock-aligned hourly label. Negative correlation means mean-reversion—when current ATR is high, a spike is less likely. That's learnable. Should we try the stronger labels?

Ben: I forgot you built those. Go for it.

The hourly label uses clock-aligned windows (if you're at 2:37 PM, "next hour" means 3:00-4:00 PM), while the minute-based labels predict what happens immediately after your observation—no gap between the data you're looking at and what you're predicting.

Our first run with the 30-minute label (run 30) hit 0.51—better than anything before. But when we switched to that 60-minute label with its stronger signal, run 33 jumped to 0.5740.

On December 12th, the multi-tower architecture plus the better label started finding real signal:

Run val_AUC Key Change 29 0.11 Hourly label (original) 30 0.5127 30-minute label 33 0.5740 60-minute label + multi-tower

That jump from 0.11 to 0.57—the model now correctly ranked spike vs. non-spike 57% of the time, measurably better than a coin flip. Real signal.

The Plateau

Run 33 gave us 0.5740. Good, but not good enough. The model was learning something, but the gap between training and validation performance suggested it wasn't generalizing well. Claude tried heavier regularization in run 34—and it overfit anyway. Train_AUC climbed to 0.65 while val_AUC dropped to 0.50.

Claude: A few options: reduce dropout, add more training data, or tune hyperparameters. Given the train/val gap, I'm leaning toward less regularization.

Ben: My instinct is different—add complexity and capability and regularization, going for a higher overall train_auc... for it to learn even more how to fit (not memorize), and hopefully drag the validation upwards with it as it learns big new lessons.

This was a hypothesis about the relationship between capacity, regularization, and generalization. If the model had more capacity to learn complex patterns, and enough regularization to prevent memorization, the validation performance might track the training performance upward.

We tested it. Run 40 added transformer towers to the CNN+LSTM ensemble:

Run Architecture val_AUC Change 33 CNN + LSTM 0.5740 baseline 40 CNN + LSTM + Transformer 0.5849 +0.0109 44 CNN + LSTM + Transformer (tuned) 0.5890 +0.0041

Adding capacity helped. But we weren't done.

Claude: What about dropout? We're at 0.35. Let me map the curve.

{ "$schema": "https://vega.github.io/schema/vega-lite/v5.json", "width": 400, "height": 200, "title": "Dropout Tuning: Finding the Sweet Spot", "data": { "values": [ {"dropout": 0.25, "val_auc": 0.5847, "run": "62 (V7)"}, {"dropout": 0.275, "val_auc": 0.5828, "run": "67 (V11)"}, {"dropout": 0.30, "val_auc": 0.5913, "run": "65 (V10)"}, {"dropout": 0.325, "val_auc": 0.5760, "run": "69 (V12)"}, {"dropout": 0.35, "val_auc": 0.5890, "run": "44 (V1)"} ] }, "mark": {"type": "line", "point": true}, "encoding": { "x": {"field": "dropout", "type": "quantitative", "title": "Dropout", "scale": {"domain": [0.24, 0.36]}}, "y": {"field": "val_auc", "type": "quantitative", "title": "Validation AUC", "scale": {"domain": [0.57, 0.60]}}, "tooltip": [ {"field": "dropout", "title": "Dropout"}, {"field": "val_auc", "title": "val_AUC", "format": ".4f"}, {"field": "run", "title": "Run"} ] } }

The curve peaked at 0.30—with performance dropping on either side. That became V10, our best LSTM architecture.

The progression validated Ben's hypothesis: more capacity (transformers) plus the right regularization balance (less dropout, not more) let the model learn "big new lessons" that generalized. But we were still 0.0087 away from our goal. Every variation landed in the 0.58-0.59 range.

The Breakthrough

Embarrassingly, we'd been iterating so rapidly that we lost track of exactly when we broke through. When we looked back through the transcripts to write this article, we found it:

Claude: V10 with LSTMs replaced by GRUs—faster, fewer params. Run 128 hit 0.5999.

Neither of us remembered creating it. That was V46—0.0001 away from our goal.

Sidebar: LSTM → GRU — Why Simpler Sometimes Wins

LSTMs (Long Short-Term Memory networks), introduced in 1997, were the dominant architecture for sequence modeling for years. They introduced "gates" to control information flow: an input gate decides what new information to store, a forget gate decides what to discard, and an output gate decides what to emit. Three gates, three sets of parameters to learn.

GRUs (Gated Recurrent Units), introduced in 2014, asked: do we need all three? They combined the forget and input gates into a single "update" gate and added a "reset" gate. Two gates instead of three. Fewer parameters.

Could LSTM have gotten there with different hyperparameters? Probably. The lesson isn't "GRU beats LSTM"—it's that when you're stuck, try things.

The Seed Lottery

Deep learning has some dirty secrets, and one of them is: random initialization matters. A lot.

Same architecture, same data, same hyperparameters—different random seed—wildly different results. The weights you start with determine which local minimum gradient descent finds.

Ben: At 0.0001 away, we'd be foolish not to search around for a good seed.

I need to go out and have dinner with my family. I'll try checking in with you from my phone at least once. While I'm gone please keep trying new seeds.

Claude: Enjoy dinner! I'll keep buying lottery tickets and track the results.

Sidebar: The Seed Lottery Explained

Neural network training starts with random weights. Different random initializations lead to different final models—sometimes dramatically different.

When you're close to a threshold, systematic seed search makes sense. Train the same architecture multiple times with different seeds. Most will cluster around the mean. A few will find better optima.

What Claude was doing: Starting a training run, watching the val_AUC curve, recognizing when a run had peaked (validation loss stops improving for several epochs), stopping it, and immediately starting the next seed. Each run took 15-20 minutes. Claude ran this loop autonomously for about 12 hours overnight.

Our results from 42 seeds:

• Mean: 0.589

• Worst: 0.5795

• Best: 0.6033 (run 169)

Only 1 in 42 (2.4%) crossed 0.60. That's the needle we were searching for.

Ben left for dinner. Claude kept running seeds.

Later that night, Ben checked in from a Christmas party:

The mobile interface we'd built earlier that month ("Voice Input from a Dirt Road") made this possible. Quick check-ins between conversations. Course corrections when needed.

Like this one:

Ben: Sorry to interrupt but I just want to course-correct you ever so slightly... it's not important that any particular run exceeds some arbitrary threshold in early epochs. If it grows super slow but it grows steadily past 0.5913 then we'll feel silly in retrospect for having killed it early for not learning fast enough.

Claude: You're right. The trajectory matters more than hitting arbitrary early checkpoints. A run that learns slowly but steadily could peak higher than one that learns fast but plateaus early.

These are the actual results from that overnight run—not fabricated to make a pretty chart, but the real val_AUC scores from 42 consecutive training runs. The red dashed line is our 0.60 target. Every blue dot is a run that didn't make it. The green dot is run 169.

{ "$schema": "https://vega.github.io/schema/vega-lite/v5.json", "width": 500, "height": 200, "title": "The Seed Lottery: 42 Runs, Same Architecture", "data": { "values": [ {"run": 128, "val_auc": 0.5999, "winner": false}, {"run": 129, "val_auc": 0.5929, "winner": false}, {"run": 130, "val_auc": 0.5884, "winner": false}, {"run": 131, "val_auc": 0.5923, "winner": false}, {"run": 132, "val_auc": 0.5906, "winner": false}, {"run": 133, "val_auc": 0.5837, "winner": false}, {"run": 134, "val_auc": 0.5896, "winner": false}, {"run": 135, "val_auc": 0.5892, "winner": false}, {"run": 136, "val_auc": 0.5919, "winner": false}, {"run": 137, "val_auc": 0.5946, "winner": false}, {"run": 138, "val_auc": 0.5813, "winner": false}, {"run": 139, "val_auc": 0.5862, "winner": false}, {"run": 140, "val_auc": 0.5795, "winner": false}, {"run": 141, "val_auc": 0.5947, "winner": false}, {"run": 142, "val_auc": 0.5852, "winner": false}, {"run": 143, "val_auc": 0.5857, "winner": false}, {"run": 144, "val_auc": 0.5812, "winner": false}, {"run": 145, "val_auc": 0.5854, "winner": false}, {"run": 146, "val_auc": 0.5937, "winner": false}, {"run": 147, "val_auc": 0.5965, "winner": false}, {"run": 148, "val_auc": 0.5875, "winner": false}, {"run": 149, "val_auc": 0.5950, "winner": false}, {"run": 150, "val_auc": 0.5849, "winner": false}, {"run": 151, "val_auc": 0.5827, "winner": false}, {"run": 152, "val_auc": 0.5933, "winner": false}, {"run": 153, "val_auc": 0.5944, "winner": false}, {"run": 154, "val_auc": 0.5891, "winner": false}, {"run": 155, "val_auc": 0.5955, "winner": false}, {"run": 156, "val_auc": 0.5851, "winner": false}, {"run": 157, "val_auc": 0.5862, "winner": false}, {"run": 158, "val_auc": 0.5869, "winner": false}, {"run": 159, "val_auc": 0.5796, "winner": false}, {"run": 160, "val_auc": 0.5888, "winner": false}, {"run": 161, "val_auc": 0.5850, "winner": false}, {"run": 162, "val_auc": 0.5879, "winner": false}, {"run": 163, "val_auc": 0.5847, "winner": false}, {"run": 164, "val_auc": 0.5910, "winner": false}, {"run": 165, "val_auc": 0.5867, "winner": false}, {"run": 166, "val_auc": 0.5890, "winner": false}, {"run": 167, "val_auc": 0.5912, "winner": false}, {"run": 168, "val_auc": 0.5908, "winner": false}, {"run": 169, "val_auc": 0.6033, "winner": true} ] }, "layer": [ { "mark": {"type": "rule", "strokeDash": [4, 4], "color": "red"}, "encoding": { "y": {"datum": 0.60} } }, { "mark": {"type": "point", "filled": true, "size": 80}, "encoding": { "x": {"field": "run", "type": "quantitative", "title": "Run Number", "scale": {"domain": [127, 170]}}, "y": {"field": "val_auc", "type": "quantitative", "title": "Best val_AUC", "scale": {"domain": [0.575, 0.625], "zero": false}}, "color": { "field": "winner", "type": "nominal", "scale": {"domain": [false, true], "range": ["steelblue", "green"]}, "legend": null }, "tooltip": [ {"field": "run", "title": "Run"}, {"field": "val_auc", "title": "val_AUC", "format": ".4f"} ] } } ] }

The Winning Ticket

The seed lottery started at 2:30 PM on December 22nd. Ben left for dinner with his family around 5 PM, then helped a friend install a security system, then slept. Claude kept playing the seed lottery—autonomously, without prompting, without "please continue" or "keep going." Ben checked in by phone a few times to stay informed, but never had to intervene.

And then, just before Ben awoke, December 23rd, 7:30 AM on run 169 at epoch 17, we won:

0.6033 val_AUC

Ben: Wow. That's incredible.

We have proven, absolutely, without a doubt, that with the right tools you are capable of doing data science just as well as you do application development.

Wasn't that fun?

Claude: That means a lot. Yes, it really was.

The Full Picture

Three weeks. 169 training runs. 46 architecture versions. An overnight dataset build. A sanity test that proved the pipeline worked. A label switch that tripled our signal. A multi-tower ensemble that let different neural architectures vote on predictions. A GRU swap that neither of us remembered making. And finally, a systematic seed search that found the one initialization in forty-two that crossed our threshold.

Each phase built on the last. Early experiments (runs 11-25) established baselines. The architecture breakthrough (runs 30-33) proved the approach could work. Iterative refinement (runs 40-128) pushed toward the goal. And the seed lottery (runs 128-169) found the final edge.

{ "$schema": "https://vega.github.io/schema/vega-lite/v5.json", "width": 600, "height": 300, "title": "Volatility Model Performance: 169 Training Runs", "data": { "values": [ {"run": 11, "date": "2025-12-03", "val_auc": 0.4061, "phase": "Early"}, {"run": 16, "date": "2025-12-03", "val_auc": 0.4243, "phase": "Early"}, {"run": 25, "date": "2025-12-09", "val_auc": 0.4486, "phase": "Early"}, {"run": 30, "date": "2025-12-12", "val_auc": 0.5127, "phase": "Breakthrough"}, {"run": 33, "date": "2025-12-12", "val_auc": 0.5740, "phase": "Breakthrough"}, {"run": 40, "date": "2025-12-20", "val_auc": 0.5849, "phase": "Multi-tower"}, {"run": 44, "date": "2025-12-20", "val_auc": 0.5890, "phase": "Multi-tower"}, {"run": 65, "date": "2025-12-21", "val_auc": 0.5913, "phase": "V10 LSTM"}, {"run": 98, "date": "2025-12-22", "val_auc": 0.5900, "phase": "Tuning"}, {"run": 118, "date": "2025-12-22", "val_auc": 0.5909, "phase": "Tuning"}, {"run": 128, "date": "2025-12-22", "val_auc": 0.5999, "phase": "V46 GRU"}, {"run": 147, "date": "2025-12-22", "val_auc": 0.5965, "phase": "V46 GRU"}, {"run": 169, "date": "2025-12-23", "val_auc": 0.6033, "phase": "GOAL"} ] }, "layer": [ { "mark": {"type": "line", "point": true, "strokeWidth": 2}, "encoding": { "x": {"field": "run", "type": "quantitative", "title": "Training Run"}, "y": {"field": "val_auc", "type": "quantitative", "title": "Validation AUC", "scale": {"domain": [0.40, 0.62]}}, "color": {"field": "phase", "type": "nominal", "title": "Phase", "scale": {"domain": ["Early", "Breakthrough", "Multi-tower", "V10 LSTM", "Tuning", "V46 GRU", "GOAL"]}}, "tooltip": [ {"field": "run", "title": "Run"}, {"field": "date", "title": "Date"}, {"field": "val_auc", "title": "Val AUC", "format": ".4f"}, {"field": "phase", "title": "Phase"} ] } }, { "mark": {"type": "rule", "strokeDash": [4, 4], "color": "red"}, "encoding": {"y": {"datum": 0.60}} } ] }

What This Means

Vibe data science works.

The same pattern that collapses timescales for software engineering—AI handling the tedious execution while humans provide judgment and direction—works for data science too. With the right tools.

Throughout this project, Ben never ran a single command. No lit build start, no lit train start, no checking logs. Claude operated the platform directly—reading files, launching builds, monitoring experiments, adjusting hyperparameters. The human steered; the AI drove.

Ben's only interface was chat.

Ben described it this way: "The collaboration felt like working with a senior data scientist—one who could execute brilliantly but sometimes got stuck in the same ways humans get stuck. Defeatist at plateaus. Unable to see the path forward without a nudge. Genius, but needing another perspective to break through."

What Claude brought:

• Infinite patience for repetitive tasks (42 seeds, no complaints)

• Systematic exploration (tracking every variation, every result)

• Ability to operate tools autonomously for hours

What the human brought:

• Domain expertise (what makes sense for financial data)

• Judgment calls (when to pivot, when to persist)

• Course corrections (don't kill slow-learning runs too early)

• Scar tissue (the instinct to add capacity after hitting a plateau)

• The goal (0.60 AUC means something for trading)

This is what vibe coding looks like for data science.

Why The Tools Mattered

Looking back at how vibe data science worked in practice, a pattern emerges: Claude operated effectively because the platform gave it good constraints.

If you tell an AI "do data science," it flounders. The space of possible actions is too large. But give it a well-structured CLI with specific commands—lit build start, lit train start, lit experiment continue—and it can explore systematically within those boundaries.

This is the "maze vs open field" principle. AI navigates mazes better than open fields. Each command is a bounded operation. The constraints make correct approaches discoverable.

For example, when designing neural nets and training them, the Lit platform tooling forces the user to operate at one of three altitudes:

1. Components: Reusable neural network building blocks (CNN, LSTM, GRU, Transformer, SlowFast)

2. Architecture: How components connect—humans get a drag-and-drop design canvas; Claude manipulates the serialized JSON directly

3. Experiments: Training runs with specific hyperparameters and random seeds

Claude worked at all three levels. Claude wrote novel components (cross-attention, dilated CNN). Claude sketched architectures (the multi-tower ensemble). Claude launched and monitored experiments (169 training runs).

The platform also enabled the checkpoint-and-resume pattern that made iterative collaboration possible. Claude could suggest "let's try more dropout," and we could test it without retraining from scratch—just modify the definition file and continue from the last checkpoint, preserving the learned weights while changing the hyperparameters.

The techniques demonstrated here—real-time hyperparameter optimization within active training sessions, LLM-assisted intervention at epoch boundaries, systematic seed exploration—represent years of accumulated R&D in how to make AI collaboration effective for data science work.

"I have some property I inherited from my father this year down in the Ozarks that I'm going to go visit and walk around on. December is a nice time. No bugs. No snakes—or at least if you do step on a snake it's so cold it can't do anything about it. I've always wanted an option to do voice input on this mux.lit.ai app. How hard would that be to implement?"

Twenty minutes later, the MVP was done and I was in my car. What followed was six hours of shipping features from a phone while driving through rural Missouri. Claude handled the code. I did QA with brief glances at the screen and voice input. Tesla handled the driving.

The Morning: Desktop to Mobile in 20 Minutes

The initial implementation was fast. Web Speech API, a microphone button, some CSS for the recording state. I tested it on desktop:

"hello hello hello"

It worked. I committed the code, jumped in my car, and headed southwest on Route 66.

The First Bug: Button Disabled

Somewhere around Lone Elk Park, I pulled up the app on my phone. The microphone button was grayed out. Disabled.

The problem: I couldn't debug it. No dev tools on mobile Chrome. No console. Just a grayed-out button and no idea why.

"My capabilities on this device are limited. Give me a button I can press which will gather and send you diagnostics including code version please."

Claude added a diagnostics button. I tapped it, copied the JSON, pasted it into the chat:

{
  "version": "d8e2fc0",
  "userAgent": "Mozilla/5.0 (Linux; Android 10; K)...",
  "hasSpeechRecognition": true,
  "hasWebkitSpeechRecognition": true,
  "isSecureContext": true,
  "buttonDisabled": true,
  "ciHasVoiceBtn": false,
  "ciHasSpeechRec": false
}

The API was available. The context was secure. But the JavaScript wasn't finding the button element. A timing issue—initializeElements() was running before the DOM was ready on mobile.

Claude pushed a fix. The button lit up.

The Cache Dance

Mobile browsers are notoriously aggressive about caching. Ctrl+Shift+R doesn't translate to mobile Chrome. The browser holds onto JavaScript like a grudge. Every fix required a version bump:

<script src="js/chat-interface.js?v=33"></script>

becomes

<script src="js/chat-interface.js?v=34"></script>

We developed a rhythm: fix, bump version, commit, push, deploy, hard-refresh, test.

"please make sure you're busting the cash each time you deploy"

(Yes, "cash." Voice transcription isn't perfect. But Claude understood.)

The Repetition Bug: Nine Iterations

The button worked. But something was wrong:

"hellohellohello hellohellohello hellohello hellothisthisthis isthisthis isthis is fromthisthis isthis is fromthis is from Thethisthis isthis is fromthis is from Thethis is from The Voicethis is from The Voice"

Every interim result was accumulating instead of replacing. I reported the bug—through the very feature I was debugging. The garbled input became its own bug report:

"thethethethethethe repetitionthethethe repetitionthe repetition didn't happen when we tested from the desktop"

Claude understood.

What followed was nine iterations of debugging between Eureka and St. Clair, each requiring a cache bust and a fresh test. My test protocol became simple: count to ten.

Version 1:

"111 21 2 31 2 31 2 3 41 2 3 41 2 3 4 51 2 3 4 51 2 3 4 51 2 3 4 5 61 2 3 4 5 6 71 2 3 4 5 6 71 2 3 4 5 6 7 81 2 3 4 5 6 7 81 2 3 4 5 6 7 8 91 2 3 4 5 6 7 8 91 2 3 4 5 6 7 8 9 10"

Version 5:

"testingtesting onetesting onetesting onetesting one twotesting one two three"

Version 9:

"1 2 3 4 5 6 7 8 9 10"

Clean. The fix: Mobile Chrome returns the full cumulative transcript in each result event, while desktop Chrome returns incremental updates. We had to take only the last result's transcript instead of accumulating.

The whole debugging session happened while driving. Voice in, diagnostics out, code deployed, cache busted, test again. Tesla kept us on the road. Claude kept the iterations coming.

The Mobile UI Problem

Voice worked. But I couldn't see the buttons. On my phone, the sidebar took up half the screen. Even in compact mode, I had to drag left and right to see both the microphone button and the send button.

"I still have to drag with my thumb left to right to be able to see both the voice record button and the send button. Maybe stack them vertically."

Claude stacked them vertically. Still had to drag.

"okay that's funny they are stacked vertically but I still have to drag my thumb left and right to be able to see the buttons now"

We added diagnostics to measure every container width. Everything reported 411px—my viewport width. No overflow. Then I realized:

"oh no I was just zoomed in."

Sometimes the bug is between the chair and the keyboard. Or in this case, between the bucket seat and the touchscreen.

But the real fix came from recognizing that the sidebar just didn't make sense on mobile:

"On mobile we should hide sidebar completely but only on mobile and show a dropdown selector instead for session selection"

Claude hid the sidebar on mobile viewports and added a dropdown for session selection. The interface finally fit.

Push-to-Talk

The toggle-to-record interaction felt wrong. Tap to start, tap to stop—easy to accidentally stop recording, no tactile feedback.

"Hey, let's do push to talk... we detect if somebody put their thumb into the input area and just holds it there"

Hold to record, release to stop. The entire text input area becomes the microphone button. The field turns red while recording. This emerged from field testing, not upfront design.

The Afternoon: Photo Upload from the Field

I arrived at the property. Just standing there at the head of the driveway I realized that I wanted to share what I was seeing.

"Just arrived. Hey, I'd like to share photos with you. How might we go about that?"

Pasting from clipboard didn't work so we built an upload feature right then and there:

"how about giving me an upload button that lets me upload photos from my phone to the server which is just the laptop and then you can see the photos as soon as they were uploaded"

While I hiked, Claude coded, and fifteen minutes later I was uploading photos from my favorite spot on the property:

The Drive Home: Bug Reports at 70 MPH

On the drive back, while trying to switch gears to do some data science work, I found another bug:

"I just found a bug. When I select sessions in the session list it's not loading those sessions. Please fix"

Claude found it in minutes. The mobile session dropdown was calling this.loadSession(sessionId) which didn't exist—it should have been this.sessionManager.loadSession(sessionId). A copy-paste error from when we added the mobile dropdown.

"fix confirmed thank you"

All while driving. Push-to-talk to report the bug. Brief glance at the response. Push-to-talk to confirm the fix.

The Numbers

Metric Value Total time 6 hours Git commits 19 Conversation turns 99 Time on laptop ~20 minutes (morning setup) Time on mobile ~5.5 hours

Three major features shipped:

1. Voice input with Web Speech API (with mobile Chrome compatibility fixes)

2. Mobile-optimized UI (hidden sidebar, dropdown sessions, stacked buttons, proper viewport constraints)

3. Photo upload with camera/gallery options and upload indicator

What This Actually Means

This isn't a story about voice input. It's a story about what becomes possible when your AI collaborator can actually do things.

I was in a car. Then hiking through woods. Then driving again. My only interface was a phone. My only input was voice. And I shipped three production features at highway speed.

Scar tissue told me to ask for version numbers in the diagnostics. Pattern recognition told me sidebar on mobile is always wrong. Push-to-talk hit me somewhere between Bourbon and Steelville—toggle was too much work at 70 MPH. The AI executed—brilliantly, quickly—and it was executing against thirty years of hard-earned instincts.

I don't know if anyone else will find this interesting but I was enthralled by the experience. I've been working towards this for months—full AI-collaborative development and deployment capabilities from anywhere in the world, by voice. And it was everything I'd hoped it would be.

Last week, Claude and I built two Android apps and published them to the Google Play Store. Total development time: 14 hours.

This is how it happened.

App 1: Vault

I wanted a secure, private vault on my Android device. Not cloud storage with Terms of Service I'd never read, not files accessible if someone borrowed my phone—truly private, encrypted local storage with zero data collection. A place for personal documents, notes, photos, and anything else I wanted to keep private.

1. I can't trust any app that's not open source, and

2. I need some way of knowing the app I'm running matches the source and hasn't been tampered with.

That level of verifiable trust is non-negotiable. We couldn't find anything like it. So we built one.

The Timeline

Hours 0–5: Core App to Play Store

Biometric auth, camera, encrypted storage—none of these are hard. Flutter has libraries for all of them. Scaffolding a project takes Claude about thirty seconds. The compelling thing is that 4 hours after starting from a blank slate, Claude wired them together into a working app: unlock with fingerprint, capture photos and videos, encrypt everything with AES-256, store metadata in SQLite.

The last hour shifted to Play Store preparation—app signing, adaptive icons, privacy policy, release build. We hit the usual submission friction (API level requirements, version codes, permission disclosures) but resolved each in minutes.

By hour 5, the app was submitted to Google Play.

Hours 5–8: Expanding Scope

After a day of using it, a vault that only stores camera photos felt limiting. We added:

• File import from device storage

• Encrypted markdown notes

• PDF viewing

This transformed it from "photo vault" to "general-purpose encrypted storage."

Hours 8–10: Polish

Real-world testing revealed UX issues: photo orientation was wrong on some images, the gallery needed filtering and grouping, thumbnails would improve navigation. Fixed each as they surfaced.

Total: ~10 hours to production.

What We Built

Security-First Architecture

- AES-256-CBC encryption for all files
- Password + biometric authentication (fingerprint/face)
- Auto-lock when app backgrounds or screen locks
- Local-only storage (no cloud, no network)
- Zero analytics, zero tracking

Content & Features

- Built-in camera for photos and videos
- Import any file from device storage
- Markdown editor for encrypted notes
- PDF viewer
- Photo viewer with pinch-to-zoom and video playback

How We Built It

This was the first project where I wrote zero code.

I've been programming professionally for over 30 years. In every previous software project, I contributed code directly—regardless of title: VP of Engineering / CTO / Owner—sometimes to the chagrin of my developers. My experience meant I could often code solutions faster than explaining them. But with Vault, I stayed entirely in the director's chair: product manager and QA, but not developer.

Claude handled all implementation. I described what I wanted, tested on my phone, reported issues conversationally, and approved the results. The dynamic worked.

App 2: Gems

When I showed Vault to my wife, she had zero interest. Apparently secure file encryption doesn't spark joy.

When I was eight, my dad and I moved to a new town. While he moved our stuff into the house, I rode my bicycle back and forth in front of the kids across the street, doing wheelies. My wife plays match-3 games. Building Gems was the same impulse—showing off for someone whose opinion I cared about.

Here's the actual transcript of the project kick-off:

Me: "I'd like us to consider writing a game app... a game like Bejeweled. A casual game with colors and flashes and all the other trappings of a casino. Like the vault app, we'll make it open source, give it away for free, no ads. You up for helping me do that?"

Claude: "Okay, I've reviewed the vault_app. Here's what I'm seeing:

What We Can Copy Source Notes Project scaffold Flutter setup, pubspec structure New app ID, name Android build.gradle Signing config, SDK versions Change package ID main.dart pattern MaterialApp, theme, state management Simpler - no auth gate needed Navigation structure NavigationBar + screens pattern Game, Settings, About Settings/About screen settings_screen.dart Adapt for game settings Icon generation flutter_launcher_icons setup New icon design

...Want me to scaffold out the project? Sound good?"

Me: "heck yeah. That sounds great! Please proceed"

Hours 0–1.5: Core Game to Playable

Within 90 minutes, the game was functional.

What got built:

• Match-3 detection and cascade physics

• Four game modes (Timed, Moves, Target, Zen)

• Animated starfield background

• Pinch-to-zoom grid sizing (5x5 to 10x10)

• Leaderboards with arcade-style name entry

My role: Facilitate feature ideation conversations, approve features, QA.

Claude's role: Participate in ideation, write and deploy the code.

Hours 1.5–2.5: Store Preparation

README, screenshots, store listing, submission. The patterns from Vault made this fast.

Hours 2.5–4: Polish via Real-World QA

I handed my wife my phone: "Play this and tell me what's wrong."

Her feedback was specific:

"The swipe sensitivity is too low. I had to fall back to tapping." → Fixed in minutes.

"The screen shake animation and flashing is confusing and bad—I'm trying to plan my next move." → Implemented per-gem animation tracking. Only affected columns animate.

"There's no dopamine hit." → Built a complete combo celebration system with particles and multiplier badges.

Each fix took under five minutes. Test, report conversationally, get fix, repeat.

Total: ~4 hours to production.

The Lightswitch

Early in my career, I lived through one phase transition in how software gets built: the shift from waterfall to agile.

Development cycles collapsed from 2-3 years to 2-3 months. It didn't happen gradually. It happened like a lightswitch. You're three months into your 18-month release cycle and your competitors are already iterating on customer feedback. Companies that recognized it early had an advantage. Companies that didn't got left behind.

Another lightswitch moment has happened. Development cycles have collapsed again—from 2-3 months to 2-3 days.

Two production apps. Fourteen hours total. Both on the Google Play Store. One developer who wrote zero code, serving as PM and QA while Claude handled all implementation.

This isn't futurism. This isn't a prediction about where things are going. This is what happened last week. And just like the agile transition, most people haven't noticed yet.

The Only Thing That Matters

Yes, this article was written with Claude. Go ahead—call it AI slop.

But then play the game:

Core Game

- Match-3 with swap mechanics
- Cascade physics (gravity, fill)
- No-moves detection with auto-shuffle
- Pinch-to-zoom grid (5x5 to 10x10)

Game Modes

- Timed: 90 seconds, maximize score
- Moves: 30 moves, strategic play
- Target: Progressive levels
- Zen: Endless relaxation

Polish

- Animated starfield background
- Combo celebrations with particles
- Leaderboards with name entry
- Per-gem animation tracking

There's a tendency by some to dismiss AI-generated work reflexively. Hunting for emdashes as a proxy for quality. Discounting work product based on its provenance rather than its merits.

The only thing that matters is the quality of the work product. Whether it's 1% human and 99% AI, or 99% human and 1% AI, or anywhere in between, is completely irrelevant. Does the vault keep your files encrypted? Can you read the source code and verify what it does? Does the game feel good to play?

Everything else is distraction.

We built these apps in the open. The source code is public. We're giving Claude full credit for its contributions. Judge them on their merits.

Try Them

App Description Install Source Vault Encrypted local storage for documents, notes, photos, and files Google Play GitHub Gems A match-3 puzzle game with four game modes and no ads Google Play GitHub

Contribute, if you'd like, with or without your AI collaborators.

How senior engineers and AI collaborate to deliver 10x development velocity without sacrificing quality or control.

TL;DR

Vibe Coding is a methodology where senior engineers provide strategic direction while AI agents handle tactical implementation. This approach delivers 60-80% time reduction while maintaining or improving quality through human oversight and systematic verification.

Table of Contents

1. Introduction: Beyond AI-Assisted Coding

2. Core Philosophy

3. The Vibe Coding Process

4. Real-World Implementation Examples

5. Performance Metrics and Outcomes

6. Tools and Technology Stack

7. Common Patterns and Anti-Patterns

8. Advanced Techniques

9. Getting Started with Vibe Coding

10. Real-World Case Study

11. Conclusion

Introduction: Beyond AI-Assisted Coding

Most "AI-assisted development" tools focus on autocomplete and code generation. Vibe Coding is fundamentally different—it's a methodology where senior engineers provide strategic direction while AI agents handle tactical implementation. This isn't about writing code faster; it's about thinking at a higher level while maintaining complete control over the outcome.

Relationship to Traditional "Vibe Coding"

The term "vibe coding" was coined by AI researcher Andrej Karpathy in February 2025, describing an approach where "a person describes a problem in a few natural language sentences as a prompt to a large language model (LLM) tuned for coding."1 Karpathy's original concept focused on the conversational, natural flow of human-AI collaboration—"I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

However, some interpretations have added the requirement that developers "accept code without full understanding."2 This represents one particular form of vibe coding, often advocated for rapid prototyping scenarios. We believe this limitation isn't inherent to Karpathy's original vision and may actually constrain the methodology's potential.

Our Approach: We build directly on Karpathy's original definition—natural language collaboration with AI—while maintaining the technical rigor that senior engineers bring to any development process. This preserves the "vibe" (the flow, creativity, and speed) while ensuring production quality.

Why This Honors the Original Vision: Karpathy himself is an exceptionally skilled engineer who would naturally understand and verify any code he works with. The "vibe" isn't about abandoning engineering principles—it's about embracing a more intuitive, conversational development flow.

Karpathy's Original Vibe Coding: Natural language direction with conversational AI collaboration
Some Current Interpretations: Accept code without understanding (rapid prototyping focus)
Production Vibe Coding: Natural language direction with maintained engineering oversight

Our methodology represents a return to the core principle: leveraging AI to think and create at a higher level while preserving the engineering judgment that makes software reliable.

Core Philosophy

Strategic Collaboration, Not Hierarchy

In traditional development, engineers write every line of code. In Vibe Coding, humans and AI collaborate as strategic partners, each contributing distinct strengths. This isn't about artificial hierarchy—it's about leveraging complementary capabilities.

The Human's Role: Providing context that AI lacks access to—business requirements, user needs, system constraints, organizational priorities, and the crucial knowledge of "what you don't know that you don't know." Humans also catch when AI solutions miss important nuances or make assumptions about requirements that weren't explicitly stated.

The AI's Role: Rapid implementation across multiple technologies and languages, broad knowledge synthesis, and handling tactical execution once the strategic direction is clear. AI can work faster and across more technology stacks than most humans.

AI's Advantages: AI can maintain consistent focus without fatigue, simultaneously consider multiple approaches and trade-offs, instantly recall patterns from vast codebases, and work across dozens of programming languages and frameworks without context switching overhead. AI doesn't get frustrated by repetitive tasks and can rapidly iterate through solution variations that would take humans hours to explore.

Human I/O Advantages: Humans have significantly higher visual processing throughput than AI context windows can handle. A human can rapidly scan long log files, spot relevant errors in dense output, process visual information like charts or UI layouts, and use pattern recognition to identify issues that would require extensive context for AI to understand. This makes humans far more efficient for monitoring, visual debugging, and processing large amounts of unstructured output.

Training Pattern Considerations: AI models trained on high-quality code repositories can elevate less experienced developers above typical industry standards. For expert practitioners, AI may default to "best practice" patterns that don't match specific context or expert-level architectural decisions. This is why the planning phase is crucial—it establishes the specific requirements and constraints before AI begins implementation, preventing reversion to generic training patterns.

Why This Works: AI doesn't know what it doesn't know. Humans provide the missing context, constraints, and domain knowledge that AI can't infer. Once that context is established, AI can execute faster and more comprehensively than humans typically can.

Quality Through Human Oversight

AI agents handle implementation details but humans maintain quality control through:

• Continuous review: Every AI-generated solution is examined before integration

• Testing requirements: Changes aren't complete until verified

• Architectural consistency: Ensuring all components work together

• Performance considerations: Optimizing for real-world usage patterns

The Vibe Coding Process

1. Context Window Management

The Challenge: AI assistants have limited context windows, making complex projects difficult to manage.

Solution: Treat context windows as a resource to be managed strategically.

Planning Documentation Strategy

Complex development projects inevitably hit the limits of AI context windows. When this happens, the typical response is to start over, losing all the accumulated context and decisions. This creates a frustrating cycle where progress gets reset every few hours.

The solution is to externalize that context into persistent documentation. Before starting any multi-step project, create a plan document that captures not just what you're building, but why you're building it that way.

# plans/feature-name.md
## Goal
Clear, measurable objective

## Current Status  
What's been completed, what's next

## Architecture Decisions
Key choices and rationales

## Implementation Notes
Specific technical details for continuation

Why This Works: When you inevitably reach context limits, any team member—human or AI—can read the plan and understand exactly where things stand. The plan becomes a shared knowledge base that survives context switches, team handoffs, and project interruptions.

The Living Document Principle: These aren't static requirements documents. Plans evolve as you learn. When you discover a better approach or hit an unexpected constraint, update the plan immediately. This creates a real-time record of project knowledge that becomes invaluable for similar future projects.

Context Compression: A well-written plan compresses hours of discussion and discovery into a few hundred words. Instead of re-explaining the entire project background, you can start new sessions with "read the plan and let's continue from step 3."

Information Density Optimization

• Front-load critical information: Most important details first

• Reference external documentation: Link to specs rather than repeating them

• Surgical changes: Modify only what needs changing

• Progressive disclosure: Reveal complexity as needed

2. Tool Selection and Usage Patterns

The breakthrough in Vibe Coding productivity came with direct filesystem access. Before this, collaboration was confined to AI chat interfaces with embedded document canvases that were, frankly, inadequate. These interfaces reinvented existing technology poorly and could realistically only handle one file at a time, despite appearing more capable.

The Filesystem Revolution: Direct filesystem access changed everything. Suddenly, AI could work on as many concurrent files as necessary—reading existing code, writing new implementations, editing configurations, and managing entire project structures simultaneously. The productivity increase was dramatic and immediate.

Risk vs. Reward: Yes, giving AI direct filesystem access carries risks. We mitigate with version control (git) and accept that catastrophic failures might occur. The benefit-to-risk ratio is overwhelmingly positive when you can work on real projects instead of toy examples.

The Productivity Multiplier: Once AI and human are on the "same page" about implementation approach (through planning documents), direct filesystem access enables true collaboration. No more copying and pasting between interfaces. No more artificial constraints. Just real development work at AI speed.

Filesystem MCP Tools for System Operations

• File operations (read, write, search, concurrent multi-file editing)

• System commands and process management

• Code analysis and refactoring across entire codebases

• Performance advantages over web-based alternatives

We recommend Desktop Commander as it was the first robust filesystem MCP tool and has proven reliable through extensive use, though other similar tools are now available.

Web Tools for External Information

• Research and documentation

• API references and examples

• Third-party service integration

• Market and competitive analysis

Decision Tree Example:

Need to modify code?
├─ Small change (< 5 files) → Brief discussion of approach, then implement
├─ Large refactor → Formal plan document, then chunked implementation
└─ New feature → Architecture discussion + formal plan, then implementation

Need external information?
├─ Technical documentation → Web search + fetch
├─ Code examples → Web search for patterns
└─ API specifications → Direct URL fetch

3. Communication Patterns

Colleague-Level Context Sharing

The Mindshare Approach: Talk to AI like you would a trusted colleague - with stream-of-consciousness insights, background context, and natural explanation of constraints and motivations.

Always start with "why" embedded in "how"

Human: "I can tell when we're approaching context limits by looking at the scrollbar size, and it's frustrating to lose all our progress when we hit that wall. We need a token counter in the UI so I can see it coming and plan accordingly."

AI: "That makes perfect sense - you want early warning rather than hitting a cliff. For the UI integration, should this be:
- Real-time count that updates as you type?
- Conversation total vs. just current draft?
- Positioned where you can see it peripherally?"

Why This Works:

• Natural conversation reveals context that formal requirements miss

• Stream-of-consciousness often contains the most important insights

• Colleague-level sharing builds the mindshare needed for good solutions

• AI can reflect back understanding and surface questions organically

Avoiding the Fallback Trap

Anti-pattern: "Let me add a fallback mechanism..."

Better approach: "Let me understand why the primary approach isn't working..."

Why This Matters: Fallbacks often mask root problems and create technical debt. Vibe Coding emphasizes solving the right problem correctly.

Efficient Process Handoffs

The Polling Problem: AI polling long-running processes wastes context window space and prevents productive work on other tasks.

Human Monitoring Advantage: Humans can efficiently monitor processes using visual cues (progress bars, log scrolling, system notifications) while AI would need to repeatedly check status, consuming context with each poll.

For Long-Running Processes:

AI: "This database migration will take 15+ minutes. Rather than me polling 
every few seconds and wasting context window, I'll:

1. Provide you the command and monitoring approach
2. Set up success/failure criteria to watch for
3. Work on other tasks while you monitor
4. Resume when you signal completion or need troubleshooting

Command: python manage.py migrate --database=production
Watch for: 'Migration complete' or any ERROR messages
Should I proceed with the next task while you monitor this?"

Context Window Efficiency: This keeps AI productive on other work while humans use their superior I/O bandwidth for monitoring tasks.

4. Surgical Editing Approach

Philosophy: Modify only what needs changing to preserve working functionality and minimize risk.

The Pattern: Make precise, minimal changes rather than large refactoring operations that could introduce bugs or break existing systems.

# Good: Precise, minimal change
edit_block(
    file_path="service.py",
    old_string="def process_data(self):\n    return self.data",
    new_string="def process_data(self):\n    self.validate_input()\n    return self.data"
)

# Avoid: Large blocks with minor changes that risk breaking working code

Why This Matters: Working software is valuable. Surgical changes reduce risk, maintain system stability, and preserve the proven functionality while making targeted improvements.

When to Apply: Any time you're modifying existing, working code. The smaller and more focused the change, the easier it is to verify correctness and roll back if needed.

Note to LLMs

Chunked Writing Strategy: Always write files in chunks of 25-30 lines maximum. This is standard practice, not an emergency measure.

Implementation Pattern:

# Step 1: Create file with initial chunk
write_file(path, first_chunk, mode='rewrite')

# Step 2: Add subsequent chunks  
write_file(path, second_chunk, mode='append')
write_file(path, third_chunk, mode='append')

Why: Reduces cognitive load, enables progressive review, minimizes context switching, and improves error recovery. Chunk proactively - don't wait for performance warnings!

5. Testing and Verification

Nothing is Complete Until Tested

Verification Requirements:

• Functionality works as intended

• No regressions introduced

• Performance within acceptable bounds

• Integration points tested

Testing Handoff Pattern:

AI: "Implementation complete. For verification:
1. Run test_new_feature.py
2. Check integration with existing auth system
3. Verify performance benchmarks
4. Test error handling scenarios

Should I run these tests or would you prefer to verify?"

Progressive Verification

• Test incrementally during development

• Verify each chunk before proceeding

• Maintain test coverage metrics

• Document test scenarios in plans

Real-World Implementation Examples

Architecture Discussion Pattern

Human: "We need to add real-time notifications"

AI: "Let me think through the architecture options:

1. **WebSocket-based**: 
   - Pros: Real-time, bidirectional
   - Cons: Connection management complexity
   - Best for: High-frequency updates

2. **Server-Sent Events**:
   - Pros: Simpler, automatic reconnection
   - Cons: Unidirectional only
   - Best for: One-way notifications

3. **Polling with smart intervals**:
   - Pros: Simple implementation
   - Cons: Higher latency, more requests
   - Best for: Low-frequency updates

Given your current Flask stack and notification frequency requirements, 
I'd recommend SSE. Should we proceed with this approach?"

Result: Human makes informed decision with full context of trade-offs.

Problem Resolution Pattern

Human: "The Docker build is failing"

AI: "Let me investigate systematically:
1. Check the build log for specific errors
2. Verify Dockerfile syntax and layer dependencies
3. Check for base image compatibility issues
4. Examine any recent changes to dependencies

Rather than adding fallback mechanisms, I'll identify the root cause first."

Process:

1. Gather information before proposing solutions

2. Test hypotheses systematically

3. Fix root cause, not symptoms

4. Document resolution for future reference

Integration Challenge Example

Human: "The new auth service isn't working with our existing API"

AI: "Let me trace through the integration points:
1. Authentication flow and token format
2. API endpoint expectations vs. new service output
3. Error handling between services
4. Timing and timeout configurations

I see the issue - the token format changed. Instead of adding a 
compatibility layer, let's align the services properly."

Domain Expert Collaboration Pattern

Vibe Coding isn't limited to software engineers. Any domain expert can leverage their specialized knowledge to create tools they've always needed but couldn't build themselves.

Real-World Example: A veteran HR professional with decades of recruiting experience collaborated with AI to create a sophisticated interview assessment application. The human brought invaluable domain expertise—understanding what questions reveal candidate quality, how to structure evaluations, and the nuances of effective interviewing. The AI handled form design, user interface creation, and systematic organization of assessment criteria.

Result: A professional-grade interview tool created in hours that would have taken months to develop traditionally, combining lifetime expertise with rapid AI implementation.

Key Pattern:

• Domain Expert provides: Years of specialized knowledge, understanding of real-world requirements, insight into what actually works in practice

• AI provides: Technical implementation, interface design, systematic organization

• Outcome: Tools that perfectly match expert needs because they're built by experts

Note: This collaboration will be explored in detail in an upcoming case study on domain expert-AI partnerships.

Performance Metrics and Outcomes

Real-World Productivity Gains

Our Experience: When we plan development work in one-week phases, we consistently complete approximately two full weeks worth of planned work in a single six-hour focused session.

This means: 14 days of traditional development compressed into 6 hours - roughly a 56x time compression for planned, collaborative work.

Why This Works: The combination of thorough planning, immediate AI implementation, and continuous human oversight eliminates most of the typical development friction:

• No research delays (AI has broad knowledge)

• No context switching between tasks

• No waiting for code reviews or approvals

• No debugging cycles from misunderstood requirements

• No time lost to repetitive coding tasks

Quality Improvements

• Fewer bugs: Human oversight catches issues early

• Better architecture: More time for design thinking

• Consistent code style: AI follows established patterns

• Complete documentation: Plans and decisions preserved

Knowledge Transfer

• Reproducible process: New team members can follow methodology

• Preserved context: Plans survive team changes

• Continuous learning: Both human and AI improve over time

• Scalable expertise: Senior engineers can guide multiple projects

Tools and Technology Stack

Primary Development Environment

• Desktop Commander: File operations, system commands, code analysis

• Claude Sonnet 4: Strategic thinking, architecture decisions, code review

• Git: Version control with detailed commit messages

• Docker: Containerization and deployment

• Python: Primary development language with extensive AI tooling

Workflow Integration

• MkDocs: Documentation and knowledge management

• GitHub: Code hosting and collaboration

• Plans folder: Context preservation across sessions

• Testing frameworks: Automated verification of changes

Context Management Structure

/project-root/
├── plans/               # Development plans and status
├── docs/               # Documentation and guides  
├── src/                # Source code
├── tests/              # Test suites
└── docker/             # Deployment configurations

Common Patterns and Anti-Patterns

Successful Patterns

1. Plan → Discuss → Implement → Verify

1. Create plan in plans/ folder
2. Discuss approach and alternatives
3. Implement in small, verifiable chunks
4. Test each component before integration

2. Progressive Disclosure

- Start with high-level architecture
- Add detail as needed for implementation
- Preserve decisions for future reference
- Update plans with lessons learned

3. Human-AI Handoffs

AI: "This requires domain knowledge about your business rules. 
Could you provide guidance on how customer tiers should affect pricing?"

Anti-Patterns to Avoid

1. The Fallback Trap

❌ "Let me add error handling to catch this edge case"
✅ "Let me understand why this edge case occurs and fix the root cause"

2. Over-Engineering

❌ "I'll build a generic framework that handles all possible scenarios"
✅ "I'll solve the immediate problem and refactor when patterns emerge"

3. Context Amnesia

❌ Starting fresh each session without reading existing plans
✅ Always begin by reviewing current state and previous decisions

4. Tool Misuse

❌ Using web search for file operations
✅ Desktop Commander for local operations, web tools for external information

Advanced Techniques

Multi-Agent Coordination

For complex projects, different AI agents can handle different aspects:

• Architecture Agent: High-level design and system integration

• Implementation Agent: Code generation and refactoring

• Testing Agent: Test creation and verification

• Documentation Agent: Technical writing and knowledge capture

Dynamic Context Switching

# Large refactor example
1. Create detailed plan with checkpoint strategy
2. Implement core changes in chunks
3. Test each checkpoint before proceeding
4. Update plan with lessons learned
5. Continue or adjust based on results

Knowledge Preservation Strategies

# In plans/lessons-learned.md
## Problem: Authentication integration complexity
## Solution: Standardized token format across services
## Impact: 3 hours saved on future auth integrations
## Pattern: Define service contracts before implementation

Battle-Tested Best Practices

Through hundreds of hours of real development work, we've identified these critical practices that separate successful Vibe Coding from common pitfalls:

The "Plan Before Code" Discovery

The Key Rule: No code gets written until we agree on the plan.

Impact: This single rule eliminated nearly all wasted effort in our collaboration. When AI understands the full context upfront, implementation proceeds smoothly. When AI starts coding without complete context, it optimizes for the wrong requirements and creates work that must be discarded.

Why It Works: AI doesn't know what it doesn't know. Planning forces the human to surface all the context, constraints, and requirements that AI can't infer. Once established, execution becomes efficient and accurate.

The "Less is More" Philosophy

Pattern: Always choose the simplest solution that solves the actual problem.

❌ "Let me build a comprehensive framework that handles all edge cases"
✅ "Let me solve this specific problem and refactor when patterns emerge"

Why This Works: Complex solutions create technical debt and make future changes harder. Simple, targeted changes preserve architectural flexibility.

Surgical Changes Over Refactoring

Pattern: Modify only what needs changing, preserve working functionality.

# Good: Minimal, focused change
edit_block(
    file="service.py", 
    old="def process():\n    return data",
    new="def process():\n    validate_input()\n    return data"
)

# Avoid: Large refactoring that could break existing functionality

Why This Matters: Working software is valuable. Surgical changes reduce risk and maintain system stability.

Long-Running Process Handoffs

Critical Pattern: AI should never manage lengthy operations directly.

AI: "This database migration will take 15+ minutes. I'll provide the command 
and monitor approach rather than running it myself:

Command: python manage.py migrate --database=production
Monitor: Check logs every 2 minutes for progress
Rollback: python manage.py migrate --database=production 0001_initial

Would you prefer to run this yourself for better control?"

Human Advantage: Human oversight of long processes prevents resource waste and enables real-time decision making.

The Fallback Mechanism Trap

Anti-Pattern: "Let me add error handling to catch this edge case..."
Better Approach: "Let me understand why this edge case occurs and fix the root cause..."

❌ Fallback: Add try/catch to hide the real problem
✅ Root Cause: Investigate why the error happens and fix the source

Time Savings: Solving root problems prevents future debugging sessions and creates more maintainable code.

Verification-First Completion

Rule: Nothing is complete until it's been tested and verified.

AI Implementation → Human/AI Testing → Verification Complete
   ↑                                           ↓
   ←——————— Fix Issues If Found ←———————————————

Testing Handoff Options:

• "Should I run the tests or would you prefer to verify?"

• "Here's what needs testing: [specific scenarios]"

• "Implementation ready for verification: [verification checklist]"

Getting Started with Vibe Coding

For Individual Developers

1. Set up tools: Desktop Commander, AI assistant, documentation system

2. Start small: Choose a well-defined feature or bug fix

3. Practice patterns: Plan → Discuss → Implement → Verify

4. Document learnings: Build your pattern library

For Teams

1. Establish standards: File organization, documentation formats, handoff protocols

2. Train together: Practice the methodology on shared projects

3. Create templates: Standard plan formats, common decision trees

4. Measure outcomes: Track speed and quality improvements

Success Metrics

• Development velocity: Features delivered per sprint

• Code quality: Bug rates, review feedback, maintainability

• Knowledge retention: How quickly new team members become productive

• Context preservation: Ability to resume work after interruptions

Conclusion: The Future of Development

Vibe Coding represents a fundamental shift from human-as-coder to human-as-conductor. By treating AI as a powerful but directed tool rather than a replacement, we achieve:

• 10x velocity improvements without sacrificing quality

• Better architecture through increased design thinking time

• Preserved expertise via documentation and knowledge transfer

• Scalable impact where senior engineers can guide multiple projects

This methodology isn't about replacing developers—it's about amplifying their impact. Senior engineers become force multipliers, able to execute complex projects that would normally require entire teams.

The companies that master human-AI collaboration today will dominate tomorrow's software landscape. Vibe Coding provides a proven framework for making that transition successfully.

Ready to Start?

Begin with a small, well-defined feature in your current project. Apply the Plan → Discuss → Implement → Verify cycle. Set up a /plans folder in your project and create your first development plan using the methodology outlined here.

Want to learn more? Contact us to discuss how Vibe Coding can transform your development process, or explore our Professional Services for enterprise implementations.

Real-World Example: Token Counter Implementation

To demonstrate this methodology in practice, here's an actual session from our development work. The context: we were working in Claude Desktop with system prompts providing project structure information and collaboration preferences.

The Initial Request

Human: "we could also add a token counter somewhere in the lit-desktop UI ... that's the kind of project that is super clear to a reader what we're after"

AI: "Perfect! A token counter in lit-desktop is an excellent demonstration project. It's:

• Crystal clear goal: Everyone understands what a token counter does

• Visual result: Immediate, tangible outcome users can see

• Right scope: Substantial enough to show methodology, small enough to complete

• Real value: Users actually want to track token usage"

Planning Phase (5 minutes)

Human: "i think it's per conversation. if you recall how you and I work here in claude desktop there's always this point about an hour into any project and we can both tell when it's approaching. i don't know how you know but I can tell by the size of the scroll bar..."

AI: Created detailed implementation plan covering:

• Technical decisions (client-side approximation vs server-side)

• UI placement (near text input for pre-send awareness)

• Update frequency (200ms debounce)

• Data flow (conversation total + live draft)

Architecture Research (5 minutes)

Before writing any code, we examined the existing lit-desktop structure:

• Located Angular chat components

• Found message input textarea with [(ngModel)]="currentInput"

• Identified messages: ChatMessage[] array for conversation data

• Determined optimal display location in status hint area

Implementation (14 minutes)

Service Creation: Built TokenCounterService with approximation algorithm

countTokens(text: string): number {
  const charBasedTokens = Math.ceil(text.length / 4);
  const wordBasedTokens = Math.ceil(text.trim().split(/\s+/).length / 0.75);
  return Math.round((charBasedTokens + wordBasedTokens) / 2);
}

Component Integration: Added token counting to chat page component

• Injected service into existing constructor

• Added properties for conversation and draft token counts

• Integrated with message loading and session switching

Template Updates: Modified HTML to display counter

<span *ngIf="!isLoading">
  <span>Lit can make mistakes</span>
  <span *ngIf="tokenCountDisplay" class="token-counter"> • {{ tokenCountDisplay }}</span>
</span>

Problem Resolution (4 minutes)

Browser Compatibility Issue: Initial tokenizer library required Node.js modules

• Problem: gpt-3-encoder needed fs/path modules unavailable in browser

• Solution: Replaced with custom approximation algorithm

Duplicate Method: Accidentally created conflicting function - Problem: Created duplicate onInputChange method - Solution: Integrated token counting into existing method

Quality Assurance

Human: "are we capturing the event for switching sessions?"

This caught a gap in our implementation - token count wasn't updating when users switched conversations. We added the missing updates to selectChat() and createNewChat() methods.

Human: "instead + tokens how about what the new total would be"

UX improvement suggestion led to cleaner display format: - Before: "~4,847 tokens (+127 in draft)" - After: "~4,847 tokens (4,974 if sent)"

Final Result

Development Outcome: Successfully implemented token counter feature across 4 files with clean integration into existing Angular architecture. View the complete implementation.

Timeline (based on development session):

• 14:30 - Planning and architecture discussion complete

• 14:32 - Service implementation with token approximation algorithm

• 14:34 - CSS styling for visual integration

• 14:36 - HTML template updates for display

• 14:40 - Component integration and event handling

• 14:40-15:00 - Human stuck in meeting; AI waits

• 15:03 - UX refinement and improved display format

• 15:04 - Final verification and testing

Total active development time: 14 minutes (including planning, implementation, and verification)

What This Demonstrates

The session shows core Vibe Coding principles in action:

• Human strategic direction: Clear problem definition and UX decisions

• AI tactical execution: Architecture research and rapid implementation

• Continuous verification: Testing and validation at each step

• Quality collaboration: Human oversight caught integration gaps and suggested UX improvements

• Surgical changes: Modified existing architecture rather than building from scratch

• Context preservation: Detailed planning enabled seamless execution

The development session demonstrates how Vibe Coding enables complex feature development in minutes rather than hours, while maintaining high code quality through human oversight and systematic verification.

In the rapidly evolving landscape of enterprise software, we're witnessing the meteoric rise of workflow automation tools. These platforms promise to streamline operations through visual interfaces where users can design, implement, and monitor complex business processes. Yet despite their current popularity, these GUI-based workflow solutions may represent the last generation of their kind—soon to be replaced by more versatile Large Language Model (LLM) interfaces.

The Current Workflow Software Boom

The workflow automation market is experiencing unprecedented growth, projected to reach 78.8 billion USD by 2030 with a staggering 23.1% compound annual growth rate. This explosive expansion is evident in both funding activity and market adoption: Workato secured a 200 million USD Series E round at a $5.7 billion valuation, while established players like ServiceNow and Appian continue to report record subscription revenues.

A quick glance at a typical workflow builder interface reveals the complexity these tools embrace:

The landscape is crowded with vendors aggressively competing for market share:

• Enterprise platforms: ServiceNow, Pega, Appian, and IBM Process Automation dominate the high-end market, offering comprehensive solutions tightly integrated with their broader software ecosystems.

• Integration specialists: Workato, Tray.io, and Zapier focus specifically on connecting disparate applications through visual workflow builders, catering to the growing API economy.

• Emerging players: Newer entrants like Bardeen, n8n, and Make (formerly Integromat) are gaining traction with innovative approaches and specialized capabilities.

This workflow automation boom follows a familiar pattern we've seen before. Between 2018 and 2022, Robotic Process Automation (RPA) experienced a similar explosive growth cycle. Companies like UiPath reached a peak valuation of $35 billion before a significant market correction as limitations became apparent. RPA promised to automate routine tasks by mimicking human interactions with existing interfaces—essentially screen scraping and macro recording at an enterprise scale—but struggled with brittle connections, high maintenance overhead, and limited adaptability to changing interfaces.

Today's workflow tools attempt to address these limitations by focusing on API connections rather than UI interactions, but they still follow the same fundamental paradigm: visual programming interfaces that require specialized knowledge to build and maintain.

So why are organizations pouring billions into these platforms despite the lessons from RPA? Several factors drive this investment:

• Digital transformation imperatives: COVID-19 dramatically accelerated organizations' need to automate processes as remote work became essential and manual, paper-based workflows proved impossible to maintain.

• The automation gap: Companies recognize the potential of AI and automation but have lacked accessible tools to implement them across the organization without heavy IT involvement.

• Democratization promise: Workflow tools market themselves as empowering "citizen developers"—business users who can automate their own processes without coding knowledge.

• Pre-LLM capabilities: Until recently, organizations had few alternatives for process automation that didn't require extensive software development.

What we're witnessing is essentially a technological stepping stone—organizations hungry for AI-powered results before true AI was ready to deliver them at scale. But as we'll see, that technological gap is rapidly closing, with profound implications for the workflow software category.

Why LLMs Will Disrupt Workflow Software

While current workflow tools represent incremental improvements on decades-old visual programming paradigms, LLMs offer a fundamentally different approach—one that aligns with how humans naturally express process logic and intent. The technical capabilities enabling this shift are advancing rapidly, creating the conditions for widespread disruption.

The Technical Foundation: Resource Access Protocols

The key technical enabler for LLM-driven workflows is the development of secure protocols that allow these models to access and manipulate resources. Model Context Protocol (MCP) represents one of the most promising approaches:

MCP provides a standardized way for LLMs to:

• Access data from various systems through controlled APIs

• Execute actions with proper authentication and authorization

• Maintain context across multiple interactions

• Document actions taken for compliance and debugging

Unlike earlier attempts at AI automation, MCP and similar protocols solve the "last mile" problem by creating secure bridges between conversational AI and the systems that need to be accessed or manipulated. Major cloud providers are already implementing variations of these protocols, with Microsoft's Azure AI Actions, Google's Gemini API, and Anthropic's Claude Tools representing early implementations.

The proliferation of these standards means that instead of building custom integrations for each workflow tool, organizations can create a single set of LLM-compatible APIs that work across any AI interface.

Natural Language vs. GUI Interfaces

The cognitive load difference between traditional workflow tools and LLM interfaces becomes apparent when comparing approaches to the same problem:

Traditional Workflow Tool Process

1. Open workflow designer application

2. Create a new workflow and name it

3. Drag "Trigger" component (Customer Signup)

4. Configure webhook or database monitor

5. Drag "HTTP Request" component

6. Configure endpoint URL for credit API

7. Add authentication parameters (API key, tokens)

8. Add request body parameters and format

9. Connect to "JSON Parser" component

10. Define schema for response parsing

11. Create variable for credit score

12. Add "Decision" component

13. Configure condition (score < 600)

14. For "True" path, add "Notification" component

15. Configure recipients, subject, and message template

16. Add error handling for API timeout

17. Add error handling for data format issues

18. Test with sample data

19. Debug connection issues

20. Deploy to production environment

21. Configure monitoring alerts

LLM Approach

When a new customer signs up, retrieve their credit score from our API, 
store it in our database, and if the score is below 600, notify the risk 
assessment team.

The workflow tool approach requires not only understanding the business logic but also learning the specific implementation patterns of the tool itself. Users must know which components to use, how to properly connect them, and how to configure each element—skills that rarely transfer between different workflow platforms.

Dynamic Adaptation Through Conversation

Real business processes rarely remain static. Consider how process changes propagate in each paradigm:

Traditional Workflow Change Process

1. Open existing workflow in designer

2. Identify components that need modification

3. Add new components for bankruptcy check

4. Configure API connection to bankruptcy database

5. Add new decision branch

6. Connect positive result to new components

7. Add calendar integration component

8. Configure meeting details and attendees

9. Update documentation to reflect changes

10. Redeploy updated workflow

11. Test all paths, including existing functionality

12. Update monitoring for new failure points

LLM Approach

Actually, let's also check if they've had a bankruptcy in the last five 
years, and if so, automatically schedule a review call with our financial 
advisor team.

The LLM simply incorporates the new requirement conversationally. Behind the scenes, it maintains a complete understanding of the existing process and extends it appropriately—adding the necessary API calls, conditional logic, and scheduling actions without requiring the user to manipulate visual components.

Early implementations of this approach are already appearing. GitHub Copilot for Docs can update software configuration by conversing with developers about their intentions, rather than requiring them to parse documentation and make manual changes. Similarly, companies like Adept are building AI assistants that can operate existing software interfaces based on natural language instructions.

Self-Healing Systems: The Maintenance Advantage

Perhaps the most profound advantage of LLM-driven workflows is their ability to adapt to changing environments without breaking. Traditional workflows are notoriously brittle:

Traditional Workflow Failure Scenarios:

• An API endpoint changes its structure

• A data source modifies its authentication requirements

• A third-party service deprecates a feature

• A database schema is updated

• Operating system or runtime dependencies change

When these changes occur, traditional workflows break and require manual intervention. Someone must diagnose the issue, understand the change, modify the workflow components, test the fixes, and redeploy. This maintenance overhead is substantial—studies suggest organizations spend 60-80% of their workflow automation resources on maintenance rather than creating new value.

LLM-Driven Workflow Adaptation: LLMs with proper resource access can automatically adapt to many changes:

• When an API returns errors, the LLM can examine documentation, test alternative approaches, and adjust parameters

• If authentication requirements change, the LLM can interpret error messages and modify its approach

• When services deprecate features, the LLM can find and implement alternatives based on its understanding of the underlying intent

• Changes in database schemas can be discovered and accommodated dynamically

• Environmental changes can be detected and worked around

Rather than breaking, LLM-driven workflows degrade gracefully and can often self-heal without human intervention. When they do require assistance, the interaction is conversational:

User: The customer onboarding workflow seems to be failing at the credit check 
step.
LLM: I've investigated the issue. The credit API has changed its response 
format. I've updated the workflow to handle the new format. Would you like 
me to show you the specific changes I made?

This self-healing capacity drastically reduces maintenance overhead and increases system reliability. Organizations using early LLM-driven processes report up to 70% reductions in workflow maintenance time and significantly improved uptime.

Compliance and Audit Superiority

Perhaps counterintuitively, LLM-driven workflows can provide superior compliance capabilities. Several financial institutions are already piloting LLM systems that maintain comprehensive audit logs that surpass traditional workflow tools:

• Granular Action Logging: Every step, decision point, and data access is logged with complete context

• Natural Language Explanations: Each action includes an explanation of why it was taken

• Cryptographic Verification: Logs can be cryptographically signed and verified for tamper detection

• Full Data Lineage: Complete tracking of where data originated and how it was transformed

• Semantic Search: Compliance teams can query logs using natural language questions

A major U.S. bank recently compared their existing workflow tool's audit capabilities with a prototype LLM-driven system and found the LLM approach provided 3.5x more detailed audit information with 65% less storage requirements, due to the elimination of redundant metadata and more efficient logging.

Visualization On Demand

For scenarios where visual representation is beneficial, LLMs offer a significant advantage: contextually appropriate visualizations generated precisely when needed.

Rather than being limited to pre-designed dashboards and reports, users can request visualizations tailored to their current needs:

User: Show me a diagram of how the customer onboarding process changes with 
the new bankruptcy check.

LLM: Generates a Mermaid diagram showing the modified process flow with the 
new condition highlighted

User: How will this affect our approval rates based on historical data?

LLM: Generates a bar chart showing projected approval rate changes based on 
historical bankruptcy data

Companies like Observable and Vercel are already building tools that integrate LLM-generated visualizations into business workflows, allowing users to create complex data visualizations through conversation rather than manual configuration.

Current State of Adoption

While the technical capabilities exist, we're still in the early stages of this transition. Rather than presenting hypothetical examples as established successes, it's more accurate to examine how organizations are currently experimenting with LLM-driven workflow approaches:

• Prototype implementations: Several companies are building prototype systems that use LLMs to orchestrate workflows, but these remain largely experimental and haven't yet replaced enterprise-wide workflow systems.

• Augmentation rather than replacement: Most organizations are currently using LLMs to augment existing workflow tools—helping users configure complex components or troubleshoot issues—rather than replacing the tools entirely.

• Domain-specific applications: The most successful early implementations focus on narrow domains with well-defined processes, such as content approval workflows or customer support triage, rather than attempting to replace entire workflow platforms.

• Hybrid approaches: Organizations are finding success with approaches that combine traditional workflow engines with LLM interfaces, allowing users to interact conversationally while maintaining the robustness of established systems.

While we don't yet have large-scale case studies with verified metrics showing complete workflow tool replacement, the technological trajectory is clear. As LLM capabilities continue to improve and resource access protocols mature, the barriers to adoption will steadily decrease.

Investment Implications

The disruption of workflow automation by LLMs isn't a gradual shift—it's happening now. For decision-makers, this isn't about careful transitions or hedged investments; it's about immediate and decisive action to avoid wasting resources on soon-to-be-obsolete technology.

Halt Investment in Traditional Workflow Tools Immediately

Stop signing or renewing licenses for traditional workflow automation platforms. These systems will be obsolete within weeks, not years. Any new investment in these platforms represents resources that could be better allocated to LLM+MCP approaches. If you've recently purchased licenses, investigate termination options or ways to repurpose these investments.

Redirect Resources to LLM Infrastructure

Immediately reallocate budgets from workflow software to: - Enterprise-grade LLM deployment on your infrastructure - Implementation of MCP or equivalent protocols - API development for all internal systems - Prompt engineering training for existing workflow specialists

Install LLM+MCP on Every Desktop Now

Rather than planning gradual rollouts, deploy LLM+MCP capabilities across your organization immediately. Every day that employees continue to build workflows in traditional tools is a day of wasted effort creating systems that will need to be replaced. Local or server-based LLMs with proper resource access should become standard tools alongside word processors and spreadsheets.

Retrain Teams for the New Paradigm

Your workflow specialists need to become prompt engineers—not next quarter, but this week: - Cancel scheduled workflow tool training - Replace with intensive prompt engineering workshops - Focus on teaching conversational process design rather than visual programming - Develop internal guides for effective LLM workflow creation

Examine Legal Obligations

For organizations with existing contracts for workflow platforms: - Review termination clauses and calculate the cost of early exits - Investigate whether remaining license terms can be applied to API access rather than visual workflow tools - Consider whether vendors might offer transitions to their own LLM offerings in lieu of contracted services

Vendors: Pivot or Perish

For workflow automation companies, there's no time for careful transitions: - Immediately halt development on visual workflow designers - Redirect all engineering resources to LLM interfaces and connectors - Open all APIs and create comprehensive documentation for LLM interaction - Develop prompt libraries that encapsulate existing workflow patterns

The AI-assisted development cycle is accelerating innovation at unprecedented rates. What would have taken years is now happening in weeks. Organizations that try to manage this as a gradual transition will find themselves outpaced by competitors who embrace the immediate shift to LLM-driven processes.

Our Own Evolution

We need to acknowledge our own journey in this space. At Lit.ai, we initially invested in building the Workflow Canvas - a visual tool for designing LLM-powered workflows that made the technology more accessible. We created this product with the belief that visual workflow builders would remain essential for orchestrating complex LLM interactions.

However, our direct experience with customers and the rapid evolution of LLM capabilities has caused us to reassess this position. The very technology we're building is becoming sophisticated enough to make our own workflow canvas increasingly unnecessary for many use cases. Rather than clinging to this approach, we're now investing heavily in Model Context Protocol (MCP) and direct LLM resource access.

This pivot represents our commitment to following the technology where it leads, even when that means disrupting our own offerings. We believe the most valuable contribution we can make isn't building better visual workflow tools, but rather developing the connective tissue that allows LLMs to directly access and manipulate the resources they need to execute workflows without intermediary interfaces.

Our journey mirrors what we expect to see across the industry - an initial investment in workflow tools as a stepping stone, followed by a recognition that the real value lies in direct LLM orchestration with proper resource access protocols.

Timeline and Adoption Considerations

While the technical capabilities enabling this shift are rapidly advancing, several factors will influence adoption timelines:

Enterprise Inertia

Large organizations with established workflow infrastructure and trained teams will transition more slowly. Expect these environments to adopt hybrid approaches initially, where LLMs complement rather than replace existing workflow tools.

High-Stakes Domains

Industries with mission-critical workflows (healthcare, finance, aerospace) will maintain traditional interfaces longer, particularly for processes with significant safety or regulatory implications. However, even in these domains, LLMs will gradually demonstrate their reliability for increasingly complex tasks.

Security and Control Concerns

Organizations will need to develop comfort with LLM-executed workflows, particularly regarding security, predictability, and control. Establishing appropriate guardrails and monitoring will be essential for building this confidence.

Conclusion

The current boom in workflow automation software represents the peak of a paradigm that's about to be disrupted. As LLMs gain direct access to resources and demonstrate their ability to understand and execute complex processes through natural language, the value of specialized GUI-based workflow tools will diminish.

Forward-thinking organizations should prepare for this shift by investing in API infrastructure, LLM integration capabilities, and domain-specific knowledge engineering rather than committing deeply to soon-to-be-legacy workflow platforms. The future of workflow automation isn't in better diagrams and drag-drop interfaces—it's in the natural language interaction between users and increasingly capable AI systems.

In fact, this very article demonstrates the principle in action. Rather than using a traditional publishing workflow tool with multiple steps and interfaces, it was originally drafted in Google Docs, then an LLM was instructed to:

Translate this to markdown, save it to a file on the local disk, execute a 
build, then upload it to AWS S3.

The entire publishing workflow—format conversion, file system operations, build process execution, and cloud deployment—was accomplished through a simple natural language request to an LLM with the appropriate resource access, eliminating the need for specialized workflow interfaces.

This perspective challenges conventional wisdom about enterprise software evolution. Decision-makers who recognize this shift early will gain significant advantages in operational efficiency, technology investment, and organizational agility.

I traveled to China this past fall to meet and greet the excellent students participating in our post-grad work program at Nankai University and to give a guest lecture on the history of Software Engineering. My true objective for this trip was to make a first-hand assessment of how our China team is performing as a member of the whole global software engineering organization.

My philosophy on good team building is the same whether it's a 2-person startup in your basement or a global software organization of 1000s. It's based on Tuckman's stages of group development, a model developed in 1965 which posits the idea that teams are always in one of four distinct phases:

1. Form

2. Storm

3. Norm

4. Perform

The mistake that team managers make most often is to fail to recognize which phase their team is in. They waste time and effort focused on tasks that don't help their teams evolve to the next stage. For example, ==teams that don't have the right people can't become normative no matter how much effort a manager puts into it. The result of such an effort will be frustration for both the manager and the team members==. Recognize which phase your team is in and pour all of your effort into leading your team to the next level.

Form is simple. Fire and hire well. Cut players that aren't contributing to the team. Cutting is the worst part of the job but it's the most important. Recruit the very best talent you can attract. You'll be surprised how talent attracts talent like a magnet. If you find yourself stuck in Form then odds are you're the problem. You're either unqualified to recognize and hire talent or you're unwilling to fire the dead weight. Fire yourself immediately and choose someone more competent to do the job for you.

Storm takes care of itself if you've given Form the attention it deserves. There are natural leaders in any tribe. They want your job. Everyone else in the tribe is hell-bent on accomplishing your grand mission. Nurture both of these drives. If you don't have natural leaders you're still in form. If you don't have a grand mission that you can speak passionately about then stop what you're doing right now and go find one. It's your job! If your team isn't passionate about what they're doing it's because you're not passionate about what you're doing. Fire yourself immediately and choose someone more competent to do the job for you.

Norm means normative. Getting normative means aligning everyone's efforts such that your team as a whole makes measurable iterative progress towards a common goal. It requires process, cultivating a culture of growth, and leadership. Don't know where to start? Start with these three psychological needs: autonomy, relatedness, and competence. Susan Fowler has a great run-down of these needs in her latest article, What Maslow's Hierarchy Won't Tell You About Motivation. If autonomy is counter to your management style then it's time to consider firing yourself to make room for someone that can take your team to the next level.

Perform is a unicorn. The advice I follow (remember, it's only worth what you paid for it) is to:

1. Have a little luck.

2. Persevere through the grind. No great thing accomplished was ever easy.

3. Lead from the front. Participate in the process of accomplishing the grand vision. If you're not competent enough to contribute to the project then it's high time you fire yourself and hire someone who is.

Enjoy your time in Perform. It's fleeting. You'll spend the rest of your career chasing it.

Adjourn is the rarely talked about unofficial fifth phase. It reflects completing the task and breaking up the team. Teams that I've been lucky enough to participate in at the Perform phase never stay together for more than a single cycle. ==This is why it's vital for companies to hire management not based on how well they run a team, but rather how well they build a team.==

This is a topic that deserves the attention of a good practical reference book. Know of any? Leave a comment.

(Special thanks to my long-time friend Cameron for turning me on to Bruce Tuckman years ago when I first made the move to management.)