In finance, there's a distinction between compensated and uncompensated risk. Compensated risk is the volatility you accept in exchange for expected returns: you buy a diversified portfolio knowing it will fluctuate, while expecting it to grow over time. Uncompensated risk is volatility without expected return, exposure to factors you're not being paid to bear. The former is the price of playing the game. The latter is just gambling with extra steps.
Technology leadership has its own version of this distinction, though we rarely name it.
When a new platform emerges, a new paradigm shifts, the instinct is often to wait. Let the early adopters find the pitfalls. Let the dust settle. Be prudent. This feels like risk management. Sometimes it is. Most new technologies don't pan out, and the patient operators who ignored the hype often end up ahead. But sometimes the caution itself becomes the uncompensated risk. It's the equivalent of holding a concentrated position in a stock that's been winning for years, assuming the past will continue to predict the future. Kodak held that position in film. Blockbuster held it in retail. The bet isn't that you're right about the technology, the bet is that you'll have time to adapt when you're wrong. When that bet fails, it fails quietly, which makes it dangerous.
The opposite instinct carries its own dangers. When a technology does seem to be panning out, the temptation is to grab it with both hands and run, to move fast and figure it out later, to ship now and understand never. This is the FOMO trade: chasing a stock because it's already up, buying the momentum without understanding the fundamentals. Sometimes it works. More often you end up holding something you don't understand, with an assumed growth you can't verify, with no clear plan for when to get out.
So the question for anyone leading a technology organization in the middle of the most significant shift in how software gets written since the advent of the internet is not whether to adopt AI, but how to adopt it in a way that's actually compensated. How do you take on variance that improves your expected outcomes, rather than variance that just makes things more volatile? How do you take compensated risk?
⁂
Steep yourself in early 2023. Stack Overflow has just crossed 100 million monthly visits, the culmination of fifteen years as the canonical answer to every programming question. Tailwind CSS is approaching $2 million in annual revenue, growing into an eight-person team, its documentation pages the funnel that drives the entire business. Adam Wathan, Tailwind's creator, is writing about how a side project became a multi-million dollar company. If you think it through, you won't be surprised to learn that by late 2025, Stack Overflow's monthly question volume will have fallen below what it was three months after launch, in 2008. Tailwind's revenue will be down 80 percent, despite being more popular than it has ever been.
"One of the hardest things for me," Wathan said on his podcast on January 7, 2026, "is feeling like a fucking idiot for somehow being able to build this CSS framework that's like, taken over the world and is used by everything and is super popular, but I can't figure out how to have it make enough money so that eight people can work on it... which is like nobody."
As of early 2026, Tailwind usage was at an all-time high. Seventy-five million downloads a month. And yet.
Here's what happened: they thought standing still was the safe option.
Stack Overflow's business was search traffic monetized through job ads and enterprise subscriptions. Tailwind's business was documentation traffic: developers googled "how to center a div in Tailwind," landed on the docs, discovered Tailwind UI's premium components, and maybe bought something. The framework itself was free; the docs were the funnel.
When ChatGPT launched in November 2022, both companies had reason to believe their models would hold. AI would hallucinate, developers would learn to distrust it, the old patterns of searching and reading documentation would persist. The risk they didn't price in was that AI would be good enough. It was.
Wathan wrote on GitHub on January 7, 2026, responding to a community pull request, "The reality is that 75% of the people on our engineering team lost their jobs here yesterday because of the brutal impact AI has had on our business. Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever. The docs are the only way people find out about our commercial products, and without customers we can't afford to maintain the framework."
In an episode of his podcast titled "We had six months left," Wathan described the slow decline as a "boiling the frog situation." Revenue dropped so gradually that he almost didn't notice. He got used to the lower numbers. They felt normal. It wasn't until he did proper forecasting over the holidays that he realized: "If absolutely nothing changed, then in about six months we would no longer be able to meet payroll obligations."
In both cases, the "safe" choice (continuing to operate the business that was working) turned out to be the uncompensated risk. They were exposed to massive downside with no corresponding upside, as the market didn’t reward them for staying the course. The variance was all in one direction.
Maybe Stack Overflow and Tailwind were just unlucky. Maybe their specific business models were unusually exposed to AI disruption, and most companies are fine. Maybe the rate of change will slow, giving everyone time to adapt. Maybe this will all look like a bubble in retrospect.
I don't find any of these scenarios convincing, because the pattern is too consistent: companies that treat AI adoption as optional are getting blindsided. But even if you grant the premise that something must change, there's a second failure mode waiting.
⁂
The opposite of sitting on your hands is flailing.
Call it vibe coding: copy-pasting from ChatGPT without understanding what you're shipping. The output works, mostly. The tests pass, mostly. The feature gets deployed. And then, six months later, someone needs to modify it and they discover that nobody (not the original author, not the AI, not the reviewer who waved it through) actually understood why it worked.
This is the other uncompensated risk. You're adding variance to your outcomes without improving expected value. Security holes appear in places no one thought to check. Architectural decisions compound in directions no one intended. The codebase accumulates what I can only call mystery: sections that function but that no one can explain and that therefore no one can safely change.
The tell is simple: when something breaks, you don't know why, and when it works, you don't know why either. Mystery compounds. Every mystery module is a future incident. Every incident is a future outage. Every outage is a future conversation with your CTO about why the system you shipped is now a liability.
The vibe coder's defense is that they're moving fast. But speed without understanding is just velocity in a random direction. You might be moving toward your goal and you might be moving away from it, and you won't know until you arrive somewhere you didn't intend.
⁂
What separates compensated risk from uncompensated risk in AI-assisted development?
The craft didn't disappear. It moved.
Consider Rails. Out of the box, Claude produces the kind of Rails that junior developers write after reading too many Medium posts: service objects scattered everywhere, callbacks sprinkled across models, resources that don't map to REST, abstractions introduced before they're needed. It works, technically. But it's not Rails the way DHH intended it. It's not the kind of code that compounds, the kind that becomes easier to maintain over time rather than harder.
The craft is knowing that CRUD and resources are preferred, that Concerns are for composition, that service objects are a smell rather than a pattern, that the framework's conventions exist for a reason and that reason isn't to be circumvented at the first sign of complexity.
But here's the thing: Claude doesn't know this, not reliably and not consistently. If you ask it to write Rails code, it will write Rails code, and that code will run, and you will have learned nothing about whether it's the right Rails code. The model has ingested every Rails tutorial ever written, including the bad ones. Especially the bad ones.
So the craft, now, is encoding that knowledge. Building skills that assert your conventions. Writing hooks that catch drift. Defining what "good" looks like in a way that can be verified, not just vibed.
This is where the work went. Not into typing characters; rather, into defining constraints.
⁂
Boris Cherny, the creator of Claude Code at Anthropic, disclosed in late December 2025 that he didn't open an IDE for an entire month. Every line of code he shipped (259 pull requests, 497 commits, 40,000 lines added, 38,000 lines removed) was written by AI.
This is not vibe coding.
Cherny runs multiple Claude instances in parallel, acting as what he calls a "fleet commander." He maintains files that encode project conventions, so that every time the AI does something incorrectly, the correction becomes a rule. He uses test-driven development, writing failing tests that define correct behavior before letting the AI implement solutions. He reviews everything.
"The future of coding," Cherny wrote in June 2025, "would be less about writing code and more about reviewing it."
The shift is real, but it would be a mistake to take Cherny's workflow as a universal template. He works on a codebase he knows intimately, building tools for other developers, in an environment where rapid iteration matters more than regulatory compliance. His context permits an approach that would be reckless in others.
Consider a payments system processing financial transactions, or a healthcare application handling patient records, or anything touching personal data in a jurisdiction that takes privacy seriously. In these domains, the character-by-character craft of writing code hasn't been displaced. Someone still needs to understand exactly what happens when a transaction fails, exactly how data flows through the system, exactly which edge cases can corrupt state. The stakes are too high and the failure modes too subtle to delegate entirely to generation and review.
But even here, AI changes the nature of the work rather than eliminating it. A developer writing financial transaction code can use AI to review their logic, to suggest edge cases they might have missed, to check their implementation against regulatory requirements. The craft of careful, deliberate coding remains essential; AI becomes a collaborator in that craft rather than a replacement for it.
The point is not that typing is dead, because it isn't. The point is that the relationship between typing and thinking has changed. In some contexts, you can now think in constraints and let AI handle the keystrokes. In others, the keystrokes themselves are the thinking, and AI's role is to augment your attention rather than replace your hands. Knowing which context you're in is itself a form of expertise.
⁂
At Fetchly, we've been thinking about this as a question of leverage.
The old model of software development was labor-intensive in predictable ways. You needed people to write code, test code, review code, deploy code. Each step took time and each step required attention. The constraint was hours.
The new model changes the constraint. AI can generate code faster than humans can review it. The bottleneck shifts from production to verification, from writing to understanding, from "can we build this" to "should we build this, and is what we built actually what we intended."
This means the returns to understanding have gone up, not down. If you can verify faster (because you've encoded your standards into automated checks, because you've built skills that assert your conventions, because your team deeply understands what good looks like) you can leverage AI more aggressively. If you can't verify, you're just generating mystery faster.
Our approach is to invest in the new craft layer.
Start with skills that encode domain expertise. Rails the DHH way, yes, but also: Shopify integrations that follow the platform's actual patterns rather than fighting the Admin API, ERP middleware that respects the boundaries that fifteen years of enterprise software have taught us matter, database schemas that anticipate the queries you'll actually run instead of normalizing for theoretical purity.
These aren't the kinds of insights that appear in tutorials. They come from production incidents and late-night debugging sessions and long conversations with clients who've been burned before. But they can be encoded.
The Svelte team understood this instinctively. When Svelte 5 shipped with its new runes syntax, every AI assistant on the market confidently generated the old reactive patterns, mixing $: declarations with $state() calls in ways that wouldn't even compile. The team could have complained about training data cutoffs. Instead, in November 2025, they released an official MCP server that gives AI assistants access to current documentation and validates generated code against Svelte 5 patterns before it reaches the developer. The craft moved: from writing Svelte to teaching machines how Svelte works now.
The knowledge that makes good code good doesn't disappear when AI writes the code. It becomes the specification that AI writes to.
Then there are hooks that assert correctness: not just tests that check behavior, but architectural constraints that catch drift. If the AI generates a service object in a project where we've decided service objects are a smell, that's a signal, and the system should surface it before a human has to notice.
Plan-first workflows that separate what from how, defining the shape of the solution before generating the implementation. This is where human judgment compounds: in deciding what to build, not in typing the characters that build it.
And review as core competency, where the code is generated and the understanding is verified. This is the work now: reading with intention, catching the subtle wrongness that passes all the tests but violates the invariants you haven't made explicit yet.
And yes, in domains where the stakes demand it, we still write code character by character. The difference is that we make that choice deliberately; understanding which parts of the system require that level of attention and which parts can be safely delegated. The judgment about where to apply craft is itself a form of craft.
⁂
Is this approach guaranteed to work? Of course not. There are valid reasons to hesitate.
Maybe the models will plateau, and the current wave of capability is as good as it gets. Maybe the returns to understanding will diminish as AI itself becomes better at verification. Maybe we're overcorrecting, investing too much in the new craft layer when the old one still matters more than we think.
But consider the alternatives.
The sitting-on-hands approach bets that the disruption will slow down, that we'll have time to adapt later, that the things we're good at today will remain valuable tomorrow. Stack Overflow and Tailwind made that bet. The results are not encouraging.
The vibe-coding approach bets that speed is sufficient, that understanding is optional, that you can outrun the consequences of not knowing what you've built. This is the single-stock bet: sometimes it pays off, but usually it doesn't, and when it doesn't the downside is severe. Technical debt that can't be reasoned about, systems that can't be safely modified, teams that have shipped product but haven't built capability.
The Fetchly approach bets that craft still compounds, but at a different layer. That the developers who understand their domain deeply will leverage AI better than those who don't. That encoding expertise is itself a form of expertise. That verification scales with understanding.
This is, we think, a compensated risk. We're taking systematic exposure to a technological shift while maintaining the judgment layer that makes that exposure pay off. We're not betting on any single tool or model. We're betting that deep understanding still matters, and that it matters more now than it used to, because understanding is the constraint on how much leverage you can safely take.
⁂
Linus Torvalds published a hobby project in January 2026 called AudioNoise, a learning exercise in digital signal processing that grew out of his guitar pedal experiments. The Python visualizer was generated entirely by AI. "I cut out the middle-man," he wrote in the README, "and just used Google Antigravity to do the audio sample visualiser." The audio processing logic, though, he wrote himself in C.
The Linux kernel still gets the same exacting attention it always has. Torvalds knows exactly where the boundary lies, and the boundary isn't arbitrary. Two factors determine it.
The first is system criticality. The kernel underpins most of the internet's infrastructure; a subtle bug can cascade through millions of systems. A Python visualizer for a hobby project can break and nobody cares. The cost of failure determines how much verification you need, and verification is still the bottleneck.
The second factor is novelty. The kernel is a unique artifact with decades of accumulated decisions that aren't documented anywhere but the code itself. AI can't draw on prior art because there isn't any; the kernel is the prior art. A Python visualizer, by contrast, has thousands of examples to learn from. The problem is well-trodden. AI can pattern-match its way to something that works.
High criticality and high novelty demand full attention. Low criticality and low novelty can be safely delegated. Most systems fall somewhere in between, and the judgment about where each component lands is the work.
This is the same judgment Torvalds applied to Rust in the kernel. In 2021, he was explicitly in the "wait and see" camp: interested in the promises, skeptical of the excitement, wanting to see how it worked in practice. By late 2022, the evidence was sufficient; Rust was merged. By December 2025, it was declared a core part of the kernel, no longer experimental. He didn't rush in. He didn't resist forever. He watched, evaluated, and moved when the case was made.
This is not a new kind of judgment. Technology leaders have always faced the question of when to adopt, when to wait, and when to hold the line. What's different now is the pace, and the cost of getting it wrong in either direction. The questions for technology leaders today: do you understand your own systems well enough to know where the boundaries are? Which parts are critical enough that failure is catastrophic? Which parts are novel enough that AI can't pattern-match its way to correctness? Which parts are commodity problems with abundant prior art, where delegation is not just safe but efficient?
The answers aren't obvious. They require a deep understanding of your own stack, your own competitive position, your own tolerance for different kinds of failure. The work is hard. It's also the only work that matters.
The craft isn't dying, it's shifting.
