Author: Madhu Shashanka

Anthropic recently started stamping an invisible watermark into everything Claude writes. The watermark is a modest piece of engineering. It was released to satisfy the European Union’s AI Act, which now asks AI providers to mark machine-generated text. Within a day, people shipped free tools to scrub it off.

A few weeks before, a multimillion-dollar book deal fell apart because the author’s own agents could not prove he had written the novel himself.

Two different worlds, same reflex. Rather than judge the work, we reach for a way to trace the tool.

The trace is easier than the judgment. It is also the wrong thing to measure, and that is the mistake worth examining. Brace for a long post as there is quite a bit of nuance to wade through.

The puzzle

We hand large parts of coding to AI and call it good practice. Experienced engineers let models draft and test significant chunks of code, and spend their own time on design, architecture, and review. Nobody calls that fraud.

Hand a sentence to the same AI, and the verdict flips. Using AI to write is looked down on, quietly or loudly.

Same tool. Opposite judgment. Why does the tool that makes you a competent engineer make you a suspect writer?

The answer is verifiability

In the book I lean on one property to predict where AI improves fastest and performs most reliably. Verifiability. A task is verifiable when its success can be specified in advance and checked. Code sits at the high end. You can state what working means before you write a line, and the check runs on its own. It compiles or it does not. The tests pass or they fail. Clean, cheap feedback is exactly what these systems learn from, which is why coding improved faster than anything else.

It is also why we forgive the tool here. When you can check the result easily and at scale, you stop needing to know how it was produced. The proof is in the running system. Where you cannot check the result, you reach for the next best thing, a guess about who or what was involved.

For writing, everything depends on one clarification: verify what, exactly. Verify the goal of the writing, whether it did the job it set out to do. That is a separate question from whether the content is true in the world, and it returns when we get to accountability. And like any task, verifiability lives at the level of the specific goal. “Writing” as a whole has no single answer. That is why “writing” is a trap word. It covers at least three goals that sit in very different places.

Some writing is functional. Its goal is to carry an idea from one head to another. Manuals, release notes, briefings, most business prose. The form is disposable. The goal is specifiable. You can say in advance what it would mean for the idea to land, and you can check whether it did with a rubric and a test reader. You judge it much the way you judge code, and almost nobody gets upset about AI here.

Some writing is expressive. The writing is not just the form or mechanism but also the end goal in itself. Poems, stories, essays, a voice you came for. Its goal is the experience it evokes in the reader. A person can judge that, and good readers agree more than you would guess. But the standard will not reduce to a specification that runs without them. Every verdict needs a human in the loop. Readers come to expressive work for a human voice, and they feel cheated when the voice turns out to be a machine. Bad AI creative work offends the most, because it asks for an emotional response it never earned.

And a lot of writing lives in between. Thought leadership, newsletters, a company’s voice. It carries an idea and represents its author at the same time. Most writing that people actually argue about lives here.

The flood, and the trap it sets

The complaint I hear most is a fair one. People say they can see through AI writing now. There is an ocean of it. They are tired, they are busy, and they want a faster way to sort it than reading every word.

That sounds like verification working. It is pattern-matching on a fingerprint.

When AI prose was rare, the fingerprint and the badness came together. The tells in the style and the emptiness of the content were the same texture, so spotting the style was a decent proxy for judging the quality of content. Volume broke that link. Now the tells sit on top of real thinking and on top of filler alike. The surface no longer tells you which is which. So readers lean harder on the fingerprint in the style, and they throw out the good with the bad.

You can watch this happen in book publishing right now. A recent Wall Street Journal piece described literary agents so overwhelmed that clumsy, human writing has become a relief. One agent said the polished submissions flooding her inbox make “Fifty Shades of Grey” look like Tolstoy. Polish has become a signal of guilt. Competence in style reads as a machine. That is what happens when a fingerprint is the only tool you have.

The same piece put numbers on the deluge. One executive estimated that the overwhelming majority of AI books online exist to trick a buyer. One study, not yet peer-reviewed, found that around a fifth of the Amazon ebooks it sampled showed substantial AI help. The flood is real. The tools for sorting it are the problem.

What the watermark actually reads

The watermark answers one narrow question. Did a Claude model probably touch this text, given enough of it to measure. That is all. It does not know who had the idea. It does not know whether the writing is any good. It does not know whether another AI wrote the whole thing. It cannot even tell generation from light help. Run your own paragraph through Claude for a grammar pass, and it comes back marked.

And it is not alone. The industry is building a whole shelf of these instruments. Producer-side watermarks like Anthropic’s. Reader-side detectors like Pangram, which publishers are already using to vet manuscripts. Honor-system badges like the Authors Guild’s “human authored” certification, which rests on a signed attestation and, as the Journal notes, not much else.

Every one of them reads the same thing. Provenance. Which tool was in the room. None of them reads quality.

The clearest case in publishing is a dystopian romance that climbed the bestseller lists, got picked up by a major publisher, and then drew fire when a detector flagged it. Readers liked it. The market judged it good. And the provenance suspicion overrode that verdict anyway. The question stopped being “is this any good” and became “was a machine involved,” as if the second answered the first.

I will grant one place where provenance genuinely matters. Ownership. AI-generated text cannot be copyrighted, so knowing what a machine produced has real legal weight. That is a fact about property. It says nothing about quality. Keep the two apart and most of the confusion clears.

The tools can miss the wrong people

Detection does not just answer the wrong question. If it answers it badly, it lands hardest on the wrong people.

The detectors produce false positives. Authors deny the charge and have no way to prove a negative. Agents and editors, who signed up to find good books, now find themselves acting as police. The person using AI to clean up grammar in a language they learned as an adult gets flagged the same way as a spam farm. The motivated bad actor, meanwhile, runs the text through another model and walks away clean.

A signal that catches the honest and misses the deceptive protects no one. It is theater.

Slop has two axes, and provenance is neither

So if AI use is not what makes something slop, what does?

In the book I define slop as cheap creation meeting vague intent. It has two moving parts.

The first axis is intent. Is it clear what this is for, and for whom. That “for whom” matters. Frictionless prose that dumps a wall of text on a busy reader is an intent failure too. The writer never decided to respect the reader’s time.

The second axis is execution. Is it done well. Clear, economical, well made, serving the job it set out to do.

Slop is a failure on either axis. Four corners.

Clear intent, good execution, is craft. That is the only corner that is not slop.

Vague intent, good execution, is polished slop. It reads beautifully and serves no purpose, or ignores the reader it was aimed at. This is the dangerous corner, because the quality in style hides the emptiness.

Clear intent, poor execution, is a real point, botched. Still slop.

Vague intent, poor execution, is the pure kind nobody argues about.

The book’s definition looks narrower than this, because it is the same picture under one assumption. The book is about the AI era, and especially about agents, where execution is assumed to have cleared the reliability bar. Assume execution is handled, and that axis drops out. The four corners flatten onto the intent line: clear intent gives craft, vague intent gives slop. The only way left to make slop is to fail on intent. That is the case the book describes.

There is a reason intent is suddenly the axis that matters. Doing the work used to be expensive, and the expense screened out a lot of weak output before anyone saw it. It took effort to write and that effort alone screened out a lot of potentially bad writing. AI removed that screen. The cost of execution no longer filters anything. So intent is the only axis left doing real work, and it is the one no tool touches.

AI mostly lifts execution and leaves intent alone. So it multiplies polished slop, while the hard axis, intent, stays exactly as hard as it always was.

And the watermark? It reads a third axis entirely. Provenance. It runs at a right angle to both of the axes that actually define slop. A human can produce pure slop with no machine anywhere near it. An author with a clear point, using AI to execute well, produces craft. The detector cannot tell them apart, because it is not looking at either thing that matters.

Why writing takes the moral heat

The practical wariness about AI writing has a simple source. We cannot cheaply check the result, so we are left guessing. The moral charge, the sense of betrayal, is a separate thing, and it comes from what effort is a proxy for.

Expressive and in-between writing carry a costly signal. The time you spend is a proxy for how much you care, the same way a thoughtful introduction carries weight because the person made the effort to vouch for you. Spend that time and the reader feels respected. Let a machine spend it in a second, and hide that you did, and it can feel like deception. That is why the reaction to AI writing runs hotter than the reaction to AI code. Code was never carrying that signal.

Where I stand

I use AI in my writing. I use it here. I use it to sharpen sentences, to test an argument against its weakest point, to find the shorter way to say a thing. I am not shy about it, and I am not going to pretend otherwise.

I am unreservedly in favor of using AI for functional writing when it makes me clearer and faster. Wanting to be more productive is a good enough reason on its own. It needs no apology.

I am unreservedly in favor of using AI for functional writing when it makes me clearer and faster. I don’t consider myself a non-native speaker working in a second language he is not fluent in, and AI certainly is a real gift that scenario. AI also helps the fluent expert who simply wants leverage. Wanting to be more productive is a good enough reason on its own. It needs no apology.

The division of labor I keep is the same one every engineer keeps with code. I own the thinking and the judgment. AI helps with the production. And I check the result before it goes out. That last part is why what comes out is craft and not polished slop. I bring the intent. The tool lifts the execution. I verify the execution. The provenance is beside the point.

Even the publishing world, at its most protective, half-concedes this. One independent publisher, guarding the most human corner of writing there is, allowed that a genuinely meaningful work could earn a place on her list as long as it carried a clear note about how it was made. If that door opens even a crack for fiction, where human presence is the whole point, then for functional writing, refusing a useful tool is superstition dressed up as principle.

There is one real cost, and I will not wave it off. Writing is how you learn to think, and leaning on the tool can dull both the craft and the thinking behind it, not on any single piece, but in the writer, over time. That is the individual version of a problem I spend the book on, the slow erosion of a capability you stop exercising. It is a cost worth watching. It is also a different question from whether a given piece is slop, and it is answered the same way any skill is kept, by still doing the hard parts yourself. Which is exactly why I keep the thinking and the judgment, and use the tool for the production.

Own every word

There is one condition that makes all of this responsible, and it has nothing to do with which tool you used.

There is one condition that makes AI use responsible. Tool or no tool, the author is accountable for what goes out under their name, including any consequences.

You own every word. Tool or no tool, the author is accountable for what goes out under their name, including the consequences of anything they failed to check. A writer covered by an imprint recently shipped a book with quotes the AI had hallucinated. He had disclosed that he used the tool. He had not checked what it produced.

This is where the truth of the content comes back. The writing did its job. The quotes read cleanly and carried their point, so the goal was met and the prose was well made. But the quotes were still false. Whether a piece achieves its goal and whether its claims are true are two different verdicts, and the author owns both. The tool can lift the writing. It cannot carry the accountability.

This is also the distinction the whole detection industry misses. Provenance asks who produced the words. Accountability asks who answers for them. A detector chases the first. Everything that matters in business runs on the second. And the “I just used a tool” defense collapses. You cannot copyright what the AI wrote, so you may own less of the words than you think, while owning all of the liability for them. Less of the property. All of the responsibility. That is the deal, and it is the right one.

What this means past writing

This is not really about novels.

Almost all business writing is functional or somewhere in the middle. And leaders, faced with the flood, will reach for the same reflex publishing reached for. Ban the tool. Scan for the watermark. Make people prove they wrote it. It will not work. The marks come off, the detectors misfire, and the removers are already on GitHub.

Watch publishing to see the future of that approach. Literary agents turned into police. Certifications that rest on a promise. An entire trust-based industry being stress-tested by a volume it cannot inspect by hand. Detection and attestation are both attempts to replace trust, and neither scales against the flood.

What an organization actually needs is a chain of accountability. Someone has to answer for whether the work is good, and no trace of which tool touched it can supply that. The reason is the same one that runs through this whole piece. The standard for good work, in most writing and most judgment, cannot be fully specified in advance, so no detector and no rule can render the verdict for you. Detecting the tool is measurement. Judging whether the output serves its purpose and holds together is a harder thing, and a human one. A better detector will not get you there. What does is an architecture that keeps a person answerable for the result. That is what coherence means.

The last word

The compiler is why we forgive AI in code. It is a standard specified so completely that it settles whether the code works, cheaply, every time, and once that is settled we stop asking who wrote it. Most writing has no compiler. So deciding whether the work is any good stays with a person.

The watermark can tell you a tool was in the room. It cannot tell you whether anyone was thinking. That was never the tool’s job. It is yours.

Use the tool. Say so if you like. Stand behind every word. And let the work answer for itself.

My book, Coherence, arrives this Fall. If you want to follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.

I wrote recently about how studying the brain led me to the question at the center of my book. The short version: once you can trust individual agents, you stop deploying one and start deploying many, and a new question appears that has nothing to do with reliability. If every agent does exactly what it was built to do, does the fleet still add up to what the organization intended?

I changed my mind about agentic AI in stages, and fairly fast, as the evidence moved. I have watched the wider conversation move the same way. When I started shaping these ideas, the common view was that AI advantage meant model capability and speed of adoption. Buy the best model, deploy it fastest, win. In the last several months a different view has been gaining ground: that capability is commoditizing and the edge has moved elsewhere. I would not call it the consensus yet. But it is far more common than it was, and the change has been quick. You do not have to take my word that the ground is shifting. One firm left a record.

In July, BCG published a CIO/CTO playbook that led with speed. Its sequence was “speed first, growth second, cost third,” and its warnings were almost all about not scaling fast enough. In early August, BCG’s Global Chair published a piece whose argument runs the other way. The thing to protect, it says, is not speed but the “enterprise cortex,” the company’s own knowledge and judgment, and the choice facing CEOs “is not whether to favor control or speed, but where to apply both first.” Same firm, five weeks apart, the emphasis inverted. I do not read that as a firm caught contradicting itself. I read it as the honest response to a technology that keeps forcing revision, the same revision I made myself. What matters is the direction everyone is revising toward, because the ones who have accepted that capability commoditizes are all reaching for the same thing, and stopping at the same line.

The moat

The move that is replacing “buy the best model” is “protect your proprietary layer.” Satya Nadella got there through a trust boundary, a hard perimeter inside which your data and evals and corrections accumulate and across which nothing passes without consent. Larry Ellison got there through proprietary data. Kirkland & Ellis put half a billion dollars behind it, building its own AI platform rather than renting the tools its rivals can license. And now BCG’s most senior voice gets there through the enterprise cortex.

I want to give the August piece its due, it names a risk most people have felt without naming: cognitive lock-in. Old lock-in trapped you on a platform, where switching cost money. The new lock-in traps you inside a model’s way of reasoning, where switching becomes too risky to attempt because the model has absorbed how your company thinks. That is a real risk, well named, and the destination the piece arrives at is the right one. The model is a commodity. The moat is what the organization knows about itself.

I agree with all of that. I have argued it here before. Which is exactly why I want to point at the assumption sitting underneath the cortex, because it is the same assumption sitting underneath Ellison’s version, and it is the one that will actually catch these companies.

A brain has one cortex. An enterprise has many.

The piece calls the cortex “the brain of the company.” Singular. One protected core, owned and governed, with vendor models sitting on top and swapping in and out as better ones arrive.

A brain does have one cortex. An enterprise in the agentic era does not. It grows a dozen. Every team builds its own context layer, its own definitions, its own business rules, its own encoded sense of what good looks like, and no one owns how those layers combine. The advice on offer is to wall the cortex off from the vendor. The prior question, the one that decides whether the walling-off means anything, is whether you have one cortex or many that quietly disagree.

You can own every byte of it. You can keep every vendor out. And you can still fail, because your pricing logic and your inventory logic were never built to agree on what a “lapsed customer” is. That example is not mine; it is BCG’s own, from the July playbook, where a bad definition of “lapsed customer” was enough to send a whole campaign sideways. Owning the definition does not make it coherent with the next team’s definition. It just makes it yours.

The same gap

This is the mistake I traced when Ellison first made the proprietary-data argument, in The Moat Is Coherence. His claim was that data is the moat. Mine was that data is not scarce, coherent data is. Every enterprise already has data, most of it fragmented across systems, contradictory between departments, disconnected from the outcomes it produced. Pour that into a powerful reasoning engine and you do not get insight. You get fast, confident reasoning over an incoherent picture, which is worse than slow reasoning, because the confidence hides the incoherence.

The enterprise cortex imports the identical error one level up. It treats the corporate brain as a thing that already coheres and tells you to protect it. But owning your brain and organizing your brain are two different jobs. The first is a contract and an architecture diagram. The second is years of work no vendor can do for you, which is the whole reason it cannot be bought. The platform that stores and serves your knowledge is plumbing, and plumbing commoditizes. The coherence is the asset, and it is the part that compounds.

Ownership is a perimeter. The failure is inside it.

The cortex is defensive in the literal sense: keep the vendor out, keep the IP in. That framing makes the threat external, someone reaching in to take your brain.

The threat that actually shows up is internal. It is a brain that quietly stops agreeing with itself. There is no villain in that story, which is precisely why it runs for months before anyone notices. Amazon had a project run 860 percent over budget for five months with every token metered and invoiced the entire time, and still did not see it, which is the failure I’ve written about. The number was there but wasn’t being watched to compare against intent.

There is a structural reason a perimeter cannot catch this, and I worked through it in Good AI Governance Is Not the Same as Coherence. A perimeter, like a governance apparatus, works by reviewing things as they arrive at the gate. But the incoherence between a dozen brains does not arrive as an item to be reviewed. It accumulates in the space between systems that were each approved separately, each sound on its own. BCG has described a very good permitting office, the place that checks each plan against the code before it proceeds. The agentic enterprise needs an air traffic controller, the one watching the live system who catches the two aircraft converging that were each individually cleared to fly. Ownership does little about the two cleared aircraft inside your own airspace.

What is still missing

The discourse has gotten the first half right faster than I expected. More and more people now accept that capability is a commodity and the moat is what the organization knows about itself. A year ago that was a contrarian position. It is not anymore.

The part still missing is that knowing is not the same as coherising. A company can own its brain completely and still have a brain at war with itself. The firms that misread this will ask “do we own our cortex?”, check the box, and feel protected. The firms that read it right will ask the harder question: does it still agree with itself as it grows?

Owning the cortex is the easy part. Keeping it coherent is the whole job, as I explain in my book, Coherence, arriving this Fall. If you want to follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.

I have spent my whole career trying to understand intelligence. I studied neuroscience because I was interested in AI and figured learning how the brain works first was a good way to begin. Intelligence first before “artificial” intelligence. That training left me with a habit. When a new capability or technology arrives, my first question is practical. What can this really do, and for what type of real-world problems?

As an AI guy, I rarely cheer on AI headlines. I look past the noise and try to understand not just the breakthroughs but also limits of the new capabilities.

Back in 2020, when the safety conversation was running hot on hype, I had some plain advice. Treat AI as a tool, a powerful one, but still a tool. Stick to the boring use cases. Work at the task level where the technology was reliable enough to help. My optimistic scenario was one of boring but useful tools.

When the agentic wave started building a couple of years later, I brought the same lens, and I came away unconvinced. An agentic system is only as strong as the tasks underneath it, and I did not yet see the task-level reliability required that would let these systems be effective.

However, the hype was growing. By the time I wrote from RSA early last year, the gap between the talk and the substance was still hard to ignore. There wasn’t even a shared understanding of what the word “agentic” meant, every person had a different definition and perspective. And I had a worry about something structural. Take ten agents, each about ninety-five percent accurate. Chain them so the output of one becomes the input of the next. By the end of that chain you are down to about sixty percent. Reliability does not survive being stacked. I was starting to think about systems of agents by then, though my concern was still whether they could be trusted to work to make a meaningful difference.

Then, the rapid improvements in coding agents changed my mind about the clock.

Within months of that article, the incredible pace of progress made one thing clear to me. Reliability was a matter of time for several real-world tasks. Better models, with better engineering harnesses built around them, were going to close the gap I had been worried about. The ceiling I was worried about was going to lift.

That is when the real problem came into focus, and it was not the one I had been watching. Once you can trust the individual agents, you don’t stop deploying after the first one. You deploy many. Fleets of them, across every function, each one capable, each one doing its job. And a new question appears that has nothing to do with reliability. If every agent in the fleet does what it was built to do, does the fleet still add up to what the organization intended?

That question was the seed of the book. It sent me straight back to where I started.

A body with capable limbs cannot move well without proprioception, the constant inner sense of where all its parts are and what they are doing. The cerebellum does more than react to that feedback. It predicts. When the brain issues a movement, it forms an expectation of the sensation that movement should produce, then checks the expectation against what actually shows up. The gap between the two is the signal that corrects what comes next. Skilled movement is a loop of predicting the result and correcting for the difference.

An organization running fleets of agents needs the same sense of itself. It has to know, continuously, where its systems are and how far they have drifted from what was intended. Without that inner awareness, capable parts do not combine into coordinated action. This is not a sensing mechanism you add to a body later to make it safer. You need it for the body to move at all.

There is a well studied case of a man named Ian Waterman who lost this sense in most of his body. He learned to move again but only by watching himself, steering every step and reach with his eyes. It works. It is also exhausting and fragile. Turn off the lights and he cannot coordinate at all. An organization that governs its agents through manual audits and periodic reviews is in his position. It compensates with constant effort for a sense it never built in, and that compensation costs more than what it replaces. The whole system collapses the moment conditions change.

There is a stranger failure worth naming too, written about in a fascinating book by neuroscientist V S Ramachandran. When a limb is amputated, the brain does not fall silent. It keeps generating signals for the limb that is gone, and the person feels it vividly. Governance can fail the same way. Strip the real judgment out of an oversight function through restructuring or neglect, and the function does not go quiet. Reviews still get completed and metrics still get produced. The organization keeps feeling the sensation of oversight while the judgment behind it has been hollowed out. Here my 2020 advice comes back, about transparency. There is no oversight without transparency, and there is no transparency in a system that only produces the appearance of being watched.

Intelligence is getting cheap. Soon it will sit in every workflow and every tool. The scarce resource in that world is coherence, the living link between what each system does on its own and what the enterprise is trying to do. Coherence is the connective tissue that keeps distributed intelligence pointed at one purpose.

I spent years studying how a brain keeps its many parts working as one. The agentic era turns out to ask the enterprise the same question. My two worlds met, and that meeting is the book, Coherence, arriving this Fall. The goal has not changed since 2020. Boring but useful, still. Only now the boring and useful thing to build is coherence itself. To follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.

A programmer named Senko Rašić published an angry post this week. He is angry at a slogan going around: “code was never the hard part.” He calls it an insult to programmers. The post hit Hacker News and Lobsters and drew more than five hundred comments.

Reading the comments, I noticed one thing over and over. They argue about what the word “coding” means. Some people say it is the easy part and always was. Others say it is the whole job and always was. They are not disagreeing about difficulty. They are using one word for two different things: producing code, and building something that holds.

I have a stake in this. I write that execution has gotten cheap and coherence is the hard thing now. Skim that fast and you might file me under the same slogan.

The hard part was always building well

Producing code that runs is one thing. Building something that holds is another: the design that survives real data, the structure that stays coherent as the system grows, the choices that still make sense a year later when the author is gone. That second thing was always the hard part, and it was always the job.

Before AI, doing it well was expensive, because it took a skilled person and their time. Doing it badly was possible, but it was slow and the result was bad. Nothing about producing software was cheap.

Cheap is what AI added. A model writes a working function or a working page in the time it takes to describe it. Someone with no training can now get running code out of a sentence. That is new, and I will not soften it. Execution got cheap.

Cheap is not the same as bad

AI writes good code in places, and the commenters who said so are right. The quality is uneven, and the unevenness has a shape. The models are strong where they had the most to imitate, the patterns written out in public a million times: CRUD, forms, glue code, the endpoint that reads the database and returns JSON. They are weaker where the examples run out, on scientific computing, embedded work, anything performance-critical. One commenter put it well: AI kills it on problems with a thousand forum posts, and you do not point it at the ten-billion-dollar machine headed to Mars.

There is a reason coding is where AI advanced fastest. Code is checkable. It runs or it does not, the tests pass or they do not, and my book argues that AI improves fastest exactly where the work can be checked. The checkable parts of building will keep getting cheaper and better. What stays hard is the judgment no test can catch.

That was never the job

I wrote recently about a delete button from a data engineering thread. An engineer built a button to remove a record. It took the record off the screen. It left behind the three related records the original had created when it was made. The screen looked right. The data underneath was orphaned.

Producing that button is the cheap part. A model does it now. Knowing it had to clean up three records you cannot see is the judgment. That was the hard part, and that was the job.

The comparison people keep reaching for

Watching the threads, I noticed people reaching for the same analogy – writing. Anyone can put words into sentences that flow and reach a point. A model does it fluently. That was never what made someone a writer. What makes a writer is the choice of words and their order. The same point can land or die on those choices. One commenter compared it to a novel, where clean sentences were never the hard part.

AI did not invent bad prose but made fluent-looking prose free and endless. “Code was never the hard part” runs the same move as saying words were never the hard part of writing. About spelling, it is a shrug. About writing, it is an insult. The slogan gets both out of the same words by letting you hear the first while it means the second.

The swap, named

The slogan is true about producing code and false about building well. It earns its credibility on the first and spends it on the second, where the conclusion is that coders are now optional. One commenter worried the line would harden into a truism for business leaders. That is the reader I have in mind.

If someone read me as saying coders no longer matter, they would be making the same swap. The thing I say got cheap is producing code. The thing I call hard is building something that holds. Those did not both get cheaper. Anyone worried about systems built fast and badly is saying that building them well is still hard. You cannot write about that problem and also believe the work is trivial.

The right version of the slogan is my argument

Some people say the line and do mean something reasonable. On Lobsters, a commenter called lcamtuf said Senko was reading it uncharitably, and that the real meaning is that producing lines of code was never the bottleneck. That is true. If coding was fifteen percent of an engineer’s week, automating all of it buys back about a sixth of the week. You aimed the speedup at the fastest part of the job. Another commenter reached for Amdahl’s Law to make the same point with a number.

Then lcamtuf added the part that matters most to me. Some friction, he said, was good, because it stopped people from building software that was unnecessary or unmaintainable. That friction was a filter. It did not stop people from producing code. It stopped building-without-judgment from becoming load-bearing, because getting anything shipped had to pass through people whose time was scarce. That filter is the thing AI removed. The difficulty of building well did not leave. It stopped being enforced.

The same thing, at two heights

Building well has a name once you zoom out. Making each part fit a whole you cannot see all of at once is coherence.

The delete button is a coherence failure inside one function. The record fit the screen and broke the data underneath. Agentic slop is the same failure across a company. Each workflow works on its own, and the enterprise stops making sense. Senko is defending coherence in one program. I am after it across an organization.

The slogan is backwards. The hard part of code was never the typing. It was always the judgment, and here is the part that lasts. Where a design was already worked out a thousand times in public, the model has something to copy, and it copies well. Where the design is new to your system, there is nothing to copy and no test to guide it. That judgment stays human, because it is both uncheckable and unwritten.

Producing code got cheap. That judgment never did. It used to get paid up front, in salaries and review and the time of people who knew what they were doing, where you could see the cost. Now it shows up late, in the corners, with no owner.

This argument runs through my book, Coherence, arriving this Fall. If you want to follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.

In January 2021 an interviewer asked me for the biggest roadblock to AI adoption. My answer came down to one thing: expectations. I called them uninformed. Organizations believed AI was a drop-in component that would improve whatever process it touched. That belief, mixed with a fear of missing out, pushed companies to rush. I wrote that they were reaching for “a new shiny hammer looking for nails,” and that disillusionment would follow.

I still think that was right. The disillusionment arrived on schedule. But I was also wrong.

Two versions of one mistake

The 2021 belief was easy to state. Buy the model and the value follows. AI was a part you slotted into an existing workflow. Reality punished that belief fast, because building anything real was hard. You needed engineering time, data science help, and a business case strong enough to justify the spend. Projects that underestimated the work usually stalled before they shipped. The return died at the front of the pipeline, where the building happened.

The belief has since turned inside out. Building is easy now. A product manager can stand up an agent in an afternoon with no engineering queue in sight. So the new expectation is that easy building means easy value. If a workflow takes a day instead of a quarter, the returns should take care of themselves.

They don’t. And the reason traces back to the same root as before.

Capability was never the outcome

Both beliefs make the same move. They treat capability as if it were the outcome. Capability is what your AI can do. The outcome is a separate thing: what your organization still has once the AI has done it. The space between those two is where the return leaks away.

In 2021 that space was easy to see, because scarcity kept it visible. To build anything, a team had to win scarce engineering time. Winning it meant convincing people outside the team. A budget owner. An architect. A security reviewer. Nobody designed that as oversight. It was just the price of a scarce resource. It still worked like a filter. Weak ideas died in the queue, and only the ones someone could defend reached production. Scarcity was doing quiet work that never showed up on an org chart.

That filter is gone. When building costs almost nothing, nothing stops a weak idea from becoming a running system. Fifty teams can each ship their own agent, every one of them green on its own dashboard, and no single person owns the question of what they add up to. The return still leaks. It leaks at the far end of the pipeline now, in the cost of coordinating systems nobody mapped.

The newest version of the old belief

What is the belief being sold right now? The frontier model vendors have told the market that the gap to ROI is expertise. You have the models. What you lack is people who know how to wire them into your environment. So the labs send forward deployed engineers. They embed at your site, build the integrations, tune the configurations, debug the odd behavior, and leave a working system behind.

The role exists because my diagnosis is right. Building the model was never the hard part. Deploying it inside a messy enterprise is. FDEs are a real answer to that, and a good one. They are also an answer to the wrong problem, and their structure guarantees it.

Start with the incentive. An FDE works for the vendor. Success for them means adoption and a satisfied customer. They have no reason, and usually no mandate, to tell you that a deployment conflicts with a system three departments away that they cannot see, or that it will cost you more in complexity than it returns in efficiency, or that the right call is to not build it. The most valuable act of coherence is sometimes the word no. You cannot buy that from the party paid to say yes.

Then there is what they can see. An FDE embedded in one business unit knows that unit. They have no view of the other agents running across the company, or the coordination surfaces their new system quietly creates. The failures I worry about do not come from one bad deployment. They come from the sum of many reasonable ones. No FDE is positioned to see the sum.

And there is what they leave behind. When the engagement ends, the deepest understanding of why the system was built that way, what it assumes, and how to change it safely often leaves with them. You inherit a running system and a dependency, not the knowledge to oversee it over time.

So the FDE belief is the 2021 belief again, dressed for 2026. In 2021 it was “buy the model and value follows.” Now it is “add the deployment experts and value follows.” Both stop at capability. Deployment velocity is still capability. It is the thing every competitor can rent from the same labs, on the same terms, in the same quarter. It gets the system live. It does not decide whether the system should have gone live at all, and it does not hold the enterprise together once fifty of them are running. FDEs solve half the problem. The half they cannot touch is the one that decides your return.

Why the old advice still works

Back then I offered a few tips. Go slow. Pick narrow, well-defined use cases. Get a quick win on the board. Kill a project when the evidence says to, and keep sunk cost from making that call for you. I stand behind every word of it. What surprises me is why it still holds.

In 2021 that discipline was prudence. Ignore it and scarcity would punish you, so the advice helped you get through the queue with something that worked. Today the same discipline is close to the only filter left in the building. “Go slow” used to save you from a stalled project. Now it is most of what stands between you and a sprawl of systems you cannot see. “Kill the project” used to fight sunk cost. Now it fights the agent that keeps running because nobody confirmed it should stop.

The advice is unchanged. What used to enforce it for free has disappeared, so the work now falls to you. Scarcity handled a crude version of this by accident. You have to handle the real version on purpose.

The name I was missing

When I wrote that post I was reaching for something I could not name. I knew rushing was dangerous. I knew AI was a means to an end. I had no word for the property that separates a company that gets value from one that gets debt.

The word is coherence. It is the capacity to see what your autonomous systems are doing, judge whether they are doing it well, and correct them when they are not. In 2021, scarcity supplied a crude version of it by accident. In 2026, you build it on purpose or you go without. Once execution gets cheap, coherence becomes the thing that decides whether all that abundance turns into advantage or into cleanup.

The disillusionment I flagged five years ago is still on its way to a lot of organizations. It reaches them from the opposite direction now. Back then it came from systems that were too hard to build. Now it comes from systems that are too easy to build. The belief underneath is the one I named in 2021. Stop mistaking what AI can do for what your organization will keep, and build the coherence that turns the first into the second.

The full argument runs through my book, Coherence, arriving this Fall. If you want to follow the thinking as it develops, join the list at coherise.com. The one-page decision tool from the book is the first thing I send.