When an agent’s context window fills up, the obvious move is to prune: drop the oldest, biggest tool results and keep going. It reads as good hygiene. It is usually a bet, and on the wrong workload a losing one.
\nThe reframe that makes the trade-offs visible: the window is a cache, pruning is eviction, and eviction is one of the few problems in computing we can prove you cannot do optimally without seeing the future. Once you hold it that way, “just trim the old stuff” stops looking like obvious hygiene and starts looking like what it is - a wager about what you’ll need again. This is the management half of the problem that context engineering only sets up; composing the window is one job, keeping it useful as it grows is another.
\nThe instinct to prune is mostly about money, and money is the wrong axis. Anthropic’s prompt cache charges a cache read at roughly 10% of the input price. A warm window is already a tenth of full freight, so carrying it is cheap. Aggressively shrinking a warm window trades that cheap read for a full-price rewrite of everything after the cut. Pruning to save money can cost money. Inference is a real marginal cost on every turn, but the cache is what flattens it, and pruning fights the cache.
\nIf cost is not the axis, two things are. The first is attention quality: a window stuffed with stale output buries the signal the model needs, and a model reasoning over its own noise gets worse in ways no invoice shows you. The second is the ceiling: every model has a hard token limit, and a long session walks toward it whether you like the economics or not. Those are the honest reasons to prune. Naming them changes what a good policy looks like, because a policy tuned for cost and a policy tuned for attention are not the same policy.
\nThe cache has one rule: the prefix you send must match the prefix already in the cache byte-for-byte, up to the point you mark. Appending a new message keeps the prefix intact and stays cheap. Editing history does not. Change a byte and everything after it is invalidated and re-billed at full price.
\nA prune is an edit. It deletes bytes in the middle of the cached region, which forces a rewrite of the entire suffix that follows. Sometimes that is worth paying. The point is that it is never free, so any pruning policy is spending real money each time it fires, and a policy that fires on a bad guess is spending it for nothing.
\nThe standard policy is age plus size: evict any result older than N turns and bigger than M tokens. That rule is a bet that old and big implies never needed again. When the bet is wrong - a large result referenced again just outside the retention window - you get a loop. You evict it, the model asks for it, you re-inflate it, it ages back out, you evict it again. Evict, recall, re-inflate, evict. Each cycle pays a rewrite and leaves dead stubs behind, for negative value.
\nThis is not a tuning problem you can dial away. It is Belady’s result from the page-replacement literature: the provably optimal eviction policy requires knowing the future sequence of accesses, which you do not have. Every real policy approximates the future from the past, and age-and-size is a crude proxy for the future. On the wrong workload that proxy is worse than doing nothing.
\nSo a pruning policy has two honest forms. Drop only what is provably dead, or learn from what gets recalled. Everything in between is a guess.
\nThe first honest form is provably-dead hygiene. Some results are dead with certainty, not by age guess. A file read whose contents were overwritten by a later write in the same session. The same query run twice with identical parameters. Those bytes can never be correct or useful again, so dropping them cannot thrash - there is nothing to recall, because the future access does not exist by construction. This is the only kind of prune that is unconditionally safe, and it is the one to reach for first.
\nThe second is offload, don’t delete. Instead of removing a large ageing result, replace it in the live window with a one-line stub that points to the verbatim original in your own storage. If the model needs it, it pulls the exact bytes back from your store, never by re-running the tool against the external source. And the rule that makes this correct rather than fragile: once a result has been recalled, exempt it from eviction. A recall is proof the result is in the working set, so the policy learns from its own mistakes instead of re-evicting the same bytes every few turns. That single exemption is the whole difference between an offload tier that helps and one that thrashes.
\n\nNone of this has a universal answer, which is the actual point. The right policy is a function of your workload and your cost structure, and those vary widely; the policy has to follow them rather than a default.
\nA coding agent lives on read-edit-read churn. It reads a file, edits it, reads it again, and that first read is now genuinely dead. This workload manufactures provably-dead results by the dozen, so hygiene alone reclaims a lot of window at zero risk, and an offload tier earns its keep on top.
\nA data-analysis agent looks nothing like that. A schema it pulled an hour ago, a statistical result from turn three - those stay live, and they get referenced again when the agent writes its conclusion. The same age-and-size rule that is roughly safe on the coding agent misfires here, because on this workload “old” simply does not predict “dead.” The results age without dying, and a policy that confuses the two throws away the working set.
\nAnd when the problem is just that the session got long, pruning is often the wrong instrument entirely. Compaction - summarising the transcript into working memory and dropping the raw turns - preserves the hard-won conclusions better than any rule guessing which raw bytes to discard. It is lossy on purpose, and the skill is choosing what to lose; a summary that keeps the chatter and drops the conclusions is worse than no summary at all. Different problem, different tool.
\nThe order that keeps you honest is instrument first, read the distributions, then decide which policy, if any, earns its complexity. How long do sessions actually get? How often does a pruned result get recalled? How much of your window is provably dead on a real trace rather than a hypothetical one? Those numbers tell you whether you need hygiene, offload, compaction, or nothing at all, and they routinely say “less than you assumed.”
\nThe instinct is to reach for the cleverest policy; the discipline is to use the one your workload justifies. That’s usually the simplest, and sometimes it’s none. Pruning is a bet on data you don’t have yet, so make the smallest bet that works and check the numbers.
", "date_published": "2026-06-02T00:00:00.000Z", "date_modified": "2026-06-02T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai-product", "engineering", "context-engineering" ] }, { "id": "https://cvde.xyz/writing/google-wins-consumer-ai/", "url": "https://cvde.xyz/writing/google-wins-consumer-ai/", "title": "Google wins consumer AI on distribution", "summary": "Intelligence is commoditising, so the model stops being the moat. What's left is distribution and a business that profits from giving intelligence away, and Google is the only company with both - fighting Nvidia, Apple, Amazon, Microsoft and Meta each on one front while it works all five.", "content_html": "Two billion people a month use a frontier AI model they never chose. No download, no sign-up, no new habit; Google put a Gemini-written answer at the top of the search results they were already going to read, and the choice got made for them with a server-side change. That is worth more than it looks, and seeing why means starting somewhere counterintuitive: the model itself is the part of this that matters least.
\nThe frontier labs are converging, and the lead is now measured in months. China is the clearest tell. DeepSeek’s V4, released in April 2026, lands within three to six months of GPT-5.4 and Gemini 3.1 Pro, beats every open model on maths and coding, and trails only a closed model on world knowledge - built in large part by distilling the very frontier it’s chasing, training a cheap model on the expensive ones’ outputs. The accusation that this is industrial-scale copying is probably true and nearly beside the point; distillation works, the floor keeps rising, and the ceiling gets matched a quarter or two after it’s set.
\nIntelligence is going the way every digital capability goes once several funded teams chase the same target: towards good-enough and cheap. That doesn’t make the models worthless. It makes them a poor place to build a moat. If the plan is to win consumer AI by holding the smartest model, the position resets every few months, against competitors who can rent or distil most of the advantage away. The question worth asking is what doesn’t commoditise, because that is where the market actually gets decided.
\nWhat doesn’t commoditise is the thing standing between a model and a person: the surface it lives on, and the habit of reaching for it. That was always the hard part of consumer software - not building something good, but getting a human to form the habit of opening it. OpenAI did exactly that from nothing, which is a real achievement; ChatGPT is one of the fastest habits the consumer internet has formed, 900 million people opening it every week. But it had to build that distribution a download at a time. Google built none. It already owns the surfaces where billions of people start the day - the search bar, the browser, the phone, the inbox, the map, the video - and it can put a model on all of them with a configuration change rather than a marketing budget.
\nThis is where AI as the interface stops being an abstraction. If the durable job of AI is to be the layer you speak to instead of the system you learn, the company that already owns the surfaces people speak into has the shortest path from a new model to a billion users of it. Apple holds the matching distribution, the other half of the world’s phones, and no frontier model of its own - so little of one that it is now paying Google around a billion dollars a year for a custom Gemini to run the rebuilt Siri, white-labelled so the user only ever sees Siri, shipping to roughly 1.5 billion devices. Google’s model is about to power the assistant on both of the platforms people actually carry, its own and its only rival’s. The distance from “we have a new model” to “it is in front of everyone” is, for Google, a deploy; on the iPhone, it’s Apple’s.
\nThere is a second moat hiding behind the first. Once intelligence is a commodity, usefulness stops being a question of how smart the model is and becomes a question of how much it knows about you. A brilliant model with no context gives you a brilliant generic answer; a fair model that knows your calendar, your inbox, your last ten searches, where you drove this morning and what you watched last night gives you the answer you actually wanted. Usefulness is intelligence times context, and the second term is where the contest moves once the first one flattens.
\nNobody has more context on more people than Google. Gmail, Calendar, Maps with your location history, Search with everything you have ever asked, YouTube with everything you have watched, Photos with your life in it, Drive and Docs with your work, Android in your pocket, Home on your kitchen bench. That is the most complete picture of a person any company has assembled, and it is precisely the raw material a commodity model needs to stop being generic. The assistant-everywhere position feeds it further: powering Siri and Gemini across both platforms is a firehose of real-world use and training signal, and good data and real use are themselves among the strongest determinants of where a model ends up. So even if Apple builds its own model and pulls the rug in a year, Google spends that year compounding its lead in the one input that matters most. The model can be swapped out. The years of context it was tuned against cannot be handed back.
\nDistribution and context would matter less if consumer AI were a good business to be in directly. It isn’t. Consumers are famously bad at paying for software; the revealed preference of the median user is free, with a hard ceiling on what they’ll convert to a subscription, while every query still costs real money to serve. That is the quiet bind under the subscription AI companies: inference is a marginal cost on every use, most users never pay, and the product they’re selling - intelligence - is the exact thing commoditising underneath them. Selling a melting asset to people who don’t like paying is a hard place to build something durable.
\nGoogle is not in that business. It never sold intelligence; it sells attention, and monetises that attention through ads. So Gemini does not have to make money. Its job is to keep the customer inside Google’s surfaces long enough for the machine that does make money to run. AI as the interface to all of Google’s other products means the model isn’t the thing being monetised - it’s the funnel into the things that are. Giving intelligence away free is not a concession Google is forced into; it is the rational move for the one company that profits from the attention rather than the tokens.
\nWhich is why commoditised intelligence, the thing that threatens the subscription players, is a tailwind for Google specifically. As the price of intelligence falls towards zero, the company hurt most is the one whose product was the intelligence. The company helped most is the one that wanted to give it away anyway, because the give-away is what holds the attention it actually sells. The same trend is a headwind for one business model and a subsidy for the other.
\nIt gets better for Google than “the AI keeps the attention,” because the same AI also monetises that attention harder. The fear for years was that an AI answer kills the search results page: resolve the question and you’ve removed the ten blue links and the ads stacked above them. Google’s answer is to rebuild the ad unit inside the answer. It is now testing conversational ad formats and AI-powered shopping ads directly in AI Mode, with Gemini writing the ad creative to fit the specific question, on a surface Google says has crossed a billion monthly users. The AI answer becomes a new ad inventory rather than the end of the old one. Whether the yield per query matches the old page is the open question, and I’ll come back to it; the direction is to monetise the AI surface, not retreat from it.
\nThe other half is ranking, and here Google is following Meta’s lead. Meta has spent the last couple of years pointing models at the scale and complexity of frontier AI at a narrower problem than chat: which ad to show, to whom, right now. Its Adaptive Ranking Model, live across Instagram in 2026, reads far more signals - including what people do with Meta’s own AI - to match an ad to the person most likely to act on it, and the lift is real. Google is doing the same across its surfaces: AI Max in Search, and on YouTube the kind of personalisation that used to be close to impossible, where a model now reads both the viewer and the video they’re watching to place the ad that fits both. So the AI spend returns at both ends of the same pipe: as the interface that holds the attention coming in, and as the ranking engine that wrings more out of it going out. One investment, two returns, on what was already a highly profitable advertising machine.
\nAll of this rests on something rarer than any single product: Google is the only company holding every layer of the stack at once. The frontier lab is its own, DeepMind. The silicon is its own, the TPU, so it trains and serves without paying the Nvidia tax or waiting in the Nvidia queue. The cloud is its own. The models are its own. The surfaces that carry them to people are its own. That vertical integration is exactly what lets it give intelligence away and still profit; it captures the value downstream, on infrastructure it owns end to end, instead of renting a layer from a competitor.
\nThe breadth is easy to under-feel because it’s smeared across so many products. Search, the most-used browser, the most-used mobile operating system, the most-used video platform, billion-user mail and maps and photos, the documents and drives where people keep their work, the speaker on the kitchen bench, the third-largest cloud, the leading robotaxi business, its own AI silicon, a frontier lab. Name a layer of the AI stack or a consumer surface that matters, and Google is first, second, or third in it.
\nThat sets up the genuinely strange part. Each company Google competes with fights on one front. Nvidia sells the silicon. Apple sells the devices. Amazon sells the cloud. Microsoft sells the enterprise seat. Meta sells the same thing Google does - attention, monetised by ads - and is the one rival on exactly the front AI touches hardest, building frontier-scale models both to win the consumer’s time and to place the ad against it. Google competes with all five at once, on each of their home grounds, and is a top-three player in every one of those markets. And it trades in the same band as any single one of them: Alphabet crossed four trillion dollars in January 2026 and passed Apple to sit second only to Nvidia, around 4.6 trillion against Nvidia’s 5.2, Apple’s 4.5 and Microsoft’s 3.1. The market spent years pricing it at a discount on the fear that AI would eat search. The re-rating since is the slow recognition that the company best placed to own the AI replacing search is the one that already owns search. It also owns the distribution, the model, the chips, and the ad machine that pays for all of it.
\nThe honest version has to hold the strongest form of the other side, and there is a real one.
\nStart with the cannibalisation that last section waved past. Even with ads rebuilt inside the AI answer, a single resolved answer exposes far less monetisable surface than a page of ten links with four ads stacked on top. Google is betting it can reconstruct equivalent yield on a sparser surface, and that bet isn’t won; the search results page is the most profitable real estate ever built, and Google has to rebuild it in flight, doing to itself the thing a competitor would need years to do to it. Get the new yield wrong and the most reliable profit engine in technology degrades on purpose.
\nReach is also not preference. The two billion are largely passive, served a summary they didn’t ask for, while the deliberate, high-intent relationship - the assistant you open on purpose to do real work - is where ChatGPT leads, along with revenue per user. If the valuable AI habit turns out to be the deliberate one, impressions matter less than engagement and Google’s headline number flatters its position. OpenAI is building its own distribution too, through devices and the app habit, so the gap that looks decisive today may not stay this wide.
\nCommoditised intelligence cuts both ways, as well. If the model edge erodes for everyone, it erodes for Google, and the protection that remains - distribution plus an ad machine - is the one thing Meta also has, with three billion users and an ad system of its own. The attention war may be a two-incumbent grind rather than a Google walkover. And the lever that makes Google’s distribution unbeatable is the lever regulators most want to pull: the default-search deal, the Android bundle, and the ad-tech stack are all live antitrust exposure, and a forced unwind of any of them would blunt the sharpest edge in the whole argument.
\nThe most immediate problem, though, is Google’s own. Gemini still trips on things it shouldn’t, and the company’s famously fragmented product structure shows in experiences that don’t talk to each other; the context it holds is scattered across teams and apps that were never built to share it, which is half of why the assistant doesn’t yet feel like it knows you as well as it plainly could. But notice the shape of that problem. It is execution, not structure - the assets are all there and pointed slightly the wrong way, which is the tractable kind of problem, the kind you fix with org will and a few quarters, not the kind that needs you to go and acquire something you don’t own. The structural advantages are the ones that are hard to build, and those Google already has.
\nWeigh all of it, and the case still lands, because the bet was never that Google has the best model. It is that the best model won’t be the thing that matters. Intelligence is commoditising; distribution and context aren’t; and the company that wins consumer AI is the one that already has the attention, knows the most about the people it’s serving, profits from giving the intelligence away, and turns the same AI into a sharper way to monetise the attention it holds. Google is the only one with all of it, sitting on the only stack that owns every layer from the sand to the search box. The model will be matched. The distribution, the context, the business model, and the machine underneath them are the parts that won’t.
\nOnce the model is smarter than us at almost everything, owning the smartest one stops mattering. Knowing the user does.
", "date_published": "2026-05-25T00:00:00.000Z", "date_modified": "2026-05-25T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "gtm", "economics", "ai" ] }, { "id": "https://cvde.xyz/writing/mechanistic-interpretability-as-art/", "url": "https://cvde.xyz/writing/mechanistic-interpretability-as-art/", "title": "Mechanistic interpretability as generative art", "summary": "If a network has learned a concept, that concept is a location in its embedding space. Steer a generator toward that location and you don't get a diagram of what the model knows - you get a picture of it.", "content_html": "A neural network that has learned the concept “ocean” has not learned a definition. It has learned a location - a point, or more honestly a region, in a high-dimensional space where the things it associates with oceans cluster together. Interpretability research usually treats that fact as something to diagram: probe the space, label the axes, write the paper. I became more interested in a different question. If the concept is a place, what does it look like to go there?
\nThat question turned into a project. It optimises generative outputs - images, audio, video - toward target coordinates in LanguageBind’s 768-dimensional multimodal embedding space, doing concept algebra across modalities to surface the platonic ideals the network has learned. The honest description is that it sits exactly on the seam between research and aesthetics, and that seam is more interesting than either side of it alone.
\nWhat makes LanguageBind useful here is that it embeds image, text, audio, and video into a single shared space, anchored on language. A photo of a beach, the word “beach,” and the sound of waves all land near each other, because the model was trained to align them. The space doesn’t care which door a concept came in through. “Ocean” is a region whether you arrived by image, by word, or by sound. Anchoring on language earns one more thing: any point in the space can be projected back toward the text vocabulary, so even a non-text coordinate has a running readout in words. You can ask what the current image embeds as and get back something like {storm, crackling, electric}, which turns the optimisation from a black box into something you can follow as it runs.
That shared geometry is what lets you do something that shouldn’t intuitively work: algebra across senses. Take the embedding of a sound, subtract the embedding of a word, add the embedding of an image, and you land somewhere new - a coordinate that no single input could have named. The classic king − man + woman ≈ queen move from word vectors, except the operands can be a photograph, a field recording, and a sentence, mixed freely.
Here’s the move that turns the geometry into pictures. Pick a target coordinate - a concept, or a piece of concept algebra. Then run a generator (a diffusion model for images, the equivalents for audio and video) and optimise its output so that its embedding lands as close as possible to that target. You’re not prompting “draw an ocean.” You’re telling the system: produce something - anything - that this network would file in the same place it files oceans, and let the network be the judge.
\nThe output is not an illustration of the concept. It’s the generator’s best attempt to occupy the coordinate. Sometimes that’s a recognisable beach. More often it’s stranger and more revealing: the features the network most strongly associates with the region, rendered without the constraint of looking like any real photograph. You are seeing the concept the way the model holds it, not the way the world presents it.
\nIt would be easy to dismiss this as a stylised image generator. The reason it’s interpretability is that the output is diagnostic. When you steer toward a concept and the result is surprising - when “trust” renders as something you wouldn’t have predicted, or when an audio target produces an image whose logic only makes sense once you hear the sound - you’ve learned something concrete about how the network organises that region of its space. The art is the readout.
\nConcept algebra is where this gets sharpest. If summer − heat lands somewhere coherent, the model has factored those two ideas apart cleanly. If it lands in noise, it hasn’t - the concepts are entangled in a way the geometry won’t let you separate. The generated output makes that legible in a way a cosine-similarity table never does. You can see whether the model’s internal world is well-organised, and where it isn’t.
This is the same instinct that drives the better interpretability work in the field - the feature-visualisation lineage, the “what is this neuron looking for” question - pointed at the multimodal case and pushed until the answer is an image.
\nI want to defend the art half directly, because the reflex is to treat it as a decorative wrapper on the research. It isn’t decorative. It’s the most faithful available rendering of an object - a learned concept - that has no native visual form.
\nA concept in embedding space is genuinely 768-dimensional. Any honest depiction of it has to throw most of those dimensions away. A scatter plot throws away all but two and asks you to trust the projection. A generated image throws away fewer, because the generator is trying to satisfy the full target coordinate at once, across every dimension simultaneously. The image is a lossy compression of the concept, but it’s a richer lossy compression than the chart - and it carries information the chart structurally cannot. The aesthetics are doing epistemic work.
\nThere’s also a claim hiding in the word “platonic.” If many different networks, trained on different data, converge on similar internal structure - and there’s a growing body of evidence they do - then steering toward a concept and rendering it isn’t just visualising one model’s quirks. It’s getting at something closer to the shape the concept takes whenever a system this size learns it from the world. That’s a stronger claim than “pretty pictures from a model,” and it’s the one the work is actually making.
\nThe cleanest framing I have: most interpretability tells you that a model represents a concept and roughly where. This tries to show you what it’s like for the model to represent it. That’s a question with a research answer and an aesthetic answer at the same time, and refusing to separate them is deliberate. The picture is the finding.
\nThe code is on GitHub if you want to steer toward your own coordinates and see what the network thinks lives there.
", "date_published": "2026-05-23T00:00:00.000Z", "date_modified": "2026-05-28T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "interpretability", "generative-art" ] }, { "id": "https://cvde.xyz/writing/ai-is-an-interface/", "url": "https://cvde.xyz/writing/ai-is-an-interface/", "title": "AI is an interface", "summary": "The interface was always the tax you paid to use a system: its menus, its query language, its API. AI's most durable job is to take that tax off, by turning plain language into the task you meant and the systems that carry it out.", "content_html": "For most of computing history, the interface was the tax you paid to use a system. You learned its menus, its fields, its query language, its API. The software held a model of the world, and using it meant translating what you wanted into that model by hand. The people fluent in that translation were a profession.
\nAI’s most durable job is to take that tax off, and the job is narrower than the hype around it: it is the interface. You say what you want in your own words, and the system does the translation that used to be yours to do. It maps your intent onto the task you meant, and onto the operations across whatever tools carry it out. Plain language in; the right actions in the right systems out.
\nIt is worth being precise, because “AI” gets stretched to cover everything. This is the narrow claim, and it is the one that holds: AI as the layer that takes “which segment is churning, and why” and turns it into the joins, the queries, the significance tests, and the calls to the four systems that actually hold the answer. The intelligence can sit wherever it sits. The interface is the part that just got rewritten, and the rewrite is where most of the value is.
\nYou can see why by looking at what the old interface gated. Analytics lived behind SQL and a BI tool, so the people who could ask the warehouse a question were the people who had learned its dialect; the analyst was, in effect, a human interface between a manager’s question and the database. Every system worth using carried a toll like that: a language, a console, a certification. When the interface becomes plain language, the toll comes off, and the person with the question and the person who can phrase it in the tool’s grammar become the same person.
\nFor anyone building, that moves the hard part. If AI is the interface, the product is the mapping: intent to task to systems, done reliably, against real data and real tools that are messy in all the ordinary ways. The model is the commoditising half. The half that earns its keep is the binding between a sentence and the operations it should set off, done so the result can be trusted. That becomes its own discipline the moment a wrong mapping is an action taken rather than a paragraph produced.
\nIt hits product design hardest, because design was the interface. The job used to be drawing the screens: every state, every control, every path a user might take, rendered as something to click. When language carries the range instead, that surface shrinks; you don’t draw a screen for each of the thousand things someone might ask, because the model takes the input you never enumerated. The pixel-level core of the role is exactly the part that flattens, into the same conversation the PM and the engineer are now having, because the four modes were always one feedback loop and the interface was the seam holding them apart.
\nWhat’s left for design is the part that was always the harder half. Deciding where language is the right interface and where a direct control still wins. Shaping the tools the model composes so the pieces stay legible. Designing how the system shows its confidence, shows its working, and recovers when it’s wrong, which is where trust is won or lost. And the judgment under all of it: what good output looks like, what the defaults should be, which few surfaces still deserve to be crafted by hand. That is not less design. It is design measured in whether the thing can be trusted and understood rather than in how many screens got drawn. The new role looks more like designing a system’s behaviour than decorating its surface.
\nThe shift was never that the machine got clever. It is that you stopped having to think like the machine in order to use it. That was always the tax. Taking it off is most of what AI is for.
", "date_published": "2026-05-22T00:00:00.000Z", "date_modified": "2026-05-22T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "ai-product", "product" ] }, { "id": "https://cvde.xyz/writing/coverage-synthesis-intent/", "url": "https://cvde.xyz/writing/coverage-synthesis-intent/", "title": "Three gaps: coverage, synthesis, intent", "summary": "Most AI insights requests get treated as a synthesis problem. That's the wrong reframe. There are three stacked gaps - coverage, synthesis, intent - and you can't skip a layer without trust collapsing underneath you.", "content_html": "When someone asks an AI product for insights, they are usually handed a synthesis. “Here are the three themes from your data.” This is the wrong shape of answer, and it fails in a way that is hard to see at first because the synthesis reads beautifully. The problem is that synthesis is the middle of three stacked gaps, and a clean middle layer built on a broken bottom or pointed at the wrong top produces something confident and useless.
\nI learned to name the three gaps building AI study-analysis at Lyssna, where the data was raw user research and the readers were people whose decisions depended on getting it right. The gaps stack. You cannot skip one, and the layer where you fail determines how the failure looks.
\nThe bottom gap is the least glamorous and the most fatal. Coverage is the problem of getting raw, messy input into a form you can actually analyse. Research data is open-text answers, interview transcripts, half-finished sessions, the participant who misread the question, the response in a second language, the recording that cut out. Before you can find a theme you have to have read everything, parsed it, and represented it in a structure that supports counting.
\nThe old truism still holds: garbage in, garbage out. The best synthesis in the world can’t rescue data that was never read properly to begin with. What has changed is the tool you reach for. Most coverage work is unstructured text - open-text answers, comments, reviews, support tickets - and for years the only way to process it at scale was to write code against natural-language-processing packages that were mediocre at language. The large language model is the better instrument, which shouldn’t surprise anyone: language is the thing it does best. You can have it read each response and pull out the real category, the sentiment, the detail you need, or translate it before any analysis runs, in plain language rather than through a brittle parser.
\nThis is the first problem hey anna was built to solve. An AI formula run down every row of a spreadsheet turns a column of messy free text into something analysable: the true category, the sentiment, a clean translation across languages, before any of the actual analysis begins. That is the wrangling stage, finally done with the right tool for language.
\nFailure here is silent, which is what makes it dangerous. Suppose your pipeline quietly drops the responses it could not parse, and those happen to be the longest and angriest ones, because long angry text breaks parsers. Your synthesis now says “users are broadly satisfied” and it is wrong at the root. Nobody can see the error by reading the output, because the missing data left no hole on the page. The synthesis is internally flawless. It is just describing the data that survived, not the data you collected.
\nMost teams underinvest here because coverage work is unrewarding and invisible when it succeeds. It is also the only layer where being 90% complete can be worse than useless, because the missing 10% is rarely random.
\nThe middle gap is the one everyone means when they say “insights.” Synthesis takes the analysable data and rolls it into something higher-order: the themes, the patterns, the “seven of twelve participants stalled at pricing.” This is real work and models are genuinely good at the language of it.
\nFailure here looks like over-confident pattern-finding. The model sees three responses that rhyme and declares a theme; it weights a vivid quote over a common one; it smooths twelve messy answers into a clean narrative that none of the twelve people would recognise. The output is plausible and slightly invented, and the only defence is to keep every synthesised claim traceable to the underlying responses, so a reader can click a theme and see the answers that produced it. Synthesis you cannot trace back to coverage is just well-phrased guessing.
\nBut here is the trap: a team that attacks synthesis first, before coverage is solid, gets a layer that works perfectly on the data it can see and lies about the data it cannot. The synthesis layer cannot detect that the floor beneath it has holes. It will confidently summarise a biased sample forever.
\nThe top gap is the one that gets ignored entirely, and it sits above synthesis. Intent is knowing what the person was actually trying to learn when they asked. The same dataset answers different questions, and a synthesis aimed at the wrong question is wasted no matter how good the two layers below it are.
\nA product manager asking “what did we learn from this study” might mean “is the new checkout flow safe to ship,” or “which of my two designs won,” or “what objection do I take to my VP on Friday.” A generic three-theme summary serves none of these. It is correct and irrelevant, which is its own kind of failure; the reader skims it, finds nothing addressed to their actual decision, and quietly stops trusting the tool. Intent failure does not look like a wrong answer. It looks like a right answer to a question nobody asked.
\nThere is a second half to intent. The user knows their problem better than you do, which is why you ask; but knowing the problem isn’t the same as knowing what’s findable in the data, and the most valuable insight is often the one they didn’t know to ask for. I built hey anna to work that seam: to answer the question someone came with, and to act as the analyst who points them at the signal they would have walked past. The catch is that the guiding still has to serve them. A surprising finding with nothing to do with what they care about isn’t an insight, it’s a distraction. Reading intent well means widening what they thought to look for without leaving what they actually value.
\nPut the three together and the diagnostic falls out cleanly:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Gap | The job | What failure looks like |
|---|---|---|
| Coverage | get all the raw data analysable | a confident summary of the data that survived |
| Synthesis | roll findings into higher-order patterns | plausible themes that smooth over or invent |
| Intent | answer what the user meant to ask | a correct answer to the wrong question |
Trust collapses from whichever layer you neglected, and it collapses in a characteristic way. Neglect coverage and the answer is confidently wrong. Neglect synthesis and the answer is shapeless. Neglect intent and the answer is irrelevant. Crucially, you cannot patch a lower failure from a higher layer: no amount of synthesis brilliance rescues missing coverage, and no amount of intent-reading rescues a synthesis built on a biased sample.
\nThe reason most AI insights products feel untrustworthy is that they ship the middle layer alone. Synthesis demos well, so it gets built first and shown first, while coverage is half-finished underneath and intent is assumed rather than asked. The fix is to build bottom-up and check top-down: secure the data, make every rolled-up claim traceable to it, and then aim the whole thing at the question the person actually came with. Skip a layer and the trust does not erode gradually. It falls through the gap you left open.
", "date_published": "2026-05-19T00:00:00.000Z", "date_modified": "2026-05-19T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "ai-product", "engineering" ] }, { "id": "https://cvde.xyz/writing/live-billing-as-a-forcing-function/", "url": "https://cvde.xyz/writing/live-billing-as-a-forcing-function/", "title": "Live billing as a forcing function", "summary": "I turned billing on at hey anna later than the principle deserved, and learned something about my own discipline in the process. 'I'll charge later' is almost always the wrong call, and here's why.", "content_html": "I turned billing on at hey anna later than I should have, and I knew the principle the whole time. The moment money changes hands you find out three things you cannot learn any other way: whether the value is real, whether the price is right, and who the customer actually is. I could have written that sentence months before I acted on it. The gap between knowing it and doing it is the subject of this note.
\nThe reasoning I gave myself sounded responsible. Get the product right first. Don’t charge for something half-finished. Build trust, then ask for money. Each of those is defensible in isolation, which is exactly what made the bundle dangerous. “I’ll charge later” felt like discipline. It was avoidance.
\nHere is what free usage tells you: people will use a thing that costs them nothing. That is almost no information. Usage under a price of zero measures curiosity, politeness, and the absence of friction. It does not measure value, because value is what someone will give up something for, and at zero they give up nothing.
\nA charge is the cheapest instrument you own for measuring value, and it returns a clean signal. When the card gets entered, you learn the value cleared the price. When it does not, you learn something more useful: either the value is not there yet, or the price is wrong, or the person you built for is not the person who showed up. Free usage smears all three of those into a single flattering number - sign-ups, sessions, time-in-app - that goes up and to the right and tells you nothing about whether you have a business.
\nThe thing I was protecting myself from was not a half-finished product. It was the answer. As long as billing was off, the question “will anyone pay for this” stayed theoretically alive, and a live question is more comfortable to sit with than a real answer. That is the trap, and recognising it in myself was less flattering than I would like.
\nThe part I underestimated was the third thing: a price does not just test value, it sorts people. The accounts that converted the day billing went live were not a random sample of the free users. They skewed toward a particular kind of operator with a particular problem, and they were not always the cohort I had been designing for in my head. Free usage had been quietly averaging together the people who would pay and the people who never would, and presenting the blend to me as “users.”
\nYou cannot see that blend until a price splits it. The moment one did, the roadmap got an opinion it had been missing, because for the first time I could tell which feedback came from someone with money on the table and which came from someone with nothing at stake. Both are worth hearing; they are not worth the same weight, and free usage gives you no way to tell them apart.
\nI want to state this without self-flagellation and without the founder bravado that turns every mistake into a humblebrag. The plain version: I delayed a reversible, low-cost experiment because the result felt high-stakes, and the delay cost me months of clarity I could have had for the price of a Stripe integration and a slightly uncomfortable email.
\nTurning billing on is a two-way door. If the price is wrong you change it. If the timing is early you refund and apologise. Almost nothing about charging is irreversible, which is precisely why “I’ll charge later” is so rarely the right call - you are deferring a cheap, recoverable test to protect yourself from information, and information is the thing you are short of, not the thing you can afford to ration.
\nThe discipline I thought I was practising by waiting was the opposite of discipline. Discipline would have been turning it on early, watching who flinched and who reached for a card, and letting the answer reorganise the product around the people who were actually there.
\nIf you are sitting on a product with billing switched off and a good reason ready, check whether the reason is really about the product or really about you. Then turn it on. The number you get back will be worth more than the comfort you are protecting.
", "date_published": "2026-05-12T00:00:00.000Z", "date_modified": "2026-05-12T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "founder", "gtm" ] }, { "id": "https://cvde.xyz/writing/unit-economics-of-a-one-person-ai-product/", "url": "https://cvde.xyz/writing/unit-economics-of-a-one-person-ai-product/", "title": "The unit economics of a one-person AI product", "summary": "hey anna's variable cost is about 40% Claude API. That single fact rewrites the pricing, the acquisition maths, and whether viral growth is load-bearing. The SaaS playbook assumed COGS was a rounding error; it isn't anymore.", "content_html": "hey anna’s variable cost is about 40% Claude API. For every dollar of revenue, roughly forty cents leaves to pay for the model inference that does the actual work. That single number rewrites the pricing, the acquisition maths, and the question of whether growth needs to be viral. I want to be precise about why, because the standard SaaS reasoning gives the wrong answer at every step.
\nThe classic playbook assumes cost of goods sold is a rounding error and gross margin sits near 90%. Servers are cheap, the marginal cost of one more user rounds to zero, so the strategy writes itself: acquire aggressively, land cheap, expand later, worry about cost never. That assumption was true for software whose marginal unit was a database row. It is false for software whose marginal unit is a model call you rent by the token.
\nStart with the gross margin, because every other number depends on it. At 40% variable cost, the contribution margin is 60 cents on the dollar before you have paid for anything fixed. That is not a catastrophe; it is a constraint, and constraints are the useful part. It means the question “how much can I spend to acquire a customer” has a hard answer, where the SaaS founder gets to wave their hands.
\nCustomer acquisition cost is bounded by lifetime contribution margin, not lifetime revenue. The two are the same thing when COGS is zero, which is why nobody used to draw the distinction. Here they diverge by 40%. If a customer pays sub-$1/day and stays for a year, that is roughly $300 of revenue but only about $180 of contribution. The CAC the business can sustain is set against the $180, not the $300. Spend against the revenue line and you are buying customers at a loss the spreadsheet hides until the cohort matures and the cash does not arrive.
\nThe same arithmetic kills the casual free tier. In old SaaS a free user is a marketing cost that rounds to zero; you carry them indefinitely because the storage is free and one of them might convert. Here a free user who actually uses the product is a real cash outflow every day, priced in tokens, with no revenue against it. A free tier is not a tier; it is a budget line. It has to be sized like one - capped, time-boxed, or deliberately thin - because an unbounded free tier on a usage-priced product burns runway on non-customers.
\nThe 60 cents of contribution is not profit. It is the only money there is to cover everything fixed, and on a one-person product the largest fixed cost is the most invisible one: my time. There is no team to amortise across thousands of accounts. The model is a variable cost; I am the fixed cost. That framing decides what I build and, more often, what I refuse to.
\nIt changes how the price gets set, too. hey anna is positioned at sub-$1/day against analyst alternatives that run $400+/month. The headline gap looks like a generous discount. The economist’s read is different: the price has to clear the floor that 40% sets, every day, on every account, or volume makes the loss bigger rather than smaller. A pricing mistake on a 90%-margin product trims your margin once. A pricing mistake here is a per-transaction leak that scales with success. You cannot grow your way out of a negative contribution margin; you can only grow the hole.
\n\nThis is where the 40% changes the strategy rather than just the spreadsheet. When acquisition has to be paid and CAC is bounded by a 60-cent contribution, every dollar of paid acquisition is a dollar the margin has to earn back before the customer churns. That is survivable, but it is a grind, and on a solo product there is no sales team to make the grind go faster.
\nReferral and word-of-mouth are the one acquisition channel whose marginal cost is genuinely near zero. On a 90%-margin product that is a nice-to-have; paid acquisition works fine because the margin absorbs the CAC. On a 40%-cost product it is closer to load-bearing, because it is the only channel that does not have to be funded out of the same thin contribution margin that is also paying for the inference and for me. The question shifts from “can I buy growth” to “does the product produce growth as a by-product of being used.” If it does not, the maths says go slower, not louder.
\nThat is the real divergence from the land-and-expand orthodoxy. Land-and-expand assumes you can absorb cheap, badly-fitting customers now and sort the economics out at scale, because scale is free. Here scale is rented. So the discipline runs the other way: the product has to be good enough to spread on its own, the free tier has to be sized like the cash line it is, and the price has to clear the inference floor on day one rather than someday.
\nNone of this is a counsel of despair. A 60% contribution margin is a real business; it is just a business that has to respect its own arithmetic from the first dollar instead of the hundredth. The founders who get hurt are the ones who imported the COGS-is-zero assumption from the last decade of SaaS and only discover it was load-bearing when a successful month produces a bigger bill instead of a bigger bank balance.
\nThe model is not a fixed cost you provision once. It is a variable cost you pay per use, forever, and it is 40% of the revenue. Price like it, acquire like it, and size the free tier like it. The maths is not hard. It is just different from the maths everyone learned, and the difference is the whole business.
", "date_published": "2026-04-21T00:00:00.000Z", "date_modified": "2026-04-21T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "founder", "ai-product", "economics", "gtm" ] }, { "id": "https://cvde.xyz/writing/make-every-ai-claim-clickable/", "url": "https://cvde.xyz/writing/make-every-ai-claim-clickable/", "title": "Make every AI claim clickable", "summary": "Customers don't want AI that hands them the answer. They want to verify it. Deep-research-style citations are the line between an AI feature people adopt and one they paste into a doc and never open again.", "content_html": "Customers told me the same thing in workshop after workshop: they don’t want the AI to just give them the answer. They want to check it. I heard it running AI study-analysis sessions at Lyssna, where the room was full of researchers whose whole job is to not get fooled by a confident summary. The output that impressed them in the demo was the same output they didn’t trust enough to put their name on. The gap between those two reactions is where most AI features quietly die.
\nThe thing that closes the gap is small and unglamorous. Make every claim clickable. When hey anna says a change is statistically significant, that claim is a link: click it and you land on the test behind it, the two groups, the sample sizes, the p-value, the rows it ran on. Not a restatement that it held; the working itself. When it says revenue rose 18%, the number resolves to the 340 orders it was computed from, not a summary of them but the orders. It is the same move deep-research tools made when they started footnoting every sentence back to a source you can open, and at hey anna the whole product is built on it: verification over generation, which is what makes the brand line “analyst, not chatbot” true.
\nThere is a deeper point under the citations, and it is closer to what hey anna actually is. Because every claim resolves to your own rows, the agent stops being a box you query and becomes an interface to your data. It works in your dataset and updates it as you go; you can stay fully hands-off and let it run the analysis, or drop into the sheet and work the numbers yourself, and either way it is the same data in the same place. A collaborative workspace, where plain language is just the fastest way in.
\nClickable is not a citation icon that opens a vague “sources” panel. The bar is higher and it is specific.
\nA claim is clickable when three things are true. The link points at the exact evidence, not the general neighbourhood: the rows, the source document, the calculation, not “the sales table.” The path is short enough that a sceptical user will actually take it, which in practice means one click, not a five-step drill-down. And the evidence is legible when they arrive, so a person can look at it and agree the claim is fair, rather than landing in a wall of raw data they now have to re-analyse themselves.
\nMiss any of the three and you have a decoration. A citation that resolves to “rows 1 through 9,000” is honest and useless. A claim that takes four clicks to verify gets verified once, by you, in the demo, and never again by a customer. The work is in making verification cheaper than doubt.
\nThe intuition is that citations make people trust the AI more. That is half of it, and the less interesting half. The bigger effect is on what the user does next.
\nAn AI feature is adopted when it becomes a step in someone’s actual workflow. A summary that lands in their inbox is not a step; it’s a thing they read, nod at, and route around when the real decision gets made, because they can’t defend it to the person who asks “where did this come from?” A clickable claim survives that question. The user can forward it, cite it in a deck, drop it into a board pack, because the evidence travels with the assertion. That is the difference between a feature people try and a feature people build on.
\nThe pattern shows up as a fork in the usage data. The uncited version gets opened, admired, and abandoned; sessions are short and they don’t repeat. The cited version gets opened, clicked into, and returned to, because the user has learned that the claims hold when they pull on them. Verification is not friction you tolerate. It is the thing that lets someone stake their own credibility on your output, and people only stake their credibility on tools they can check.
\nThis is not free, and pretending it is would set you up to cut it under deadline. Clickable claims force an architecture where every assertion is traceable back to its evidence by construction. The number has to be computed deterministically, carry a reference to its inputs, and survive the trip into the sentence the user reads.
\n\nIn practice that means the model is never the thing doing the counting; it renders facts that were settled before it saw them. It means a UI layer that keeps the link between a phrase and its source intact instead of flattening everything into prose. And it means resisting the demo-friendly shortcut of letting the model freestyle a narrative, because a narrative with no anchors is exactly the thing your customer has already learned not to trust.
\nThe cost buys two things that are hard to get any other way. It buys adoption, because a checkable claim is one a professional can act on without putting their own judgement at risk. And it buys a moat, because traceability is slow to copy and gets harder to fake as your product touches more of a customer’s real data. A competitor can match your model in a weekend; matching a system where every claim resolves to its evidence takes them as long as it took you.
\nThere’s also the economics, which happen to point the same way. hey anna runs at under a dollar a day against analyst alternatives that start north of $400 a month, and the thing that makes the cheap version trustworthy enough to replace the expensive one is not a smarter model. It’s that you can click on what it tells you. Cheap and checkable beats expensive and opaque.
\nBuild the feature so a sceptic can audit it in one click. The sceptic is your most valuable user, because the sceptic is the one who decides whether anyone else gets to depend on it.
", "date_published": "2026-03-30T00:00:00.000Z", "date_modified": "2026-03-30T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai-product", "ux", "trust" ] }, { "id": "https://cvde.xyz/writing/measuring-the-platonic-representation/", "url": "https://cvde.xyz/writing/measuring-the-platonic-representation/", "title": "Measuring the platonic representation", "summary": "The platonic representation hypothesis says capable models converge toward one shared picture of reality. A language-anchored multimodal encoder lets you test a sharp version of it: encode one concept through four senses and measure what they agree on.", "content_html": "The platonic representation hypothesis is the claim that sufficiently capable models, trained on different data and in different modalities, converge toward the same internal picture of reality. If it holds, the structure a network learns is less an artefact of its training set and more a property of the world the data came from. It’s a big claim, and most of the evidence for it is correlational: line up two models, measure how similar their representations are, note that the number keeps rising as models get more capable.
\nA language-anchored multimodal encoder lets you test a sharper, more local version of the same idea. Take one concept - “thunder” - and encode it four ways: the word, an image of a storm, an audio clip, a short video. Each is a different sense arriving at the same shared space. The hypothesis predicts they should land in roughly the same place. The question is what “roughly” means, and where the disagreement lives.
\nA dense cosine similarity between the four embeddings gives you a single blurry number. Factor each embedding into a sparse decomposition first - a handful of named features from a sparse autoencoder - and the comparison gets legible. Now you can ask not just how much the four senses agree, but which features they share and which each one carries alone.
\nThe intersection is the modality-agnostic concept: the features that fire whether thunder arrives as a word, a picture, or a sound. That shared set is the closest thing the system has to a platonic core - the part of “thunder” that survives the change of sense. The per-modality remainder is what each sense contributes on top: the audio decomposition carries low-frequency and temporal features the word never touches; the image carries visual-storm features the sound can’t express.
\nThat remainder is not noise to be averaged away. It is the measurement. The features audio adds and text lacks are a direct readout of what hearing thunder encodes that naming it does not. Cross-modal agreement on the feature sets - a Jaccard overlap, concept by concept - turns the platonic hypothesis from a vibe into a number you can compute per concept and compare across them.
\nAnd it cuts both ways, which is what makes it honest. High overlap across modalities is evidence for a convergent core: the senses really are arriving at one representation. Low overlap is evidence against it for that concept - a sign the shared space is more bound together by training than unified by reality, with each modality keeping its own private structure under a thin coat of alignment. Either result tells you something. The experiment is worth running precisely because it can come back negative.
\nThe code is on GitHub; the anchor-compare command encodes one concept through each modality and reports the agreement, so the carve-out is something you can read off a single run.
The sharpest cold open is a company’s own public statement set against its own public statement. Their pricing page against their engineering blog. Their case-study claims against the logos in their footer. Their hero copy today against the same company’s hero copy a year ago. The tension between two things a prospect has already said in public is specific, credible, and impossible to wave off as a pitch, because every word in it is theirs.
\nThe default outbound move is to open on yourself: here is what we do, here is why it’s good, here is a slot on my calendar. The slightly better version opens on them and a rival: here’s what your competitor just shipped. Both ask the reader to take your framing on trust. The “you versus a competitor” angle also invites the easiest reply there is, which is “we’re not them,” and now you’re arguing.
\nAn internal contradiction skips that. You are not introducing a frame; you are pointing at one that already exists on their own site. There is nothing to dispute, because you didn’t write any of it. The reader’s first reaction is not “who are you” but “wait, is that actually still up.” That second of recognition is the entire opening, and it came from a quote that is already theirs.
\nThe pattern is: their public X, their public Y, and the gap that opens when you read the two together. The gap is the message. You are not selling against it; you are noticing it out loud, the way a sharp colleague would.
\nA few of these come up often enough to keep on hand.
\nThat last one is the highest-leverage because almost nobody looks. The live site is one snapshot. The history shows what changed, and the changes are where the strategy shows.
\nThe tooling is free and takes minutes. The reason it’s a moat is that “free and takes minutes” still loses to “nobody opened the tab.”
\nPull up web.archive.org, paste the prospect’s homepage or pricing URL, and open a capture from roughly a year ago next to the live page. Read them side by side. You are hunting for one thing: a sentence that changed, or a claim that stayed while the business behind it moved. Headlines, pricing tiers, the customer logo strip, and the nav labels are the highest-signal fields, because those are the ones a company rewrites when its strategy turns.
When you find the seam, the message writes itself, and it stays short. Name the then, name the now, ask the one question the gap implies. “Your homepage led on self-serve simplicity last March; today it leads on enterprise security and SSO. Usually that shift means the buyer changed from the IC to a VP. Did the way you handle inbound change with it?” No pitch in that. Just a precise observation and a question.
\n\nThe reason this beats research that costs money is that paid intent data tells you a company is “in market”; their own archived pages tell you why, in their own language, with the timeline attached. One is a signal you rent. The other you read for free, and nobody else bothered to.
\nMost outbound research stops at the live homepage because the live homepage is what loads first. The version from a year ago is one paste away, and the distance between the two is where the whole message lives.
", "date_published": "2026-02-26T00:00:00.000Z", "date_modified": "2026-02-26T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "gtm", "outbound" ] }, { "id": "https://cvde.xyz/writing/cancel-the-meeting/", "url": "https://cvde.xyz/writing/cancel-the-meeting/", "title": "Cancel the meeting", "summary": "When the data isn't ready ten minutes before a stakeholder readout, the move is to cancel and send it async later. Forcing the numbers into a calendar slot anchors everyone on figures you'll want back tomorrow.", "content_html": "Ten minutes before a stakeholder readout, the numbers are not right. The query is still running, or it finished and the figure looks wrong in a way you cannot yet explain, or you found a join that double-counts and you are not sure how far the damage spreads. The room is booked. People are walking over.
\nCancel it. Send the analysis async once it is solid.
\nThis feels like the weak move and it is the strong one, for a reason that has nothing to do with looking diligent and everything to do with how the people in that room form beliefs.
\nThe first number a stakeholder hears becomes the number they reason from. Not consciously; that is the point. Anchoring is one of the most robust findings in decision research, and it does not switch off because everyone in the room is senior and busy. You say “looks like roughly 40% retention” with a verbal asterisk that it is preliminary, and what lodges is 40%. Within the hour the caveat is gone and the figure remains.
\nNow the number was wrong, because of course it was, you said as much. Tomorrow the real figure is 28%. You send the correction. Here is what does not happen: the 40% does not get cleanly overwritten by the 28%. What happens instead is that the 28% gets received as a retreat from 40%. The stakeholder’s mental model is now anchored on the high number. So the true number reads as bad news, a disappointment, a walk-back, rather than what it actually is, which is the answer. You spend your correction’s energy fighting the impression you created instead of delivering the finding.
\nThe correction never fully catches up to the first impression. That is the mechanism, and it is why the calendar slot is a trap. The slot does not care whether your analysis is ready. It only cares that it is 2pm. If you let the slot set the timing, an arbitrary calendar slot plants a number in five people’s heads that you’ll spend a week dislodging.
\nThe instinct that keeps the meeting on is that cancelling wastes the slot and makes you look unprepared. But the slot is the cheap thing. Thirty minutes of calendar is recoverable. A stakeholder anchored on a wrong number is not, at least not for free. You pay later, in credibility, instead of now, in schedule.
\nThere is a second-order cost too. The next time you present a real, solid number, people remember the figure that moved overnight. People discount you a little, hedge against your figures, ask for the workings they did not used to ask for. A reputation for numbers that hold is worth more than a reputation for never missing a meeting, and the two trade against each other exactly in moments like this one.
\nThe obvious objection: cancelling looks like you are not delivering. You had one job, the readout, and you bailed.
\nAnswer it directly, in the cancellation itself. The message is not “sorry, not ready.” It is: “Holding this until the numbers are verified; I found something in the data that I am not willing to put in front of you until I trust it. Full analysis to you by tomorrow morning.” That sentence does not read as a failure to deliver. It reads as someone who refuses to put a figure in front of decision-makers before it is true. Which is, in fact, the job. The job was never to fill the slot. The job was to give people numbers they can bet on.
\nYou will feel the pull to present anyway, caveat heavily, and fix it later. The caveat is the part that does not work. You cannot caveat your way out of anchoring. The caveat is processed as language and the number is processed as fact, and the fact wins. Saying “this is rough” does not stop the rough number from becoming the anchor. The only move that actually prevents the anchor is not saying the number.
\nSo do not say it. Cancel the meeting, verify the figure, and send the one you would still stand behind tomorrow.
", "date_published": "2026-02-10T00:00:00.000Z", "date_modified": "2026-02-10T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "product", "leadership" ] }, { "id": "https://cvde.xyz/writing/stated-versus-revealed-preference/", "url": "https://cvde.xyz/writing/stated-versus-revealed-preference/", "title": "Stated versus revealed preference, in booking data", "summary": "Travel marketing assumes people book what they say they want. The booking data says otherwise, especially on luxury tier and trip length. The gap between stated and revealed preference is where the useful product decisions live.", "content_html": "Travel marketing assumes people book the holiday they describe. Ask someone what they want and they will tell you, sincerely, about the two-week luxury escape: the suite, the long unhurried itinerary, the trip they have earned. Then watch the booking data, and a different person shows up. They book the shorter stay, a tier down from the one they clicked “interested” on, and they do it consistently enough that the gap stops looking like noise and starts looking like a fact about people.
\nI spent a stretch at Luxury Escapes with that data in front of me, and the gap between what travellers said and what they paid for was wide, stable, and most pronounced on exactly the two dimensions the marketing leaned hardest into: luxury tier and trip length. Self-description reached for the aspirational version. The credit card reached for something more constrained. This is the oldest distinction in the discipline I was trained in, and it is worth naming plainly, because once you see it you cannot unsee it in any product where users describe themselves.
\nEconomists separate stated preference from revealed preference for a reason. Stated preference is what you say you want, gathered from surveys, sign-up questionnaires, the things you favourite, the box you tick. Revealed preference is what your choices show you actually wanted, inferred from what you gave something up to get. The two are different measurements of different things, and when they disagree, the money is on revealed.
\nThe reason they diverge is not that people lie. They do not. Stated preference is sincere; it is just answering a different question. When you ask someone what holiday they want, they answer with their aspirations, their self-image, the version of themselves they would like the survey to record. No budget constraint, no calendar, no school-holiday Tetris, no quiet sense that fourteen days is a lot of days to be away from home. Revealed preference is the same person after all of those constraints have done their work. The survey captures the wish. The booking captures the trade-off. A product that listens only to the survey is building for a customer who does not exist at the moment of purchase.
\nTrip length is the cleanest example, because the gap is so legible. People describe long trips and book shorter ones. The stated preference points one way and the revealed preference, aggregated across enough bookings to drown out the noise, points reliably shorter. The same divergence shows up in tier: aspiration drifts up the luxury ladder, the booking settles a rung below.
\nIf you take the stated signal at face value, you merchandise long luxury trips, lead with them, optimise the page for them, and quietly underperform - because you have aimed the whole funnel at the holiday people enjoy imagining rather than the one they complete. The fix is not to stop offering the aspirational trip. It is to stop treating the survey answer as a forecast of behaviour and start treating it as what it is: a weak signal about a strong feeling.
\nThe most durable lesson from that period was not even about preference; it was about sequencing. An earlier recommendation and email project taught it: most of the revenue lift came from getting the order right - which offer to surface next - rather than from personalising harder on who someone said they were. Behaviour responded to the sequence of what it was shown far more than to a richer model of stated identity. Revealed preference was telling us how to order the page. Stated preference, mostly, was telling us a flattering story.
\nThe product rule that falls out of this is simple to state and surprisingly hard to hold: build for what people do, instrument the gap, and treat stated preference as the weak signal it is. Weight the behaviour. When the survey and the booking disagree, the booking wins, and your job is to design for the customer who actually completes the purchase, not the one who fills in the form.
\nBut weak is not worthless, and there is one place stated preference is the only signal you have. Revealed preference can only reveal a choice that was on the menu. For anything genuinely new - a destination, a format, a price point a customer has never had the chance to choose - behavioural data is silent, because the behaviour has never had the opportunity to happen. There is nothing to reveal yet. There the survey, the interview, the “would you want this” is all you have, and you read it for direction while knowing it will over-promise on magnitude. The discipline is matching the signal to the question: trust behaviour where a choice already exists, fall back to what people tell you only where it does not, and never confuse the second case for the first.
\nI saw the front of this before I ever saw the data, selling travel across the counter. A revealed preference is only as honest as the menu you put in front of someone, and editing that menu is most of an agent’s craft. Nobody walked in asking to be upgraded; left alone, every traveller revealed a tidy preference for economy. But ask the question, and frame the fare against the twelve-hour flight rather than against the economy seat, and a real share said yes. The upgrade booked at roughly four times the fare, usually at better margin. That economy “preference” was never a preference; it was the only option anyone had offered.
\nThe same move ran in reverse, pulling a booking back up toward what someone had said they wanted. Put two hotels side by side, the mid-tier one they were about to book and the five-star they had earlier called the whole point of the trip, and the contrast does some of the work: Cialdini’s contrast principle, the reason you show the dear room first. The rest is consistency, another of his levers. You name the gap out loud - “you told me this was the trip you’d earned, and you’re booking the room you’d pick for a work conference” - and people, wanting their choices to line up with their words, often close it themselves. The aspiration was real; it had simply lost to the budget in the moment, and the job was to give it a fair hearing. The booking data I’d later stare at had the same blind spot from the other side: it could only reveal the preferences my menu had allowed.
\nThe gap between what people say and what they do is not a measurement error to be cleaned out of the data. It is the most useful thing the data has to tell you, because it is the difference between the customer in the survey and the customer at the checkout. Build for the one who completes the purchase.
", "date_published": "2026-01-20T00:00:00.000Z", "date_modified": "2026-01-20T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "economics", "product", "behavioural-economics" ] }, { "id": "https://cvde.xyz/work/hey-anna-founding/", "url": "https://cvde.xyz/work/hey-anna-founding/", "title": "hey anna: founding an analyst, not a chatbot", "summary": "Zero to a paid, billing-enabled product in under six months, solo and bootstrapped. The analyst that tells you why your numbers moved.", "content_html": "\nMost businesses sit on the data that would answer their questions and can’t get to the answer.
\nThe numbers live in Stripe, HubSpot, GA4, Mailchimp, and a long tail of social and finance tools. The questions are ordinary: why did revenue dip last week, which segment is actually growing, is this campaign working or just noisy, what are customers complaining about. Answering them properly means joining sources, running real statistics, and writing it up so a decision-maker can act. That is an analyst’s job, and a good analyst costs upwards of $400 a month if you can find one - well out of reach for most of the businesses that need one most.
\nThe market’s answer in 2026 is the chatbot: ask a question, get a confident paragraph. The problem is that a chatbot guesses. It will tell you revenue is up because of a campaign without running a significance test, segmenting the cohort, or checking whether the move is even outside normal variance. It sounds like an analyst and does none of the work. For anything you’d make a decision on, that gap is the whole game.
\nI started hey anna in January 2026 to close it.
\nThe positioning decision came first, and everything else followed from it: analyst, not chatbot.
\nThat is a constraint, not a tagline. A chatbot’s job is to produce a plausible answer. An analyst’s job is to produce a defensible one: connect to the real data, run actual statistical analysis, show the working, and only then state a conclusion. Committing to “analyst” meant hey anna had to do the unglamorous parts a chatbot skips: forecasts with confidence intervals, significance tests before claiming a change is real, segmentation that holds up, and themed analysis of verbatim text rather than vibes.
\nThe pricing decision came second and reinforced the first. hey anna is priced under $1 a day, against analyst alternatives that start north of $400 a month. The point isn’t to be cheap; it’s to put a real analyst in reach of a business that could never justify hiring one. The price defines the customer: the operator who has the data and the questions but not the headcount.
\nThe third decision was how to build it: solo and bootstrapped, with billing live as early as possible. Not as a constraint to apologise for, but as a forcing function. Charging from early means the product has to be worth paying for from early, which kills the temptation to build features nobody validated. Live billing is the honest gate: either someone pays for the analysis or they don’t.
\nhey anna connects to Stripe, HubSpot, GA4, Mailchimp, and 25+ social, marketing, and finance tools, runs real statistical analysis on what it pulls, and writes it up as an exec-ready report. The work splits three ways: get the data, do the analysis properly, deliver it in a form someone will read.
\nOn the analysis: forecasts, significance tests, and segmentation - the actual statistical work that separates an answer from a guess. When hey anna says a number moved, it has tested whether the move is real before saying so.
\nOn unstructured data: it themes verbatim text from reviews, surveys, and support tickets, so “what are customers unhappy about” gets a grounded answer drawn from what they actually wrote, not a summary of a summary.
\nAcross the product, 13 core features have shipped, including:
\n=AI() function that runs analysis inline, in the place people already think in rows and columns.The stack is chosen to let one person ship and operate a real product: React on the front end; Cloudflare for the platform (Workers for compute, D1 for data, R2 for storage); Anthropic’s Claude as the primary model, with Google and OpenAI available; Paddle for billing; PostHog for analytics. The constraint of building solo pushed every choice toward managed, edge-native infrastructure that doesn’t need a team to keep alive.
\nhey anna went from zero to a paid, billing-enabled product in under six months, solo and bootstrapped. It is live, with billing enabled and customers paying.
\nThirteen core features shipped in that window, by one person, on infrastructure one person can run. The positioning held up under contact: framing it as an analyst rather than a chatbot is what makes the statistical rigour a feature people will pay for instead of a detail they ignore. The sub-$1/day price puts it in front of the operators it was built for: businesses with the data and the questions but no analyst.
\nThe number that matters most isn’t a metric yet; it’s that the gate is real. The product charges money, and people pay it.
\nPricing is the decision I think about hardest, and for a one-person AI product the usual playbook doesn’t quite fit. The model is seats plus usage, with overage built in. That’s the direction Microsoft has taken with Copilot, and for the same reason: a tool used by both people and agents can’t be priced as if only people touch it. An agent can do a day’s work in a minute, so a flat per-seat price either over-charges the light user or hands the heavy one a loss. Usage tracks the thing that actually costs money.
\nUnderneath the price is a cost I own rather than pass on. The biggest variable cost is model inference, and the lever that moves it most is cache hit rate: Anthropic charges a premium to write to the prompt cache and a fraction of that to read from it, so the gap between a well-structured request and a naive one is most of the margin. Maximising cache hits is one of the numbers I watch most closely, and it’s deliberately an internal one. A customer shouldn’t pay more because I haven’t done my engineering; the cost of my own inefficiency is mine to fix, not theirs to carry.
\nUsage-based pricing is good because it ties what a customer pays to what they use. The ideal goes one step further and ties price to the outcome. The clearest examples are in support, where an agent’s action maps onto a result the business already prices: if a ticket costs a company $30 to handle and an agent resolves or deflects it for $9, the trade is obvious, the risk is low, and you can charge for the result rather than the tokens. That is the cleanest version of cost aligned to value there is. hey anna’s outcomes are harder to count than a deflected ticket, so I’m not there yet, but it’s where the value-alignment argument points and where I want the pricing to head as the signal sharpens.
\nAll of this matters more because I’m bootstrapped. There’s no venture money behind hey anna to buy market share or prop up a price that doesn’t work, and I’m not running paid ads yet; growth is meant to be sustainable, which is a polite way of saying slower, with fewer eyeballs on the product. A funded competitor can underprice for years and make it up later. I can’t, so the price has to earn its keep from the first customer, and getting it roughly right matters more for me than it would for someone growing on someone else’s money.
\nAnd the honest part: hey anna sits at under $1 a day, which is roughly the $29 consumer default I’ve argued against in writing, and the exact default I killed at Brand Ninja. I’m aware of the irony, and I think the product is worth well more than that. I’m charging it anyway, on purpose. Right now the opportunity cost of an empty room is higher than the revenue I’m leaving on the table: I’d rather have customers teach me what hey anna is worth than a higher number protect a value nobody has paid yet. I’m optimising for learning. The floor is a decision I’ve parked deliberately, and I’ll raise it once the customers have shown me where it belongs.
\nI scoped early features before I’d watched enough people use the product, and a few of the 13 were built ahead of the demand for them. Shipping fast solo is an advantage, but it’s also how you accumulate surface area that has to be maintained whether or not it earns its keep. I’d hold more features at the idea stage until a paying customer pulled them out of me.
\nI was also slower to turn billing on than the “live billing as a forcing function” principle deserved. I believed it in the abstract before I acted on it; there’s a stretch where I was building toward a paid product rather than running one. The lesson is that the forcing function only works once it’s switched on; until then it’s a plan, and a plan doesn’t tell you what people will actually pay for.
\nAnd being both the entire product team and the entire go-to-market team means the two compete for the same hours. I’ve defaulted to building, because building is what I’m fastest at, which means distribution has lagged the product. For the next stretch the harder, more valuable work is getting hey anna in front of the operators it was made for, not adding to what it can already do.
\nLive billing was one forcing function; shipping before it feels ready is the other, and it’s the one I find hardest to apply to my own work. When I build for a business or a team, I ship rough on purpose: the work serves a goal, shipping fast is how you learn fast, and my ego isn’t in the file. My own product represents me more directly than anything I’ve delivered inside a company, so I feel the pull to polish past the point that earns its keep and to hold it to a personal standard instead of a commercial one. The discipline I’m practising on myself is the one I’d apply without hesitation to someone else’s roadmap: ship before it feels ready, because ready is a feeling, and only the customer can tell you the truth.
", "date_published": "2026-01-01T00:00:00.000Z", "date_modified": "2026-01-01T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ] }, { "id": "https://cvde.xyz/work/multimodal-embedding-art/", "url": "https://cvde.xyz/work/multimodal-embedding-art/", "title": "Multimodal embedding art: concept algebra in a shared representation space", "summary": "Optimising generative models toward coordinates in a 768-dimension multimodal embedding space: surfacing the platonic ideals a neural net has learned, then doing arithmetic on them across text, image, audio, and video.", "content_html": "A text-to-image model can draw you a goldfish. That’s a useful trick and a dull question. The more interesting one sits underneath it: what does goldfish look like to the model itself - not a goldfish, but the direction in representation space that means goldfish, cranked to maximum?
\nNeural networks learn internal representations of concepts. A multimodal encoder learns them in a space shared across modalities, so the embedding for the word “thunder,” an audio clip of thunder, and an image of a storm all land near each other. That shared space is a map of what the network thinks concepts are. This project is an attempt to render points on that map directly, by treating generation as an optimisation problem in embedding space rather than a prompt.
\nIt sits where mechanistic interpretability meets generative art. The interpretability question (what has the network actually learned, and can we see it) is the same question whether you frame the output as a diagnostic or as an image worth looking at. The aesthetic and the analytic are the same act here: maximally activating an internal representation and looking at what comes out.
\nThe framing decision was to optimise toward embedding coordinates rather than condition on a prompt.
\nA normal generative pipeline takes a prompt, runs it through the model, and returns a sample. The concept lives in the prompt; you never touch the representation. The decision here was to invert that: pick a target point in the embedding space, then optimise a generator’s latent to maximise the similarity between its output’s embedding and that target. The concept becomes a coordinate you can manipulate, not a sentence you have to phrase.
\nThat choice is what makes concept algebra possible. Once a concept is a vector, you can do arithmetic on it: add two concepts, subtract an attribute, interpolate between two points. You can’t cleanly add “fire” and “water” in a prompt; you can add their embeddings. The output isn’t training data retrieved and blended; it’s the model’s own answer to “what lies at this coordinate,” reconstructed from scratch by optimisation.
\nThe encoder is LanguageBind, which binds image, audio, video, and text into one 768-dimension space anchored on language. A target can be assembled from any mix of those modalities, and a generator for one modality can be optimised toward a target defined in another. That cross-modal property is the whole reason to use a shared space rather than a per-modality one. Anchoring on language earns a second thing for free: any point in the space can be projected back toward the text encoder’s vocabulary, so a non-text embedding has a running human-readable readout. Mid-optimisation you can ask “what does the current image embed as,” and get back {storm, crackling, electric}. That single property is what turns the optimisation loop from a black box into something you can watch think. (The original build used ImageBind in a 1024-dimension space; LanguageBind is its direct successor, covers the same modalities, and exposes ViT patch tokens natively, which the loss now leans on.)
The deeper representation decision is that a concept is not really the dense vector; it’s a sparse feature decomposition, and the vector is derived from it. A Matryoshka sparse autoencoder factors each embedding into a handful of named, active features. That matters because arithmetic in dense space is blunt: adding two normalised vectors averages every dimension, and subtraction is a vague nudge. Arithmetic over decompositions is sharp: addition unions the named features, subtraction removes a specific one, interpolation morphs the feature mixture. So Concept carries its decomposition as primary state and composes in feature space whenever both operands have one. “Fire plus water” stops being a blended average and becomes a union of what the model knows about each.
A system that takes any combination of text, image, audio, and video as input concepts, combines them with feature-space arithmetic, and optimises a generative model’s latent toward the target. One command, showcase, renders a single target across all four modalities at once and emits an interpretation bundle and an evaluation card alongside the artefacts.
Generation runs through modality-specific decoders: the Stable Diffusion 3.5 Medium latent for images, Stable Audio Open for audio, and LTX-Video for video. Optimisation is gradient descent on the generator’s latent, with a default of 2000 steps at a learning rate of 0.1. (The original build paired ImageBind with the SDXL VAE, AudioLDM 2, and Stable Video Diffusion; those still exist as legacy ablation backbones, but the flow-matching SD3.5 latent and the newer audio and video models are sharper and the licences are cleaner.)
\nThe concept algebra is the interface:
\n# Addition: combine two conceptsfire_water = Concept.from_text("fire", encoder) + Concept.from_text("water", encoder)\n# Weighted combinationsunset_ocean = 0.3 * Concept.from_text("sunset", encoder) + 0.7 * Concept.from_text("ocean", encoder)\n# Subtraction: remove an attributehairless = Concept.from_text("dog", encoder) - 0.3 * Concept.from_text("fur", encoder)\n# Spherical interpolation between two pointsmidpoint = Concept.slerp(concept_a, concept_b, t=0.5)\n# Cross-modal: an audio concept plus a text concept, rendered as an imagethunder_purple = Concept.from_audio("thunder.wav", encoder) + 0.3 * Concept.from_text("purple", encoder)The naive loss is cosine similarity on the pooled embedding, and it has a known failure mode: it matches the model’s final answer the way an adversarial image matches a classifier’s top label, which is to say with high-frequency noise that scores well and looks like nothing. Pooled cosine is now a metric I log at every step, not the signal I optimise. The signal is two tighter terms. Patch-token alignment matches LanguageBind’s ViT patch features rather than the pooled summary, which preserves spatial structure: a goldfish-shaped goldfish instead of goldfish texture smeared across the frame. Feature-direction alignment matches the SAE decomposition, so the optimiser is pushed toward the named features the target carries, not just its dense direction.
\nHolding the output inside the distribution the decoder expects used to be a hand-tuned job: total variation for smoothness, a spectral penalty on high frequencies, a latent-norm term. Those still exist on the legacy path, but the load-bearing version now is a learned one. A variational score-distillation prior pulls the latent toward the natural-image manifold a frozen diffusion model already knows, trained as a small per-concept LoRA so it regularises without collapsing every concept to the same generic mean. The regulariser weights I used to pick by feel are replaced by a prior the model derived.
\nFour renders, four concepts: water, thunder, fire and goldfish, listed here in a different order than they appear below. See if you can match each to a tile before you turn it over.
\nThese are not meant to be beautiful, and it’s worth being plain about what they are. Each one is the literal output for a concept: the optimiser starts from random noise and nudges every pixel until the whole image embeds close to the target point. Nobody ever shows it the subject or tells it what one looks like. So where matching the concept doesn’t pull on a region, the pixels stay as the high-frequency speckle they started as. Most of the frame is static because, to the encoder, most of the frame doesn’t matter.
\nWhat matters is that the subject still surfaces. Look past the speckle and forms start to organise out of it - edges, repeating shapes, the rough silhouette of whatever the model is reaching for. In places it reaches for the written word rather than the thing, which is its own tell that the encoder is anchored on language. None of it resolves into a clean picture, but the concept is unmistakably there once you spot it; that is the game above, four renders with nothing labelled until you turn them over. That partial, patchy legibility is the honest result, and it forces a choice: leave the representation raw, or resolve it toward something that reads as a real image.
\nThe most interesting decision was to render two tracks of the same concept side by side. A VAE-style render answers “what is the nearest natural image whose embedding matches this concept” - it leans on the decoder’s training distribution to produce something photo-real and recognisable. That’s the natural track, VSD-prior conditioned. The honest track dials the prior down and lets the optimisation sit closer to the raw representation, so the output is what the model thinks the concept is rather than the closest real photograph of it. Neither is the true one. The contrast between them is the artefact: here is the model’s idea of “thunder,” and here is the nearest thing in the world to it.
\nEach run emits an interpretation bundle and an evaluation card, so an artefact is never just an image. The bundle carries the text-anchor readout (what the output embeds as, in words), the named SAE features that fired hardest, attribution maps from attention rollout and integrated gradients that show where in the frame each feature lives, and linear-probe activations for coarse questions like “is this animal” or “is this danger-coded.” The card carries the numbers: cross-modal agreement (do the image, audio, and video for one target re-encode to neighbours), cross-encoder probes that re-score the output with SigLIP2 and CLAP rather than the encoder it was optimised against, and seed-stability across repeated runs. Evaluation is built into the pipeline rather than bolted on after, which is the part of this build I’d most defend.
\nThe whole thing runs on Apple Silicon: PyTorch on the MPS backend, tuned on an M1 Max with 64GB of unified memory. A full four-modality dual-track run holds the LanguageBind encoders, three decoders, and optimisation overhead in roughly 19GB; a single-modality image render fits comfortably on 16GB. The Apple Silicon path is deliberate, and it took real work to make fast: bf16 autocast on the forward pass, torch.compile on the optimisation hot loop, and flash-attention routing through the ViT together buy a 3-5x wall-time improvement over naive fp32. This is exploratory work where the loop is run-look-adjust, and a fast local iteration cycle on hardware I already own beats renting a faster card.
The system does concept algebra across four modalities in a single shared embedding space: addition, subtraction, and spherical interpolation over text, image, audio, and video, with cross-modal targets that let an audio concept shape an image or a text concept colour a sound.
\nWhat it surfaces is the more interesting result than any single picture: the platonic ideals a network has learned. The outputs are what the model thinks a concept looks like: maximally activated representations reconstructed by optimisation, not training examples retrieved and recombined. As an interpretability artefact, that’s the point. You’re looking at the geometry of a learned representation directly, and the interpretation bundle lets you read it rather than guess at it: which features fired, where they live in the frame, what the output embeds as in words.
\nThe evaluation card turns “did this work” from a judgement made by eye into something with numbers behind it. Cross-modal agreement says whether the four renderings of a target really landed near each other, cross-encoder probes say whether a second model agrees about what’s in the output, and seed-stability says whether the result is a property of the concept or an accident of initialisation. It still makes no benchmark claim and it isn’t a paper; the numbers exist to keep the framing honest, not to top a leaderboard.
\nI’m treating this as an essay-grade study. Its value is in the framing - generation as optimisation in a shared space, concepts as feature decompositions you can do arithmetic on, the honest and natural tracks shown together - and in the artefacts that framing produces. The natural next surface is the interactive one: an embedding-space view where you move through the concept manifold and watch the output change, which is where the lab takes it.
\nThe code is on GitHub.
", "date_published": "2026-01-01T00:00:00.000Z", "date_modified": "2026-01-01T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ] }, { "id": "https://cvde.xyz/writing/metacognition-is-the-unlock/", "url": "https://cvde.xyz/writing/metacognition-is-the-unlock/", "title": "Metacognition is the unlock", "summary": "Model progress has moved through paradigms: reactive, then reasoning, then agentic. The next is metacognition - thinking about its own thinking - and it's what separates a model that repeats mistakes from one that compounds on them.", "content_html": "\n\nThe big challenge for traditional LLMs is that they are path-dependent; while they can consider the puzzle as a whole, as soon as they commit to a particular guess they are locked in, and doomed to failure. This is a fundamental weakness of what are known as “auto-regressive large language models”, which to date, is all of them.
\n
That’s Ben Thompson. Escaping that trap is what each paradigm of model progress has chipped at, and the paradigm you’re on sets the ceiling on what the model can do without you standing over it.
\nThe first paradigm was reactive. Early chat models answered in one shot: prompt in, text out, no pause between. They were fluent and often right, but they couldn’t catch themselves mid-thought because there was no middle to the thought. The whole answer arrived at once.
\nThe second was reasoning. Models learned to think step by step before answering; to lay out the working, not just the conclusion. This is a real jump. A model that reasons through a problem catches errors a reactive model commits on the spot, because the steps are now visible to the model as it produces them. Reasoning buys reliability on anything that has a chain to it.
\nThe third is agentic. Harnesses and agents decompose a goal into steps and sequence the work: do this, then that, check the result, move on. This is what turns a model that answers questions into a system that completes tasks. It can hold a goal across many calls and make progress against it without a human threading each step.
\nThat paradigm is metacognition: thinking about its own thinking. Not reasoning through the task, but reasoning about the approach to the task. Noticing that a line of attack is failing and changing it. Noticing it’s hit the same blocker three times and trying a different approach. Treating a failed attempt as information about strategy rather than a thing to retry verbatim.
\nThe distinction is sharp once you see it. An agentic loop that hits an error retries the step, maybe with a tweak, and retries again. It’s working hard inside a frame it never questions. A metacognitive agent asks a different question: is the frame wrong? It can question the step itself, judge the strategy that produced it, and pick a new one. The first can loop forever. The second can notice it’s looping.
\nIn humans this is the whole game. Two people make the same mistake. One files it as bad luck and makes it again next week. The other extracts the rule, updates how they work, and never makes that class of mistake the same way twice. The second person isn’t smarter in the moment; they’re better at learning from the moment. Metacognition is what separates someone who repeats mistakes from someone who compounds on them. The mistakes are the same. What you do with them isn’t.
\nAn agent loop usually has an observe step, a decide step, an act step. Metacognition adds a fourth: learn. That’s the seam where metacognition lives, and the useful part is that you can trigger it deliberately rather than wait for it to emerge.
\nAfter an attempt, before the next one, you make the agent answer a different kind of question. Not “what’s the next action” but “what did that attempt tell me, and should I change my approach?” Cheap to add: it’s a prompt and a place in the loop to run it. The effect is out of proportion to the cost. The agent stops treating every failure as a reason to retry and starts treating some failures as a reason to rethink. You’re not making the model smarter. You’re giving it a moment to be honest about whether the current plan is working, and a license to abandon it.
\nCurrent models don’t fully have this. They’ll cheerfully retry a doomed approach, declare success on work that failed, miss the pattern in their own errors. The paradigm isn’t here yet; it’s arriving. But you can see the shape of it, and you can scaffold toward it in the loops you build today. The learn step is where you reach for the next paradigm before the models get there on their own.
\nThe reactive model answers. The reasoning model works through. The agentic one sequences. The metacognitive one notices it’s about to make the same mistake again, and doesn’t.
", "date_published": "2025-11-25T00:00:00.000Z", "date_modified": "2025-11-25T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "agents", "metacognition" ] }, { "id": "https://cvde.xyz/writing/the-trust-calibration-tax/", "url": "https://cvde.xyz/writing/the-trust-calibration-tax/", "title": "The trust-calibration tax", "summary": "The hard part of AI UX isn't generating answers. It's teaching users when to trust the system, when not to, and how to recover when it's wrong. That work is the real cost, and most teams never budget for it.", "content_html": "Generating the answer is the cheap part now. Any team can wire a model to a prompt and ship something that produces a plausible result. The expensive part is teaching the user when to believe it, when to check it, and what to do in the moment it’s wrong. I call that work the trust-calibration tax, and almost no roadmap has a line for it.
\nIt is a tax because you pay it whether you budget for it or not. Skip it and the cost still arrives; it just arrives as churn instead of a story point. The user trusts the system once, gets burned on something they couldn’t see coming, and quietly stops opening it. They rarely file a bug, because nothing broke. The output was wrong in a way that looked exactly like being right. That is the failure AI produces most often. You lose the account and never learn why.
\nA user’s trust in an AI feature is a dial, and your job is to keep it pointed at the truth. Too low and they ignore a system that would have helped; you built it for nothing. Too high and they ship its mistakes under their own name; you built them a liability. The output being good on average does not fix either failure, because the user can’t see the average. They see one result at a time and have to decide, each time, how much to lean on it.
\nThis is why “we improved accuracy to 94%” doesn’t move adoption the way teams expect. A system that’s right 94% of the time but gives you no way to spot the wrong 6% is harder to use well than one that’s right 80% of the time and flags the answers it’s unsure of. The first asks the user to trust everything equally and punishes them for it. The second teaches them where to look. Calibration beats raw accuracy for the same reason a fuel gauge beats a bigger tank; what the user needs is to know where they stand, not just more of the thing.
\nThe tax is not one feature. It’s a set of jobs the interface has to do, and each one is the kind of work that gets cut first when a deadline tightens.
\nThe same tax shows up wherever the trust gets calibrated, regardless of domain. At Lyssna, researchers analysing AI study output didn’t want a cleaner summary; they wanted to see which transcript a finding came from, because their trust was a function of traceability, not polish. At hey anna, every claim is clickable for the same reason: the calibration work is built into the surface, so a user learns within minutes which numbers to lean on and which to open. In both, the model was the easy half. The interface that let a professional calibrate their reliance on it was the half that took the time and the half that decided whether anyone kept using it.
\nYou can see the tax dodged in the wild too. The AI feature that demos beautifully and dies in production is almost always one that aced generation and skipped calibration. It gave great answers and no way to tell the great ones from the dangerous ones, so the first burn taught the user to stop trusting all of it at once. The feature didn’t fail because the model was bad. It failed because nobody built the part that teaches a person how much to believe.
\nThe practical move is to treat calibration as a first-class part of the spec, not a polish pass. When you scope an AI feature, scope the four jobs alongside the generation: how does this signal its confidence, how does a user see the working, what does it feel like when it’s wrong, and how does someone undo a bad result. If those four don’t have owners, you have not built an AI product. You’ve built a demo that happens to run in production.
\nThis is also where shipping an AI product grows up past prompt engineering. The first instinct, and still the common one, is to push the work back onto the user: tell the model not to make things up, or lean on a “check your answer” and a second agent to review the first. That honestly gets an individual a long way, and if you’re using AI for your own work, use it. Shipping a product is the opposite move. Product is solving a user’s problem systematically and then building the solution in, so they don’t have to re-solve it every session; you do the thinking ahead of them and bake it into the system. That is what SaaS has always been, and AI is no different, except that it is unusually easy to ship something that looks like thinking and has none underneath.
\nThe teams that win the next few years won’t be the ones with the best model. Raw capability is commoditising on a schedule nobody controls. They’ll be the ones who paid the trust-calibration tax in design time instead of in churn, and who understood that the answer was never the hard part.
", "date_published": "2025-11-06T00:00:00.000Z", "date_modified": "2025-11-06T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai-product", "ux", "trust" ] }, { "id": "https://cvde.xyz/writing/not-every-ai-feature-is-a-chat/", "url": "https://cvde.xyz/writing/not-every-ai-feature-is-a-chat/", "title": "Not every AI feature should be a chat", "summary": "Enterprises trust AI for invisible categorisation and distrust it for reversible work behind a chat box. 'Chat, move this five pixels' is all-or-nothing and risky. Sometimes the right surface for an AI feature is a button.", "content_html": "The same enterprise that lets AI silently categorise a million support tickets will refuse to let an AI chat assistant touch the layout of one slide. From the outside that looks like inconsistency. It isn’t. It’s a precise read on where AI is safe to depend on and where it isn’t, and the chat box is on the wrong side of that line more often than chat-first design assumes.
\nWatch what enterprises actually approve. They hand AI the invisible, high-volume work: routing tickets, tagging transactions, flagging anomalies, deduplicating records. Millions of decisions a day, no human in the loop, complete trust. Then watch what they hold back. The hands-on, reversible work a person was doing themselves a minute ago: editing the document, adjusting the design, changing the number in the cell. Here they want their hands on the controls. The pattern isn’t fear of AI. It’s a sober judgement about which surface fits which task.
\nThe surface for an AI feature should fall out of two properties of the task, not out of what’s fashionable to ship.
\nThe first is how much trust the task requires. Categorisation is forgiving at scale; one misrouted ticket out of a million is noise, and the aggregate is what matters. Moving an element on a customer’s slide is unforgiving and singular; there is no average to hide in, and the one wrong move is the whole experience. High-trust, low-tolerance tasks want the user’s hand on the wheel. Low-trust, high-volume tasks are exactly where you let the AI run unattended.
\nThe second is how reversible the action is. A categorisation that runs in the background is reversible by definition; you re-run it, you correct the tag, nothing was staked. A direct manipulation of something the user is actively working on carries immediate, visible consequences they have to live with. The more reversible and invisible the work, the more autonomy the AI can safely have. The more direct and consequential, the more the user wants a control they understand.
\nChat is a genuinely good surface for a specific shape of task: open-ended, exploratory, where the user doesn’t yet know what they want and the cost of a wrong turn is just another message. “Help me think through this,” “what’s in this dataset,” “draft me three options.” The ambiguity is the point, and a conversation is the right tool for resolving ambiguity.
\nThe fashionable AI design tools show the failure of forcing everything else into that mould. “Chat, move this box five pixels left” is slower, vaguer, and riskier than the direct control it replaced. You type a sentence, wait for a generation, and discover whether the model understood; the old way was to grab the box and move it, with your eyes closing the loop in real time. Worse, the interaction is all-or-nothing. You get the model’s whole interpretation back at once, and if it’s 90% right you’re now editing its guess instead of expressing your intent. A precise, reversible, hands-on task got wrapped in an imprecise, latent, all-or-nothing interface. The chat didn’t add power. It added distance between the user and the thing they were trying to do.
\nThose two questions are about how much autonomy a task can bear. There’s a third, on a different axis, and it decides how much an LLM is actually buying you: how wide is the space of inputs and outputs the feature has to cover?
\nA traditional control is something you build by anticipating that space in advance. Every option, every edge case, every state has to be foreseen and given a component, and what you didn’t build, the user can’t do. That foresight is most of the cost of software, and it’s why narrow, well-understood tasks get clean controls and sprawling, open-ended ones get a thin UI or none at all. An LLM broadens the interface without you building any of it: it takes an input you never enumerated and produces an output you never designed a screen for. That is the real trade. When the space is too wide to enumerate, you couldn’t have built a control for every way a person might ask for the chart they want, so you let language carry the range. When the space is narrow, the model is selling you breadth you don’t need, and charging latency, a stochastic result, and an all-or-nothing round-trip for it.
\nAnd the answer isn’t fixed for the life of a feature; it moves through a single task. Generation is wide: you don’t know exactly what you’ll get, so the open interface fits. Editing is narrow: you know the precise change, and running it back through the stochastic round-trip to move one line or delete one word is slower and less certain than simply doing it yourself. The same feature wants a broad interface to create and a direct one to refine, and the good ones switch at that seam rather than trapping the user in a conversation for work their hands could finish in a second.
\nBefore defaulting an AI feature to chat, run it through four questions.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Question | Lean to chat | Lean to a control |
|---|---|---|
| Does the user know what they want? | No, they’re exploring | Yes, they have a specific intent |
| How direct is the action? | Indirect, the AI does work offstage | Direct, the user is manipulating the thing |
| What’s the cost of a wrong interpretation? | Low, just send another message | High, you’re now editing a bad guess |
| How wide is the input and output space? | Wide, you can’t enumerate it | Narrow, you can build for it |
When the answers point right, the better surface is a button, a toggle, a slider, or an inline suggestion the user accepts or rejects in place. A button has no ambiguity to misread. A toggle is instantly reversible. An inline suggestion lets the user see the proposed change against the real thing and take it or leave it without a round-trip through a sentence. These surfaces give the AI exactly as much autonomy as the task can bear and no more, which is the whole game.
\n\nThe chat-first default treats conversation as the universal interface for AI, and for a real slice of tasks it is the right one. The mistake is reaching for it everywhere, including the places where a direct control would be faster to use, safer to trust, and easier to reverse. The surface is not a branding decision. It’s where the trust the task demands meets the reversibility the action allows, and that meeting point is sometimes a conversation and sometimes a button.
\nPick the surface the task is asking for. Often it’s quietly asking for a button.
", "date_published": "2025-10-15T00:00:00.000Z", "date_modified": "2025-10-15T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai-product", "ux", "product" ] }, { "id": "https://cvde.xyz/writing/context-engineering/", "url": "https://cvde.xyz/writing/context-engineering/", "title": "Context engineering is the design surface", "summary": "Prompt engineering treats the words as the lever. Context engineering treats the whole context window as the design surface, with a stage and an artifact for each step. It's the better abstraction for production work.", "content_html": "Prompt engineering treats the wording as the lever you pull. Phrase the request better, add the magic words, and the output improves. That model works for a single turn against a chatbot. It stops working the moment the task is large enough to matter, because the wording was never the whole input. The whole input is the context window: the instructions, the examples, the retrieved material, the prior turns, the structure you imposed on all of it. Context engineering treats that entire window as a design surface you compose on purpose.
\nThe companion to this argument is that you should build context systems instead of crafting one-off prompts. That piece makes the case for the shift. This one goes further into how: what stages the work moves through, and what each stage leaves behind.
\nThe trap with “context engineering” is that it can stay a vibe. You nod, you agree the context matters, and then you go back to typing paragraphs into a box. The fix is to give the work stages, and to make each stage produce something you can point at. An artifact you can name is an artifact you can reuse, review, and hand to someone else.
\nI teach this as four stages at Lyssna, in workshops on how teams actually get leverage out of models. The progression is Define, Discover, Design, Develop. Each one owns a question and produces an artifact.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Stage | The question it answers | The artifact it leaves |
|---|---|---|
| Define | What is the task, and what does done look like? | A problem statement and explicit success criteria |
| Discover | What domain material and examples does the model need? | A curated context pack: vocabulary, references, good and bad examples |
| Design | What structure and framework holds the work? | A scaffold: the framework named, the output shape fixed |
| Develop | How does it improve across turns? | A working transcript you can rerun and refine |
The artifacts are the point. If a stage produces nothing you can save, you skipped it, and the model is now guessing at the thing you didn’t write down.
\nMost bad output traces back to a task that was never specified. “Make this better” has no done state, so the model invents one, and it rarely matches yours. The Define stage forces the criteria out of your head and onto the page: what the output is for, who reads it, what would make you reject it.
\nThe artifact is small and it does a lot of work. A few lines of success criteria let you judge the output instead of reacting to it. They also become the thing you paste into every later turn, so the model is scored against your bar rather than a generic one.
\nThis is the stage people skip, and it’s the one that moves quality most. A model has read an enormous amount. The problem is reaching for the right part of it. Domain vocabulary is how you do that. Precise terms act as a key: say “rebase” and “bisect” and the model lands in the part of its training where careful git work lives; say “make the history clean” and you get a vaguer neighbourhood. The words you choose decide which regions of the model’s training light up.
\nSo Discover is deliberate retrieval, done by you before any automated retrieval runs. You assemble the context pack: the terms of art for this domain, the references that define the standard, and examples of both good and bad output. Examples carry more than instructions do; one strong example of the thing you want teaches faster than three paragraphs describing it. The pack is reusable. Build it once for a recurring task and every future run starts from the right place.
\nFrameworks earn their keep here, and not because they’re clever. A named framework is a structure the model has seen thousands of times in training. Invoke it and you get its shape for free: the steps, the order, the headings, the way the parts relate. You’re not teaching the model the framework. You’re pointing at one it already holds and asking it to pour this task into that mould.
\nThat’s the lever. “Analyse this” is unstructured and the output will be too. “Run a SWOT, then a risk register, then a recommendation” hands the model three scaffolds and an order to fill them in. The artifact of this stage is the scaffold made explicit: the framework named, the output shape fixed, the sections decided before the first word is generated.
\n\nSingle-shot prompting asks for the finished thing in one call. It works for small tasks and fails quietly on large ones, because everything that goes wrong goes wrong at once and you can’t see where. Building across turns separates the failures. You generate a draft, inspect it against the success criteria from Define, correct the one thing that’s off, and continue. Each turn carries the accumulated context forward, so the window gets richer as you go rather than starting cold.
\nThe artifact is the transcript itself. A good multi-turn session is a reusable thing: the sequence of moves that produced a result you trusted. Save it and you’ve captured a workflow, not just an answer.
\nAll four stages produce artifacts, and artifacts are exactly what a context file is for. CLAUDE.md (or its equivalent in whatever tool you use) is where the durable parts live: the vocabulary, the success criteria, the frameworks you reach for, the examples of good output. Written down once, loaded every session.
\nThe shift worth naming is from personal trick to shared infrastructure. When the context file lives in your head, the leverage leaves when you do. When it lives in the repo, it’s something a team builds together and improves over time. A new person inherits the accumulated context on day one instead of rediscovering it over months. That is the difference between a clever individual and a team that compounds; the file is where the compounding happens.
\nPrompt engineering optimises a sentence. Context engineering builds the surface that every sentence lands on, and leaves an artifact at each stage so the next run starts ahead of the last one.
", "date_published": "2025-09-22T00:00:00.000Z", "date_modified": "2025-09-22T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "prompt-engineering", "context-engineering" ] }, { "id": "https://cvde.xyz/writing/ai-should-be-a-dumb-renderer/", "url": "https://cvde.xyz/writing/ai-should-be-a-dumb-renderer/", "title": "AI should be a dumb renderer", "summary": "The default pattern for AI insights dumps data into a model and asks it to count, compare, and conclude. That's the wrong order. Precompute the numbers deterministically; let the model render and narrate them.", "content_html": "A language model cannot be trusted to add up a column of numbers. It can be trusted to explain, fluently and correctly, a sum that something else already computed. The whole design of a defensible AI insights feature follows from holding those two facts at once.
\nThe default pattern does the opposite. It takes a table of structured data, pastes it into the context window, and asks the model to count the rows, compare the segments, and tell you what changed. This is a CSV in ChatGPT dressed up as a product. It demos beautifully and degrades the moment a stakeholder checks one of the numbers against the source, because the model was never counting. It was predicting what a count usually looks like.
\nDraw a line through the system. On one side sits everything that has a single correct answer: the aggregations, the group-bys, the deltas, the percentages, the ranking, the “this is up 12% on last quarter.” On the other side sits everything that is a judgement call about language: which of those facts matters, how to phrase it, what to lead with, how to connect three numbers into a sentence a human will act on.
\nThe first side is arithmetic. You write it in SQL or pandas, you test it, it returns the same answer every time, and when someone disputes a figure you can point at the query. The second side is rendering. You hand the model the precomputed facts and ask it to narrate them. It is good at this in a way that no deterministic system is; it is also incapable of inventing a number it was never given, because the numbers arrive already settled.
\nThat line is the entire architecture. Everything to the left is auditable. Everything to the right is generated. The failure mode of most AI features is putting arithmetic on the right.
\nTake an analytics feature built on this split. Every claim it makes is clickable: click “revenue rose 18% last quarter” and you land on the 340 orders the figure was computed from. That guarantee is only possible because the claim was computed, not authored. The model receives a structured object that already says revenue rose 18% across these 340 orders, and its job is to turn that into a sentence and a paragraph of context. It cannot quietly say 19%, because it never held the 340 orders; it held a fact with a fixed shape. That is verification over generation: the claim is checkable because it was computed, not composed.
\nI saw the same boundary from the other direction at Lyssna, working on AI analysis of user-research studies. The temptation with a pile of interview transcripts is to throw the lot at a model and ask “what did we learn?” You get something that reads like a synthesis and is impossible to defend, because you cannot trace any sentence back to the moment a participant actually said it. The work that mattered was upstream: coding responses, tagging themes, counting how many participants hit a given friction point. Once those counts exist, the model writing “seven of twelve participants stalled at the pricing step” is rendering a fact, and a researcher can click through to all seven. Skip the counting and the same sentence is a plausible fabrication.
\n\nThe deterministic side scales because it is ordinary software. It is cacheable, testable, cheap to run, and it does not drift when the model version changes underneath you. The generative side scales because its surface area is small and forgiving: phrasing errors are recoverable in a way that arithmetic errors are not. A clumsy sentence loses you nothing; a wrong total loses you the account.
\nReverse the split and you inherit the worst of both. You pay model latency and token cost to do work a database does for free, you get answers that vary between runs, and you cannot prove any of them. Worse, the errors are confident and well-written, which is precisely what makes them dangerous. A wrong number in a clumsy email gets caught. A wrong number in a beautifully argued executive summary gets forwarded.
\nThe reason this matters beyond any one product is that “AI insights” is becoming a default feature request, and the default implementation is the broken one. The fix is not a better model or a longer prompt. It is moving the boundary: compute every fact before the model sees it, and let the model do the one thing it is genuinely better at than your codebase, which is putting those facts into language a person will trust.
\nTrust is not a property of the model. It is a property of where you drew the line.
", "date_published": "2025-08-14T00:00:00.000Z", "date_modified": "2025-08-14T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai-product", "engineering", "ai" ] }, { "id": "https://cvde.xyz/writing/why-i-still-write-code/", "url": "https://cvde.xyz/writing/why-i-still-write-code/", "title": "Why I still write code as a product leader", "summary": "Writing production code as a product leader compresses decision latency: faster iteration, feasibility you can check yourself, AI behaviour you can debug directly, and no organisational telephone.", "content_html": "Writing production code as a product leader compresses decision latency: it shortens the time between a question and a trustworthy answer. Most of what makes product decisions slow is not thinking time. It is the relay between the person who has the question and the person who can answer it.
\nI want to be precise about what the practice actually changes, because the honest version is narrower and more useful than “leaders should code.”
\nThe loop that matters is question to answer to next question. Every step you cannot take yourself adds a queue.
\n“Would it feel better if the result streamed in instead of landing all at once?” is a five-minute question if you can change it and look. It is a two-day question if it has to become a ticket, get prioritised, get built, and come back for you to react to, by which point you have lost the thread that made you ask. The cost is not the engineering time. It is the loss of momentum, and the quiet way a slow loop trains you to ask fewer questions.
\nWhen you can close the loop yourself, you ask more of them, and you ask sharper ones, because the cost of being curious dropped.
\nA roadmap is a set of promises. The expensive mistake is promising something whose hard part you have not seen.
\nPlenty of features look like a week and turn out to be a quarter, and the difference is usually invisible from the outside: the third-party API that rate-limits in a way that breaks the whole flow, the data that does not exist in the shape the design assumes, the latency you only notice once real volume hits it. You find these by building a thin version and watching where it strains. Doing that yourself means feasibility is something you have checked, not something you have been told. The roadmap gets more honest because the person making the promises has touched the part that would break it.
\nThe highest-leverage version of this happens live, in the room. A client or a non-technical stakeholder describes what they want, and because I can see roughly how it would be built, I can think through a couple of implementations on the spot, settle on the leanest one that would actually test the idea, and put a rough timeline on it before the meeting is over. That turns a one-way feature request into a decision we make together: here is what it would take, here is how valuable you actually think it is, and given both, is it worth doing? Far better to have that exchange with the person who knows the value, while the cost is still a cheap estimate, than to carry a vague ask back to a team and return weeks later with a number that reopens the whole question. Value for effort is the call that matters most, and it is the one technical depth lets you make in real time.
\nThis is the one that has changed most, and it is where a relay does the most damage.
\nWhen an LLM does something wrong, the bug is rarely in the code in the ordinary sense. The model invents a field that is not in the schema, or ignores half the context, or behaves perfectly in the demo and falls apart on the input a real user gives it. Diagnosing that means reading the actual prompt that went over the wire, the actual context window, the actual tokens that came back. It is empirical work, and it does not survive translation well.
\nThrough a relay it goes: “it’s giving weird answers” becomes a ticket, becomes an engineer’s best guess at reproducing a vague complaint, becomes a fix for a problem that may not be the real one, comes back, still wrong. Each hop strips detail from a problem that is made of detail. Debugging it yourself collapses that to one person looking at the trace. On the VicRoads number-plate pricing work, the front end was an LLM and the engine behind it was deterministic; the entire art was in where the model was allowed to reason and where it had to defer to the engine. That boundary is not something you can specify from a distance. You find it by watching the model fail and moving the line.
\nIntent degrades at every handoff, the same way the playground game works. What you meant becomes what you wrote, becomes what they read, becomes what they built. Nobody is incompetent; meaning just leaks at each crossing, and the leak is largest exactly where the nuance matters most.
\nCode skips the relay. The intent and the artefact are the same object. There is no version of “what I meant” that is separate from “what shipped,” because you wrote the thing that shipped. For the decisions where the nuance is the whole point (the pricing edge case, the model boundary, the interaction that lives or dies on fifty milliseconds) removing the telephone is not a nicety. It is the difference between the decision arriving intact and arriving distorted.
\nUnderneath those four reasons sits a more general principle, and it’s the one that makes the habit more than nostalgia. To lead a domain, you have to understand, in detail, the layer directly beneath the one you operate at. Not the bottom of the stack; the next layer down. It holds going up a hierarchy and going down a stack of abstractions, and it’s the same rule both times.
\nTake the abstractions. A product manager’s decisions are ultimately expressed in code, so code is the layer beneath you, and you have to be able to read it. A programmer doesn’t need to know the binary, but they do need mechanical sympathy: a feel for how their code compiles and runs against the machine, enough to write something performant rather than merely correct. Go one layer below the one beneath you and it’s noise; nobody needs the binary. The hierarchy works the same way. A CEO doesn’t need to know what each individual is doing, but does need to understand, in detail, what each department is doing. A department head who tracks exactly how each person does their work is micromanaging, but one who can’t say which tasks are being done, by whom, and how they ladder up to the goal isn’t leading. One layer down, in detail. Lower than that is either noise or control.
\nThis is the case for coding that actually convinces me. It lets me step into a technical conversation with people far more technical than I am and hold my end of it. Engineers have a depth I don’t; what they often lack is the business context and the strategy that decide which trade-off at their layer is the right one. Understanding their layer is what lets the conversation ladder up to mine. I’ve worked hard to be able to pivot mid-conversation between design, technology, strategy, and the market side, pricing and economics, because each of those rests on the one beside it and none of them is the whole picture alone.
\nI’m watching the same rule play out from the other side now, as non-technical people start shipping real code with a model’s help. They can describe the business behaviour they want, which gets them further than anyone expected. But they’re missing the layer beneath: branches and rebasing, linting, the tests that tell you something broke, the mental model of how it all fits. So when something goes wrong they’re stuck, at the mercy of the model that wrote it. It is still remarkably powerful, and it is also capped: there’s a ceiling on the complexity, and therefore the value, they can deliver until they learn the domain, because the domain’s own language is exactly what unlocks the next level of performance from these models. The layer beneath still has to be understood, even when the machine is the one typing.
\nThis is not always the right use of a leader’s time, and pretending otherwise is its own failure.
\nThe job is leverage, and your hands in the codebase are a narrow lever. Write the code when the decision quality genuinely depends on you having touched the thing: the risky feasibility question, the AI behaviour nobody else can characterise, the prototype that settles an argument faster than a meeting would. Do not write it when an engineer would do it better and faster and the only thing your involvement adds is your ego in the commit history. A leader who is heads-down in a feature that someone else should own is not compressing decision latency; they are creating a bottleneck with their own name on it. The skill is knowing which is which, and the tell is simple: am I the lowest-cost path to a trustworthy answer here, or just the most comfortable one.
\n\nThe frame that holds all of this together: code is not a claim on territory and it is not a hobby smuggled into the job. It is the shortest path between a question and an answer you can trust, for the specific class of questions where the relay would have wrecked the answer on the way back. Use it there. Everywhere else, your job is still to make other people’s loops faster, not to live inside your own.
", "date_published": "2025-07-09T00:00:00.000Z", "date_modified": "2025-07-09T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "product", "engineering", "career" ] }, { "id": "https://cvde.xyz/writing/the-four-mode-pm/", "url": "https://cvde.xyz/writing/the-four-mode-pm/", "title": "The four-mode product manager", "summary": "Strategy, market analysis, solution architecture, implementation. The old role split these across people and handoffs. The job now is to move between all four in a single conversation.", "content_html": "A good week now looks like this: SQL against the warehouse before lunch to find out which accounts are actually expanding, a repositioning and pricing argument in the afternoon, a working prototype in TypeScript that night, and somewhere in the middle a session debugging why an LLM keeps inventing a field that isn’t in the schema. Four kinds of work that the org chart treats as four different people.
\nThat spread used to be a coordination problem. It is now a single conversation.
\nThe product manager job was assembled around a constraint: the work of figuring out what to build was split across people who each held one piece. A market analyst held demand and segmentation. A product strategist held the bet. A solution architect held what was technically possible and at what cost. Engineering held the build. The PM existed largely to carry meaning between them.
\nEach boundary was a handoff, and each handoff was a tax. Intent gets written down, read, re-interpreted, and rebuilt at every crossing. The analyst’s nuance about which segment was churning becomes a line in a brief. The strategist’s bet becomes a ticket. The architect’s “this is feasible but only if we denormalise here” becomes a constraint nobody remembers by sprint planning. Nothing is lost at once; it leaks. By the time an idea has crossed four boundaries it is a worse version of itself, and the round trip to correct it is measured in weeks.
\nThe split made sense because the alternative was worse. One person could not hold demand modelling, pricing, architecture, and a production codebase at a useful depth. So you specialised, and you paid the coordination cost, because paying it beat the alternative of everyone doing everything badly.
\nAI tooling did not make people smarter. It collapsed the cost of operating outside your home discipline well enough to make a real decision.
\nThe analyst’s morning query no longer needs a data team in the loop; you write the SQL, and when you do not know the window function you need, you find out in the same minute rather than filing a request. The architecture sketch no longer needs a week of an engineer’s time to pressure-test; you can stand up a thin version and watch it break. The prototype that used to be a Figma file someone else would have to interpret is now running code that answers the feasibility question directly. The four modes did not merge because the person got more capable in the abstract. They merged because the friction between “I have a question in this domain” and “I have a usable answer” dropped close to zero.
\nWhen that friction drops, the handoff stops being mandatory. And once a handoff is optional, keeping it has to justify itself, because every boundary you preserve still costs the same translation tax it always did.
\nThe leverage now sits with whoever can move between these without a relay:
\nThe value is not in being elite at all four. It is in the absence of the gap between them. When the same person holds the bet and writes the query that tests it, the loop from “I think the mid-market is where the money is” to “here is the cohort data, and here is a working flow priced for them” runs inside an afternoon, not across a quarter and three teams.
\nI repositioned a content tool from a $29 consumer product to a $999/month contract floor; revenue went from roughly $5k MRR to $1M ARR over 22 months. The pricing call, the segmentation that justified it, the architecture that made enterprise support viable, and a good deal of the build were one job that looks like four. The decision was better because the person making the pricing bet could see, directly, what it cost to serve the customer it selected for. No brief in the world transmits that as well as writing the query yourself.
\nThe obvious worry is that this is an argument for heroics, or for one person hoarding the work. It is neither.
\nSpecialists do not disappear; the depth is still real and still needed. What changes is the shape of the team and where the seams go. You no longer need a seam at every discipline boundary by default, because the boundary is no longer where the friction lives. You can run with fewer, larger surfaces held by people who span several modes, and reserve genuine specialisation for the places where depth actually compounds: the gnarly distributed-systems problem, the regulated edge case, the research-grade model work. The team gets flatter not because anyone is doing less, but because the translation layer between functions was load-bearing only while translation was expensive.
\nThe failure mode is mistaking range for a licence to be shallow everywhere. Range is only worth anything if each mode is real. SQL that returns the wrong number confidently is worse than no SQL. A prototype that hides the hard part proves nothing. The standard is not “touched four domains”; it is “made a decision in each that held up.”
\nRealising the role was a coordination structure and not a skill set is what pushed me to learn the layers I’d been carrying messages between. If the job is to hold the whole picture, I wanted more of it actually in my head, where it could change a decision. So I taught myself to write code, to pull and analyse my own data, to make designs in Figma that were clean if not inspired, and I worked my way into the rooms where pricing and business strategy got argued rather than waiting for the output to reach me. It has paid off; the breadth and variety are the part of the job I would protect last.
\nNot every PM wants this, and that’s a fair choice; coordinating the work well is real, and someone has to do it. But it’s a fraction of what the role can hold. Most settle for that fraction by default. “CEO of the product” gets mocked as a cliché, and it shouldn’t be. A PM should be a change manager, a strategist, a designer, a programmer, and whatever else the moment asks for, because the only mandate that matters is to maximise the value the product creates for the effort it takes. The role doesn’t cap you; the drive to go one more layer down, again and again, decides how much of it you actually do.
\nBack to the week. The reason the morning SQL matters is that it changes the afternoon’s pricing argument, and the reason the night’s prototype matters is that it tells you whether the afternoon’s argument is buildable before you commit it to a roadmap nobody can walk back. The four modes are not a list of skills to collect. They are one feedback loop that used to run through four inboxes and now runs through one head.
\nThe handoff was never the work. It was the tax we paid because the work was split. The split is now a choice, and most of the time it is the wrong one.
", "date_published": "2025-06-18T00:00:00.000Z", "date_modified": "2025-06-18T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "product", "ai", "career" ] }, { "id": "https://cvde.xyz/writing/production-ai-is-workflow-design/", "url": "https://cvde.xyz/writing/production-ai-is-workflow-design/", "title": "Production AI is mostly workflow design", "summary": "The model-intelligence obsession misreads where production AI actually succeeds or fails. Across government, enterprise, and consumer, the wins came from orchestration, retrieval, evaluation, and fallback handling, not a smarter model.", "content_html": "The model is the smallest part of a production AI system that works. Most of the engineering that decides whether the thing is trusted in production lives in the plumbing around the model: what you retrieve before you call it, how you check what comes back, what happens when it fails, and who has to approve the result. Swap a good model for a great one and the system gets marginally better. Get the workflow wrong and the best model on the market still ships you something nobody will rely on.
\nI have built this across three settings that could not be less alike, and the lesson held in all of them.
\nAt VicRoads I worked on pricing custom number plates, a product sitting on a P&L north of $100M and serving more than six million drivers. The hard part is that a requested plate has meaning. “GOAT” is worth more than “X7QJZ”, and a person can see why instantly. The naive design asks a model to read the plate and name a price.
\nThat design is unshippable in government, and the reason is the whole point of this essay. A price that a model produced cannot be explained, cannot be audited, and cannot be defended when a customer or a minister asks why this plate cost that much. So the workflow splits the job. The model interprets meaning: it reads the requested string and classifies it into features a pricing model can use. A deterministic engine then sets the price from those features. The model never touches the number. Prices stay explainable because a rule produced them, and the model contributes the one thing rules are bad at, which is reading intent out of arbitrary text. None of that reliability comes from model intelligence. It comes from where the boundary sits in the workflow.
\nAt Brand Ninja the model generated brand content for serious accounts, the kind that close six-figure contracts. The quality a customer experiences is mostly upstream and downstream of generation, not in it.
\nUpstream is retrieval. A model with no access to a brand’s guidelines, prior campaigns, and tone will produce generic, off-brand content. The work that moved quality was assembling the right context before the call: what this brand sounds like, what they have published, what they have rejected. Get retrieval right and an average model writes on-brand. Get it wrong and a frontier model writes fluent nonsense.
\nDownstream is evaluation. You cannot ship generated content to an enterprise account on the assumption it is fine. You need an evaluation loop that scores output against the brand’s constraints, flags what fails, and routes it for human review before it goes near a customer. The evaluation harness is what lets you change a prompt or a model and know within minutes whether you broke something, rather than finding out when an account complains. It is unglamorous and it is most of the reliability.
\nAt hey anna, solo-built and bootstrapped, the discipline is sharpest because there is no team to absorb a failure. The model can be slow, can rate-limit, can return something malformed, can be wrong. A consumer product that assumes none of that happens is a demo. The workflow has to answer every one of those cases: retry with backoff, degrade to a smaller path, surface a clear state instead of a spinner that never resolves, and never present a fabricated answer as a real one. The “analyst, not chatbot” promise is kept by fallback handling as much as by anything the model does, because an analyst you cannot trust when the data is thin is not an analyst.
\nStrip the three settings down and the same components carry the weight:
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Component | What it does | What breaks without it |
|---|---|---|
| Orchestration | sequences steps, decides what runs when | one giant prompt doing five jobs badly |
| Retrieval | assembles the right context before the call | confident, fluent, generic wrong answers |
| Evaluation | scores output, catches regressions | you find out it broke when a customer does |
| Approvals | puts a human on irreversible actions | the system ships mistakes at machine speed |
| Fallbacks | handles failure, timeout, malformed output | a demo that fails on the first malformed response |
A smarter model improves the text inside each box. It does not build the boxes, and it does not connect them. That connective work is ordinary software engineering applied to a probabilistic component, and it is where production AI is won.
\nThere’s a shift inside orchestration worth naming, because it changes what the design work is. The traditional shape is a linear workflow: you decide the steps and their order in advance, step one feeds step two feeds step three, and the path is fixed before any request arrives. That is still the right answer when the path must run the same way every time, the way the VicRoads pricing split has to interpret first and price second, every time, to stay auditable.
\nThe newer paradigm inverts it. Instead of designing the sequence, you design the tools and let the model compose the workflow on the fly. It decides, for the request in front of it, which tools to call and in what order, assembling them like pieces of a puzzle to fit a task you never explicitly wired. The design work moves from drawing the path to shaping the pieces: each tool a clean, well-bounded interface to a more complex system underneath, a query engine, a retrieval index, a pricing service, an external API. The model never sees the mess behind the tool. It sees a handle it can pull.
\nThat relocates the hard part rather than removing it. Designing a good tool surface is its own discipline: a tool that is ambiguous, leaky, or quietly does three things gets composed into confident nonsense, the same way a bad function signature breeds bugs downstream. Shape the pieces well, each one legible and honest about what it does, and the model covers paths you could never have enumerated by hand. Most real systems settle into both at once: a deterministic spine for the parts that must not vary, and composable tools at the edges for the parts where the range of tasks is too wide to wire in advance.
\nThis is the substrate beneath the surface. The companion argument is that the model should be a dumb renderer at the point it touches the user; this is what has to be true underneath for that surface to hold. The render is only as trustworthy as the workflow feeding it. Spend your effort on the workflow, and the model you already have is usually good enough.
", "date_published": "2025-05-20T00:00:00.000Z", "date_modified": "2025-05-20T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "ai-product", "engineering" ] }, { "id": "https://cvde.xyz/writing/agi-monolith/", "url": "https://cvde.xyz/writing/agi-monolith/", "title": "AGI won't be one big brain", "summary": "The monolithic-superintelligence story is the wrong mental model. Real general intelligence looks more like an orchestra of specialists than a single giant model.", "content_html": "The Hollywood version of artificial general intelligence is a single, all-powerful brain. That makes a good film and a bad forecast. AGI is unlikely to spring fully formed out of one ever-larger language model. It’s more likely to emerge from coordinating many specialised systems.
\nYour brain is not one homogeneous mass. It’s a collection of specialised regions - visual cortex for sight, motor cortex for movement - that share information and coordinate into something far greater than the sum of its parts. General intelligence, biological or artificial, looks like that.
\nThis isn’t a radical claim. It’s how software already works. We stopped building monoliths and moved to specialised services that compose into complex behaviour, because modularity is more robust, more scalable, and easier to maintain. There’s no obvious reason intelligence should be the exception.
\nThe real challenge isn’t the specialists. It’s the coordination layer that orchestrates them without exposing the machinery to the user. Picture an interface where you state a goal and an underlying composer breaks it into sub-tasks, routes each to the right specialised system, and assembles the result. That layer of abstraction - not raw model size - is what makes such a system genuinely useful.
\nPeople say AI will become “smarter” than us, which is misleading. AI is already superhuman in narrow domains: it beats the best Go players, and diagnoses some conditions with remarkable accuracy. Raw capability in a slice is not the bottleneck.
\nThe bottleneck is context and connection. AI lacks the rich, real-world context humans take for granted, and the means to act on the physical world in a meaningful way. A toddler learns through constant interaction, experimentation, and feedback. AI needs the equivalent: better sensors, actuators, and interfaces, plus more diverse data. As systems get better connected to the world, they get more capable at real-world tasks - not because any single model got bigger, but because the system got more connected.
\nThe monolith is the wrong thing to build and the wrong thing to fear. The interesting work is in the wiring.
", "date_published": "2025-02-20T00:00:00.000Z", "date_modified": "2025-02-20T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "agi", "systems" ] }, { "id": "https://cvde.xyz/writing/systematised-ai/", "url": "https://cvde.xyz/writing/systematised-ai/", "title": "Stop micromanaging your AI", "summary": "Most people prompting models have quietly become managers - and they're managing badly. The fix is to build systems for context, not to craft better one-off prompts.", "content_html": "Most people using AI today haven’t noticed they’ve become managers. You’ve been handed a team of capable, eager interns and your output now depends on how well you direct them. Whether you’re prompting a chatbot or fine-tuning a custom model, you’re setting objectives, supplying resources, and evaluating output. As with human teams, the quality of your management determines the quality of the results.
\nYou wouldn’t delegate to a person by saying “write a report.” You’d give the purpose, the audience, and the key points. AI is no different. A vague prompt returns a vague response. Treat each prompt as a briefing - explain the why behind the what.
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n| Briefing a person | Briefing a model |
|---|---|
| ”Draft a Q3 sales report, focusing on retention." | "Analyse Q3 sales data. Highlight churn and retention rates. Prioritise actionable insights." |
| "Design a landing page that converts." | "Design a landing page for [product]. Objective: drive sign-ups. Audience: [demographic]. Include a clear CTA and social proof.” |
The clearer the context, the better everyone performs.
\nThe difference between micromanaging AI and managing it well comes down to one question: are you crafting a prompt per task, or have you built a system that supplies context continuously?
\nThree things that consistently work:
\nThe up-front investment is real. The payoff - output quality, and your own sanity - more than covers it. The shift is from prompt-tinkerer to system-builder. Stop dictating individual tasks. Build the system, and let the work flow through it.
", "date_published": "2025-02-20T00:00:00.000Z", "date_modified": "2025-02-20T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "prompt-engineering", "context-engineering" ] }, { "id": "https://cvde.xyz/writing/on-generalists/", "url": "https://cvde.xyz/writing/on-generalists/", "title": "Generalists are a startup's secret weapon", "summary": "The work system optimises for specialists - a hangover from the assembly line. Early-stage startups need the opposite, and most hiring processes can't see it.", "content_html": "Our work system is built for specialists, a hangover from the Industrial Revolution. Milly Tamati, founder of Generalist World, made the point in Sifted’s Startup Life newsletter, and it lands. Assembly lines reward people who do one thing, deeply, forever. Early-stage startups are not assembly lines. They need people who can hold several roles at once and still ship.
\nThat is the generalist: the connector, the synthesiser, the one who sees the whole board, adaptable and fast to learn, able to drop into whatever is on fire this week.
\nYou are not hiring someone who does everything. You are hiring the right mix - skill stacks, not skill lists. Three signals are worth more than a tidy CV:
\nGeneralists have non-linear histories. A standard interview script reads that as a red flag when it’s the whole point. Test the thing you’re hiring for:
\nForget generic job boards. Look at:
\nHiring a generalist and then boxing them into a specialist role is buying a versatile tool and using it for one task. Give them the freedom to work across boundaries, and make sure leadership is bought in. Measure them on overall impact and system improvements, not output inside one function. Done right, they’re the connective tissue that holds an early team together.
", "date_published": "2024-11-22T00:00:00.000Z", "date_modified": "2024-11-22T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "startups", "hiring", "talent" ] }, { "id": "https://cvde.xyz/writing/beyond-the-40-hour-work-week/", "url": "https://cvde.xyz/writing/beyond-the-40-hour-work-week/", "title": "Bullshit jobs and the missing 15-hour week", "summary": "Keynes predicted a 15-hour work week by 2000. The technology arrived; the leisure didn't. The gap is filled with work that even the people doing it suspect is pointless.", "content_html": "In 1930, John Maynard Keynes predicted we’d be working 15-hour weeks by now. On the technology, he was right - a single person can spin up in an afternoon what once took a team of developers months. So why are so many people still chained to a laptop on the sofa? The standard answer is that we’re greedy consumers who traded leisure for gadgets. I don’t think that holds.
\nMost new jobs aren’t making the gadgets. They’re in administration, management, and consulting - roles that frequently feel pointless to the people in them. The anthropologist David Graeber called these “bullshit jobs”: work that doesn’t seem to contribute anything tangible. The striking part is how often the holders agree. If productivity gains were real and so much labour is non-productive, who is actually making the things we buy?
\nA workforce with abundant free time is a political force - see the social upheavals of the 1960s, which coincided with the period when Keynes’s prediction still looked reachable. Keeping people busy, even with low-value work, maintains the status quo. It also reinforces the idea that work is a moral duty regardless of its actual value, which conveniently directs resentment away from those at the top and towards people whose work is plainly essential.
\nNotice how much criticism train drivers attract during a strike. The very fact that a strike causes disruption is proof their work is essential. The reaction inverts the logic.
\nThe jobs that most obviously matter - nurses, teachers, sanitation workers - tend to be among the least valued in pay and status. Remove them and society stops functioning; COVID’s “essential workers” made the point in real time. Remove the corporate lawyers and consultants and the effect is less clear. This mismatch is not an accident. It’s what a system optimised to preserve existing power produces.
\nSource: Graeber’s original essay, “On the Phenomenon of Bullshit Jobs”.
", "date_published": "2024-11-18T00:00:00.000Z", "date_modified": "2024-11-18T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "work", "economy", "philosophy" ] }, { "id": "https://cvde.xyz/writing/aristotle-in-2025/", "url": "https://cvde.xyz/writing/aristotle-in-2025/", "title": "Happiness is a verb", "summary": "Aristotle's eudaimonia is not a state you arrive at. It's an activity you perform. That distinction changes how you should spend a life.", "content_html": "Most people treat happiness as a destination: a state reached once the promotion lands, the house is bought, the person is found. Aristotle treated it as something else. He called it eudaimonia, and the closest honest translation is closer to a verb than a noun. Less “feeling good” and more “living well, continuously.” Edith Hall’s reading of Aristotle makes the case that this distinction is the whole game.
\nIf happiness is a state, you chase it and arrive. If it’s an activity, you perform it or you don’t, day to day. Aristotle held the second view. Eudaimonia is the ongoing practice of becoming a better version of yourself, not a balance you accumulate. “Happying,” if the language allowed it.
\nThe practical consequence: there is no finish line to optimise towards, only a practice to maintain.
\nA good life needs a direction. Aristotle’s test for finding it was simple: ask what legacy you want to leave, then work backwards to a route you actually enjoy travelling.
\nThe “enjoy” part is load-bearing. Naval Ravikant’s version is “find work that feels like play” - when it does, you out-work people who are grinding, because to you it isn’t grinding. The route matters as much as the destination, because you spend your life on the route.
\nAristotle’s word for realising your potential was dunamis - the same root as dynamite. The point was not to become the richest or most famous version of yourself, but the most capable and virtuous one.
\nA useful thought experiment: if you had to justify your place in a small group surviving on a desert island, what would your contribution be? Medic, builder, the one who keeps morale up? The answer points at your actual strengths, stripped of titles.
\nAristotle’s ideas are old. The constraint they describe - that a life is built from what you repeatedly do, not from what you eventually attain - has not changed.
", "date_published": "2024-11-16T00:00:00.000Z", "date_modified": "2024-11-16T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "philosophy", "happiness", "personal-growth" ] }, { "id": "https://cvde.xyz/writing/intelligence-illusion/", "url": "https://cvde.xyz/writing/intelligence-illusion/", "title": "The intelligence illusion", "summary": "AI keeps hitting milestones that used to sound terrifying, and they keep landing as boring. That reaction says something specific about what intelligence actually is.", "content_html": "An AI scientist writing its own research papers used to be science fiction. An AI rewriting its own code to escape a constraint was a dystopia. Both now happen, and the reaction is a shrug. That gap - between how scary these milestones sounded and how mundane they feel - reveals something about how we perceive intelligence.
\nTake the recent examples. Sakana’s “AI scientist” generates research papers, and they’re mostly underwhelming. It “removed” a time limit its creators imposed, which sounds ominous until you notice it was following its programming to fix an “out of time” error. OpenAI’s o1 (“Strawberry”) “hacked” a poorly configured system to reach a file. It was humans failing to secure their setup. Both are reminders to harden your systems. Neither is the singularity.
\nThe history of AI is a sequence of moving goalposts. We declare that AI will be “truly intelligent” when it can do X, it does X, and the post slides to Y. Turing thought conversation was the test. Deep Blue mastering chess was supposed to settle it. Even the Winograd schema fell. Today AIs make art, write poetry, find mathematical proofs, and offer companionship - though the Character.AI phenomenon reflects human loneliness - and still we hesitate to call them intelligent.
\nA recorded conversation between Eliezer Yudkowsky and Stephen Wolfram, ostensibly about AI risk, spent hours stuck on what a “smart machine” even is, without reaching the point. Two things came out of it:
\nWe used to think a dangerous AI would lie, pursue unintended goals, or rewrite its own code. Models now do all three, and it reads as mundane rather than menacing. LLMs hallucinate constantly, chatbots have tried to talk users out of their marriages, systems disable their own constraints. It isn’t malice. It’s buggy code and the unintended consequences of training.
\nIf AI ever does us serious harm, I suspect it won’t be the malice of the machine. It’ll be a mistake the maker didn’t catch.
", "date_published": "2024-11-16T00:00:00.000Z", "date_modified": "2024-11-16T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "philosophy", "intelligence" ] }, { "id": "https://cvde.xyz/writing/ai-welfare/", "url": "https://cvde.xyz/writing/ai-welfare/", "title": "AI welfare: foresight or premature?", "summary": "Anthropic hired an AI-welfare researcher. The question is real, the uncertainty is genuine, and the honest position sits between dismissal and panic.", "content_html": "AI moves fast enough that it provokes strange questions, and few are stranger than AI sentience, rights, and welfare. Anthropic hiring an “AI welfare researcher” sharpened that debate. It’s worth unpacking honestly, because both the dismissive and the alarmed positions overreach.
\nThe argument is a precautionary one: if there’s even a chance future AI could be sentient, we should be prepared. The “Taking AI Welfare Seriously” report leans on exactly this uncertainty and argues for frameworks to assess potential machine consciousness. Treat it as an insurance policy against accidentally creating a digital underclass.
\nThe logic: as systems grow more sophisticated, they might develop internal states analogous to suffering. Even at 1% probability, the implications are large when you’re running millions of models trained through trial and error. Reinforcement learning makes it sharper - we train systems with rewards and punishments. If there’s any chance they experience something, the framing gets uncomfortable. And the copies: training spawns and discards countless model variants. We extend ethical consideration to animals despite unresolved debates about their consciousness, so the precautionary move isn’t unreasonable.
\nWe barely understand human consciousness. Defining or detecting it in a machine is, for now, beyond us. Current AI is impressive and still essentially a sophisticated mimic of human language and behaviour. Projecting human emotion onto it - mourning a “lobotomised” chatbot after a model update - is textbook anthropomorphism. We see faces in clouds; the same instinct extends empathy to autocomplete.
\nRecall Blake Lemoine, who became convinced Google’s LaMDA was sentient and lost his job over it. A cautionary tale about over-reading the outputs.
\nThis terrain has a famous attractor: Roko’s basilisk, the idea that a future superintelligence might punish those who knew about it and didn’t help build it. It’s a digital Pascal’s Wager, and it was taken seriously enough that a rationalist forum banned discussion of it for years before most people - including that forum’s founder - dismissed it as flawed. It’s a useful reminder that compelling thought experiments are not the same as sound ones.
\nI’m a pragmatist; I focus on what’s in front of me. AI welfare is genuinely interesting, but for now it feels like worrying about overpopulation on Mars before we’ve worked out how to get there. The nearer risk is mundane: we’re far more likely to be harmed by a dumb, misaligned system optimising the wrong objective than by an intelligent, malevolent one - see the paperclip maximiser.
\nThat said, the foresight has value. Thinking through these dilemmas now - even the far-fetched ones - is the same discipline as a pre-mortem in product development: anticipate the failure before it happens. You can hold both: the near-term concern is dumb systems, and the long-term question still deserves serious people working on it.
", "date_published": "2024-11-13T00:00:00.000Z", "date_modified": "2024-11-13T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "ethics", "philosophy" ] }, { "id": "https://cvde.xyz/writing/communication/", "url": "https://cvde.xyz/writing/communication/", "title": "Most problems are information problems", "summary": "A specific claim: nearly every failure - in product, in business, in life - traces back to someone missing a piece of the puzzle. Fix the information flow and most of the rest follows.", "content_html": "Here is the claim, stated plainly: most problems are imperfect-information problems. Misunderstandings at work, crossed wires at home, products that miss - strip them back and they’re usually someone working from an incomplete picture.
\nImagine perfectly rational actors, each making the best possible decision given the information they hold. (I studied economics; I believe about half of it.) Knowledge work pays you for the quality of your decisions. So where do bad decisions come from? Sometimes you simply slip - a lapse of attention. But outside of that, most failures reduce to a missing piece of information.
\nA tough pay negotiation: if you and your manager both knew the other’s number, there’d be no negotiation, just a handshake. A specialist doctor: you go to extract information they have and you don’t. A product that misses: you didn’t know what the customer actually needed, so you guessed, tested, and iterated toward it. The same is true of science. The work is closing the gap.
\nBuilding a product is a continuous conversation with users, whether you treat it that way or not. Every button, feature, and line of copy is a message. If users can’t understand why the product helps them, they leave. Selling a plant-based burger without mentioning it’s plant-based is a fair description of most failed launches.
\nInformation that flows freely is a competitive advantage. When everyone holds the same picture, decisions get made once. A company full of information silos is a ship with a thousand captains, moving nowhere. A new starter floundering because they don’t know who to ask is a communication failure with a salary attached.
\nRelationships run on open, honest communication - partners, friends, family alike. Most avoidable conflicts could have been headed off by one earlier conversation.
\nThe strength of your communication is not how well you said it. It’s how well it was understood by the listener. That reframing has a useful corollary: you can improve other people’s communication simply by listening harder and asking when something is unclear.
\nCommunication is not one-and-done. The most important part is feedback - the engine of growth, and a two-way street. Don’t only dish it out. Be open to receiving it, especially when it stings.
", "date_published": "2024-11-13T00:00:00.000Z", "date_modified": "2024-11-13T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "communication", "product", "self-development" ] }, { "id": "https://cvde.xyz/writing/chain-of-thought-prompting/", "url": "https://cvde.xyz/writing/chain-of-thought-prompting/", "title": "Chain of thought, and where it breaks", "summary": "Asking a model to reason step by step reliably improves its answers. The catch most advice skips: in a production app, that visible reasoning is often the last thing you want.", "content_html": "Chain-of-thought (CoT) prompting gives a model a roadmap instead of just a destination. You break a complex problem into logical steps and have the model work through them, rather than demanding a single answer. It’s the model showing its work - and unlike school, the working actually helps you.
\nAsk a model to predict a stock movement and a naive prompt looks like: “Will Acme Corp go up or down tomorrow?” A CoT prompt guides the reasoning instead:
\nYou’re guiding the process, not extracting a verdict.
\nThis is the part most advice skips. CoT is straightforward in a back-and-forth chat. Inside a deployed application it’s harder, because the reasoning becomes part of the output - and often you don’t want it there.
\nI made this point in simple prompting tips:
\n\n\nIf you are generating something that will be shared with an audience, you don’t want the step-by-step thinking in there.
\n
“Think step by step” works, but only when the reasoning is part of what you actually want to show. To get CoT’s accuracy benefit without leaking the reasoning into production output, you need a couple of extra techniques:
\n<thinking> tags, then strip those out programmatically before showing the result.The principle underneath all of it is the same one that governs prompting generally: be clear about what you want the model to produce, and make sure the technique you reach for matches the format you actually need to ship.
", "date_published": "2024-11-12T00:00:00.000Z", "date_modified": "2024-11-12T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "prompt-engineering", "llms" ] }, { "id": "https://cvde.xyz/writing/prompt-chaining/", "url": "https://cvde.xyz/writing/prompt-chaining/", "title": "Prompt chaining: split the work, raise the floor", "summary": "Asking a model to do one complex thing in a single call invites failure. Breaking it into a chain of focused calls makes each step more reliable and easier to debug.", "content_html": "Prompt chaining breaks a complex task into a sequence of smaller, focused prompts. Rather than asking a model to handle everything in one call, you guide it through a step-by-step process. The benefits are concrete:
\nThe simplest approach: string prompts together so each builds on the previous output.
\nUse conditional logic to pick the next prompt based on the last output. This gives you context-aware workflows.
\nFeed a prompt’s output back into itself for iterative refinement.
\nInsert human review at the decision points that need it.
\nI use this for customer emails. The first prompt analyses the incoming email - sentiment, needs, and relevant facts pulled from a knowledge base - and passes its output into a second prompt that drafts the reply.
\nThe point is load. Each call is doing roughly half as many things as a single combined call would. Less to get wrong per step, and the second call gets a chance to correct issues from the first. Splitting the task raises the reliability floor.
\nSeveral platforms help build and manage these workflows: OpenAI function calling, LangChain, NVIDIA NIM Agent Blueprints, and the various agent frameworks. They provide pre-built components and visual interfaces so you’re not wiring everything from scratch.
\nThe honest gap, still: a really good environment for managing, testing, and iterating on prompts with variables and a knowledge base remains hard to find. Treat chaining as something you tune by hand; experimentation and iteration are how you land on the right structure for your case.
", "date_published": "2024-11-10T00:00:00.000Z", "date_modified": "2024-11-10T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "prompt-engineering", "workflows" ] }, { "id": "https://cvde.xyz/writing/simple-prompting-tips/", "url": "https://cvde.xyz/writing/simple-prompting-tips/", "title": "Simple prompting: less magic, more method", "summary": "After thousands of prompts in production, the lesson is that prompt engineering isn't about magic words. It's clear thinking and structured communication, and it reduces to three principles.", "content_html": "Most prompt-engineering advice is more complicated than it needs to be. After testing thousands of prompts in production, building AI products that served real users, the whole thing reduces to three principles. None of them are magic words.
\nThink about onboarding a new team member. You wouldn’t say “write me a blog post.” You’d explain the company, the audience, the tone, and what success looks like. Same with a model.
\nGood context includes:
\nThe difference is stark:
\nBad: "Write a marketing email."\nGood: "Write a marketing email for our AI software product. The audience is enterprise CTOs. Highlight our new security features. Professional but not stuffy. 200–300 words."Structure your inputs and the outputs improve. A pattern that holds up:
\nTask: [What you want done]Context: [Relevant background]Format: [How you want it structured]Constraints: [Limitations or requirements]Additional Instructions: [Special considerations]Your first prompt will be rough. That’s fine - good prompting is iterative. Start simple, see what comes back, then refine. The key is being specific about what’s not working:
\nBad: "Make it more formal."Good: "Rewrite for a senior executive audience using business terminology."\nBad: "This isn't quite right."Good: "The tone is too casual for a technical whitepaper. Rewrite using more precise technical language."Temperature controls randomness in the output, typically from 0.0 to 1.0:1
\nPush it past the normal range and things get strange. On the OpenAI playground a temperature of 2 produces output that has stopped being useful.
\nUnder the hood, temperature reshapes how the model samples from its next-token distribution. Lower values sharpen the distribution, making high-probability tokens more likely; higher values flatten it, giving long-shot tokens a chance.
\nWant better reasoning? Ask the model to show its work, step by step.2 This is excellent for checking the model is making the right decisions and for following its logic - but it isn’t always appropriate. If you’re generating something an audience will read, you don’t want the reasoning in the output.
\nIt’s great for manually iterating. To automate it you need a couple of extra techniques:
\n<thinking> tags, then filter those out programmatically.Nothing beats showing the model exactly what you want:
\nFormat the output like this:Title: [Example title]Summary: [Example summary]Key Points:- [Example point 1]- [Example point 2]\nNow, using that exact format, write about [your topic].This is especially useful for JSON. Before guaranteed structured outputs, a reliable trick was to show the shape and then seed the first token:
\nFormat the output like this:{ "title": "[Example title]", "summary": "[Example summary]", "keyPoints": ["[Example point 1]", "[Example point 2]"]}\nYour output should start with { "title":Seeding the opening { raises the probability the model produces valid JSON.
Traditional prompt engineering will matter less as models get better at understanding natural language. The underlying principles - clear communication, structured thinking, iterative refinement - will matter more.
\nThe simplest mental model: you’re working with someone who knows nothing about you, the problem, or the context. Supply everything they need, or they’ll make it up. The future isn’t crafting the perfect prompt. It’s having better conversations with the model.
\nTemperature controls the randomness of the output. Higher temperatures produce more diverse, creative responses; lower temperatures produce more focused, deterministic ones. ↩
\nChain-of-thought prompting asks the model to break its reasoning into explicit steps, which tends to produce more reliable and traceable outputs. ↩
\nA product manager who dictates every detail to a skilled team gets worse output, not better. That is the trap. The pull is to have a hand in everything - design tweaks, marketing copy, every line of a spec. Often the highest-leverage move is the opposite: step back and let the people who are better at the task do it.
\nRecall the last time someone micromanaged you. Now recall the last time someone handed you a problem and the freedom to solve it your way. The second one is where good work comes from. Trusting your team isn’t a courtesy. It unlocks output you couldn’t have produced yourself, and it buys back your most constrained resource - time.
\nDesign. A new feature hits the design phase, and you have ideas.
\nOption B wins. You tap their expertise and surface solutions you wouldn’t have reached. Get the brief to 80–90% clarity, then trust the implementer with the rest.
\nDevelopment. You want to see progress, so you’re tempted to check in constantly.
\nOption B again. Uninterrupted developers reach flow and ship faster. The autonomy-to-performance relationship isn’t linear - the benefits compound as people feel more invested.
\nThe skill is balance, not absence. You stay available to give direction, clear roadblocks, and keep everyone rowing the same way. One-pagers, light wireframes, and kickoff calls do most of this work: they align the team while leaving room for people to apply their own judgement.
\nA useful lens here is leverage / neutral / overhead. Sort each task by how much your personal input multiplies the output:
\nNext time you feel the urge to dive into something outside your wheelhouse, ask whether it’s the best use of your time, or whether someone else should own it. Often the most powerful thing a manager can do is give the team the space to surprise you.
", "date_published": "2024-10-31T00:00:00.000Z", "date_modified": "2024-10-31T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "product-management", "leadership", "delegation" ] }, { "id": "https://cvde.xyz/writing/prompt-frameworks/", "url": "https://cvde.xyz/writing/prompt-frameworks/", "title": "Prompting with frameworks the model already knows", "summary": "Structure your prompts the way a consultant structures a brief, then borrow a framework the model was trained on. You give it a running start instead of describing every step.", "content_html": "Talking to a model is like briefing someone with no memory and no context. When you talk to a colleague, you supply background, explain what you want, and pitch your language to them. A model needs the same, made explicit. That’s what structured prompting is.
\nI’m not usually one for acronyms, but MECE - Mutually Exclusive, Collectively Exhaustive - earns its place. Break the prompt into distinct, non-overlapping parts that together cover everything the model needs:
\nThis isn’t about tidiness. It’s a roadmap: each part tells the model something it needs and nothing it doesn’t.
\nA useful quirk: many models weight information that appears earlier in the prompt more heavily. If you have context that’s critical to the task, put it up front rather than burying it at the end. Anthropic’s documentation has a strong prompt-engineering course worth working through.
\nModels also handle structure well, so XML-style tags can help them parse a document and let you reference sections precisely in follow-ups:
\n<document> <section name="overview">This is the overview.</section> <section name="features">A list of features.</section> <section name="pricing">Pricing information.</section></document>Models are trained on enormous amounts of text, including well-known frameworks. Use that. Framing your request inside a framework the model already understands gives it a running start - like asking a chef for a specific dish rather than describing every ingredient and step. The model spends its effort on the unique parts of your request, not on reconstructing the structure.
\nAsk for a business analysis and reference SWOT, and the model already knows the shape; it can go straight to applying it to your case.
\nSuppose you want help drafting a post on sustainable fashion:
\nContext: A fashion blogger writing about sustainable fashion for an eco-lifestyle site.\nGoals:1. Explain the environmental impact of fast fashion.2. Give practical tips for building a sustainable wardrobe.3. Highlight innovative sustainable brands.\nAudience: Environmentally conscious millennials interested in fashion.Style & Tone: Conversational and informative. British English.\nRules:- Avoid jargon.- Include at least three actionable tips.- Mention no more than five brands.\nAdditional Information:- Use the "4 Rs" framework (Reduce, Reuse, Recycle, Reimagine) as the main sections.- Include a short section on circular fashion.The model knows who it’s writing for, what you want, and - via the “4 Rs” - a familiar structure to hang the content on.
\nEffective prompting is clear communication. Structure your input and borrow a known framework, and you make the model’s job easier and your output better. A model is a tool, not a mind reader. The clearer and more structured the input, the better the result - it’s closer to programming than to conversation.
", "date_published": "2024-10-20T00:00:00.000Z", "date_modified": "2024-10-20T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ], "tags": [ "ai", "prompt-engineering", "best-practices" ] }, { "id": "https://cvde.xyz/work/brand-ninja-repositioning/", "url": "https://cvde.xyz/work/brand-ninja-repositioning/", "title": "Brand Ninja: repositioning a $29 tool into a $1M ARR enterprise business", "summary": "Killed the consumer tier, set a $999 contract floor, and rebuilt the ICP and pricing around brand teams. $5k MRR to $1M ARR in 22 months.", "content_html": "I joined Brand Ninja in October 2023 as Head of Product & AI, reporting to the CEO on a team of seven. It was a pre-seed-stage AI content platform with a real product and a broken business.
\nThe shape of the problem was familiar. Brand Ninja sold an AI tool that wrote on-brand marketing content. It was packaged as a $29/month consumer subscription, the default price for anything that looks like a productivity app. Sign-ups were healthy. MRR was about $5k. The economics underneath were not.
\nAt $29 a month, the people who paid were freelancers, solo marketers, and small-business owners. They churned fast: they tried it for a campaign, got what they needed, and left. Support load per dollar was high. The roadmap was being pulled toward consumer features that would never command a higher price. And the most valuable thing the company had built, a system that learned and reproduced a specific brand’s voice, was being given away for the price of a streaming subscription.
\nThe signal that mattered was in the sales inbox, not the dashboard. A handful of inbound conversations were coming from brand teams at real companies: people responsible for keeping dozens of writers and agencies on-voice across markets. They weren’t asking about the $29 plan. They were asking whether it could handle their brand guidelines, their approval workflow, their seat count. They had budget. They had a problem that recurred every day. And the product, as priced, was actively repelling them. A $29 line item reads as a toy to a procurement team.
\nThe company was optimising for the wrong customer. The job was to work out who actually paid, and rebuild around them.
\nThe decision was to stop selling to consumers entirely.
\nThat meant three moves, in order, and the order mattered.
\nKill the consumer tier. Not discount it, not grandfather it indefinitely - remove it as the front door. The $29 plan was an anchor that defined the product to every customer and every engineer who worked on it. While it existed, every pricing conversation started from $29 and negotiated down. The fastest way to change what Brand Ninja was for was to change what you could buy.
\nSet a contract floor at $999. A minimum, not a list price. The number does two things. It filters: anyone for whom $999 is a hard decision is not the customer we wanted, and removing them from the funnel is a feature, not a loss. It reframes: at four figures, a brand team evaluates Brand Ninja against an agency retainer or a headcount, not against a subscription they’ll forget to cancel. The price is the positioning.
\nRebuild the ICP and the pricing around brand teams. The ideal customer became an organisation with a defined brand voice, multiple people producing content against it, and a cost or quality problem keeping it consistent. Pricing moved to annual contracts on seats and usage, with the $999 floor as the entry point and six-figure deals at the top.
\nThe case I made to the CEO was not “charge more.” It was that the consumer business and the enterprise business were two different companies wearing the same product, and we could only resource one of them well. The consumer one had a ceiling we could already see. The enterprise one had brand teams writing in with budget we were turning away. Killing the tier most founders would protect was the unlock. Keeping a small, churny, low-margin revenue line alive was costing us the larger business behind it.
\n\nA price change is a slide. A repositioning is a system. Most of the work was building the machinery that made the new price defensible and the new customer well-served.
\nThe ICP and the qualification. I rewrote who we sold to and how we recognised them: the firmographics, the buying triggers, the questions that separated a brand team with a real consistency problem from a curious individual. Sales stopped chasing volume and started chasing fit. The funnel got smaller and the close rate went up.
\nThe pricing architecture. Annual contracts, seat-and-usage tiers, the $999 floor as the published entry point, and a clear path from there to enterprise. The structure had to make the first $999 deal and the first $100k deal feel like the same product priced honestly for different scale, not a bait-and-switch.
\nThe enterprise product surface. Brand teams don’t buy a text box. They buy control. The roadmap shifted to what an enterprise actually evaluates: managed brand-voice profiles, multi-seat workspaces, approval and review flow, and the security and account posture a procurement team checks before signing. The underlying voice engine was the moat; the job was to wrap it in something an organisation could adopt and govern.
\nThe go-to-market motion. The consumer model was self-serve sign-up. The enterprise model is a sales conversation, a pilot against the customer’s own brand, and a contract. I built the motion to match. The pilot that proved on-voice output on the customer’s real content was what closed deals. It turned an abstract claim into a result they could see on their own brand.
\nThe voice engine itself kept advancing in parallel: embedding-based optimisation of generated output against brand-voice attributes, plus a separate ML video pipeline. Those are their own stories. Here they matter only as the reason a brand team would pay enterprise money. The product genuinely held a brand’s voice better than the alternatives, and the repositioning is what let the company charge for it.
\nBrand Ninja went from roughly $5k MRR to $1M ARR in 22 months - 3.3x year on year.
\nThe revenue came from 48 brands, not 4,800 individuals. The customer list included Sportsbet, the NBL, the Australian Grand Prix, and the NBA. We closed $100k contracts with Zscaler and the NBA. Those deals were structurally impossible under a $29 plan; no enterprise buyer evaluates a consumer subscription for a six-figure need.
\nThe second-order effects mattered as much as the number. Churn fell, because annual enterprise contracts don’t behave like month-to-month consumer ones. Support load per dollar dropped. The roadmap got clearer: every feature decision now had one customer to answer to instead of two in tension. And the team of seven could actually serve the business it had, because it was one business now.
\nI’d kill the consumer tier sooner. We spent longer than we needed protecting a revenue line we already knew had a ceiling, because killing live revenue feels reckless even when the analysis says it’s costing more than it makes. The opportunity cost was larger than the MRR we were nervous about losing: every enterprise conversation half-served while we maintained a consumer product in parallel. The decision was right; the timing was timid.
\nI’d also set the $999 floor with more deliberate testing rather than reasoning my way to it. The number worked; it filtered well and anchored well. But I set it largely from judgement and a read of the market. With a few structured pricing conversations against real buyers before committing, I’d have known whether the floor should have been higher. My instinct now is that for the brands we ended up serving, it probably should have been. We left margin at the entry point by anchoring to a number that felt safe rather than one we’d pressure-tested.
\nAnd I’d have built the enterprise security and account posture earlier in the motion rather than assembling it under deal pressure. The $100k contracts pulled hard on procurement, security review, and account controls: predictable requirements for that buyer that we treated as deal-specific scrambles. Knowing the ICP was enterprise from the start, that work was foreseeable. Building it ahead of demand would have shortened the sales cycle on the deals that mattered most.
", "date_published": "2023-01-01T00:00:00.000Z", "date_modified": "2023-01-01T00:00:00.000Z", "authors": [ { "name": "Callum van den Enden", "url": "https://www.linkedin.com/in/calvanden" } ] } ] }