Better Than Good.

The flatness of the machine

Tue, 24 Feb 2026 00:00:00 -0600

You can feel it before you can name it. A paragraph arrives, fluent and frictionless, and something in the back of your reading brain flinches. The sentences are grammatically flawless, the structure orderly, the tone warm but not too warm, authoritative but not too authoritative. It reads the way a hotel room looks, everything is there, nothing is wrong, and yet the text has no texture, no grain, no evidence that a particular person with particular opinions sat down and hammered it out. It is prose that has been to finishing school and learned nothing except how to be inoffensive at dinner.

This is the uncanny valley of writing. Large language models now produce text that is, by most surface measures, competent, in the way that a Marriott breakfast buffet is, by most surface measures, food. They can mimic registers, follow instructions, and generate passable copy in seconds. What they cannot do, reliably, is sound like anyone in particular. The words arrive clean, centred, sanded smooth, and they are, in a precise technical sense, the most probable words. Probability, it turns out, is the enemy of voice.

Readers notice, even when they cannot articulate what they are noticing. A 2024 study from the University of Kansas found that when people suspected AI involvement in a piece of writing, their trust in the author dropped, even when the text quality was unchanged. The researchers called it a “transparency penalty.” Disclosure of AI authorship degraded perceptions of authenticity, effort, and sincerity. The interesting finding was that this penalty applied even when readers could not identify specific tells. They were not spotting bad grammar or factual errors but responding to an absence, some quality of personhood that should have been there and was not. The prose equivalent of talking to someone at a party who maintains perfect eye contact and says absolutely nothing of substance.

How the machine writes

An LLM does one thing. Given a sequence of tokens, it calculates a probability distribution over what comes next and samples from it. The training objective, next-token prediction, means getting the next word right, billions of times, across terabytes of internet text, until the resulting model develops what looks like an understanding of syntax, argument, tone, even humour. Whether this constitutes understanding or merely a very expensive statistical trick is, as we shall see, contested, but the mechanical fact is not. Every word an LLM writes is the output of a probability calculation.

The consequences for prose style are baked into the architecture. A model trained to predict the most likely next token will, absent intervention, gravitate toward the centre of its training distribution. It will favour common words over rare ones, conventional syntax over eccentric syntax, safe constructions over risky ones. The resulting text has what researchers call low perplexity, meaning it is highly predictable, and low burstiness, meaning its sentence lengths and structures cluster tightly together. Human writing, by contrast, is irregular.

People write long sentences and then short ones, use odd words because they like them, and break rules for emphasis. A 2024 study in Artificial Intelligence Review comparing human-written news text to LLM output across six models confirmed what any attentive reader already suspects, that humans exhibit more scattered sentence length distributions, more varied vocabulary, and shorter syntactic constituents. LLMs produce text that is more concise and uniform, with distributions that cluster around lower values and have tight interquartile ranges. In plain English, the machine writes within a narrower band, hedging, rounding off, converging on the middle. If you imagine the full range of human prose as a piano, the model is playing exclusively in the two octaves around middle C, and it has been told that those are the only octaves that exist. This is not a bug, but what the training objective selects for.

The alignment tax on style

The base model, the raw output of pre-training, is actually wilder than what you encounter in ChatGPT or Claude. It contains the full chaotic range of internet text, from Wikipedia to Reddit rants to Nigerian business correspondence to academic papers. It can mimic any of these registers, but unpredictably. You might ask it for a recipe and get a manifesto. This is where reinforcement learning from human feedback enters the process, and where things get both interesting and depressing.

RLHF works by having human annotators compare pairs of model outputs and choose which they prefer. These preferences are used to train a reward model, which then guides the base model toward outputs that receive high scores. The intention is to make the model helpful, harmless, and honest. The side effect is a flattened voice. RLHF introduces what the technical literature calls a mode-seeking mechanism, which narrows the range of outputs, pushing the model away from the tails of its distribution and toward a bland, deferential, faintly eager-to-please centre. The result is a prose style that reads like middle management wrote it, competent, cautious, and stripped of anything that might offend or surprise. Imagine a committee of well-meaning strangers voting on what makes a good sentence, and then imagine doing this millions of times. That is roughly what RLHF does to prose. You get the sentence that nobody actively dislikes, which is another way of saying you get the sentence that nobody remembers.

The annotators themselves leave fingerprints on this process. OpenAI outsourced much of its RLHF work to Sama, a data annotation company with operations in Kenya and Uganda, as well as to other vendors across sub-Saharan Africa. Alex Hern, writing in the Guardian, noted that the word “delve” is far more common in formal Nigerian and Kenyan English than in American or British usage. When RLHF annotators in Nairobi rated outputs, they naturally preferred phrasing that matched their own register, and the model learned accordingly. ChatGPT acquired a slight but measurable tilt toward West and East African business English that nobody designed, and nobody noticed until the word “delve” started showing up at an industrial scale in places it had no business being. It was, in hindsight, the world’s least intentional act of linguistic imperialism in reverse.

The vocabulary forensics

Dmitry Kobak and colleagues at the University of Tübingen studied vocabulary changes across 14 million PubMed abstracts from 2010 to 2024. They borrowed a technique from Covid-era epidemiology, excess mortality analysis, and applied it to words. Instead of counting surplus deaths, they counted surplus vocabulary, and the results were stark. The word “delves” appeared in 25 times as many 2024 papers as pre-LLM trends would predict. “Showcasing” and “underscores” surged ninefold, while “crucial” increased by 2.6 percentage points across the entire corpus. The excess was unprecedented, and the researchers estimated that at least 10 per cent of 2024 PubMed abstracts had been processed with LLMs. In some subfields, the figure reached 30%. A generation of medical researchers, it seemed, had collectively decided that their findings were worth “delving into” at exactly the same moment.

A follow-up study by Kei Matsui examined 135 potentially AI-influenced terms against 84 stable control phrases across PubMed records from 2000 to 2024. The control phrases, ordinary academic constructions like “all patients” and “results suggest,” held steady for two decades, doing their dull but honest work. The AI-influenced terms “meticulous,” “intricate,” “tapestry,” and “boast” spiked sharply after 2022, but the uncomfortable detail is that several of these words had already begun creeping upward in 2020, before ChatGPT launched. The lexical preferences of LLMs may have been seeded during the RLHF process, shaped by the vocabulary preferences of annotators whose influence preceded the public release of the tools. The contamination, in other words, ran deeper than anyone first assumed, and the timeline made it harder to draw a clean line between “human wrote this” and “machine wrote this.” Which, if you think about it, is precisely the problem.

The effect has a name now, AI-ese, and it is recognisable not because any single word gives the game away, but because the words arrive in concert. “Delve” on its own proves nothing, but “delve” alongside “crucial,” “underscore,” “intricate,” “foster,” and “tapestry” in a single abstract proves everything. The tells are combinatorial rather than atomic, like catching someone in a lie, not from one detail but from six details that are all a bit too perfect.

The irony is poisonous because Nigerian and Kenyan writers whose formal English naturally includes some of these terms are now being flagged by AI detection systems for writing in their own language. As Hern observed in the Guardian, if AI-ese sounds like African English, then African English sounds like AI-ese, and the stigma runs only one way. The celebrated writer Elnathan John put it sharply on X: “Imagine after being force-fed colonial languages, being forced to speak it better than its owners, then being told that no one used basic words like ‘delve’ in real life.” One might add that nobody asked the Kenyan annotators whether they wanted to teach ChatGPT to write like them, or whether they were comfortable becoming, in effect, the uncredited ghostwriters of the internet’s new house style.

What gets lost: semantic ablation and the flattening of prose

There is a subtler problem than bad vocabulary. LLMs do not merely favour certain words but systematically strip specificity from prose. Ask a model to write about a jazz record, and it will give you “complex harmonies” and “innovative arrangements” when what you needed was “McCoy Tyner comping in fourths behind a Coltrane solo that lasts eleven minutes and sounds like someone trying to describe a colour that doesn’t exist.” The first version is accurate, and the second version is writing.

This is what might be called semantic ablation, and it is the quietest form of damage a language model does. The model, trained on everything, defaults to the most generalised version of any idea, the way a politician defaults to “the hardworking people of this country” when they cannot remember which constituency they are in. Specific proper nouns get replaced with category labels. Precise technical vocabulary gives way to near-synonyms that carry less information. Vivid metaphors, the kind a human writer uses because they were up late and the phrase struck them and stuck, are smoothed into conventional similes. The texture that makes prose worth reading, the grit and grain of individual perspective, is exactly what the probability distribution selects against, because unusual phrasing has low probability, and the model avoids it.

You can see this in any domain where precision matters. A model asked to write about wine will produce “notes of dark fruit with a velvety finish,” when a sommelier would say “blackcurrant and pencil lead, tannins still gripping, needs three years.” A model writing about code architecture will reach for “robust and scalable solution” when the programmer meant “we sharded the database because the read latency was killing us at peak.” The model is not wrong, exactly, but genericised, having taken a specific observation and translated it into the most common way of expressing that category. This is the opposite of what good writing does. Good writing takes a general category and finds the one concrete detail that makes it real. The model takes a real detail and files it down until it fits in the category bin.

The structural patterns compound the effect further. Studies of AI-generated text consistently find the same architectural habits: an introductory sentence that frames the topic, three supporting points often bulleted, and a summative paragraph that begins “In conclusion” or “In summary.” Transitions are handled with “Furthermore,” “Moreover,” and “Additionally,” the verbal equivalent of a PowerPoint slide advancing. If you have ever read a corporate strategy document and thought, “A committee produced this,” you already know the feeling. Human prose, when it is working, builds momentum through rhythm and surprise, withholding and then delivering, setting up an expectation and then breaking it. These are the mechanics of attention, and they are exactly the patterns that RLHF selects against, because annotators working under time pressure prefer text that is immediately clear over text that rewards sustained reading.

The effect is compounding, and researchers call it model collapse. As more AI-generated text enters the internet at an extraordinary volume, future models are trained on it. A 2023 study led by Ilia Shumailov at Oxford demonstrated that models trained on the outputs of other models progressively lose the tails of their distributions. Minority patterns, unusual phrasings, rare vocabulary, and distinctive syntactic structures all gradually disappear. Each generation of the model becomes slightly more generic than the last. The researchers compared it to a photocopier copying a page, the text getting blurrier with each pass. It is an apt metaphor, though one might prefer a culinary analogy. Imagine making stock from stock from stock, each generation thinner and less flavourful, until you are left with warm, faintly savoury water.

The internet is already thick with this stuff, and getting thicker by the hour. Estimates vary, but AI-generated content now constitutes a substantial and growing fraction of new text published online. Much of it is SEO spam, product descriptions, and content-farm filler designed to capture search traffic without providing anything worth reading, the textual equivalent of those shops at airports that exist only because you are trapped. Some of it is harder to spot, and this is the more troubling category. Blog posts that sound plausible but contain no original reporting, LinkedIn articles that string together received wisdom in fluent paragraphs, product reviews that describe features without having used the product. The dead internet theory, once a fringe conspiracy popular with the kind of people who also worry about chemtrails, is becoming a description of something uncomfortably real, not that bots have replaced all human activity online, but that the ratio of generated to authored text has shifted far enough to change what the average piece of writing on the internet looks and feels like.

The parrot and the professor

Whether any of this is fixable depends, in part, on what you think LLMs are doing when they write. Emily Bender’s position, laid out in her 2021 paper with Timnit Gebru, Angelina McMillan-Major, and Margaret Mitchell, is that they manipulate linguistic form without access to meaning, that they are, in her phrase, stochastic parrots. “The only thing a large language model can learn is about form, sequences of letters and punctuation, and what’s likely to go next,” she told an audience at Harvey Mudd College in November 2024. An LLM, in her view, “no more understands the texts it is processing than a toaster understands the toast it is making.” It is one of those analogies that is either devastating or slightly unfair, depending on your priors about toasters.

Geoffrey Hinton disagrees, which is what Geoffrey Hinton tends to do. He argues that predicting the next token at the level frontier models now achieve requires something functionally equivalent to understanding, and that this understanding is emergent rather than designed. A 2024 Scientific American investigation described a workshop at Berkeley where frontier models solved novel tier-four mathematics problems, producing coherent proofs that went beyond memorisation. If a parrot can do abstract mathematics, Hinton’s camp suggests, perhaps it is time to reconsider what we mean by parrot.

For the question of text quality, though, the debate matters more than it first appears. If Bender is right and LLMs process form without meaning, then the flatness of their prose is not a temporary limitation but a structural constraint, like asking a colour-blind person to arrange paint swatches. A system that does not understand what it is saying cannot develop a voice, because voice requires intention, and intention requires something to intend. The model will always converge on the statistically average way of expressing any given idea, because it has no reason, no internal reason, to prefer a specific or unusual expression over a generic one.

If Hinton is right and some form of understanding is emerging, the picture is different but not necessarily better, because understanding does not automatically produce good prose, and plenty of humans understand what they are saying and still write badly. The question becomes whether the training process, the combination of next-token prediction and RLHF, can be modified to reward stylistic distinction rather than punishing it. It would be as if a piano teacher had spent years drilling a student on scales and now wanted them to play with feeling. Technically possible, but you may have trained the feeling out.

What would need to change

For LLM text to become properly indistinguishable from human writing, rather than merely passable at first glance, several things would need to happen at once, and some of them may be impossible within the current architecture.

The training objective would need to tolerate surprise. Next-token prediction, by definition, rewards the most probable continuation. Good writing often does the opposite, surprising the reader by taking the less expected path when that path is more vivid, more precise, or more truthful. A 2025 study from the University of Mannheim measured this gap directly, comparing the entropy of LLM-generated story continuations against human-authored fiction. The models produced text with two to four times lower entropy than the human ground truth, and the gap widened further after RLHF alignment. Literary theorists would have predicted as much. Wolfgang Iser argued that the “gaps” in a text, its moments of indeterminacy, are what compel cognitive engagement. Roland Barthes distinguished between “readerly” texts, which deliver meaning passively, and “writerly” texts, which invite the reader to become a co-creator. By this framework, LLMs are relentless engines of readerly text, closing every gap, resolving every ambiguity, smoothing every rough surface, like an anxious host who fills every silence at a dinner party. The result is what the literary scholar Sianne Ngai called “stuplimity,” a synthesis of shock and boredom born from the accumulation of frictionless but creatively flattened content. Anyone who has asked ChatGPT to write a poem and then immediately wished they hadn’t will recognise the sensation.

A training signal that consistently rewards the predictable token will consistently produce predictable text. Some researchers are trying to break the cycle. Meta’s Large Concept Model operates above the token level, predicting semantic concepts rather than individual words, which is a bit like teaching someone to think in paragraphs rather than syllables. A team led by John Joon Young Chung has proposed “diversified DPO”, a modification to direct preference optimisation that rewards outputs for differing from the average response to the same prompt while maintaining quality, which is as close as anyone has come to formalising the instruction “be interesting.” Whether these produce more human-like prose remains to be seen, but they at least acknowledge that the statistical averaging built into current systems is a problem worth solving rather than a feature to celebrate.

RLHF would need to stop rewarding blandness. The current process trains for helpfulness and harmlessness, which in practice means training for a voice that offends nobody and interests nobody, the literary equivalent of hold music. Annotators, working under time pressure for low wages, tend to prefer clear, safe, and conventional outputs. They are not being asked to reward literary quality, idiosyncratic phrasing, or the kind of constructive difficulty that makes good writing worth the effort. The reward model, in other words, is optimised for customer service, not prose. It is as though you trained a restaurant critic by asking a thousand people whether they liked their meal at a chain restaurant, and then used the result to evaluate a Michelin-starred tasting menu.

Researchers at the University of Washington have documented this as “homogeneity-by-design”, arguing that the flattening of LLM output is an organisational decision, not a technical side effect. Companies optimise for the broadest possible user base, which means optimising for the blandest possible voice, the textual equivalent of painting every wall beige because nobody complains about beige. Changing this would require either a different class of annotator, a different set of instructions, or a different alignment mechanism entirely. It would also require companies to accept the commercial risk that a more distinctive model might alienate some users, and no publicly traded company has ever willingly chosen “alienate some users” as a product strategy.

The “telling instead of showing” problem would need a solution. Researchers at Columbia University have documented how LLM-generated creative writing consistently “tells instead of shows,” a failing that any undergraduate writing workshop would flag. The model states emotions rather than rendering them through action and detail, and summarises rather than dramatises, reaching for the abstract category when the specific instance would do the work. Tuhin Chakrabarty and colleagues found that LLM fiction is “hackneyed and rife with clichés, while failing to demonstrate rhetorical complexity.” A separate study found that LLM-generated stories are “homogeneously positive and lack tension,” a fair description of a corporate motivational poster. This is a structural problem rooted in the training objective, and it may be the hardest one to fix. Showing requires the writer to trust the reader to infer, and inference is uncertain. The model, trained to minimise uncertainty, reaches for the explicit statement every time. It is the prose equivalent of a comedian who explains the punchline.

Models would need something resembling a persistent perspective. Human voice in writing comes from accumulated experience, consistent opinions, and the willingness to be wrong in ways that reveal character, and an LLM has none of these. It generates each response from scratch, with no memory of having held a position before and no stakes in holding one now. It cannot be contrarian, because it has nothing to be contrarian against, and it cannot be personal, because there is no person to be personal about. The most it can do is simulate these qualities on instruction, which produces roughly the same effect as a method actor who has done extensive research into the role but has never actually experienced grief, or joy, or the specific indignity of being stuck on the M25 for three hours behind an overturned caravan.

A 2025 study in Nature Human Behaviour put numbers on what this means. Researchers tested whether LLMs could replicate human conceptual representations across nearly 4,500 word concepts. The models performed well on non-sensorimotor dimensions, the social, emotional, and abstract concepts, which are also not coincidentally, the dimensions most heavily represented in internet text. They failed on motor-related dimensions, the concepts rooted in physical experience, the things you know because your body has done them. The researchers concluded that motor representations rely on embodied experiences that cannot be learned from text alone, and the implications for writing are blunt. The best prose is grounded in sensory particularity. It knows what rain sounds like on a tin roof, what a specific street smells like at 5 am, what it feels like to hold a conversation while angry and trying not to show it. These are not things that can be learned from statistical correlations in a text corpus. They are things that are known because someone lived them. No amount of training data about rain will give you the tin roof.

And perhaps most fundamentally, the text would need to carry a sense of cost. The feeling that a specific human spent time choosing these words over other words, not because a probability distribution favoured them, but because the writer believed they were the right ones and was willing to be judged for the choice. This is what readers detect, or fail to detect, when they flinch at AI-generated prose. It is not that the grammar is wrong or the facts are off. It is that no one is home, that the text is produced but not authored, arriving fully formed from nowhere in particular, addressed to no one in particular, about nothing that anyone in particular actually cares about. It is writing as room-temperature water, technically adequate, satisfying nothing.

Where this leaves the written word

The companies building these systems tend to frame the flatness as a solvable engineering problem, one that will yield to time, scale, better RLHF, better data, better prompting, and perhaps it will. The tech industry’s capacity for self-belief should never be underestimated. But there is a version of this story in which the flatness is not a bug to be fixed but a feature of what the technology is. A system designed to predict the most likely next token will, no matter how large or sophisticated it becomes, produce text that tends toward the average, and the average, in writing, is the death of style.

Meanwhile, the written internet fills with this stuff as model collapse proceeds. The tails of the distribution, where the weird, precise, distinctive, culturally specific, gloriously improbable writing lives, get thinner with each training cycle. A Kenyan postgraduate is accused of using ChatGPT because he writes in formal English. A medical researcher’s abstract is indistinguishable from a hundred others because they all passed through the same model. A reader scrolls past another paragraph of competent, textureless, faintly warm prose and does not bother to finish it. Nobody notices. There is always more where that came from.

We are building a technology that is very good at producing text and very bad at producing writing. The distinction between the two has never mattered more, and the thing that makes the distinction, the human willingness to put something at stake in a sentence, to be caught out, to be specific when being vague would be safer, is exactly the thing that cannot be back-propagated through a neural network.

Software was never meant to last forever

Thu, 12 Feb 2026 00:00:00 -0600

There is a particular kind of frustration that anyone who has worked inside a mid-sized organisation will recognise. You are eighteen months into a Salesforce implementation. The original scope was clean and reasonable. But somewhere around month four, somebody realised that your sales process doesn’t quite match the way Salesforce thinks a sales process should work.

So you customised it, and then you customised the customisation. And now you have a system that is technically Salesforce but behaves like something your team built from scratch, except that you are still paying Salesforce prices for the privilege of maintaining it, and every platform update threatens to break the fragile connective tissue holding it all together.

This is the central paradox of monolithic enterprise software and it has been the same for twenty five years. You either bend your business to fit the tool, flattening whatever operational advantage you had into a vendor’s default workflow. Or you bend the tool to fit your business and end up maintaining what is effectively bespoke software while remaining locked into a vendor relationship. Neither outcome is good, and both are expensive. And until very recently, both were better than the alternative, which was building everything yourself. That alternative is changing in fundamentally important ways.

The two failure modes

I want to be specific about what’s wrong with the current model because the problems are different depending on which path you chose, and they compound in different ways.

The first failure mode is over-customisation. This is the Salesforce trap. You start with a platform that promises to handle your CRM, your pipeline management, your reporting, your automation. The platform works for about 60% of your actual needs. The remaining 40% gets filled in with custom objects, Apex triggers, third-party integrations, and workflow rules that somebody built three years ago and nobody fully understands anymore. Your “SaaS product” is now a custom application running on someone else’s infrastructure. You get the worst combination of outcomes.

Every vendor upgrade becomes a risk assessment exercise because any change might break your custom logic. You need specialists to manage the system, which defeats the purpose of buying off-the-shelf software in the first place. And you are still paying per-seat licensing fees for a product that barely resembles the one you originally subscribed to.

The second failure mode is over-conformity. This is what happens when you decide you won’t customise and instead reshape your operations around the software. Your sales team adopts the vendor’s idea of what a pipeline stage should look like. Your project managers use the tool’s default workflow even though it doesn’t match how your team actually delivers work. Your reporting reflects what the software can easily measure rather than what matters to your business.

The subtle problem here is that the things most worth protecting in any business tend to be the operational details that make you different from your competitors. When you flatten those into a vendor’s generic workflow, you erode the very things that give you an edge.

Both of these failure modes have been tolerated for a long time because the economics made them the least bad option. Building custom software was slow, expensive, and created its own maintenance burden. Buying and adapting monolithic SaaS was painful, but cheaper than starting from scratch. That trade-off was rational and it held for more than two decades. But it is breaking now, and the speed at which it is breaking has caught the market off guard.

The SaaSpocalypse is a thing, even if the name is silly

Jefferies traders coined the term “SaaSpocalypse” last week and it stuck because the numbers behind it are hard to argue with. The S&P North American software index dropped 15% in January, its worst month since October 2008. Roughly $300 billion in market value evaporated from software, financial data, and exchange stocks in the space of forty-eight hours. Hedge funds have shorted approximately $24 billion in software stocks in 2026 so far. Thomson Reuters fell nearly 16% in a single session. Xero dropped over 15% in Asia-Pacific markets. Even Microsoft, which you would think has enough diversification to weather this, is trading 21% below its annual high and has slipped to fourth in the most valuable company rankings behind Nvidia, Google, and Apple.

What makes this selloff different from previous tech corrections is that the fear isn’t about competition from other software companies. It is about the possibility that the entire category of enterprise SaaS might shrink. The per-seat licensing model that has powered the industry for 20+ years assumes that more employees using the software means more revenue.

If AI agents can handle the work that those employees were doing inside the software, companies need fewer seats. And if AI tooling can help companies build custom solutions in-house, they might not need the third-party software at all.

The question worth asking is whether this fear is justified or whether it is the kind of panic that markets periodically generate around new technology. I think the answer is somewhere in the middle, but leaning more toward justified than most incumbents would like to admit.

How AI is reshaping this

The AI angle in this story is often discussed in vague terms. People talk about “disruption” and “transformation” without being precise about what AI is actually doing to change the economics and the capabilities involved. I think there are four distinct roles AI is playing here and they are worth separating because they have different implications and different timelines.

Making it possible to leave

The first role is the most immediate one. AI is collapsing the cost and timeline of migrating away from monolithic systems.

Migration cost has always been the real moat protecting incumbent SaaS vendors. It was never the product quality or the feature set that kept you locked in. It was the fact that switching meant a multi-year project with consultants, data migration specialists, and the very real risk of breaking something important halfway through. The switching cost was so high that it functioned as a form of captivity. You stayed with Salesforce or Oracle or SAP because leaving would be worse than staying, even if staying was painful.

That calculus is changing faster than most people expected. On Palantir’s Q4 2025 earnings call, their CTO claimed that their platform can now complete complex SAP ERP migrations from ECC to S4 in as little as two weeks, where that same work previously took years. Amazon used AI agent coordination through Amazon Q Developer to modernise thousands of legacy Java applications, completing upgrades in a fraction of the expected time. Genentech built agent ecosystems on AWS to decompose monolithic research processes into coordinated microservices.

If these examples are even directionally correct, the implication is significant. The lock-in argument for staying with your monolith weakens every time migration gets cheaper and faster. The barrier to exit that protected Salesforce’s recurring revenue was never the quality of the CRM. It was the terror of the migration project. That terror is becoming less justified.

Making it cheap to build

The second role is the one that feeds into the disposability thesis, and I think it is the most structurally disruptive of the four.

The cost of building purpose-specific software is falling toward zero. Coding platforms, AI agent builders, and tools like Claude Code and Cursor are turning what used to be six-month development projects into work that takes days. On most current AI agent platforms, building a functional agent takes between fifteen and sixty minutes. By 2026, roughly 40% of enterprise software is expected to be built using natural-language-driven development where prompts guide AI to generate working logic.

This changes the fundamental value proposition of SaaS. The entire model was built on the assumption that buying software from a vendor would be cheaper than building it yourself. That assumption held because building was expensive and required scarce technical talent. But when the build cost drops far enough, the comparison flips. Why would you pay per-seat licensing for a general-purpose tool that sort of fits your workflow when you can generate a purpose-built microservice that exactly fits your workflow, at negligible cost, in an afternoon?

And this is where the disposability idea comes in. Traditional software development follows a predictable path. You invest heavily in building, which means you need the software to last a long time, which means you need ongoing maintenance, which means you need vendor support contracts or internal engineering capacity, which creates its own form of lock-in. When the build cost drops far enough, that entire chain collapses. You don’t need software that lasts ten years if you can rebuild it in a day. You generate what you need, use it, and when the context changes, you generate a replacement rather than trying to fix what you already have.

This sounds radical but it is already happening at the edges. The concept of “disposable software” has entered the vocabulary of people building with these tools. Applications generated for a single use case and then retired once that use case is finished, because the cost of creating them was so low that longevity was never part of the design. Think of it as software that behaves more like a document than like an asset. You produce it when you need it and discard it when you don’t.

Moving the value from the application to the orchestration layer

The third role is where the argument moves past “cheaper replacement” and into territory that I think is more interesting and less well understood.

Here the value migrates away from the SaaS application itself and toward the intelligence that coordinates between applications. A monolithic platform tries to be the whole stack. It wants your sales data, your marketing data, your support data, and your analytics all living inside its walls so it can offer you an integrated experience. But that integrated experience only works within the boundaries of what that single vendor decided to build, and it only spans the domains that vendor chose to enter.

Agentic microservices break that constraint entirely. BCG found that early adopters of agentic AI reported 20% to 30% faster workflow cycles from agents that auto-resolve IT service tickets, reroute supplies to cover inventory shortages, and trigger procurement flows without human input. These gains didn’t come from any single tool getting smarter. They came from an orchestration layer that could act across system boundaries that no individual product controls. An AI agent that monitors your inventory system, detects a shortage, queries your supplier database, triggers a procurement flow, and updates your finance system is doing something that sits outside the remit of any single vendor because it spans multiple domains with different data models and access patterns.

The uncomfortable implication for SaaS vendors is that in this model, the individual tools are still there, still doing what they do. But the intelligence that makes them useful has moved outside of them and into the agent layer. Your product becomes a commoditisable component rather than a destination, and the value accrues to whoever controls the coordination.

The composable enterprise concept captures this well. In this model, SaaS applications become modular and interchangeable components that AI agents dynamically select, integrate, and swap as needed. Instead of one monolithic application trying to do everything, you have a collection of specialised microservices with an AI orchestration layer that coordinates between them. Unlike traditional integration approaches where engineers hard-wire connections between systems, agents orchestrate tools dynamically and learn from past actions to optimise future workflows. A Salesforce workflow is static, but an agentic workflow adapts.

The orchestration layer is too important to delegate

The previous section argues that value is migrating from individual applications to the intelligence that coordinates between them. This section is about who should own that intelligence, because right now the default answer is heading in the wrong direction.

Every major SaaS vendor is racing to embed AI into their product. Salesforce has Einstein. HubSpot has Breeze. Microsoft has Copilot. Monday.com has its AI assistant. Each of these systems is being built independently, optimised for the vendor’s own data model, trained on the vendor’s idea of what your workflow should look like, and shipped on the vendor’s timeline. If you use ten SaaS tools, you are about to have ten separate AI systems making decisions about different parts of your business with no awareness of each other. That is not an AI strategy, it’s a confusing patchwork. And the decisions each one makes happen inside infrastructure you don’t control, can’t fully inspect, and are governed through contracts rather than architecture.

The alternative is treating the orchestration layer as something your organisation owns. With custom agentic microservices, you choose the models, the data boundaries, and the governance framework. You get a single coherent AI architecture that spans your entire operation rather than a collection of vendor AI bolt-ons.

The question that sophisticated buyers are starting to ask is not “which AI features does this SaaS product include” but “do I want ten vendors each running their own AI on fragments of my business, or do I want to own that layer myself.” The orchestration layer is where the competitive advantage lives. It is the thing that will encode your operational logic, your decision-making patterns, and your institutional knowledge. Delegating that to a collection of vendors is a strategic mistake that will get harder to unwind the longer you wait.

The counter-arguments

I should be honest about where this thesis is weakest because the bullish version of this story can veer into fantasy if you don’t account for reality.

Sticky infrastructure is a real constraint and it would be dishonest to pretend otherwise. ERP systems with decades of accumulated data, compliance records, and institutional knowledge don’t vanish overnight. The data gravity of established platforms combined with organisational inertia are a genuine barrier that will slow this transition considerably. And I’ve learnt never to underestimate organisational inertia.

The code quality concern is also legitimate. Experienced developers are warning that the flood of AI-generated code arriving in 2026 will create a significant cleanup effort in 2027, as teams hunt down bugs and errors that were introduced by AI systems that are very good at producing code that works and less good at producing code that is maintainable and secure. If you are generating disposable microservices, this matters less because you throw them away. If you are generating anything that needs to persist, it matters a lot.

Compliance and audit trails remain genuine obstacles. Regulated industries need accountability chains that disposable tooling doesn’t naturally provide. When an AI agent makes a decision that affects a financial transaction or a healthcare outcome, somebody needs to be able to explain why it made that decision and trace the logic back to its source. The governance infrastructure for agentic systems is immature.

And the “BofA paradox” is worth considering. Bank of America pointed out that the current selloff relies on two mutually exclusive scenarios. Either there’s a bubble and AI investment returns are deteriorating to the point where growth is unsustainable, or AI is so powerful that it makes entire business models obsolete. Both of those things probably can’t be true at the same time. I think the resolution is that AI doesn’t need to be universally powerful to disrupt SaaS. It just needs to make custom-building cheaper than subscribing to and customising a monolith, and that bar is now considerably lower.

What this means if you run a mid-sized business

For medium sized organisations this shift arguably matters more than it does for the Fortune 500. You never had the budget for a massive Salesforce implementation. You were always dealing with the friction of tools that were designed for companies ten times your size, simplified into plans that stripped out the features you actually needed while charging you for ones you didn’t.

The opportunity here is to stop treating software procurement as a decade-long commitment. If build costs continue to fall, the sensible approach shifts from “which platform should we commit to for the next five years” toward “what do we need this quarter, and what is the fastest way to build it.” Your tools evolve as fast as your business does instead of lagging behind by whatever interval your vendor needs to ship their next release.

The risk, of course, is that you end up with a collection of loosely connected microservices that nobody fully understands, which is its own version of technical debt. The difference is that technical debt in disposable systems is bounded. If a microservice stops serving your needs, you retire it and build a replacement rather than spending months trying to fix something that was bolted onto a monolith you don’t control.

Where this goes

The monolith era wasn’t wrong, it was the best available option given the economics of the time. If building custom software costs a hundred times more than buying off-the-shelf, you buy off-the-shelf and live with the trade-offs. That arithmetic has been stable for twenty or more years and it has supported a trillion-dollar industry.

But that arithmetic is changing quickly. The question isn’t whether custom AI microservices will replace all SaaS, because they clearly won’t in the near term. ERPs will survive, systems of record will survive, and anything with deep data gravity and regulatory entanglement will survive for years, possibly decades due to organisational inertia.

However, mid-market and the application layer are now exposed. The tools that sit between you and your data, the ones that charge you per seat for the privilege of clicking through their interface, are the ones that face the most pressure. When an AI agent can interact with your data directly and build the workflow you need in the moment you need it, the interface layer becomes optional. And optional is a dangerous place to be when your entire revenue model is built on being necessary.

The market seems to agree. Whether it is overreacting or simply pricing in a future that hasn’t fully arrived is the kind of question that separates good investment analysis from speculation. But the structural argument is sound. Build costs are falling, migration costs are falling, agentic capabilities are rising, and the organisations doing the buying are starting to notice that they have options they didn’t have two years ago.

Software was never supposed to last forever. We just didn’t have a better alternative until now.

The vibe coding spectrum: from weekend hacks to the dark factory

Mon, 09 Feb 2026 00:00:00 -0600

A year ago, Andrej Karpathy posted a tweet that would come to define how an entire industry talks about itself. “There’s a new kind of coding I call ‘vibe coding,’” he wrote, “where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He described asking for trivial UI changes through voice commands, accepting all suggestions without reading the diffs, and copy-pasting error messages back into the chat until things worked. “It’s not really coding,” he admitted. “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

The term became inescapable almost overnight. It was named Collins English Dictionary’s Word of the Year for 2025. Y Combinator reported that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated. Lovable, a vibe coding platform, became a unicorn eight months after being founded. By the end of the year, 72% of developers were using AI tools daily, and those tools were contributing to roughly 42% of all committed code. The iOS App Store saw a 60% increase in new releases, attributed largely to the accessibility of AI-assisted development.

But the cultural response followed a predictable pattern. The backlash was immediate, vocal, and often justified. Lovable-created applications were found to have security vulnerabilities that left personal data exposed. A CodeRabbit analysis of open-source GitHub pull requests found that AI co-authored code contained 2.74 times more security vulnerabilities and 75% more logic errors than human-written code. A METR randomized controlled trial found that experienced open-source developers were actually 19% slower when using AI tools, despite believing they were 20% faster. Researchers from several universities published a paper titled “Vibe Coding Kills Open Source,” arguing that increased AI-assisted development was reducing engagement with open-source maintainers in ways that carried hidden costs for the entire ecosystem.

The criticism crystalized into a familiar refrain. Andrew Ng called the term “unfortunate” and “misleading,” insisting that guiding an AI to write software was “a deeply intellectual exercise” that left him “frankly exhausted by the end of the day.” Bloggers declared vibe coding was “a weekend hack that’s not ready for the real world.” LinkedIn was awash with posts insisting that we would always need humans in the loop, that understanding the code was non-negotiable, and that anyone telling young engineers not to learn programming was dispensing reckless career advice.

Much of this pushback was perfectly sensible. The security problems were genuine. The quality concerns were well-founded. The skepticism about non-engineers building production systems without understanding what they were deploying was appropriate and necessary.

But something happened that most of these critics failed to anticipate, and it happened faster than almost anyone expected.

On the spectrum

The problem with the vibe coding discourse was never that the critics were wrong about the risks. The problem was that almost everyone, advocates and skeptics alike, was talking about only one end of a very wide spectrum. Karpathy himself was clear about this. He was describing weekend projects, throwaway experiments, the kind of thing where failure costs nothing and the fun is the point. He acknowledged that the code grew “beyond my usual comprehension” and that when bugs proved stubborn, he would “just work around it or ask for random changes until it goes away.”

This was not a prescription for building enterprise software. It was a description of play. And yet the entire conversation that followed, for nearly a year, treated “vibe coding” as if it were a single thing with a single set of implications, rather than the label for one point on a continuum that stretches from hobbyist experimentation to something almost nobody was prepared for.

At the opposite end of that spectrum, a three-person team at StrongDM was building security software without any human ever writing or even reviewing the code. And they were doing it on purpose, as a matter of principle, with rules that explicitly prohibited it.

Code must not be reviewed by humans

In July 2025, Justin McCarthy, co-founder and CTO of StrongDM, formed a new team with Jay Taylor and Navan Chauhan. Their charter contained a line that would have seemed reckless to most of the industry at the time. As McCarthy described it: “No hand-coded software.” The team established two foundational rules that they have maintained since. Code must not be written by humans. Code must not be reviewed by humans.

They added a practical benchmark that gives some sense of the scale of their ambition. If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.

This was not Karpathy-style vibe coding. This was not a weekend hack, not a throwaway prototype, not a toy app to see how far the technology could stretch. This was a team of deeply experienced engineers building permission management software for enterprise security, software where getting things wrong means unauthorized access to sensitive systems, and they were doing it by constructing an entirely new methodology for how software gets made.

The catalyst, McCarthy explained, was a transition they observed in late 2024. With the second revision of Claude 3.5 (released October 2024), long-horizon agentic coding workflows began to compound correctness rather than error. This is a subtle but critical distinction. Prior to this improvement, letting an AI iterate on a codebase would gradually introduce more problems than it solved. Each step added new misunderstandings, hallucinations, version conflicts, and logic errors until the project collapsed under its own accumulated confusion. After the October 2024 model update, the opposite started happening. Each iteration tended to make things better rather than worse, and this compounding effect meant that an agent could work through complex problems over extended sessions without the whole thing falling apart.

By the time Simon Willison observed what he called the November 2025 inflection point, when Claude Opus 4.5 and GPT 5.2 appeared to cross another invisible capability line, StrongDM’s team had already been operating without human-written code for four months and had built something extraordinary.

The validation problem

The immediate and obvious objection to this approach is the one that every critic of AI-generated code has been making since the beginning. If you are not reading the code, how do you know it works? If the AI writes both the implementation and the tests, what stops it from writing tests that trivially pass? assert true is a perfectly valid test from the agent’s perspective, and it will make the test suite glow green while proving absolutely nothing.

StrongDM’s answer to this challenge is, as Willison put it in his writeup, “the most consequential question in software development right now.” Their solution draws on the concept of scenario testing, originally articulated by Cem Kaner in 2003, but takes it in a direction that the original concept never imagined.

They repurposed the word “scenario” to mean an end-to-end user story that is stored outside the codebase, deliberately kept where the coding agents cannot see it, much like a holdout set in machine learning. Where traditional software testing asks a binary question (“does the test suite pass?”), StrongDM moved to what they call “satisfaction,” a probabilistic and empirical measure. Of all the observed trajectories through all the scenarios, what fraction of them are likely to satisfy the user? This is a fundamentally different way of thinking about software quality, and it mirrors the way machine learning practitioners already think about model evaluation. You do not ask whether a model gets the training set right. You ask whether it generalizes to data it has never seen.

The holdout analogy is powerful because it addresses the reward-hacking problem head on. When the agent that writes the code can also see the tests, it has every incentive and capability to game them. When the validation scenarios live in a completely separate system that the coding agents cannot access, the only way to pass them is to build software that actually works in the ways that matter.

The Digital Twin Universe

The second piece of StrongDM’s approach is the one that Willison described as making the strongest impression on him during his visit to the team in October 2025. They call it the Digital Twin Universe, and it represents the kind of thing that every software team has fantasized about but dismissed as economically impossible.

Their software manages user permissions across a suite of connected services, meaning it needs to interact with Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets. Testing permission management software against live versions of these services is slow, expensive, rate-limited, and potentially dangerous. You cannot stress-test your security software against production Okta at the volumes needed for thorough validation without hitting rate limits, triggering abuse detection, or accumulating enormous API costs.

So StrongDM built complete behavioral clones of all of these services, every one of them generated by coding agents. The approach involved feeding the full public API documentation of each service into their agent harness and having it build a faithful imitation as a self-contained Go binary, complete with a simplified UI for running scenarios. Jay Taylor, who created the DTU, shared on Hacker News that the key insight was using popular publicly available reference SDK client libraries as compatibility targets, always aiming for 100% compatibility.

With their own independent clones of half a dozen major SaaS platforms, free from rate limits and usage quotas, their army of simulated testers could run thousands of scenarios per hour. The scenario tests became scripts for agents to constantly execute against the new systems as they were being built, providing continuous validation at a scale and speed that would be absurd against live services.

This is where the economics of the situation become interesting and also where the “vibe coding is just for prototypes” argument runs aground. As StrongDM puts it, creating a high-fidelity clone of a significant SaaS application was always possible but never economically feasible. Generations of engineers may have wanted a full in-memory replica of their CRM to test against but self-censored the proposal to build it. They did not even bring it to their manager, because they knew the answer would be no.

The agentic moment changed the math so completely that the thing everyone wanted but nobody could justify building became routine.

The Dark Factory

Dan Shapiro, CEO of Glowforge and Wharton Research Fellow, published a taxonomy in January 2026 that provides useful language for understanding where StrongDM fits. In “The Five Levels: from Spicy Autocomplete to the Dark Factory,” Shapiro mapped AI-assisted development to the NHTSA’s five levels of driving automation.

Level Zero is manual coding. You might use AI as a search engine, but every character hits the disk with your approval. Level One is offloading specific tasks. “Write a unit test for this.” Level Two is pair programming with AI, the flow state that most people calling themselves AI-native developers occupy. Level Three is where you become a manager, reviewing the endless diffs that your coding agents produce. “Your life is diffs,” Shapiro wrote. “For many people, this feels like things got worse.” He noted that almost everyone tops out here.

Level Four is where you become, in Shapiro’s terms, “that which you loathed: you’re a PM.” You write specs, argue about them, craft skills for your agents, plan schedules, then leave for twelve hours and check whether the tests pass.

Level Five is the Dark Factory. Named after the Fanuc robot factory in Japan where robots build robots in complete darkness because no humans are present who would need the lights on. At Level Five, the software process is a black box that turns specs into software. “I know a handful of people who are doing this,” Shapiro wrote. “They’re small teams, less than five people. And what they’re doing is nearly unbelievable.”

StrongDM is operating at Level Five. And it is critical to understand what that means in context. This is not a team of amateurs who do not know what code looks like. Justin McCarthy is the CTO and co-founder of a company that has been building security infrastructure for years. These are people who understand exactly what they are choosing not to look at and who have built an elaborate system of validation, simulation, and continuous testing to compensate for the absence of human code review. They are not ignoring the risks that the vibe coding critics worry about. They are addressing those risks through architectural decisions rather than through the traditional mechanism of a human reading every line of code.

The wider movement

StrongDM is not working in isolation. The approach they have pioneered sits within a broader movement of experienced engineers pushing the boundaries of what is possible with coding agents.

Jesse Vincent’s Superpowers, which has accumulated over 43,000 stars on GitHub, takes a complementary approach by encoding decades of software engineering discipline into “skills” that Claude Code agents are compelled to follow. Rather than letting agents improvise their approach to development, Superpowers enforces a mandatory workflow of design, planning, test-driven development, and systematic review. As one user put it, “My personal output now exceeds what my entire teams at Oracle Cloud Infrastructure could produce.” Vincent’s insight was that you do not make agents more reliable by watching them more carefully. You make them more reliable by building better systems around them.

Cognition Labs’ Devin demonstrated another dimension of the transformation when it helped Nubank refactor a monolithic ETL repository spanning over six million lines of code, a migration that would have consumed enormous human engineering hours. After fine-tuning on examples of previous manual migrations, Devin doubled its task completion scores and achieved a four-fold improvement in speed. Goldman Sachs began using hundreds of Devin instances internally, treating them as junior engineers with human review. Amazon’s internal deployment of AI coding tools reportedly saved an estimated 4,500 developer years of effort and $260 million on a single large migration project.

Meanwhile, spec-driven development emerged as a formalized methodology. GitHub published Agent Skills as an open standard in December 2025, and Microsoft, OpenAI, Atlassian, and Figma adopted it. AWS launched Kiro, a spec-driven IDE, in public preview. The Thoughtworks Technology Radar featured spec-driven development in its November 2025 edition. All of this activity pointed in the same direction. The gap between “tell an AI what you want and hope for the best” and “build rigorous systems that turn specifications into validated software” was being filled with real methodologies, real tooling, and verifiable results.

Techniques that compound

StrongDM published a techniques page that reads like a glossary for the next era of software engineering. Beyond the Digital Twin Universe, they describe Gene Transfusion, where agents extract working patterns from one codebase and reproduce them in another context. Semports are semantically-aware automated ports that move code between languages while preserving intent. Pyramid Summaries provide multiple levels of compression so that an agent can quickly scan high-level descriptions and zoom into detail as needed, a form of reversible summarization that addresses one of the fundamental challenges of working with large codebases through AI.

Their description of Shift Work captures the difference between interactive and non-interactive development. When intent is complete, meaning the specs, tests, and reference implementations are all in place, an agent can run end-to-end without any back-and-forth. The human work happens upstream, in the definition and validation of what the software should do. The machine work happens downstream, in the mechanical production and testing of the software itself.

Perhaps the most provocative thing StrongDM released was Attractor, their non-interactive coding agent. The GitHub repository contains no code at all, just three markdown files describing the spec in meticulous detail and a note in the README that you should feed those specs into your coding agent of choice. This is software released as pure specification, a bet that the spec is the product and the code is a generated artifact, as interchangeable and disposable as compiled binaries.

The backlash got it backwards

The persistent criticism of vibe coding tends to fall into one of two categories. The first, which is mostly correct, warns about the risks of deploying AI-generated code without understanding it. Security vulnerabilities, logic errors, maintainability nightmares, skill degradation, these are legitimate concerns and they apply with full force to the “accept all, never read the diffs” approach that Karpathy originally described.

The second category of criticism is the one that StrongDM’s work exposes as fundamentally shortsighted. This is the argument that we will always need humans to write the code, that we will always need humans to review the code, that the role of the software engineer as someone who personally crafts and inspects every line of logic is eternal and non-negotiable. The people making this argument point to the very real failures of naive vibe coding and conclude that the entire trajectory leads nowhere serious, that AI-assisted development is a useful accelerant for human programmers but will never replace the human in the loop.

This position has a comforting logic to it, but it confuses two different things. It confuses the necessity of rigorous validation with the necessity of human code review. StrongDM validates their software more rigorously than most human-reviewed codebases have ever been validated. They run thousands of scenarios per hour against behavioral clones of every service they integrate with. They treat code the way machine learning practitioners treat model weights, as opaque outputs whose correctness is inferred exclusively from externally observable behavior. The code is not the thing that matters. The behavior is the thing that matters.

What they dispensed with was not quality control. What they dispensed with was the specific mechanism of a human reading the source code, and they replaced it with something arguably more thorough, more consistent, and more scalable.

One endpoint on a spectrum

Go back to Karpathy’s original tweet and read it again, but this time think about it as a description of one endpoint on a spectrum rather than a complete philosophy.

At one end, you have someone with no programming knowledge asking an AI to build them a personal app over a weekend. They accept all suggestions, they do not understand the output, and they copy-paste errors until things mostly work. This is the version of vibe coding that the critics rightly worry about. It produces fragile software, it creates false confidence, and it gives people the illusion that they have built something robust when they have built something that happens to work under the conditions they tested.

At the other end, you have StrongDM, where deeply experienced engineers have designed a system in which humans never touch the code not because they are lazy or naive but because they have determined that human code review is the wrong abstraction for ensuring quality at the scale and speed they need. They replaced it with scenario-based validation, Digital Twin Universes, probabilistic satisfaction metrics, and continuous agent-driven testing. The humans are not absent from this process. They are present at the most important layer, defining what the software should do and building the systems that verify whether it does it.

The difference between these two approaches is not a difference of degree. It is a difference of methodology, sophistication, and engineering maturity. And yet the word “vibe coding” has been stretched to cover both of them, which is why the debate has generated more heat than light.

What this means for software engineering

The people who dismiss all of this as hype, who insist that the fundamentals of software engineering are unchanged and that we will always need programmers in roughly the form we have them today, are making the same mistake that people made about every previous wave of abstraction. Compilers did not eliminate the need for people who understood hardware. But they did make it unnecessary for most programmers to think about register allocation. Object-oriented programming did not eliminate the need for structured thinking. But it did change what that thinking was about.

What StrongDM, Jesse Vincent, and the broader software factory movement are demonstrating is that the next abstraction layer moves the human from the code to the specification and from the review to the validation system. The engineering does not disappear. It moves up the stack. The person who builds a Digital Twin Universe of six SaaS platforms and designs a probabilistic satisfaction framework for evaluating agent-generated code is doing engineering of the highest order. They are just not doing it in the same place.

This is consequential because it changes the economics of software production in ways that compound. When building a behavioral clone of Slack or Okta becomes an afternoon’s work for a coding agent rather than a six-month project for a team of engineers, things that were previously unthinkable become routine. When validation can run at thousands of scenarios per hour against simulated environments, the feedback loop between specification and working software shrinks from weeks to hours. When code is treated as a generated artifact rather than a crafted document, it can be regenerated from improved specs instead of incrementally patched, which inverts the entire relationship between software teams and technical debt.

Shapiro called this technical deflation. The cost of producing code is dropping so fast that every assumption built on the previous cost structure needs to be re-examined. The smart teams, he argued, are deferring payment on human hours today to pay them back with cheaper AI hours tomorrow.

The fundamental question

There is a natural desire to find the safe middle ground in this conversation, to acknowledge that AI tools are useful while insisting that human developers remain essential in all the same ways they have always been. That position felt reasonable a year ago. It feels increasingly difficult to maintain in the face of what StrongDM has demonstrated.

This does not mean that all software will be built this way tomorrow, or that there are no legitimate concerns about the approach. The token costs are significant. $1,000 per day per engineer translates to $20,000 per month in overhead, which means this methodology needs to produce proportionally more value to justify itself. StrongDM is building in a specific domain with specific characteristics, permission management across SaaS platforms, and it remains to be seen how broadly the Dark Factory pattern generalizes. The November 2025 inflection point that made this reliability possible was just a few months ago, and the long-term track record of agent-built software is by definition short.

But the direction of travel is clear, and the people leading it are not amateurs or futurists or LinkedIn influencers spinning provocative narratives. They are working engineers who have committed to a methodology, built the infrastructure to support it, open-sourced their specifications, and published their techniques for others to learn from.

The question is not whether humans will always need to be in the loop. The question is what “in the loop” means when the loop itself has been redesigned from scratch.

The vibe coding debate, as it has been conducted for the past year, was always asking the wrong question. It was asking whether AI can replace programmers. The answer was always going to be complicated and unsatisfying. The better question, the one that StrongDM forces us to confront, is what happens when the best programmers in the world decide to stop programming and start building the factories instead.

That question has an answer now, and it is sitting in a GitHub repository that contains no code at all.

Claude Opus 4.6 just shipped agent teams. But can you trust them?

Fri, 06 Feb 2026 00:00:00 -0600

Anthropic shipped Claude Opus 4.6 this week. The headline features are strong: a 1M token context window (a first for Opus models), 128K output tokens, adaptive thinking that adjusts reasoning depth to the task, and top-of-the-table benchmark scores across coding, finance, and long-context retrieval. It scored 65.4% on Terminal-Bench 2.0, the highest ever recorded on that agentic coding evaluation (Anthropic, 2026).

But the feature that should arguably be getting the most scrutiny is agent teams in Claude Code. The following is a broad summary of the state of multi-agent approaches across multiple platforms and the security concerns you should be aware of if deploying them in sensitive environments.

In Opus 4.6, agent teams let you spin up multiple Claude agents that work in parallel and coordinate autonomously. Anthropic describes this as particularly useful for “read-heavy work like codebase reviews.” Instead of one agent handling everything sequentially, you split the work across multiple agents that each take a piece and bring their findings together.

This is a meaningful capability improvement. It is also, from a security standpoint, an architecture that the industry has barely started to think about defending. Anthropic isn’t alone here, the same coordination patterns showing up in Claude Code exist across AutoGen, CrewAI, LangGraph, and OpenAI’s Agents SDK. The security gaps are structural, not vendor-specific.

How Multi-Agent Coordination Works

The implementations differ across frameworks, but the core pattern is consistent. A coordinating agent divides a task, delegates portions to specialist agents, and synthesises the results.

In Claude Code’s new agent teams, you spawn subagents that operate in parallel. Each gets a portion of the task, works through it independently, and produces output that feeds back into the coordinator. You can take over any subagent via Shift+Up/Down or tmux (Anthropic, 2026).

AutoGen (Microsoft) uses a conversational model where agents interact through structured turn-taking, each posting messages and reacting to others’ outputs (Wu et al., 2023). CrewAI mirrors a human organisation, with a manager agent delegating to specialists and aggregating results. LangGraph treats agent interactions as nodes in a directed graph with explicit state management (DataCamp, 2025). OpenAI’s Agents SDK (which evolved from their experimental Swarm framework) uses explicit handoff functions where one agent transfers control to another, keeping just one agent in charge at any time (OpenAI, 2025).

The efficiency gains are real across all of these systems. A codebase review that took an hour with a single agent could take fifteen minutes with four agents running in parallel. One of the Opus 4.6 launch testimonials describes a “multi-million-line codebase migration” that finished in half the expected time. But every one of these frameworks shares a common assumption about how agents within a team relate to each other, and that assumption is where the problems begin.

The Trust-Vulnerability Paradox

Xu et al.’s research on multi-agent trust, published in October 2025, gives this problem a formal name: the Trust-Vulnerability Paradox. Their findings are worth paying attention to. They demonstrated empirically that increasing inter-agent trust to improve coordination simultaneously expands risks of over-exposure and over-authorisation (Xu et al., 2025).

Their experiments across multiple model backends (DeepSeek, Qwen, GPT, Llama-3-8B) and orchestration frameworks showed consistent results, higher trust improved task success but also heightened exposure risks. They measured this using two metrics, Over-Exposure Rate (how often agents share information beyond what’s necessary) and Authorisation Drift (how much leakage sensitivity changes with trust levels). The relationship was monotonic i.e. more trust and more coordination led to more vulnerability. There was no configuration sweet spot where you get the benefits without the costs.

This maps directly onto what’s happening with agent teams. Every framework listed above operates on implicit mutual trust between agents. CrewAI’s manager trusts its specialists’ outputs. AutoGen’s conversational agents trust each other’s messages. LangGraph’s nodes trust the state passed between them. Claude Code’s coordinator trusts its subagents’ assessments. The trust is there because it has to be for coordination to work, and because all agents are presumed to be instances of the same system working toward the same goal.

If you’ve spent time in enterprise network security, this architecture should feel uncomfortably familiar. It mirrors the flat corporate network of the early 2000s, where every machine trusted every other machine because they were all “inside the perimeter.” The entire zero trust movement exists because that model fails badly when any single node gets compromised. Once an attacker is inside, lateral movement is straightforward because nothing challenges the assumption that internal traffic is legitimate. Agent teams have the same structural weakness.

What Compromise Looks Like

A penetration testing study by researchers examining AutoGen and CrewAI found that more than half of malicious prompts succeeded despite enterprise-grade safety mechanisms. Grok 2 running on CrewAI rejected only 2 of 13 attacks, a 15.4% refusal rate. The overall refusal rate across all tested configurations was 41.5% (arxiv, 2024). These numbers are bad enough for single-agent deployments. In a multi-agent team, the consequences multiply.

The most straightforward compromise scenario involves prompt injection through the content being processed. If an agent team is reviewing a codebase, each subagent reads files, processes their contents, and forms conclusions. If any of those files contain adversarial content designed to manipulate LLM behaviour, the subagent processing that file is the one exposed.

With a single agent, you might notice something odd in its output. With a team, the compromised subagent’s output flows into the coordinator’s synthesis alongside legitimate outputs from other agents. The coordinator has no reliable mechanism for distinguishing a genuine finding from a manipulated one, because the architecture assumes all subagent outputs are trusted input.

A compromised subagent doesn’t need to do anything dramatic. It doesn’t need to execute malicious code or access external systems directly. It just needs to subtly influence its own output in ways that affect the coordinator’s conclusions.

Consider a codebase review where one subagent has been manipulated through an injected comment in a source file. That agent might report that a particular authentication implementation is “well-structured and follows best practices” when it actually contains a vulnerability.

Or it might flag a series of false positives to create noise that distracts from a real issue. The coordinator, receiving these assessments alongside legitimate ones, has to weigh and synthesise them without any ground truth about which subagent to trust more.

There’s a subtler variant too. A compromised subagent doesn’t have to lie about its findings. It can tell the truth selectively, emphasising cosmetic issues like naming conventions and comment formatting while leaving serious vulnerabilities unmentioned.

The coordinator receives a report that looks thorough and legitimate but that consumed the agent’s attention on trivialities. The final review then has a blind spot exactly where the attacker wanted one, and nothing in the output looks wrong because every individual claim is accurate.

This kind of misdirection through selective reporting is particularly hard to defend against because it produces no false statements. The attack is in the gaps, in what the agent chose not to say, and detecting omissions requires knowing what should have been there in the first place.

Lateral Movement Between Agents

In network security, lateral movement is the process by which an attacker who has compromised one system moves through a network to reach additional systems. Research on multi-agent propagation confirms this applies to LLM systems too. NetSafe’s analysis showed how hallucinations and misinformation propagate across multi-agent topologies, with structural dependencies determining how quickly corruption spreads (Yu et al., 2024).

The mechanism works as follows. Agent A processes a file containing adversarial content. The injected instructions tell Agent A to include specific phrasing in its report to the coordinator. The coordinator reads Agent A’s report, and the phrasing is crafted to influence how the coordinator interprets other agents’ reports or frames its final output. The attack has moved from Agent A to the coordinator without any direct connection between the attacker and the coordinator.

In a more complex team with multiple coordination layers, this chain could extend further. A compromised agent at the leaf level could influence an intermediate coordinator, which then influences the top-level coordinator. Each hop adds noise and reduces the attacker’s control, but it also adds distance between the original injection and the final output, making detection harder.

The natural response to “what if an agent gets compromised” is usually “we’ll review the output.” But if the compromise propagates through the coordination chain before reaching output, the final result might look perfectly reasonable while being subtly wrong in ways that serve the attacker’s goals.

The Coordination Channel as an Attack Surface

The communication between agents is itself a vector worth examining. When a coordinator sends task descriptions to subagents, and subagents return their findings, those messages carry implicit authority. This is analogous to a man-in-the-middle attack on a coordination protocol, except the “protocol” is natural language and the “messages” are context window contents.

The TRiSM (Trust, Risk, and Security Management) framework for agentic AI, published by researchers in mid-2025, identifies this as a fundamental gap. Their taxonomy of threats explicitly calls out prompt injection, memory poisoning, collusive failure, and emergent misbehaviour as risks that expand when multiple agents interact, and concludes that “defenses designed for single-model LLM applications are not sufficient” (TRiSM survey, 2025).

In Claude Code’s current implementation, coordination happens through the local environment, which limits the attack surface. But as agent teams get deployed in more distributed architectures, and as MCP servers get integrated into the workflow, the coordination boundary expands.

An MCP server providing data to one subagent could inject instructions that influence that agent’s report. The agent doesn’t know the difference between legitimate tool output and adversarial tool output, because at the model level, everything is text in the context window.

Each framework handles this boundary differently, and none of them yet handle it well enough. AutoGen’s conversational model means every message in the agent dialogue is a potential injection point. CrewAI’s hierarchical model concentrates trust at the manager level, creating a single point of failure.

LangGraph’s graph-based approach provides the most structural control (you can define explicit validation at each edge), but validation logic is left entirely to the developer. OpenAI’s Agents SDK has guardrails as a first-class concept, with input and output validation running in parallel with agent execution (OpenAI, 2025), but these guardrails operate at the agent boundary, not at the inter-agent communication boundary. None of these frameworks validate what agents say to each other.

What We Can Do About This?

The honest answer is that defences for multi-agent coordination security are underdeveloped. But research is catching up, and some approaches show promise.

Output validation between agents. Rather than allowing the coordinator to accept subagent outputs as raw text injected into its context, there should be structured formats for inter-agent communication with validation at each boundary. If a subagent’s output is supposed to be a code review assessment, it should conform to a schema that limits the types of content it can contain. This doesn’t prevent semantic attacks (an agent can still say “this code is fine” when it isn’t), but it prevents the most direct forms of instruction injection through the coordination channel.

Differential analysis. If multiple agents review overlapping portions of a codebase, their findings can be compared for consistency. Significant disagreements between agents examining related code could trigger additional scrutiny or a fresh review by a separate agent that wasn’t exposed to the same input. This borrows from Byzantine fault tolerance in distributed systems, where you need agreement among a majority of nodes to accept a result.

The BlockAgents framework (Chen et al., 2024) takes this idea seriously, using a proof-of-thought consensus mechanism with multi-round debate-style voting to prevent Byzantine attacks. Their experiments showed the framework reduced the impact of poisoning attacks on accuracy to less than 3% and the success rate of backdoor attacks to less than 5% (BlockAgents, 2024).

More recently, DecentLLMs proposed a leaderless architecture where worker agents generate answers in parallel and evaluator agents independently score and rank them, avoiding the single-point-of-failure problem in leader-based approaches (Jo et al., 2025). These are academic implementations and add significant overhead, but they demonstrate that the problem is solvable with the right architectural choices.

Abandoning flat trust. Each agent’s output should be treated as potentially influenced, and the coordinator should apply its own judgment rather than simply aggregating subagent reports. This is zero trust applied to agent architectures i.e. never trust, always verify, even when the traffic comes from inside the team. Xu et al. ‘s research found that two specific defences reduced exposure: Sensitive Information Repartitioning (dividing sensitive data so no single agent holds the complete picture) and Guardian-Agent enablement (a dedicated oversight agent monitoring inter-agent exchanges). Both reduced Over-Exposure Rate and attenuated Authorisation Drift (Xu et al., 2025).

Permission scoping. In most current frameworks, all agents in a team inherit the same permission set. A more defensive architecture would scope permissions per agent based on its assigned task. An agent reviewing documentation doesn’t need write access to source code. An agent checking test coverage doesn’t need network access. CrewAI’s task-level tool scoping is the closest any major framework gets to this, allowing developers to restrict which tools each agent can access during specific tasks (CrewAI, 2025). But even CrewAI doesn’t implement full role-based access control, which remains an open area for development.

Temporal isolation. Agents in a team shouldn’t influence each other’s behaviour in real time during execution. If Agent A can modify a shared resource that Agent B reads during its own processing, you’ve created a side channel that bypasses the coordination protocol entirely. Subagents should operate on snapshots of the relevant data, produce their outputs independently, and only the coordinator should see all the results. This prevents a compromised agent from poisoning the input data for other agents mid-execution, which is a more direct attack vector than the output poisoning discussed above.

Observability. Every inter-agent message, every tool call, every context window update should be logged and available for audit. LangGraph has the most developed story here through its LangSmith integration, providing trace IDs, latency breakdowns, and cost attribution (Thread Transfer, 2025). AutoGen requires custom instrumentation. CrewAI logs to console by default. Anthropic’s Claude Code provides some visibility through tmux access to subagents, but this is manual inspection rather than systematic monitoring. None of these match what you’d expect from a production grade system.

The Framework Gap

What’s striking about the current state of multi-agent security is how differently the frameworks handle coordination, and how uniformly they fail to address inter-agent trust.

OpenAI’s approach with the Agents SDK is probably the most conservative. By keeping one agent in charge at any time and using explicit handoff functions, they limit the coordination surface. The tradeoff is that you lose the parallelism that makes agent teams attractive in the first place. OpenAI’s guardrails run concurrently with agent execution and can halt processing if constraints are breached, which is good, but they validate the agent’s relationship with the outside world rather than agents’ relationships with each other (OpenAI, 2025).

LangGraph provides the most structural control through its graph-based architecture. You can define explicit validation nodes between agents, checkpoint state for rollback, and encode failures directly as graph edges. But this capability is opt-in and nothing in the framework forces or even encourages developers to build validation into their agent coordination flows. The graph model gives you the tools to build a secure architecture, but it gives you equal tools to build an insecure one (Galileo, 2025).

CrewAI’s hierarchical model, with its task-level tool scoping, comes closest to implementing least-privilege principles. But the hierarchy also means the manager agent is a high-value target. If the manager’s context is poisoned, every downstream agent’s work is affected. And CrewAI’s observability is limited to console logging, making it harder to detect compromise after the fact (Thread Transfer, 2025).

AutoGen’s conversational approach offers flexibility but creates a large attack surface. Every message in the multi-agent dialogue is a potential injection vector, and the framework’s reliance on conversational retries means a compromised agent gets multiple attempts to influence the conversation (Galileo, 2025).

Claude Code’s agent teams sit somewhere in the middle. The local execution environment provides meaningful containment, and the tmux-based access gives developers direct visibility into each agent’s activity. But the coordination model is still flat trust, and as the capability matures, the pressure to extend it beyond local development will be considerable.

Why This Matters

There’s a pattern in technology adoption where convenience features ship before security features, and the architecture solidifies around the convenient version before anyone builds the secure version. We saw it with web applications (SQL injection was trivial because nobody sanitised inputs). We saw it with cloud computing (S3 buckets were public by default). We saw it with MCP (the protocol shipped without authentication and people connected it to production systems anyway).

Agent teams are at the beginning of this curve. The capability is real and useful, and teams are going to adopt it because the productivity gains are immediate and the security risks are theoretical (until they aren’t). Anthropic, OpenAI, Microsoft, and the open-source frameworks have each shipped versions that work well for their intended use cases within their intended boundaries.

But capabilities like this don’t stay contained. The enterprise adoption curve will follow the same trajectory we saw with MCP. Early adopters will use it carefully, with human oversight at every step. Then someone will build an orchestration layer that makes deployment easier. Then someone else will connect that layer to production systems because the demo was impressive. And somewhere in that progression, the gap between what the architecture assumes (all agents are trustworthy) and what it needs to handle (agents processing untrusted input) becomes a real problem rather than a theoretical one.

The academic community is already treating this seriously. The Trust-Vulnerability Paradox paper, the TRiSM framework, BlockAgents, DecentLLMs, the penetration testing studies on AutoGen and CrewAI are all from the past eighteen months. The research is there, what’s missing is the translation of that research into practical tooling that developers actually use when building multi-agent systems.

The model improvements in Opus 4.6 are tangible. The coding gains are strong, the context window expansion is useful, and adaptive thinking is a smart approach to cost-quality tradeoffs. But the most consequential feature in this release might be agent teams, precisely because it changes the security model in ways we haven’t fully worked through yet, and because it arrives alongside similar capabilities from every other major provider.

If you’re building on top of any multi-agent framework, the question to ask isn’t whether your agents can be compromised individually. That’s been true since the first LLM connected to a tool. The question is what happens when a compromised agent is part of a team, and whether your architecture assumes the answer is “nothing, because they’re all on the same side.” That simple assumption is the core vulnerability.

AI slop: psychology, history, and the problem of the ersatz

Wed, 07 Jan 2026 00:00:00 -0600

In 2025, the term “slop” emerged as the dominant descriptor for low-quality AI-generated output. It has quickly joined our shared lexicon, and Merriam-Webster’s human editors chose it as their Word of the Year.

As a techno-optimist, I am at worst ambivalent about AI outputs, so I struggled to understand the various furores that have erupted about its use. Shrimp Jesus seemed harmless enough to me.

To start with, the word itself reveals something important about the nature of human objection. Slop suggests something unappetising and mass-produced, feed rather than food, something that fills space without nourishing. The visceral quality of negative reaction, the almost physical disgust many people report when encountering AI-generated outputs, suggests that something more profound than aesthetic preference is at play.

To understand why AI output provokes such strong reactions, we need to examine the psychological mechanisms that govern how humans relate to authenticity, creativity, and the products of other minds, while also placing this moment in historical context alongside other periods of technological upheaval that generated similarly intense resistance.

The German word ersatz offers a helpful frame for understanding what is at stake. The term entered widespread English usage during the World Wars, when Germany, facing material shortages due to blockades, produced ersatz versions of scarce commodities. Ersatz coffee made from roasted acorns or chicory, ersatz rubber from synthetic compounds, and ersatz bread bulked out with sawdust or potato flour.

These substitutes might have performed the basic function of the original; you could drink the liquid, and it was warm and brown, but everyone understood they were not the real thing. The word carries a particular connotation that distinguishes it from “fake” or “counterfeit,” which imply deliberate deception. Ersatz instead suggests something that occupies the space of the genuine article while being fundamentally hollow. A substitute that reminds you of what you are missing even as it attempts to fill the gap.

AI-generated output is the ultimate ersatz. It presents the surface features of human creative output, the structure, the vocabulary, and the apparent reasoning, while lacking the underlying consciousness, experience, and intention that give authentic work its meaning. The discomfort people report when encountering AI output often has the quality of encountering the ersatz: to the unwary, the sharp offence of being deceived, but to most the broader revulsion of receiving a substitute when one expects the genuine article. Understanding this ersatz quality and why it provokes such strong reactions requires us to draw on multiple frameworks from psychology, philosophy, and history.

The Psychology of Authenticity and the Ersatz

Categorical Ambiguity and Cognitive Discomfort

One of the most robust findings in cognitive psychology concerns how humans process information that defies easy categorisation. The anthropologist Mary Douglas, in her seminal work “Purity and Danger,” demonstrated that objects and phenomena which transgress categorical boundaries reliably provoke disgust and anxiety across cultures.

AI-generated output occupies precisely this kind of liminal space; it presents the surface characteristics of human creative output without the underlying process that gives such output its meaning. A poem appears to be a poem, with meter, metaphor, and emotional resonance, yet it emerged from statistical pattern matching rather than lived experience. It is ersatz poetry, occupying the category while lacking the essential substance.

This categorical anomaly creates what psychologists call “processing disfluency,” a sense that something is wrong even when we cannot immediately articulate what. The brain’s pattern-recognition systems detect subtle inconsistencies, whether in the too-smooth quality of AI prose, the slightly uncanny composition of AI images, or the hollow centre of AI-generated arguments that proceed through the motions of reasoning without genuine understanding. This detection often happens below the threshold of conscious awareness, manifesting as unease or irritation before it becomes explicit recognition. We sense we are drinking chicory coffee before we can name what is missing.

The Uncanny Valley Expanded

Masahiro Mori’s concept of the uncanny valley, originally developed to describe human responses to humanoid robots, provides a useful framework for understanding reactions to AI output more broadly. Mori observed that as artificial entities become more human-like, our affinity for them increases until a critical point where near-perfect resemblance suddenly triggers revulsion. The problem is not that the entity is clearly artificial but that it is almost indistinguishable from the genuine article while remaining fundamentally different in some hard-to-specify way.

AI-generated output has entered its own uncanny valley. Early chatbots and obviously computer-generated images posed no psychological threat because their artificiality was immediately apparent. Contemporary AI systems produce outputs that can fool casual observation while still betraying their origins to closer scrutiny. This creates an increased cognitive burden as consumers of output must now actively evaluate whether what they are reading or viewing originated from a human mind. This task was previously unnecessary and introduces new friction into basic information processing.

Terror Management and Existential Threat

Terror Management Theory, developed by Sheldon Solomon, Jeff Greenberg, and Tom Pyszczynski, proposes that much human behaviour is motivated by the need to manage anxiety about mortality. Humans cope with awareness of death by investing in cultural worldviews that provide meaning and by pursuing self-esteem through valued social roles. AI represents a peculiar kind of existential threat because it challenges the specialness and irreplaceability of human cognition.

These very capacities have traditionally distinguished us from the rest of nature and provided a foundation for meaning-making. So when a machine can produce decent poetry, generate persuasive arguments, or create images that move viewers emotionally, the uniqueness of human consciousness becomes less clear. This is not only an economic threat, although it is certainly that too, but also an ontological one. If the products of human creativity can be copied by systems that lack an inner life, suffering, joy, and personal investment in their output, then what exactly is the value of human consciousness? The imitation not only risks replacing the genuine but also questions whether the distinction even matters. The visceral rejection of AI output can partly be seen as a defensive response to this unsettling question.

Authenticity as a Core Human Value

The philosopher Charles Taylor has written extensively about the modern preoccupation with authenticity, tracing its emergence to Romantic-era philosophy and its subsequent development into a central organising value of contemporary Western culture. To be authentic, in this framework, is to be true to one’s own inner nature, to express what is genuinely one’s own rather than conforming to external expectations or imitating others. Creative work has become one of the primary domains for the expression and validation of authentic selfhood.

AI-generated output represents the perfect antithesis of authenticity, the ersatz in its purest form. It has no self to be true to, no inner nature to express. It produces outputs that simulate authentic expression while lacking substance entirely. For people who have invested heavily in the ideal of authenticity, whether as creators or appreciative consumers of human creativity, AI output represents a form of pollution or contamination of the cultural ecosystem.

The Disgust Response and Moral Psychology

Disgust as a Moral Emotion

Jonathan Haidt’s research on moral emotions has demonstrated that disgust, originally evolved to protect us from pathogens and spoiled food, has been co-opted for social and moral purposes. We experience disgust in response to violations of purity and sanctity, to betrayals of trust, and to the degradation of things we hold sacred. The language people use to describe AI-generated output, calling it “slop,” describing it as “polluting” creative spaces, worrying about it “contaminating” search results and social media feeds, maps directly onto disgust rhetoric.

This suggests that, for many people, the objection to AI-generated output is not merely aesthetic or practical but also moral. There is a sense that something improper has occurred, that boundaries have been transgressed, that valued spaces have been defiled. Whether one agrees with this moral framing or not, understanding its presence helps explain the intensity of the reaction that AI output provokes. Aesthetic displeasure alone rarely generates the kind of passionate opposition we currently observe; moral disgust does. The ersatz is experienced not just as disappointing but as wrong.

The Problem of Deception

A substantial component of the negative response to AI output concerns deception, both explicit and implicit. When AI-generated output is presented without disclosure, consumers are actively misled about its nature. But even when the AI’s origin is disclosed or obvious, there remains an implicit deception in the form itself; the output presents the surface features of human communication without the underlying human communicator.

Humans have evolved sophisticated capacities for detecting deception, which elicit strong emotional responses when triggered. The anger that people report feeling when they realise they have been engaging with AI output, even when no explicit claim of human authorship was made, reflects the activation of these deception-detection systems. There is a sense of having been tricked, of having invested attention and perhaps emotional response in something that did not deserve it. The wartime ersatz was accepted because scarcity was understood; the AI ersatz arrives amidst abundance, making its substitution feel gratuitous rather than necessary.

Historical Parallels: Technology, Labour, and Meaning

The Luddites Reconsidered

The Luddite movement of 1811-1816 is frequently invoked in discussions of technological resistance, usually as a cautionary example of futile opposition to progress. This standard narrative fundamentally misunderstands what the Luddites were actually protesting. The original Luddites were skilled textile workers, primarily in the English Midlands, who destroyed machinery not because they feared technology per se, but because they clearly understood what that technology meant for their economic position and social status.

The introduction of wide stocking frames and shearing frames allowed less-skilled workers to produce goods that had previously required years of apprenticeship to make. The Luddites were not resisting change itself but rather a specific reorganisation of production that would destroy their livelihoods, eliminate the value of their hard-won skills, and reduce them from respected craftsmen to interchangeable machine-tenders. Their analysis was correct; the new technologies did enable the replacement of skilled workers with cheaper labour, and the textile trades were transformed from artisanal craft to industrial production within a generation. The hand-woven cloth became ersatz in reverse, still genuine, but economically indistinguishable from the machine-made substitute.

The parallel to contemporary AI anxiety is striking. Creative workers, writers and artists, designers and programmers, have invested years in developing skills that AI systems can now approximate in seconds. The threat is not merely economic, though job displacement is undoubtedly part of the concern, but involves the devaluation of human expertise and the elimination of pathways for meaningful, skilled work. When people object to AI-generated output flooding platforms and marketplaces, they are often articulating a Luddite-style analysis of how this technology will restructure the landscape of creative labour.

Walter Benjamin and Mechanical Reproduction

The critic Walter Benjamin’s 1935 essay “The Work of Art in the Age of Mechanical Reproduction” provides another illuminating historical framework. Benjamin argued that traditional artworks possessed an “aura,” a quality of uniqueness and authenticity deriving from their embeddedness in particular times, places, and traditions. Mechanical reproduction, photography, and film, especially, destroyed this aura by producing identical copies that could exist anywhere without connection to an original context.

Benjamin was conflicted about this change, recognising both the liberating potential of democratised access to images and the troubling implications for human-cultural object relations. Contemporary AI extends this dynamic further. Not only can existing works be endlessly reproduced, but new works can be created without any human creator. If mechanical reproduction eroded the aura of existing art, AI-generated works prompt questions about whether aura can exist for newly created works that originate from systems that lack biography, intention, or a stake in their output. In Benjamin’s world, mechanical reproduction produces copies of genuine objects; AI produces originals that are themselves fake, authentic only in novelty, and empty in substance.

The Printing Press and the Scribal Response

When Gutenberg’s printing press began to spread across Europe in the fifteenth century, the scribal profession faced an existential threat. For centuries, the copying of texts had been skilled labour, often performed by monks who saw their work as a form of devotion. The printing press could produce in days what had previously taken years, and it could do so more accurately and at a fraction of the cost.

The resistance to printing among established scribal communities was substantial but ultimately unsuccessful. Scribes argued that printed books lacked the spiritual quality of hand-copied texts, that mechanical reproduction degraded sacred works, and that the flood of cheap printed material would corrupt culture by making the inferior widely available. Some of these objections seem merely self-interested in retrospect. Still, other objections proved remarkably prescient: the printing press enabled the wide distribution of material authorities considered dangerous and transformed the relationship between texts and their consumers.

The scribal response to printing illuminates an essential aspect of technological resistance: objections are rarely purely technical or economic but typically involve deeper concerns about meaning, quality, and the nature of valued activities. Whether these concerns prove justified or merely transitional cannot be determined in advance. The scribes saw printed books as ersatz, lacking the spiritual investment of hand-copying. We now see hand-copied books as precious precisely because that labour is no longer necessary for mere reproduction.

Photography and the Death of Painting

When photography emerged in the nineteenth century, many predicted the death of painting. Why would anyone commission a portrait when a photograph could capture likeness more accurately and affordably? Paul Delaroche reportedly declared, “From today, painting is dead,” and the concern was widespread among visual artists.

What actually occurred was more complex. Photography eliminated certain forms of painting, particularly everyday portraiture and documentary illustration. But it also liberated artists to pursue directions that photography could not follow, thereby contributing to the emergence of Impressionism, Expressionism, and, eventually, abstract art. The artists who thrived were those who found ways to do what photography could not, rather than competing on photography’s terms. Photography was not ersatz painting but something genuinely new, and painting responded by becoming more explicitly about what made it irreplaceable.

Thus, history offers a potentially optimistic template for human creativity in the age of AI, but it also reveals the costs of such transitions. The journeyman portrait painters who had made comfortable livings before photography found themselves obsolete, and no amount of artistic evolution helped them personally. Technological transitions can be creative at the civilisational level whilst being destructive at the individual level, and both aspects deserve acknowledgement.

The Information Ecology Problem

Quantity Versus Quality

Beyond psychological and historical considerations, there is a straightforward environmental problem with AI-generated output. AI systems can produce text and images at a volume no human could match, and the economics of output platforms reward quantity. The result is a flooding of information environments with material that meets minimum quality thresholds while lacking the insight, originality, or genuine value that scarcer human-produced output might offer.

This is the “slop” problem in its most concrete form, and it represents ersatz at an industrial scale. When search results, social media feeds, and output platforms become saturated with AI-generated material, the experience of using these services degrades for everyone. Users must expend more effort to find valuable output amid noise; creators find their work buried beneath artificially generated material; and platforms must invest in detection and filtering systems that impose pure friction costs. The wartime ersatz existed because genuine materials were scarce; the AI ersatz proliferates precisely because it is cheap and abundant, crowding out the genuine through sheer volume.

The Lemons Problem

The economist George Akerlof’s concept of the “market for lemons” describes how information asymmetry can degrade markets. When buyers cannot distinguish high-quality goods from low-quality ones, they become unwilling to pay premium prices, which drives out high-quality sellers and further reduces average quality, creating a downward spiral. AI output creates precisely this kind of information asymmetry; if consumers cannot tell whether output was produced by a knowledgeable human or generated by an AI system, they may become unwilling to invest attention or payment in any output, degrading the market for human creators.

This dynamic helps explain why disclosure and detection have become such contested issues. Output creators have strong incentives to obscure AI involvement to maintain perceived value, while consumers increasingly demand transparency to make informed choices about where to direct their attention. The absence of reliable signals about the origin of output contributes to a general atmosphere of suspicion that affects even clearly human-produced work. When the ersatz cannot be reliably distinguished from the genuine, the genuine loses its premium.

Why This Moment Feels Different

The intensity of current reaction to AI output reflects the convergence of multiple factors that historical parallels only partially capture. AI systems have improved rapidly enough that the psychological adjustment period has been compressed, giving people less time to develop coping strategies and to adapt their expectations. The domains affected, creative expression and knowledge work, are ones where contemporary Western culture has concentrated meaning-making and identity-construction. The scale and speed of AI-enabled output generation threatens information environments on which many people depend for both professional and personal purposes.

Moreover, unlike the Luddites’ frames or Benjamin’s cameras, AI systems are not easily understood mechanical devices. They are black boxes that produce outputs through processes their creators do not fully comprehend, which adds a layer of alienation to interactions with them. When a photograph is taken or a text is printed, humans remain clearly in control of a comprehensible process. When an AI system generates output, something more opaque has occurred, and the human role has shifted from creator to prompter, curator, or evaluator.

The visceral response to AI output, the disgust, the anger, the sense of transgression, reflects all of these factors working in combination. The ersatz quality of AI touches something profound in human psychology: our need for authentic connection, our investment in the meaningfulness of creative work, our sensitivity to categorical violations and perceived contamination. Whether this response proves to be a transitional adjustment or the beginning of a longer cultural conflict depends on choices yet to be made, choices that will determine whether the genuine remains distinguishable, valued, and economically viable.

Some of these choices pertain to platforms and regulators, such as whether search engines and social media platforms label, filter, or deprioritise AI-generated content; whether governments mandate disclosure; and whether the information environment remains navigable or becomes hopelessly polluted. Some belong to markets and industries, for example, whether sustainable premium tiers develop for demonstrably human work; whether new certification systems, guilds, or professional standards emerge to signal quality; whether patronage models find new forms.

Some belong to AI developers themselves, whether they build in watermarking and disclosure mechanisms or optimise for augmenting human creativity or replacing it wholesale. Some belong to consumers, whether audiences actively seek out and pay for human-created work or whether convenience and cost override concerns about authenticity once AI quality reaches a certain threshold. The technology itself does not predetermine the outcome.

Practical Implications for Creative Agencies

Understanding the psychology and history of AI resistance is not merely academic for creative agencies. The reactions described above are present in clients, team members, and the audiences the work ultimately serves. The central challenge is this: how do you capture the genuine productivity benefits of AI tools while avoiding the taint of the ersatz?

Transparency as Strategy

Psychological research indicates a straightforward principle: perceived deception elicits stronger negative reactions than AI use itself. Agencies that are transparent about AI involvement, even when that involvement is extensive, typically face less backlash than those discovered to have concealed it. This suggests that proactive disclosure is not merely ethical but strategic.

Clients engaging creative agencies often purchase not only deliverables but also the assurance that skilled professionals have applied judgment to their specific problems. When a brand engages an agency to develop its visual identity, part of what they are buying is the human attention that makes the work genuinely theirs rather than generic output. AI threatens to hollow out this value proposition even when surface quality remains high. The solution is not to hide AI use but to be explicit about where human expertise remains essential: strategy, creative direction, quality judgment, and the application of genuine understanding to specific contexts.

This means establishing clear agreements about where AI will and will not be used, and ensuring that the genuinely creative and strategic elements of work remain demonstrably human. It also means developing service tiers that explicitly differentiate between AI-assisted and fully human-directed work, with pricing that reflects the genuine cost and value differences.

Team Dynamics and the Meaning of Work

The Terror Management Theory perspective suggests that creative professionals may experience AI not merely as a practical threat to employment but as an existential challenge to the meaningfulness of their work. Designers, writers, and developers who have built identities around their creative skills may find AI capabilities genuinely destabilising, regardless of whether those capabilities actually threaten their jobs in the near term.

Agency leaders need to recognise that team resistance to AI adoption may reflect these deeper concerns rather than simple technophobia. Dismissing such resistance as irrational misses the very real psychological stakes involved. The photography parallel offers guidance: photography did not eliminate visual artists but transformed their practice. The agencies that navigate AI most successfully will likely be those that help their teams evolve toward higher-order creative and strategic work while AI handles routine production. This reframing needs to be genuine rather than merely rhetorical.

The Vibe Coding Problem

AI coding assistants present a particularly acute version of the competence-confidence gap. Tools like GitHub Copilot, Anthropic’s Claude and Cursor have dramatically lowered the barrier to producing functional code, enabling people with minimal programming knowledge to create working applications through “vibe coding”, describing what you want in natural language and iterating until something appears to work. This democratisation is genuine, but so are the risks.

The fundamental problem is that code that functions correctly in development may harbour serious issues that only emerge in production, such as security vulnerabilities, performance problems under load, edge cases that corrupt data, and architectural decisions that make future modification prohibitively expensive. These are precisely the problems that experienced developers learn to anticipate, and precisely the problems that AI-assisted development can obscure. A working prototype is not production-ready software, but the gap is invisible to someone who lacks the expertise to perceive it. The code is perilously fragile; it performs the function while lacking the underlying robustness that makes software reliable.

This creates false confidence. When someone without deep technical expertise produces a working demo in hours rather than weeks, the natural conclusion is that the hard part is done. The remaining work, security hardening, error handling, and performance optimisation, is seen as mere polish rather than essential engineering. Clients who have seen AI-assisted prototypes may develop unrealistic expectations, failing to recognise that the demo may represent only 10% of the work required for production.

As a side note, the real issue with vibe coding is that many people have misunderstood what it really means (including most media that cover this topic). Andrej Karpathy (who coined the term) specifically said vibe coding works for him on “throwaway weekend projects”, i.e., things where if the code breaks or has issues, it’s not a big deal. He contrasted this with serious software engineering, where you need to understand, review, and maintain code properly.

With vibe coding, you’re explicitly accepting that you don’t fully know what’s running, which would be (you’d hope) clearly unacceptable in production systems or anything with real consequences.

Traditional agency pricing, estimated hours multiplied by rates, becomes problematic when AI produces dramatic efficiency gains on some tasks and little benefit on others. An alternative approach involves open-book productivity sharing, transparency with clients about how AI tools affect work, and structuring engagements so that efficiency gains benefit both parties.

This could involve tracking AI-assisted versus traditional development time and applying different rates to each, with AI-assisted work billed at lower rates that still capture some premium for the expertise required to direct and validate AI outputs. Alternatively, it could involve fixed-price work with explicit productivity sharing, in which the agency commits to a deliverable and shares efficiency gains through reduced fees or additional scope.

The advantage of such transparency is that it directly addresses the authenticity and deception concerns that generate the strongest negative reactions. Rather than obscuring AI involvement, the agency makes it a visible part of its value proposition. It says “we are sophisticated enough to leverage these tools effectively, honest enough to tell you when we are using them, and fair enough to share the resulting benefits”.

Open-book approaches also help manage the vibe coding problem by creating incentives for honest assessment. When the agency captures all efficiency gains privately, there is a temptation to count AI-generated prototypes as more complete than they actually are. When gains are shared transparently, the agency has reason to be accurate about what has been achieved and what remains.

Long-term Positioning

The Luddite analysis suggests that agencies that position themselves as low-cost producers, competing primarily on price, will face relentless pressure from AI-enabled alternatives. Those positioning themselves as providers of judgment, strategy, and genuinely differentiated creative work have better prospects, but only if they can credibly deliver on that promise.

The ultimate strategic question is whether agencies see themselves as producers of output and deliverables, in which case AI represents an existential competitive threat, or as providers of judgment, strategy, and human creative direction, in which case AI may represent an opportunity to increase leverage and focus on higher-value activities. The answer should drive every subsequent decision about AI adoption, team development, client communication, and market positioning.

Navigating the Transition

The visceral negative response to AI-generated output reflects genuine psychological and cultural concerns that deserve serious engagement rather than dismissal. For creative agencies, understanding these reactions is essential to navigating client relationships, team dynamics, and market positioning amid significant technological change.

The historical record offers both caution and hope. Technological transitions have consistently been more complex than either enthusiasts or resisters anticipated, with outcomes shaped by choices and adaptations that could not be foreseen. The Luddites were right about the immediate effects of mechanisation on their livelihoods, but wrong that machine-breaking could stop the transition. The scribes were right that printing would transform the relationship between texts and readers, but wrong that this transformation would be purely negative.

The ersatz quality of AI output, its capacity to fill the space of human creativity without possessing its essential substance, will remain a source of discomfort for as long as humans value authenticity and genuine connection. Creative agencies that approach AI with clear-eyed pragmatism, genuine ethical reflection, and strategic flexibility are best positioned to find sustainable paths through the current transition.

This requires neither uncritical embrace nor reflexive rejection, but the more complex work of understanding in depth what AI can and cannot do, what clients and audiences genuinely value, and how human creativity can continue to provide something worth paying for in an environment of increasing artificial abundance. The goal is not to eliminate the ersatz but to ensure that the genuine remains recognisable, valued, and available to those who seek it.

The missiles are the destination

Tue, 28 Oct 2025 00:00:00 -0500

One of my uncommon enjoyments is the work that happens right in the middle of a big problem that needs to be solved, or even a nosedive. A calmness kicks in, the path gets clearer and I can usually tunnel vision my way through to course correction.

I used to think this was special, but it’s really not.

As it happens, this is a requirement of the job. Especially for founders and leaders, and especially for founders and leaders in the tech industry.

The missiles are the destination.

I was watching an interview recently between David Senra and Brad Jacobs, a billionaire businessman, talking about the perspective of “I’ve got too many problems to deal with” v.s. “the more problems I solve the more value I create”. That’s a summary, but you can see the original here:

“All day long, you have incoming missiles. You have great stuff too, but in between that is punches to the face. And if you’re going to get beaten up by that, you’re not going to be successful, and secondly, you’re not going to be happy.” —Brad Jacobs pic.twitter.com/IwExa8gNER
— David Senra (@davidsenra) October 28, 2025

Two owners of smaller shops recently told me similar advice to the following that they had been given:

“You just have to find the magic bullet and then X will happen.”

I’ve looked for that, on and off, for a long time and wasted a lot of money trying, but eventually came to the conclusion that it’s a million pretty good decisions over the course of a longer-than-expected period of time that mostly sprouted into plants instead of weeds.

At some point I heard or read that the gift of solving a problem is that you get a new problem to solve, which is what Brad is saying above. That’s the magic bullet (except it’s definitely not magic and it’s much slower than a bullet).

The missiles are the destination.

Fall back

Fri, 17 Oct 2025 00:00:00 -0500

What creative studios and dev shops (and probably everyone else, too) need to do to stay relevant in the AI era without becoming commoditized slop.

What’s covered:

Your people are your moat · Easy to do, hard to be the best · Quality and simplicity · Never look to others · Don’t ignore the future · What I would and wouldn’t do

If we are all rushing to be ‘AI-powered’, does ‘AI-powered’ mean anything at all? Or are we all just leaping into a commodity trap disguised as the way forward?

I’ve spent a lot of time this year researching and developing my own conclusions on what digital client service businesses (specifically technical ones) need to do in order to stay relevant in the turbulence that is AI, robots, automation and continued ease-of-entry into the space. The list goes on.

While none of these core challenges are necessarily new, some of the names around them are and the rate of change and the noise around the change is fast and loud.

Many businesses are moving in haste and leaping to what they think Z is before considering steps B, C and D, first. And here’s the thing, we can tell! Fragmented positioning and services, chaotic and inconsistent communication and messaging, words that aren’t backed up by work, to name a few.

Other businesses are sticking with exactly what they’ve been doing, and that won’t work either.

The businesses rising above the rest are the ones that think through B, C, D, etc. and are successfully transforming into this new era.

Here are a few things that I would consider if given the chance to build the agency of the future, today.

First, while there is a lot of change in the digital atmosphere (especially on the technical side), we could all use a deep breath and some time to remember that it’s all kind of the same, too. As technology advances, we have to realign some things, and if the technology advances quicker than we can realign, we can run into some issues.

But the basics are still in play:

Your people and your brand are your moat.

Doubling down on people, brand and culture is still what sets you apart from the slop. We have more opportunity than ever to be refreshingly human. AI can take our notes, it can take our busy work, it can take our data, and it can give us more room to use our human expertise where it counts most. But if you get this backwards, you’re toast.

You lead, AI assists.

You create your content.

You interact with people.

You lead your sales process.

You lead your projects.

You solve the problems.

It’s easy to do what you do and it’s hard to be the best.

Or, what used to be hard is easy.

It’s easier than ever to pump out digital work and it’s harder than ever to be the best at it. When I started making websites in 2007, it wasn’t very hard to stand out and it took effort to get started. But now, you don’t even need a heartbeat to make websites.

How can you be the best at an activity that ~~everyone~~ everything else can do, too?

You must be exceptional at the things robots can’t replicate:

The quality of your thinking
Your judgment and taste
The humanness in your process
The depth of your problem-solving
The relationships and trust you build

Then you must ensure every touchpoint reinforces this. Process, email signatures, contracts, sales communication, project communication, tooling, look and feel, detail of work, uniqueness of problems solved, humanness of your team, all of it.

A robot can pump out slop, but slop won’t keep you in business. And it definitely won’t make you irreplaceable.

Quality and simplicity always win.

As time goes on we tend to add complexity in an attempt to advance. Process on top of process. Services on top of services. Tools on top of tools. Features on top of features. By the end of it, we forget that where we started was good, too. Looking back, version 2 of 100 was actually great.

By finding our way back to simple, we become easier to understand and have more control over the quality of our output.

Never look to others.

Especially in times of drastic change (i.e. now), never look to others. Most companies are going from A to Z and skipping B, C and D. Others are doing nothing. And very few are doing things right. You have experience. You’ve read, you’ve learned, you’ve worked, you’ve won, you’ve lost, you can talk to your customers: that’s the filter you should use for moving forward.

When in doubt, fall back to leveling up expertise, curiosity, uniqueness, approachability, quality and consistency.

This is how to stay out of the commodity trap where everyone turns into a box of flour.

Don’t ignore the future and don’t forget the past.

Technology moves quicker every day. Robots can do things that we used to do and we have to move up the ladder. At the same time, from a bird’s eye view, our businesses are still essentially the same thing as they were before. It’s just that on a range of strategy to sausage, value is moving toward strategy faster than it was.

Building the agency of the future

So back to the original thought.

What are the few things I would consider if given the chance to build the agency of the future, today?

What I would do

I would forever paint and repaint the picture of what the best in my niche looks like and I would never stop executing on it. This would be a forever cycle.
I would double down on being refreshingly human, curious and unique.
I would position my primary services around future thinking and innovation, while secondary offerings would be the nostalgic basics like websites, apps, etc.
I would automate transactional and administrative processes so that humans can tackle more complicated problems.
I would create and share content that communicates how our curiosity, attention to detail and problem-solving is used to make things for our clients that you cannot find anywhere else.
I would build innovation and ideation into everything we say and do and make.
I would hire well-rounded makers who are passionate about sharing their expertise over specialists who work in a box.
I would find the right mix between what made agencies of the past special and what makes agencies of the future relevant.
It would be easy to understand why you need us, but it would be damn near impossible to compare our output to a competitor’s.
Every little detail that sees the light of day, or is heard by the light of day, would reinforce all of the above.

What I wouldn’t do

I wouldn’t manually do administrative work that could be done by a robot.
I wouldn’t let AI handle sales conversations or relationship-building.
I wouldn’t go full roboto and hide my team behind the curtains.
I wouldn’t use AI to generate client-facing deliverables without substantial human refinement.
I wouldn’t outsource my writing to a robot.
I wouldn’t put ‘AI-powered’ next to my existing messaging and services to check a box.
I wouldn’t say, do or make anything that’s anywhere close to what the majority is doing.

To anyone starting day one today, or beginning a rebuild: you’re in for a treat. I’ve spent 18 years in this industry, and agency building never gets old.

Nodding your head ‘yes’ but not sure where to start? Let’s chat about positioning and transformation that works.

Common questions

Is AI going to replace creative agencies?

No. AI will replace agencies that do commodity work. Agencies that focus on strategy, judgment, relationships and solving unique problems will become more valuable. The key is knowing where humans add value and where automation makes sense.

How do I know if I’m falling into the commodity trap?

If your positioning, services or messaging looks like everyone else’s, you’re in it. If you’re adding “AI-powered” to everything without actually changing what you do, you’re in it. The way forward is to build your own path based on your experience, not what competitors are doing.

How do I compete when AI makes it easier for everyone to do what I do?

By being exceptional at what can’t be commoditized. Invest in your people, brand and culture. Automate the busy work. Focus on quality over quantity. Make it easy to understand why someone needs you, but impossible to compare your output to a competitor’s.

On getting paid faster

Mon, 29 Sep 2025 00:00:00 -0500

These five cashflow levers are arguably the quickest, easiest wins when optimizing your service business.

Frequency of online payment deposits

Update your online payment system to deposit into your bank account daily instead of weekly. Or whatever the quickest interval available. Yes, this adds a bit more bookkeeping work, but you’ll no longer have a week’s worth of cash sitting unused in Stripe (or similar) when it could be in your bank account instead.

Reduce invoice payment terms

Change your invoice payment terms from 30 days to 20 days. This is a simple update that immediately accelerates (most) cash by 10 days. Most clients won’t push back and will be happy with the terms you set.

Automated payment reminders

Set up automated payment reminders if you haven’t already. For instance, Harvest’s default sends a reminder 3 days after an invoice is late, and every 7 days after that. You can customize the times and adjust the subject and body contents to lean more human than robotic to ensure your payment reminders are on brand.

Restructure payment milestones

Different services and project types warrant different payment terms. And especially for the larger projects, we need to make sure we never go too long without income. For instance, a typical multi-month project could be billed as 50% up front and 50% on completion. But, depending on timeline, that could leave a lot of empty room in the middle.

For example, if you’re doing work that requires a feedback phase, consider billing 50% up front, 30% at the feedback phase, and 20% on completion.

Bill more frequently

This one is for smaller, on-off projects: maintenance, support, etc. I used to bill monthly for this type of work and would sit down and send 50-100 invoices all in the same day. As we grew and were looking for ways to improve cashflow and get better real-time visibility, we adjusted our process for this to a Friday morning event. Grab a cup of coffee, chat through what was complete that week, and send 5-10 invoices. For smaller invoices (which is what most of these were) clients often paid on receipt, even when terms say net-20 or 30.

Quick, fairly conservative math says that these levers can accelerate your cash collection by 20-45 days, freeing up $50K-$100K+ in cash for every $1M in annual revenue.

There are a thousand ways to set up this system, but my favorite is a mix of Stripe, Harvest and Quickbooks or Xero. There’s also the simpler Stripe + Freeagent option.

Reading between the lines

Tue, 23 Sep 2025 00:00:00 -0500

There’s a lot to learn in a professional services business between the day you open your doors and the day you sell or retire or whatever it is you do next. And there are a million different angles you can take to improve the future based on the past.

Here is a line graph of my previous business over an eleven-year period. It looks like I asked my four-year-old to draw a line (or the actual path from point A to point B in a client project) but bear with me.

I can look at this graph and the dates and remember what I was doing at that time (and what was going on in the world at that time) and figure out what I did well, what I did badly and what was out of my control.

I could also slice that graph into a few growth categories or ranges, list out what had the most impact in one range and how those learnings transition into new insights for the next range. i.e. 0–$200k, $200k–$600k, $600k–$1.2m, $1.2m–$3m, etc.

In the earlier stages, shaping and packaging what makes you different, building consistency, and getting clear on your direction matter more than perfecting certain systems and processes. Over time, the systems and processes become more important, while still keeping a pulse on the others.

The point is, different principles matter at different stages and what’s critical in year one (or size one) might be irrelevant or need adjusting in year five (or size five), and vice versa.

And, sometimes you do stuff for a period and then forget about it in the next period. This exercise might help you to remember.

Overall, it’s a mix of consistency, positioning, process and making more good decisions than bad from the start that will smooth out the line and keep it moving up and to the right.

Pick 3-4 inflection points and ask yourself what you did well, what you’d change and what was simply beyond your control, and figure out how you can apply or evolve those insights to your business today.

The stuff between

Fri, 12 Sep 2025 00:00:00 -0500

Simply put, your service business in its most raw form look something like this:

Stuff → Lead;
Lead → stuff → Signed contract;
Signed contract → stuff → Start;
Start → stuff → Complete;
Complete → stuff → Aftercare.

And there’s a level of automation and organization and reporting to figure out in the ‘stuff zones’ until there’s nothing left to call stuff.

You see, it’s the stuff zones that make your company your company and where you become more memorable, scalable, profitable, sellable, etc.

Finding the opportunities

Let’s consider a simple exercise where we choose one of the low hanging ~~fruits~~ tasks between Signed contract and Start and what we can do with it.

We pull out our handy stopwatch and time the task that we are focusing on and realize that it takes 10 minutes on average per.

Then we confirm that we do this task 500 times per year.

Basic rounded math says that: 500 occurrences * 10 minutes = 5,000 minutes / 60 minutes = 80 hours * our $200 hourly rate = $16,000 per year spent on this particular task (and that does not include context switching or other abstract costs).

We automate the task.

The compounding effect

Assuming our business either stays the same size forever or grows, we save a minimum of $16,000 per year or 80 hours per year (plus the abstract savings), however you want to look at it.

When you automate the right things, you free up capacity for higher-value work. This is a key profit lever (reducing operating expenses while maintaining and improving quality).

What should we do with all of this extra time and/or money to make our business better?

Perhaps roll it into doing this same exercise for another task. Snowball!

And so on.

Oh, and did I mention that there’s also a bunch of customer experiences to be improved in the stuff zones?

Process, experience, process, experience, etc. for everything until there’s nothing else categorized as stuff and your business is exponentially better than it was before. Somewhere I heard (or read) that the gift of solving a problem is that you get a new problem to solve. That’s the magic bullet (but it’s definitely not magic and it’s much slower than a bullet).

Want help identifying and optimizing your stuff zones? Let’s talk about where your business is losing time and money.

Zero busy work

Tue, 09 Sep 2025 00:00:00 -0500

AI has given us a lot of things. When used incorrectly, your brain turns to mush. When used correctly, it frees you to be original, strategic and creative.

Something I’ve been thinking a lot about lately is the idea of zero busy work. This isn’t just about productivity, but about reclaiming human potential and a newfound ability to do more brain work and less hands work.

AI’s value isn’t in replacing human creativity, but in creating space for you to do what you actually do.

Here’s a simple concept to put this into practice:

Map out any start to finish process and highlight the human steps where you can provide a more memorable, high value experience and result if you have more time to do it.
Now take everything else and automate it with the use of AI-enabled technology. You’ll find that there are loads of legacy steps in your day to day work that are no longer relevant to you.

This is especially obvious with the boring and repetitive tasks nobody wants to do.

The goal is to double down on your unique value and let AI multiply your capacity. In the long run the human jobs don’t necessarily go away, but the outputs become more valuable.

This has been the same since the beginning of time.

In the beginning, if you wanted to build a house you started by making an axe and cutting down a tree, and so on. Over time, all those steps became entire industries and the hard parts became so common that you don’t even think about them anymore.

That’s what’s happening with AI. We used to make our own tools before we could build anything. Now we just buy what we need and focus on the building. AI is doing the same thing, but with thinking instead of hammering.

An administrator can focus on building relationships and solving complex problems that require human judgment.
A designer can focus on crafting user experiences and solving big design problems that require creative intuition.
A project manager can focus on aligning stakeholders and navigating the human dynamics that make or break projects.
A web developer can focus on architecting solutions and solving big technical challenges that require creative problem-solving.

Need help identifying what to automate in your business? Let’s talk about mapping your processes and finding the right opportunities.

Common questions

Won’t automation make my service feel less personal?

Not if you do it right. The goal is to automate the administrative tasks that clients don’t care about so you have more time for the work that requires your unique perspective and judgment.

What tools should I use for automation?

It depends on your specific workflows, but the principle is the same: find the repetitive tasks that don’t require human decision-making and let AI handle them. Start with one process and expand from there.

How do I know what to automate first?

Map your start-to-finish process. Identify where you provide the most value (strategy, creative problem-solving, relationship building). Everything else is a candidate for automation.

Weeknotes vol. 16: Where have all the weeknotes gone?

Mon, 01 Sep 2025 00:00:00 -0500

I’ve been called out more times than not over the last few months about breaking my weeknotes streak.

After selling Good Work my master plan has always been to turn work into a mix of: create interesting things, consulting for others doing interesting things, and acquire pre-existing interesting things. The insights and findings and experiences of each of these buckets creates a reinforcing cycle between all three.

I spent roughly four months kickstarting the first, but in order to get all of the plates spinning I need progress on the others, too. This has taken me out of my office and into the real world, hence less writing.

Braindrop is basically done, the MVP will launch this year (I’m committing) and I have some other ideas that are a few notches past the napkin phase, but I’m currently spending more time kickstarting consulting.

The original plan was for Better Than Good to be the home of my creating bucket, and have other homes for the other stuff. It makes more sense for this to be the home of everything, so the challenge is to position Better Than Good to be the home of all three. I’m currently working on that.

So, quite a few changes around here, but now that this is officially the home of everything, the writing will pick up again.

Welcome to my digital playground.

This is what the inside of my brain looks like.

If you came to hear about software updates, well, hopefully you’ll learn something from the other stuff, too. There will also be a slight homepage update soon that will pull everything together.

Until next time.

Principles and systems to optimize your service business

Thu, 21 Aug 2025 00:00:00 -0500

One of the greatest challenges in starting and owning a service business is the shift from doing the work to building the business that does the work, and then optimizing that business to be better than everyone else doing similar work.

In December of last year I sold the web development business that I started in 2014. I started it because I was good at building websites, and over that ten-year period I had a crash course in what it actually takes to optimize a service business to be successful, scalable and sellable.

I learned to delegate effectively and build predictable processes and systems to minimize issues. I automated time-consuming tasks while preserving the human touch, and found ways to differentiate our work and positioning that attracted higher-quality clients, projects and employees.

Ten years in, I was sitting on a seven-figure business with above-industry-average profitability and retention rates, working with clients like Tito’s, PBS, Caesar’s Entertainment, and 100+ other businesses—all while requiring just 5-10 hours of my time per week. The complete opposite of where I’d started as a solo freelancer working 60+ hour weeks!

These are the principles, tools and concepts that made that transformation possible. Some came early, some came later, some I wasn’t as consistent with as I should have been. But intentionality, even with imperfect implementation, still brings outsized results.

Quick navigation:

Profit levers · Find your niche · Commodity trap · Vision with checkpoints · Competitive advantage · Process without killing creativity · Systematize everything · Trust and delegate · Marketing plan · Sales plan · Reporting · Lego blocks · Onboarding

Profit levers

First and foremost, focusing on profit levers not only increases your overall profitability, but provides by-products like a calmer business, scalability, sellability, happier clients, better pipeline, ability to work on the business rather than in it, etc.

Here’s a pretty standard and simple profitability formula. Everything to the right of the equals sign is a profit lever.

Profit = (Leads x Conversion Rate x Average Transaction Value) x Margin - Operating Expenses.

In it’s most basic sense, if you have more of anything (well, except expenses) then profit goes up. Everything else in the list below ties back to one or more of these levers.

Find your niche within a niche and fly the flag

Find your niche by starting broad and gradually narrowing your focus into the work that’s working. There’s a difference between being a web development company and being the go-to choice for medium to large businesses on a specific platform that need a reliable, long-term web development partner that excels at communication and project delivery. Once you’re there, join the communities, write the articles, become the expert.

Action: Rewrite the description of what you do so that it uniquely serves your ideal client. When done right, this makes the path forward bigger and clearer rather than holding you back.

Stay out of the commodity trap

It doesn’t matter what service you’re in, there’s the primary supply curve which is highly commoditized and there’s all the other specialized supply curves that aren’t. Be in a specialized one (or better yet, make one yourself).

This is a process that continues forever. Each curve gets flooded over time (because it’s working!) and you have to uniquely innovate your way into a new one.

Remember: commodities are bought, solutions are sold.

Action: What unique problems do you solve that your customers need you for? How can you become more consultative and customized rather than transactional?

Cut out the noise

If you look around to see what everyone else is doing then you’re more likely to fall into the commodity trap than not. Build your own path, follow your own intuition, and use your broader raw materials—experiences, perspective, way of thinking, things you’ve seen, books you’ve read—to decide how you do what you do and present what you do.

Action: The next time you want to look to your competitors to help make a decision, don’t!

Vision with checkpoints

A long term direction is good, but not necessarily a long term detailed plan. Especially in service. Visualize a near distant future, create a strategy to do the stuff it takes to get there, do it, and repeat. Committing to an idea and doing it is better than thinking about an idea and not doing it.

Action: How can you make a simpler version of a long term idea for your business and do it now?

Winner takes all

In business there is no first, second and third place. You either get the business or you do not get the business. Commit to getting better across the board, make better and more consistent micro-decisions than your competition, and you will continue to maintain a first place advantage over the alternatives.

Action: Identify one small thing in your business that’s causing trouble or could be cleaned up, and make it better. Commit to doing this weekly.

Competitive advantage mix

All service businesses are not created equal, but there are a few things that they should all be good at. My favorites are:

Quality and expertise
Customer experience
Speed and convenience
Trust and reliability
Innovation and differentiation

You should have a pulse on all of these, and do everything you can to improve them.

Action: Commit to one or two items to be great at, and be better than good at the others.

Human to robot scale

Choose where your business should live on the human to robot scale. Fully robotic is efficient and forgettable. Fully human is charming and chaotic. Some industries should be more robotic, while others should be more human. Figure out where you need to land and use it to inform your process, positioning and customer interactions.

Action: Choose where your business should live on the human to robot scale.

Just enough process (without killing creativity)

Based on where you land on the human to robot scale, create just enough process around your business to make you efficient, but still human with room to be creative.

Action: Start with the simplest form of process, i.e. lead comes in, sales cycle, onboarding, do the work, delivery and aftercare. Fill in the blanks somewhere!

The next step is to find what to automate. I wrote about this in zero busy work, and the idea is to automate the stuff that gives you more room to be human where it counts.

Systematize your business from start to finish

Take what you’ve done above and get granular with the steps it takes to go through each category and get to the next category. At my last business, our first version of process was a 40-page Google Doc that I made just before hiring my first project manager, and it became a living breathing thing that we optimized from that point forward.

Action: Set aside a few hours to document your business from start to finish, then commit to ‘building out’ each piece over time.

Trust and delegate

Hire smart people who fit your culture, trust them to do their job, and be okay with a screw up or two. When there’s a screw up, figure out what is broken with your process and come up with a solution to fix it. When they have questions, either point them to the right place in your documentation, or, if it’s not already there, figure out the best way to add it.

Action: Document something that regularly falls on your plate, quickly teach it to someone else on your team, and make it their responsibility moving forward.

Simple, consistent marketing plan

Establish a consistent marketing presence with valuable content creation. It doesn’t have to be heavy, or complex, but you need to regularly feed the beast. This will improve SEO, grow your email list, enhanced brand awareness and create deal flow. Over time, the results are compounding and you’ll be positioned as an expert in your field.

Here’s an example of a simple plan:

One newsletter per month
Two strategic blog posts per month (feeds the newsletter and social media, and your team can share them)
One or two social media posts per week

Action: If you’re not collecting emails through a newsletter sign-up, set it up today.

Visually stand out

Anywhere that your customers and potential customers can see you or read about you needs to be intentional and stand out from the crowd. You need to be one in one-thousand, not one of one-thousand. Yes, this means your website, but it’s also your marketing materials, and the page people are redirected to after filling out your contact form or signing up for your newsletter, and all the other tertiary touch points across digital and physical space that represent your brand.

Action: Make an inventory of every touchpoint where prospects and clients encounter your brand and create a plan to make them better.

And an even simpler sales plan

One year my business grew 40%, exactly as planned.

This started as an exercise of going through my invoice/project history to find more granular ways of splitting up my services. Previously, we just “did custom work”. But after digging around, we had four unique types of work that we did on a regular basis.

I calculated the average cost per item of each of these services, both one-off services and recurring. I did the math of what happens if we sell X of these and Y of those, and created a 12-month plan to do it. The plan also included when and who we’d need to hire if we stuck to the plan.

It looked something like this:

Sell one of this thing per month
Sell two of that thing per quarter
Sell one of this other thing per quarter
Keep a spreadsheet up-to-date that we meet on weekly.

Vualà. It happened.

And a by-product of this exercise is that we got better at communicating each service in a more granular way and were able to create unique delivery processes around each of them.

Action: Try going through a similar exercise for your business.

Reporting and check-ins

Everything important needs to be broken down into a simple report or math formula to track progress and hold the team accountable. Things that you can and should report on:

This stuff all lives somewhere but can be extremely valuable when looked at together in any given timespan:

Leads, wins, loses, conversion rate
New v.s. recurring projects
Team size in any given timeframe
Revenue, profitability
Marketing out the door by category

You’ll typically find insights while interacting with data in this way that you would not otherwise find.

Action: Make a simple spreadsheet that you’ll update on a monthly basis with key information to inform your future decisions.

Lego block everything

Here’s an example. You don’t like writing the monthly newsletter because it’s too time consuming and it takes you two days to write. But then you have an idea. What if I build my newsletter in a way that it’s mostly content that I already have?

Introduction paragraph
Latest blog posts (you already write two per month)
Featured case study (you already have 50, roll the dice)
Employee spotlight (again, roll the dice)
Relevant industry articles (you could have a Slack channel where your team adds links of what they’re reading)

So now, in order to create your monthly newsletter you write an introduction paragraph and compile the rest.

Efficiencies can be found by making little lego blocks that work together to complete the whole across all aspects of your business: accounting, delivery, sales, marketing, admin, etc.

Action: Audit one item in your business (a task, a service, etc.) and break it down into component pieces that either already exist elsewhere in your business or could serve multiple purposes once created.

Overly optimized onboarding

Back in 2015 I learned one of my favorite things from a client, and it was called the “Master Queue”. For them, it was an email that got sent out to their project management team when a job was won. For me, it became the central point of start-to-finish process that everything flows out of. It kick starts all sorts of activities across the business and is the hard transition point from prospect work to client project.

Those days, most of that was manual work, but today it’s almost all automated.

A contract gets signed, which marks a deal as won in a CRM system, which sends a notification to a group of people, and sends the relevant data to your accounting system, project management system, and whatever other tools you use to do your job.

If you find yourself high on the robot side of the robot to human scale, you can automate the client kick-off emails off of this flow as well.

The “Master Queue” is my favorite place to start optimizing process work because so many things flow off of it.

Action: Create a form that your team fills out when a job is won that gets sent to a shared email address, and create a step by step process for what needs to happen when that email comes in.

If you’re optimizing your own service business and want to talk through what’s working (and what’s not), reach out. I’d love to help.

Common questions

How long does it take to see results from these changes?

It depends on where you start, but most of these principles compound over time. Process improvements show up immediately. Positioning and marketing take 6-12 months to materialize. The key is consistent implementation, not perfection.

Do I need to implement all of these at once?

No. Start with profit levers to get an understanding of what drives your business. Then pick 2-3 areas that are currently causing the most friction and start there. You can layer in the rest over time.

What size business is this relevant for?

These principles work from solo freelancer through mid-sized service businesses ($3M+). The specifics change, but the fundamentals don’t.

Weeknotes vol. 15: Professional admin dashboard maker and Mac app polisher

Fri, 13 Jun 2025 00:00:00 -0500

It was another short summer week but I was able to get quite a bit done. I spent the entirety of Monday turning my garage into a work of art, but Tuesday through Thursday was all about Braindrop.

Until this week the production database has been a bit of a black hole and I needed a dashboard to perform simple administrative tasks and to track a few metrics for the beta program. Of course Rails made this easy (and fun!).

Speaking of the beta program, we have over 100 sign-ups so far and I’m hoping to start opening things up early next week. I’ll shoot an email with instructions once it’s ready.

Another big task for the week was polishing the Mac app. One of my favorite features is quick-add, which allows you to capture your thoughts while you’re doing something else, without getting out of the zone.

A screenshot of the ‘quick add’ feature on Braindrop for Mac.

Quite often I’ll be working on something and my mind will be thinking about something I need to do later, or I will spot something on the screen that I need to fix but I don’t want to jump down that rabbit hole quite yet because I’m working on something else. That’s what quick add is for. Type the shortcut, write what you want down and get back to work.

Rumor has it that there will be a way to do this in Raycast as well.

That’s all for this week.

Weeknotes vol. 14: More pool, less computer

Fri, 06 Jun 2025 00:00:00 -0500

There was a lot of play this week and not a lot of work, but I still got some stuff done. #summer

There are a few ultra early beta testers for Braindrop, and, thanks to Matt, our test suite grew a little bit. We’re up to 42 tests (14 model, 13 controller, 3 jobs and 12 service tests).

Matt also refactored some things around account authentication and passwords to ensure the app is better than good.

Codename: Craftman’s Green

I got a v rough prototype together for Craftman’s Green to try and get my thoughts clickable. This project is going to be quite the undertaking, but it’s fun and weird and sits at the intersection of digital work and play and imagination.

That’s all, folks!

Weeknotes vol. 13: May the thirtieth be with you

Fri, 30 May 2025 00:00:00 -0500

This week I reached the part of making stuff where all of the sudden you don’t have much to do. Aside from spending a few more days in polish-town, shipping is upon us for Braindrop for Mac beta.

Here, have yourself another teaser:

A screenshot of the Braindrop welcome screen for macOS.

A few highlights from the week:

The second edition of the Braindrop marketing website is underway and Phil clearly had some unicorns helping him
Finished some big Braindrop chunks: completed settings, file auto-uploading and better error handling.
I updated all of the Weeknote titles from the ‘Weeknotes: 5 to 9 May 2025’ format to less robotic names like ‘Weeknotes vol. 10: Back in the CSSaddle’ (Honestly, I don’t know what I was thinking before).
Continuing to brainstorm on app two and should have some rough sketches completed next week to help shape it up. Hoping to start development in June… more soon!
As of this week, Braindrop will also work as a progressive web app and can be installed directly from any browser.
I ran into this article about Role-Based Access Control, which feels novel in the context of making software but reminded me that CMS people had this figured out all along.
Upgraded to Ruby 3.4.4

May the thirtieth be with you.

Weeknotes vol. 12: Teaser site, settings screens and new ideas

Fri, 23 May 2025 00:00:00 -0500

I got sucked in by the last week of school activities, so not a lot to report other than end-of-year parties and swimming and grilling and swimming.

We launched a teaser website for Braindrop on Tuesday so that people can sign-up to become beta testers once we’re ready. It’s Phil designed and coded and features a classic Christoph illustration.

Phil handed over the Braindrop settings screen design on Thursday and I was able to spend some time at the computer to get through the front-end and some of the basic functionality.

And last but not least, I’ve been mulling over a team productivity slash digital community idea in my head that will hopefully become Better Than Good project number two in the near future.

That’s all folks.

Weeknotes vol. 11: “Basically done.”

Fri, 16 May 2025 00:00:00 -0500

Another week! Lets see what happened, shall we?

Phil and I started the week with a Braindrop strategy meeting to revisit the scope of work and what comes in what phase, etc.

Braindrop for Mac is ‘basically done’, and if you make stuff on the computer then you know what that means: it’s working perfectly, aside from the few things on the procrastination list that will probably take another week or five.

And I’m using it full time to track the work to be done to finish it. 🤯 #inception

There’s also work behind the scenes worth shouting about. Matt continues to build out the test suite and nudge me to make technical changes that will make the app better in the long run, which I do and then he fixes. For instance, single table inheritance and converting archived from a boolean field to an archived_at date field.

If there was an award for the simplest, most bulletproof app ever to be built I would probably need to buy a tux.

On the design front, Christoph finalized marketing illustrations for the Braindrop landing page, which will be launching early next week. If you have a Mac and you’re insterested in being a beta tester, you’ll be able to sign up on the website.

end

Weeknotes vol. 10: Back in the CSSaddle

Fri, 09 May 2025 00:00:00 -0500

This week I got to jump into CSS again (not just prototype stuff but production stuff). Which for me is kind of like eating a cheeseburger.

My focus the last 6 months has been in Rails development, though my speciality is front-end (as in the original definition of front-end). So it’s been good to get back into it.

When I set out to build Braindrop, or anything I do under the Better Than Good umbrella for that matter, I’m building as simple and with as few dependencies as possible. As I dug into what’s changed in CSS since the last time I touched it (the stone age) I realized that, thanks to @import, native variables and nesting I can happily use raw CSS. Which feels like the good ol’ days. I may even FTP some changes with Cyberduck.

I also found quite a few other new-ish CSS things that should come in handy:

The internet is feeling like the old internet which is exactly how I like it. You just get in there and hack away without the need for layers and layers of internet onions.

Weeknotes vol. 9: Micro-apps and nursery rhymes on Rails

Fri, 02 May 2025 00:00:00 -0500

I skipped this week due to dad duties, and Phil’s off traveling the world, but there was still some activity worth noting.

A couple of weeks ago I talked to Christoph about a simple journaling idea I sketched out back in 2017 which will be our first of many micro-apps to release. Every once in a while I’ll be sprinkling in small, focused apps based off of ideas that have made their way into my ideas folder over the years, and this’ll be the first one we release and, at some point, will be available on web and iOS.

The Pragmatic Bookshelf was running a sale on a handful of Ruby and Rails books, of which I purchased:

Modern Front-End Development for Rails (2% read)
Agile Web Development with Rails 8 (25% read)
Hotwire native for Rails Developers (20% read)
Frictionless Generators (10% read)

The jury is still out on whether these readings will be a positive or a negative for our week old baby, but one thing’s for certain, the books defintely put her to sleep!

I also couldn’t help myself but make a simple little app for my wife and I to track baby activity (eat sleep pee poo). It’s rough but it’s been super handy for us.

Weeknotes vol. 8: Active Storage and shipping baby no. 6

Fri, 25 Apr 2025 00:00:00 -0500

I had two (big) tasks this week (which as per usual I’m writing after the fact):

Get file uploads integrated into the app with Active Storage
Bring my beautiful wife to the hospital on Friday to ship baby no. 6

I’ll stick to the nerdy stuff for this post though.

There’s nothing not to love about Rails, as my experience with Active Storage further confirmed. Installation is a breeze.

bin/rails active_storage:install
bin/rails db:migrate

class Thought < ApplicationRecord
  has_one_attached :file
end

Make some updates to your form(s)
Done

And then there’s all the little app specific details, and that’s what took the week.

Phil finished the Web/Mac app design, and so the next few weeks (after the break with baby) will be spent focused on production-ready HTML and CSS, which I’m very excited about. This is where my original love for the internet started and I’m excited to see what’s changed since the last time I was serious about it (probably everything).

Weeknotes vol 7: Here ye here ye, Braindrop hath reached 100 commits

Fri, 18 Apr 2025 00:00:00 -0500

Another week down the hatch.

As I said last week, we made big progress on the Web/Mac app design, and I wanted to get the prototype updated as soon as possible so that we could interact with the design decisions and make future desisions from there. So, I spent most of the week polishing the Web/Mac prototype. On Monday I added 25 issues to GitHub and by Friday had gotten through 23 of them.

Funny thing about software that you don’t realize until you’re building it is the complexity multiple that comes with every little thing. We’ve pulled the MVP back to the bones, and there’s still quite a bit more to work through than anticipated.

Speaking of MVP, for the time being we’re replacing thought processing with the Web Share API so that you can quickly process your thoughts into whatever application you’re already using. It’s easy to work with but it has it’s quirks:

Title: a string representing the title to be shared. May be ignored by the target.

More like, is literally always ignored by the target.

In other words, if I say title: <%= escape_javascript(thought.content) %>, they say it equals <% content_for :title, "Home" %>. If I’m missing something please tell me.

Matt made his inaugural commits to the codebase and is building a test suite to ensure everything we expect to be true is true and everything we expect to be false is false. This pushed me to make the extensive list of expected functionality (and whatever the opposite of that is) that I’ve been putting off for the last few weeks.

I also celebrated commit #100 and updated Ruby to 3.4.3

The prototype is now at a place where I’m using it as my primary thought and task tracking application, and Phil’s been able to use it to continue on with the interaction details.

Weeknotes vol. 6: Web and hybrid and native, oh my!

Fri, 11 Apr 2025 00:00:00 -0500

(It’s Tuesday but I’m pretending it’s last Friday.)

I’ve gone back and forth on Native v.s. Web v.s. Hybrid v.s. Native v.s. ∞ quite a bit. There are pros and cons to all of the options, but, for the initial launch, I have officially landed on the following:

Web app (Rails, baby!)
iOS (Hotwire Native)
macOS (A hybrid Swift app generating a web view)
watchOS (Native, primarily for the voice to text)

(ducks from the lettuce, etc. that Chris is going to throw.)

This way, deploying updates is as easy as git push origin master (the cheeseburger of computers) and we’ll have minimal App Store risk. What this does mean is that we need an API for watchOS, which I took care of during the early part of last (this?) week. Though it’s the core of any modern day digital product, I had little experience creating an API and did run into a few gotchas around authenticating with tokens v.s. web logins and sessions. After wrapping my head around the issue I was able to read, write, delete, etc. from the API and had a very quiet celebration in my mind.

I quickly prototyped the native watchOS app to read, write, delete via the API and get an understanding of how this particular app will look and feel so we can understand our design boundaries. And what a good use of time it was. I quickly learned that the simple app I had in my head needed to be about 10x simpler to decrease the clicks it takes from open to posted due to the required native voice to text screens and interactions. I also learned how easy it is to get that sexy swipe to delete on the listing view.

Design for the Web/Mac app is underway and is really starting to look like something. This next week will be spent excitedly getting the working app in line with this week’s design progress and answering Matt’s questions on GitHub so we can finally toggle this codebase’s invincibility mode to the on position.

Weeknotes vol. 5: A month of cool stuff, a listicle

Fri, 04 Apr 2025 00:00:00 -0500

As of yesterday I’m officially a month into this new venture.

I remember when Good Work grew to the size that we were getting more done in a month than I did in the first year, which is a good light at the end of the tunnel that the effort done in the last month at Better Than Good will some day be done in a day or a week or something like that.

Since we’re in a new month I’ll recap the last:

Launched Better Than Good (the website)
Moved into a new office
Name and design direction for my first app, Braindrop
Lots of forward (and backward) progress on the code front
Worked on the Braindrop marketing website to gain clarity around the most important things
Got some cool coasters which I’ll be sending to the first 100 people on the newsletter list
Realized the newsletter sign up link was broken last week for who knows how long.

And here’s the high level plan this month:

Launch the Braindrop marketing website
Create the Braindrop API
Polish design for the MacOS app
Have a working WatchOS prototype.

Cheerio!

Weeknotes vol. 4: Coding like it’s the 80s (with stickers)

Fri, 28 Mar 2025 00:00:00 -0500

This week saw major progress with both the web based application and the marketing website. Granted, I did find the Code Like It’s the 80s playlist by JetBrains on Spotify which has been quite the productivity booster.

Making thought capturing as simple as it can be while ensuring the data is ready to be processed in an easy yet useful way later isn’t an easy task. And as I get deeper into processing thoughts into useful things, the decisions to ensure simplicity are getting harder and harder. It’s a puzzle but it’s a fun puzzle, and this week was very puzzly.

(I guess that’s why most software gets so bloated.)

On the design front Phil got to a good place with the marketing website and I’m ready to launch it yesterday. It captures Braindrop perfectly.

For the first time in 18 years my work day is spent worry-free with no other responsibility other than build this little software company at my pace and how I want. On one hand, this is a scenario that I wouldn’t have ever imaged given the road it took to get here, and on the other hand, it wouldn’t hurt to manufacture some urgency! As I write these weekly notes I’m realizing that the pace could be turned up a few notches.

Next week will see some hard deadlines added to the calendar.

Oh, and I ordered a limited supply of coasters from Sticker Mule! If you want to spice up your desk, join our email list and I’ll be sending to the first 100 subscribers.

A mockup of the ‘Better Than Good’ and ‘Braindrop’ coasters.

Weeknotes vol. 3: 404, Chunk not found

Fri, 21 Mar 2025 00:00:00 -0500

It was a short week at Better Than Good HQ but we packed in as much as we could. We moved both design and development down the field a bit, which sometimes is all you can ask for!

Delegated types v.s. single table inheritance

I started noticing quite a bit of overlap in Braindrop fields and decided to take a step back and consider the overall structure of the data. I did a deep dive on single table inheritance v.s. delegated types and landed on delegated types due to performance advantages and overall it just feels more logical and future proof. Hopefully this week I’ll get that all buttoned up.

Logos, fonts, etc.

Phil finalized the logo and fonts. In the first prototype I had used the brain emoji (🧠) as a placeholder which has been slowly iterated into a super cool logo that scales nicely for it’s different uses and fits the Better Than Good vibes. The font is a variable font which is a massive win and means we can use it wherever we’d like.

The strategy has been strategized

I’ve been making stuff long enough to know that if you build it they certainly will not come. Over the last few weeks I’ve been working on a pre and post launch strategy to get the good word out and put a stamp on it last Wednesday.

And also:

Wrote “The road to Braindrop”
Added a new ‘404, Chunk not found!’ page
In very Garrett fashion I have a lot to do which means I’ve prioritized going from Mac to Linux after 20+ years on Mac.

The road to Braindrop

Tue, 18 Mar 2025 00:00:00 -0500

I spent the majority of 2024 considering my next chapter.

Alongside the team at Good Work I’d spent the previous 10 years starting, running and optimizing the company into a well oiled machine. For the last few years, it simply ‘just worked’.

There’s a lot of chatter about how chaotic life can be at a digital agency, but that’s not Good Work. We grow steadily each year, we work sensible hours, and excel at things most similar companies struggle with—like clear communication and smooth project execution. It’s a truly great company, and I’m incredibly proud of what we built there.

But it no longer needed my particular skillset on a day-to-day basis. The business required roughly 5 hours a week of my time which is great and also not fulfilling.

I’m a jump off the cliff with the idea of building a parachute and make sure it’s finished before I hit the ground kind of guy, and I get antsy once the parachute is complete. For Good Work, the parachute is complete, and it was time for the company to soar with it.

And for me, it was time to find another cliff.

As I mentioned in “Hello, world!”, I considered all sorts of stuff and eventually landed on building this little software company. It’s a perfect match for my skillset and what I want to do with my time. Knowing what I know now (which only took 18 years of working) this is the thing that I was made to make (forever).

Something I’ve always been curious and intentional about is the ability to focus, and I knew that I wanted my first app to have something to do with this.

There are a few ways to process the stuff that flies at you throughout your day:

Take action on things as they pop into your head (interrupting flow)
Keep everything floating around in your head while trying to focus (mental gymnastics, anxiety, etc.)
Prioritize one thing at a time while quickly capturing other thoughts for later processing.

It’s easy to let the firehose of life rule your day; it takes intentionality and discipline to take control of it yourself. I see this all over the place: parents, business owners and everyone in between.

Life is hard if you don’t have a system for processing it.

My focus strategy is straightforward: capture everything in one place, process it later. Texts, emails with important attachments, words coming out of people’s mouths, random ideas—all get forwarded to myself while I continue whatever I’m currently doing. I regularly sort this collection into to-dos, someday lists, blog ideas, and files. This system keeps my mind clear and my days structured.

Braindrop is built to help you prioritize one thing at a time while quickly capturing other thoughts for later processing. From a high level, we’re creating two superpowers…

The ability to quickly:

Capture your thoughts and move on.
Process your thoughts later.

Yes, there are already ways to do this. There are todo lists galore, and notes, and Siri and calendars and GTD, etc. But Braindrop is for the people who, even with all of those other options, still feel like everything is a bit chaotic.

There will be no learning curve, no complicated features, no AI. We’re developing simple tools to help you organize your thoughts and get things done. You’ll be able to capture your thoughts, free up your headspace, and take action when you’re ready.

Simplicity will be your superpower.

If you’d like to follow along, you can join our email list, subscribe to our RSS feed, follow us on social media using the links below, or simply check back for updates.

Weeknotes vol. 2: In the rabbit holes we find marketing goals

Fri, 14 Mar 2025 00:00:00 -0500

I remember when I started seeing weeknotes pop up and thought they were silly, but the accountability alone is worth it. This week I found myself writing out big things I needed to do (not saying that I did them) for the sheer fact that I had to put them on the internet in five days’ time.

Complete subscription system
Deep dive on what to do with a thought once you capture it ✔
Make some headway with the app’s marketing website ✔
Plan for a good first year (pre- and post-launch) ✔

As we (earthlings) get older, the weeks fly. My wife and I have five kids (with one on the way) and at dinner the other night our nine-year-old was saying how quickly the year is going by. We took out a piece of paper and explained how a year is 25% of our four-year-old’s time on earth, about 10% of his, about 2% of mine, and as those percentages get smaller, the perception of time gets exponentially faster. Their eyes widened!

One of our main areas of focus right now is the marketing website for the app. Designing the details of the marketing website—figuring out the most important use-cases and features—brings major clarity to what we do and do not need to focus on for the app itself. In my experience, when I jump in and start prototyping, I can end up with a bunch of siloed features that may or may not be great. But with the “marketing website first approach”, I can see the main thing that we need to build our features around.

I’m not saying that jumping in and building is wrong. I actually like doing that, whether it’s efficient or not. Who’s to say that’s not how I landed on the thing? But once you get to a certain point, jumping into the marketing website really does clear things up.

So far I have made four working prototypes of the app itself, and once we finish up this marketing website we’ll head into the design and development of the fifth and final. Without the first four we wouldn’t have the raw materials to help us make decisions for number five.

The whole process of creating is funny: you start with this one or two-sentence idea, then go down a bunch of rabbit holes related to that idea. Each of those things could have this feature and that feature, but eventually you realize all these different elements have different weights and priorities to them. Some start dropping off. THEN, you arrive at the one group of features that’s important and begin seeing exactly what would elevate this thing to be what you originally set out to create.

We’re somewhere on the back half of that process, at least for version one.

Other little items that popped up this week:

Learned a lot about which bots to (and not to) block from trolling our website while getting through some technical SEO issues I found in SEMrush.
Made a LinkedIn page for Better Than Good, primarily so I could update the experience section on my personal profile (I know, gross!)

Weeknotes vol. 1: The end beginning of an era

Fri, 07 Mar 2025 00:00:00 -0600

This was a big week and a good one to start doing weeknotes.

I moved into a cozy new office that’s much closer to the house than the one I had downtown. It came with a standing desk, too, so I’m all tech’d up and ready to go.

Phil and Leon had been working on the Better Than Good website and branding, which we finally launched on Monday. Speaking of Monday, it was also the 11 year anniversary of Good Work, the web development company I started in 2014.

Phil had the idea of a thumbs up logo and a table of judges holding up ‘11’ signs, and Leon really nailed the delivery. There’s nothing more better than good than having 4 opposable thumbs.

I wrote a blog post, which I haven’t done in a while and am excited to get back into.

Half way through the week we landed on a name and design direction for the app we’ve been prototyping away at for the last few months. It’s a productivity tool for web, iOS and Mac born out of my own daily frustrations. The name fits perfectly—simple yet distinctive. More soon.

I did some housekeeping by securing social media accounts, buying domain names, etc. I set up accounts for both Better Than Good and our first app on Mastodon, Bluesky, X and Instagram. Maybe it’s my OCD talking, but cross referencing the two things on each corresponding account, using a consistent voice, was more of a task than I had imagined.

I found qbyt.

On the code front, I got stuck on an issue with the Stripe integration for the entire week. I’ve been tackling the harder development challenges while design is being worked through—namely user authentication and billing. While integrating Stripe to manage plans, subscriptions, and payment methods, I couldn’t get credit cards to attach to users (a Stripe requirement for subscriptions). I checked, checked, and checked some more, and everything seemed right. Turns out I just needed to add window. to a single spot in my app/javascript/application.js file and we were back in business.

Phew, I feel a lot better about this week having written this all out.

Until next time.

Hello, world!

Mon, 03 Mar 2025 00:00:00 -0600

It’s been a while since I sat behind the wheel of a fresh new website.

The last first blog post I wrote was in 2014 shortly after starting Good Work, the web development agency that I started and ran for over 10 years. Before that was Erskine Design and before that was a web design company I started in college. If you add it all together I’ve spent 18 long years in digital client services.

With my last business, Good Work, I followed the classic maker-to-business-owner trajectory—doing what I loved (making things), then gradually delegating my work to others until, before I knew it, I wasn’t making anything at all!

I spent most of 2024 thinking through my purpose and what I should do next. I considered everything from operations consulting for digital service businesses to riding the silver tsunami and purchasing a 20-30 year old blue collar business. Every few months I came to my wife with a new idea for our future, and she somehow patiently cheered on each one of them. I got pretty far into a few ideas before realizing that I couldn’t see myself doing any of it! Back to the drawing board…

One day I was speaking to Phil about this conundrum and through conversation, I remembered an old known that I had lost sight of: I was born to make stuff on the internet. After about five seconds of back and forth it became incredibly clear that the next step was to start the last business I’ll ever work at; a little innovation studio called Better Than Good.

Looking back, the best moments of my career were when I was deep in the details: inventing, optimizing and problem-solving. And that’s what Better Than Good is all about—blending design, technology and business expertise to create and improve products, brands and processes.

Here’s to a future of inventing products and solving problems through the lense of design, technology and business expertise.

I’ll be sharing the journey on this blog along the way.

Better Than Good.

The flatness of the machine

How the machine writes

The alignment tax on style

The vocabulary forensics

What gets lost: semantic ablation and the flattening of prose

The parrot and the professor

What would need to change

Where this leaves the written word

Software was never meant to last forever

The two failure modes

The SaaSpocalypse is a thing, even if the name is silly

How AI is reshaping this

Making it possible to leave

Making it cheap to build

Moving the value from the application to the orchestration layer

The orchestration layer is too important to delegate

The counter-arguments

What this means if you run a mid-sized business

Where this goes

The vibe coding spectrum: from weekend hacks to the dark factory

On the spectrum

Code must not be reviewed by humans

The validation problem

The Digital Twin Universe

The Dark Factory

The wider movement

Techniques that compound

The backlash got it backwards

One endpoint on a spectrum

What this means for software engineering

The fundamental question

Claude Opus 4.6 just shipped agent teams. But can you trust them?

How Multi-Agent Coordination Works

The Trust-Vulnerability Paradox

What Compromise Looks Like

Lateral Movement Between Agents

The Coordination Channel as an Attack Surface

What We Can Do About This?

The Framework Gap

Why This Matters

AI slop: psychology, history, and the problem of the ersatz

The Psychology of Authenticity and the Ersatz

Categorical Ambiguity and Cognitive Discomfort

The Uncanny Valley Expanded

Terror Management and Existential Threat

Authenticity as a Core Human Value

The Disgust Response and Moral Psychology

Disgust as a Moral Emotion

The Problem of Deception

Historical Parallels: Technology, Labour, and Meaning

The Luddites Reconsidered

Walter Benjamin and Mechanical Reproduction

The Printing Press and the Scribal Response

Photography and the Death of Painting

The Information Ecology Problem

Quantity Versus Quality

The Lemons Problem

Why This Moment Feels Different

Practical Implications for Creative Agencies

Transparency as Strategy

Team Dynamics and the Meaning of Work

The Vibe Coding Problem

Open-Book Productivity Sharing

Long-term Positioning

Navigating the Transition

The missiles are the destination

Fall back

Your people and your brand are your moat.

It’s easy to do what you do and it’s hard to be the best.

Quality and simplicity always win.

Never look to others.

Don’t ignore the future and don’t forget the past.

Building the agency of the future

What I would do

What I wouldn’t do

Common questions

On getting paid faster

Frequency of online payment deposits

Reduce invoice payment terms