Where Does Software Engineering Go From Here? (Part 1)

I’ve been sitting on this one long enough that a few of these predictions will read as obvious to anyone who lives on Twitter. I don’t think that’s because I’m slow, but because the half-life of a paradigm in this industry has collapsed from years to months to weeks. A take goes from contrarian to consensus to cliché quite literally before you’ve finished writing it down.

I’m putting this in writing anyway, mostly because of the massive gap between the ecosystem’s loudest factions: the “AI is slop” camp, still living in denial and typing at 60 wpm, and the “AGI soon” camp, rapidly tipping into genuine AI psychosis. As usual, both extremes are wrong, and the truth lies somewhere in the messy middle.

1. LLMs are not intelligent, and never will be

Let’s get this out of the way first. If you disagree with this premise, nothing that follows will land.

People define intelligence a dozen ways, but I always return to Naval’s definition: the only real test of intelligence is whether you get what you want out of life (while knowing what’s worth wanting is wisdom). The machine doesn’t want anything. There is no “life” for it to get anything out of, and a thing without desire cannot have intent. Intention is the root of automation and the exclusive domain of beings with a soul, the one thing automation cannot supply. Even when an LLM looks like it’s acting with intent, that intent is borrowed; it’s the echo of the spark you supplied the moment you typed the prompt.

Over a millennium ago, Ibn Sina made this observation. Fast forward to 2026, and Pope Leo XIV reached for the same distinction in Magnifica Humanitas, his encyclical on AI, noting that these machines “do not undergo experiences, do not possess a body, do not mature through relationships.” They don’t want. They don’t feel. You don’t empathize with your power drill; you don’t ask if it’s having a good day, or handle it more gently so its feelings don’t get hurt.

Yes, a computer does more arithmetic in a second than I’ll do in a lifetime. An LLM extracts, summarizes, and remixes the written output of our species better than any single one of us. It lives in the space between a search engine and a synthesizer, approximating the internet as it stood on some past Tuesday. Inside that distribution, it performs miracles. Outside the training data, past the edge of context, it devolves into confident nonsense. That’s not to say they’re not incredibly effective at probing the limits of our knowledge — in May 2026, an 80-year-old Erdős conjecture fell to a single prompt — but those wins belong to a particular class of problem: the answer is checkable, the search space is bounded, and being right is unambiguous. The world rarely hands you problems shaped like that.

The same math that lets them do all this has a gravity that pulls relentlessly toward the median. To defend the “AI is just autocomplete” crowd, that is truly all this is: predicting the likeliest next token. And the likeliest answer is, by definition, the most typical one — the literal consensus of its training data. Then alignment training sands that down further, rewarding whatever a rater was most likely to nod at.

So treat it for what it is: an amplification tool for what already exists. Call it a “clanker” if that helps keep your distance; better an unfeeling machine catches a stray than a fellow human. But stop saying model X is smarter than model Y when you just mean it’s more effective. Attribute intelligence to a thing that has none, and the only thing you’ve shown is where it’s lacking.

2. English is a leaky abstraction; it will never fully replace code

Every rung we climbed up the abstraction ladder so far has been deterministic. Punch cards gave way to assembly, assembly to compiled languages like C, C to the languages you actually use, and at each step the higher layer compiled down to the lower one the same way every time. Feed a compiler the same input twice and you get the same machine code twice; obviously not the case with LLMs.

Joel Spolsky called this the law of leaky abstractions: the tax on every abstraction is that you still have to understand the layer below it for the day it inevitably leaks. You save time executing, not learning. Using English to drive software is that same bargain, cranked to the absolute maximum.

Ask your AI assistant to add real-time features to your app. How is it doing that? Is it polling, long-polling, SSE, or WebSockets? What’s the consistency model when two people edit at once? Last-write-wins, CRDTs, or OT? How is it handling reconnection, offline queueing, or presence? People write dissertations on just one of these topics. The model picks a lane and buries the rest, and you won’t find out which lane it chose until production breaks.

Say you catch the bug born from its wrong guess, and you write the assistant a prompt detailing exactly what you meant. If you do that well, the prompt gets long. It gets precise. It fills up with the constraints and edge cases you left implicit the first time around.

Eventually, it gets so long and precise that it stops being a prompt altogether. We already have a word for a document that perfectly pins down every architectural decision and edge case: it’s called code.

3. Code is a liability; always has been, always will be

The very first thing that came to mind when chat interfaces started getting shoehorned into apps with perfectly good, decades-honed UX was: oh boy, a new interface to maintain. As if mobile, web, and desktop weren’t enough. A text box isn’t going to magically deprecate the GUI; it’s just another layer of the stack to test, design for, and inevitably patch.

Jaded? Maybe. But every line of code you ship is a building you’ve just committed to maintaining, perhaps indefinitely. Maintenance already eats 60 to 80 percent of a system’s total lifecycle cost, a metric that has held steady across decades of studies. The bulk of that cost isn’t even fixing bugs; it’s managing the sheer weight of what already works. Every feature is a new surface area that every future change must route around. If agents multiply the rate of construction, they multiply the upkeep right along with it. Generating code faster just means generating liability faster.

You could argue the cost of generating code is trending to zero, so volume no longer matters. But trending to zero isn’t zero. You are still paying the maintenance tax, whether it’s in LLM compute tokens or consultants you eventually have to hire to fix your slop. (If that’s you, shoot me a message, I know a guy.)

More importantly, typing the actual code was never where the time or money went; it occupied maybe ten to twenty percent of the job. The rest is figuring out what to build, safely wedging it into a legacy codebase, testing it, and keeping it running until the end of time. We haven’t automated software engineering; we’ve just sped up the typing.

4. Context and tooling is what makes an agent useful, and control will be open source’s advantage

An agent’s usefulness scales with how much of your world it can safely see and touch. Mine became sharply more useful the moment I connected my calendar, email, projects, and apps, and better again when I let it onto my laptop to actually click around and do things.

You could argue that this data should never have been siloed in the first place. But those walls were the rational product of the previous software era, when companies bought the best tool for each job and every tool had an incentive to hoard its data like the business depended on it, because it usually did.

That incentive is now inverting. If a customer’s agent cannot reach the customer’s own data inside your platform, they will leave for one where it can. The wall that once kept them trapped is becoming the reason they churn.

So the frontier moves up a layer.

“Open” used to mean data sovereignty: prying your information out of someone else’s walled garden. Once access is table stakes, it comes to mean control: swapping memory stores (temporal knowledge graphs, LSM trees on object storage), swapping tools, or JIT compiling the harness itself, and making sure your Millennium Prize research doesn’t show up in someone else’s LLM.

But more is not always better. Shove too much information into an LLM’s context window and it struggles to separate signal from noise, much as a human would. It latches onto the stale note, the obsolete calendar invite, or the half-dead pattern buried somewhere in the repository.

The same tradeoff applies to tools. Give an agent tools that are too primitive and it has to reconstruct higher-level behavior itself, fumbling through ten brittle steps for something that should have been one reliable operation. Give it too many tools, or tools with sprawling and ambiguous interfaces, and it struggles to choose between them, passes the wrong arguments, or chains them together incorrectly.

The quality of the tools matters just as much as the intelligence of the model using them, and a mediocre model in a good harness can beat a frontier model dropped into a bad one. For example, a better search engine like Exa gives the agent cleaner raw material. A faster browser like Lightpanda, which throws out rendering entirely and does the same crawl in a fraction of the time Chrome needs, lets it explore more paths before the task times out. A narrow, well-designed API can outperform a general computer-use interface because it removes entire categories of possible mistakes.

If this is starting to sound a lot like the same stuff software engineering has been doing for decades, that’s because it is. The durable advantage will belong to whoever gives you the most control over what the agent sees, what it can do, and how those capabilities are assembled. That is where open source has always been strongest.

5. Specialized models and harnesses will dominate, coordinated by a central orchestrator

For now it’s useful to talk about the model and the harness as separate things. The model supplies the raw capability; the harness decides what it sees, what it can touch, and how its work is checked. That split won’t last. Specialized models and the environments built around them will be trained, evaluated, and sold as one system, and asking where the model ends and the agent begins will be like asking where a database ends and its query planner starts. Technically answerable, but mostly irrelevant to the person using it.

These specialized systems will win for three reasons.

First, the money. Today’s token spend is subsidized by VCs and trillion-dollar balance sheets terrified of missing the next platform shift, and that era is closing fast. GitHub moved every Copilot plan to usage-based billing, heavy agentic users are reporting bills 10 to 50 times higher, Microsoft pulled its own engineers off Claude Code after per-seat costs hit $2,000 a month, and Uber burned its entire annual AI budget in four months.

The days of cheap Uber…I mean, cheap token spending are over.

Meanwhile, capable open-weight models keep arriving with absurd token efficiency, and using the largest model available for every task is like hiring a Nobel laureate to alphabetize your filing cabinet. Most work doesn’t need everything the model knows, just a narrow slice of it, delivered cheaply and reliably.

Second, the math bends toward cheap. Approximating data you already have is exactly the kind of problem that gets relentlessly cheaper: distillation squeezes a big model’s behavior into a small one, and inference at a fixed level of quality keeps collapsing in cost. What doesn’t get cheaper is new knowledge. A human still has to discover it, prove it, and write it down before a training run can absorb it.

Third, and thorniest, proprietary data is the moat. The open web that trained this generation of models is filling with their own output, and training on that sludge gives you a photocopy of a photocopy, blurrier with every pass. The way out is data nobody else has: your codebase, your incident history, your customers’ actual support tickets, the fixes your best engineers make on instinct, the tribal knowledge nobody ever wrote down clearly enough to scrape. As the public corpus rots, the premium on a clean private well only rises.

Tomasz Tunguz compared where this leads to databases: one category that fragmented into relational, document, graph, time-series, and vector stores, each shaped around a workload. Models will fragment the same way.

Skill files are a crude preview. They package domain knowledge into something the model loads at runtime, which means paying to reread and reinterpret the same material on every task. A fine-tuned model is that skill file compiled into the weights; Callstack’s Apex, tuned for React Native, is an early example. The likely destination is a mix: stable knowledge compiled into the model, changing context left in the harness, and lightweight LoRA adapters in between, so a skill becomes a module you load, combine, or drop without retraining anything.

You can already see early signs of this: Skill-to-LoRA replaces runtime skill text with skill-specific adapters, and Microsoft’s MoLoRA loads several at once and learns which to activate for each token. A Rails adapter. A Terraform adapter. A company adapter trained on your code, incidents, and conventions.

The harness is going the same way. Today it’s hand-built and fixed, a guess about the average task made before any task has arrived. JIT-Agent is the first serious attempt to kill that guess: a model trained to emit harnesses, composing memory, planning, and tool modules per task and repairing them when execution goes sideways. In a generated harness, DeepSeek-V4-Flash beats GPT-5.6 on DeepSearchQA by 9.1 points, GLM-5.2 gains up to 20.2, and the generated harnesses hold their own against Claude Code and OpenCode. The cheap model in the bespoke harness beat the expensive model in the generic one.

The famous counterargument is Rich Sutton’s “bitter lesson”: general methods that scale with compute have repeatedly beaten systems where humans tried to hard-code domain expertise. But the lesson assumes compute keeps getting cheaper, data stays abundant, and you have time for generality to win. Put a meter on every token and a deadline on every task, and the calculus flips. A specialized model isn’t a return to hand-written rules, either; it’s the same learning machinery aimed at a narrower distribution. The bitter lesson still governs the base layer. The products built on top of it are another matter.

Which finally brings us to the orchestrator.

The orchestrator doesn’t need to be the best model at anything. It needs to understand the task, break it apart, route each piece to the right specialist, and check that the pieces fit back together: architecture questions to a frontier model, implementation to a framework-specific one, security review to a third, routine repository chores to something small enough to run locally. That’s how the economics resolve: frontier capability only where ambiguity demands it.

The models already contain this architecture in miniature. A Mixture-of-Experts model doesn’t fire every parameter for every input; a router picks a few specialized experts per token, so the model carries enormous capacity without paying for all of it at once. The agent stack will do the same one level up, routing tasks between models, adapters, tools, and harnesses instead of tokens between experts. Whether the answer came from the weights, an adapter, a tool, or the context, the user will neither know nor care.

From the outside, it will simply feel like competence.

5b. Open source gets a new business model

This new paradigm also creates a potential way to monetize open source.

In January 2026, Tailwind laid off three of its four engineers while the framework was more popular than ever, powering a huge share of the sites produced by the vibe-coding boom.

Its business depended partly on documentation traffic. Developers searched for how to center a div, landed on the docs, and some fraction bought Tailwind UI or another paid product. AI assistants now answer the question directly, so the framework can remain widely used without sending attention or revenue back to the people who built it.

Open source has always struggled with this mismatch. A project can sit underneath half the internet while capturing almost none of the value it creates. AI makes the mismatch worse by removing the few remaining points where attention flowed back to maintainers.

But the same shift that destroys the documentation funnel may create its replacement.

Depending on where the tooling lands, that replacement could be a model fine-tuned on the framework itself, a set of LoRA adapters, or a maintained skill and plugin package that drops the project’s conventions directly into whatever agent you use. The implementation may vary, but the business model is the same: the people who built the framework, and understand it better than any general model scraping its documentation, sell the canonical way to wield it.

Instead of selling access to an answer one consulting hour at a time, maintainers can encode their expertise and judgment into something an agent applies repeatedly. Keep the package current as the framework evolves, charge for access or updates, and that knowledge becomes a scalable product rather than a service constrained by the number of hours in a day.

You could even move advertising into the tooling itself. That may sound like blasphemy, but a single sponsored status line in your terminal is a small price to pay if it keeps the open source project underneath your entire stack alive. I’m exploring a version of this model now. If you maintain an open source project and the idea sounds interesting, reach out.

6. The role of a Sofware Engineer will keep changing, but demand will continue to outpace supply

Repeat after me: LLMs are not intelligent. They cannot set intentions, decide what is worth building, cook up truly novel ideas, or take accountability for their decisions. There will always be a need for human operators to supply direction.

And for those humans to participate meaningfully in the software development lifecycle, they still need to understand the software being built. You cannot specify what correct means, judge whether an abstraction fits, or recognize when an agent has confidently wandered into nonsense without understanding the system beneath it. The code may increasingly be written by machines, but responsibility for it cannot be.

It may not feel like demand is outpacing supply because the software job market is brutal right now. But we are still coming down from two overlapping distortions: Covid forcing years of digital transformation into a few quarters, and zero-interest-rate overhiring that treated engineers like a speculative asset. The correction was always going to be painful, with or without AI.

You could argue that company leaders are laying off engineers because they see where the market is headed. I personally don’t buy it. Record profits, repeated re-hiring after cuts, and a general lack of understanding of how software actually gets built, all suggest something simpler: AI became a convenient story for cost cutting that was already going to happen.

If you are skeptical, ask yourself a simpler question: do you, or any engineers you know, work less since you started using AI?

Probably not.

The classic explanation is Jevons paradox. When a resource becomes cheaper or more efficient to use, consumption often rises enough to offset the savings. More efficient engines did not reduce coal consumption. They made coal economical for more uses.

Software follows the same pattern. When building a feature becomes ten times cheaper, companies do not build the same number of features with one tenth of the staff. They attempt ten times as many features, automate work that was never worth automating before, maintain more internal tools, personalize more workflows, and expand the frontier of what counts as economically viable software.

On a micro level, practices that once felt too expensive or tedious to apply consistently will make a comeback. Test-driven development, domain-driven design, formal specifications, property-based testing, exhaustive observability, threat modeling, and all the other acronyms we invented and then selectively ignored because deadlines were real.

In the past, a startup could get away with poor engineering practices because it wrote code slowly enough for humans to keep some rough picture of the system in their heads, so the mess accumulated gradually. When agents can generate a month of implementation in an afternoon, the same lack of discipline becomes catastrophic. You can create a codebase faster than anyone can understand it.

Best practices therefore move earlier in the development lifecycle. Tests are written before implementation not because someone finally won an argument about methodology, but because agents need a machine-readable definition of correctness, an eval if you will. Architecture has to be made explicit because the system can no longer rely on conventions being absorbed slowly through osmosis. Documentation, invariants, schemas, and constraints stop being chores performed after the work and become the inputs required to do the work safely.

We also lose most of our excuses for tolerating technical debt beyond the phase where we are still discovering the right abstraction. If a language is unsuitable for the workload, an agent can help migrate it. If a legacy library is holding the system back, an agent can replace it. If a critical path needs a more performant component, an agent can write and benchmark several versions before lunch.

That does not mean every migration becomes wise, as you still need to decide whether the benefit justifies the risk, define the migration path, preserve behavior, and know which ugly parts of the old system were accidental and which were load-bearing. But at least you can automate the boring parts.

This is also the engineer’s side of the bargain. Every hour not spent on grunt work and boilerplate is an hour spent understanding the technology one layer deeper, and that understanding is precisely what extends the agent: sharper specs, better tools, evals that mean something, more work that can be offloaded safely. Less grunt work buys more understanding, and more understanding buys more leverage. It is a virtuous cycle of learning, but only for those who spend the time they get back on learning rather than on more prompting.

More broadly, the job moves up the stack from writing code to specifying systems. Engineers will define invariants, design verification, decide what correct means, and audit fleets of agents the way a line manager audits stations on a production floor. “Everyone is an architect now” gets thrown around a lot, for good reason, though the defining job of an architect was never drawing diagrams. It was managing risk and preserving optionality: making the few decisions that are expensive to reverse slowly and deliberately, and structuring everything else so it stays cheap to change your mind later. That skill becomes essential the moment agents can pour concrete at ten times the speed, because when implementation is nearly free, the cost of a system is how difficult it is to change.

This will require a psychological reorientation. Engineers have started describing themselves as the bottleneck, and if you accept that framing, the logical endpoint is getting rid of yourself.

The better frame is rate limiter, quality gate, and direction setter. A bottleneck is a flaw in the line. A rate limiter is part of its design. Engineers who see review as an obstacle start cutting corners. Reviews become shallow, agents merge more code than anyone understands, and soon nobody is watching the system evolve.

The scarce skill stops being syntax and becomes judgment, which mostly means taste: knowing when a feature is bloated, when an abstraction is premature, when a release should slow down, and when not to ship at all. Agents raise the stakes on both sides of that judgment. Every option you preserve gives the fleet more room to operate. Every irreversible decision made carelessly becomes a foundation a tireless machine can build a thousand things on before anyone notices.

7. Small companies will operate like Big Tech, and Big Tech like small companies

Trying to be Google when you are not Google has always been a good way to drown in processes you did not earn. Google could throw an org at a problem. You had three engineers and a Notion page.

Agents invert that equation.

A five-person company will be able to operate capabilities that once required entire departments: platform engineering, QA, security, data infrastructure, internal tooling, compliance, and customer support. Small teams will gain much of the operational surface area of large organizations without inheriting their headcount.

They will maintain more products, support larger customers, run more experiments, and build internal systems that would previously have been dismissed as too expensive for a company their size. Not because the work disappears, but because a small number of people can direct far more execution.

The reverse happens inside Big Tech.

Large companies were built around the assumption that execution was scarce enough to justify enormous coordination costs. Every new problem could support another team, and every new team brought managers, planning cycles, roadmaps, dependencies, status meetings, and approval chains.

Agents make execution cheap. Coordination remains stubbornly human.

A company with fifty teams does not automatically produce fifty times as much. It may produce fifty competing priorities, duplicated systems, and six months of cross-org alignment before anyone can change a button. The faster agents make each team, the more obvious the cost of coordinating all of them becomes.

The giants will discover that much of what looked like scale was coordination overhead made tolerable by enormous margins. As smaller competitors begin shipping with a fraction of the people, large companies will be forced to collapse management layers, combine functions, and give smaller groups ownership over much larger surfaces.

The basic organizational unit starts to resemble a startup: a few people with broad responsibility, supported by agents instead of a pyramid of narrowly scoped specialists.

This will also change what management means. A manager whose primary job was moving information between layers becomes difficult to justify when agents can summarize, plan, report, and coordinate routine work. The valuable manager will look more like the engineer described in the previous section: someone who sets direction, resolves ambiguity, allocates scarce attention, and takes responsibility for decisions that are expensive to reverse.

Small companies will gain the leverage of Big Tech. Big Tech will be forced to rediscover the speed and ownership of small companies.

The companies in the most danger are those caught in the middle: carrying the coordination costs of a large organization without the capital, distribution, or margins that once made those costs survivable.

8. The current AI leaders will be martyred in the process

Anthropic in particular has been on an absolute tear, assembling what may be the most star-studded roster in the history of tech and shipping at a pace that makes most companies look asleep.

But no matter how cracked the roster, mere men cannot conquer market forces.

This is not an argument that Anthropic is badly run. On the contrary, it may be the best-run frontier lab, which is why it makes the best example.

Anthropic was built to win the frontier-model era: train the most capable general model, own the infrastructure to serve it, charge by the token. In May 2026 it raised another $65 billion at a $965 billion valuation to keep doing exactly that. Every part of the machine assumes frontier intelligence stays scarce.

Everything above runs against that assumption: cheaper models, better open weights, knowledge compiled into adapters, orchestrators that reserve frontier capability for the few tasks that need it. The model becomes a component, and the value moves to the data, the workflow, and whatever decides which model to call. Customers don’t want to maximize their frontier-token bill. They want to minimize it without degrading the result.

Anthropic clearly understands this. Claude Code is a harness, and it may be the clearest evidence anywhere that the product is worth more than the model beneath it. So it’s moving up the stack: Claude Cowork, Claude Design, and vertical workflows like legal. OpenAI is making the same move with ChatGPT for Financial Services.

Neither is likely to win the war against the open model. A developer in Montreal making CAD 60,000 can take an open model at a hundredth of the cost, tune it around one narrow workflow, wrap it in tools built for that job, and match the general product. In a narrow enough domain, beat it. Anthropic attacks the same market with a team that costs millions a year, the overhead of a frontier lab, and infrastructure expensive enough to justify that lab’s existence.

The solo developer, SMB, and even Enterprise customer uses whichever model is cheapest and switches whenever the market moves. Anthropic can’t, because its products exist to protect the model business, and a product pivots more easily than a balance sheet. Cowork, Design, Legal, and whatever comes next don’t just need to be good businesses. They need to carry the frontier lab beneath them. The startup is free to optimize for the customer. Anthropic must also optimize for Anthropic.

Now multiply that by every vertical it enters, each defended by people who have spent their careers on one design tool or one legal workflow. Talent, distribution, and brand buy an excellent horizontal interface, but good packaging only makes people tolerate subpar software for so long.

History rhymes; Netscape taught the world to browse, then lost the market when Microsoft bundled Internet Explorer into Windows. AltaVista made the web searchable, then lost it to Google. Sun sold the servers that powered the dot-com boom, then ended up inside Oracle. None of them were staffed by idiots. They were optimized around the bottleneck of one era just as the value migrated to the next.

The model labs are building the same bridge: historic sums spent industrializing the production of intelligence at the very moment intelligence becomes abundant, modular, and interchangeable. Their success accelerates the commoditization that threatens them.

That said, Martyrdom doesn’t have to mean bankruptcy. Anthropic could stay enormous as infrastructure for someone else’s products. But relative to the value creation that’s going to happen, their slice of the pie will look increasingly small.

At least the early employees will be able to dump their bags on to the general public post-IPO before reality catches up, and with the money and talent coming out of the comapny’s carcass, the Anthropic Mafia is going to be unbelievable.

9. Power law amplification in the broader market

Want to see what democratized creation produces? Look at social media. Everyone has a camera and everyone posts. Why is everyone not an influencer?

The mistake in “everyone will be a software engineer” is assuming people want to be. This may come as news to some of you, but we’re very weird people. Like, really weird. The average person does not, believe it or not, enjoy spending a Sunday morning tinkering with a new JavaScript framework.

The same way most people do not want to do their taxes, most people do not enjoy the act of developing software. Sure, the initial rush of building that got most of us into software engineering is now more accessible than ever, but the difference between production software and a nifty project has never been larger, and most people would rather outsource it to someone who is good at it and not think about it at all.

App Store submissions jumped 84 percent in a quarter, enough to buckle Apple’s review pipeline, and yet attention and revenue remain concentrated among the few who treat the work as a craft. The tools spread to everyone. The rewards do not.

The explosion in quantity also makes room for an explosion in quality because the marginal cost of polish is collapsing. Case in point, this post has illustrations I would never have made by hand. The people who care about the work will not just outlast the flood. They will use the same tools to raise the ceiling.

That probably means an even wider divergence in pay. When one exceptional engineer can direct the output of what used to be a team, their economic value starts looking less like a normal salary band and more like professional sports. Big Tech already paid its best engineers multiples of everyone else. Agents give the best operators even more leverage.

The other place where the social media analogy holds is distribution. As building gets cheaper, getting anyone to care gets harder. Having an audience, a recognizable voice, and an active presence online becomes part of the product whether you like it or not.

Software is becoming abundant, while our attention is scarcer than ever, and it’s practically an all-out brawl over it.

10. We’re still very early

As an LLM would say: this isn’t a cop-out, this is an acknowledgment.

I’m betting both time and money on these predictions, but the truth is that we really don’t know what the true second, third, and fourth order effects of releasing these amplification machines unto the world are going to be, nor what breakthroughs in their core tech await us, nor what applications that previously seemed implausible have suddenly become possible.

The software world is unique in the sense that it’s already 100% digital. But even then, LLMs have cranked up exactly one station, code generation, while every adjacent station still runs at the old speed. In legal, Legora and Harvey have made research and drafting dramatically faster, while discovery, negotiation, filing, and the court’s own calendar move at precisely the speed they did a decade ago. Speeding up one station on a slow line doesn’t give you a faster line, it gives you a pileup, and I suspect the coming decades will be about finding where those pileups accrue and equipping workers with the skills to run the stations that are still stubbornly human.

There’s also still a massive skill issue as we learn to harmonize, as AI usage reports read like early computing reports: lots of perceived productivity, not much real productivity. Experienced open source developers using AI tools turn out to be 19% slower while believing they’re 20% faster. We’ve run this experiment before. Businesses spent the 70s and 80s pouring money into computers while the gains stayed invisible in the productivity statistics. They only showed up in the late 90s, once firms restructured work around the machines instead of bolting them onto old processes. The companies that did the restructuring saw gains several times larger than the ones that just bought the technology.

But what’s clear today are the limits of our current processes, since we’ve made writing code fast, and left everything around it slow.

Which is where the next part picks up: what a tool built for that problem — rather than for faster typing — actually has to look like.