In part 1 I explained why there are so many different programming languages: because languages come with tradeoffs, and everyone wants to choose their tradeoffs differently. We discussed how memory and how it’s managed is one of if not the most important of those tradeoffs, and how when it comes to memory management you pretty much need to choose between your program being fast, or your program being safe.

The speed vs. safety thing was always around, but it was ultimately manageable. Slow safe programs were fast enough for most users, and fast unsafe languages could broadly keep up with the speed of attackers trying to exploit any memory-related vulnerabilities that snuck into production.

But the game hath changed. Today, increasingly lag-intolerant consumers rely on massive multiplayer games with millions of concurrent players, trading platforms where a millisecond of latency costs real money, and critical infrastructure that nation-states are actively and effectively hacking. Which begged the question (again): can we have a programming language that is both fast to write and safe from a memory perspective?

Rust is a programming language that says maybe you don’t have to choose.

It was created by a Mozilla engineer named Graydon Hoare, started as a personal project in 2006, got picked up by Mozilla as an official project in 2009, and hit its stable 1.0 release in 2015. It was built from scratch to be as fast as C and C++ while making an entire category of bugs impossible to write due to its unique approach to the memory problem.

To understand how Rust pulls this thing off, we need to go a little deeper on memory (again). What does it look like to write in a programming languages that do or don’t require you to manually work with memory?

First, the simpler one. In higher level languages like Python there is something called the garbage collector – a glamorous position if there ever was one. The garbage collector is a sort of “engine” that runs periodically in Python programs to help handle your memory for you. It scans your memory story and cleans it up. And much like a garbage truck if you’ve ever been stuck behind one while 10 minutes late for something important, it’s slow as hell because garbage collection is a computationally intensive task. Again, tradeoffs.

In a low level language like C, you must manually interact with the memory system, allocating data for each piece in your program. Before you can store a user’s birthday to display it to them in an app, you need to allocate a slot for it, and when you are done with the birthday, you need to release the memory. By allocating a slot, I mean literally telling the computer: hey, I need you to store this variable (an allocation), and it will require 8 bytes and data, and you should do it here in particular. And then Mr. Computer, when we are done with this variable, you should delete that data (a release). Like I said, computers both dumb and smart.

This manual process skirts around the garbage truck – which means it’s much faster while running – but it’s incredibly time consuming and error prone to write. If you miss an allocation or release anywhere in your code, it’s likely your program will crash or be vulnerable to hackers.

Like I said, for what seems like forever these were your two choices. Easy breezy but very slow garbage collection, or rigorous and fast but highly labor intensive (and vulnerable) manual memory allocation. Rust does a third thing.

What makes Rust, Rust

The entire point of Rust is to enable developers to write manually allocated code that’s safe. It’s all about avoiding the vulnerabilities and bugs that tend to happen when you have to manually allocate memory. Both ways, western man.

So Rust’s primary thing, the thing it will not stop talking about at parties, is that it approaches memory management differently. It aims to be fast, so runtime memory management (the garbage truck) like in Python is a no-go. But those damn lower level languages are so unsafe. I saw three of them go into the bathroom together!

Rust’s Raison d’être is the ownership system, which approaches our heralded tradeoff with a twist:

• You in fact do have to manage memory on your own. No garbage collection.

• BUT, instead of manual memory allocation being the Wild West, Rust gives you a helpful partner of sorts to do that with you.

Specifically, Rust elevates the role of the compiler from a simple translation machine to the world’s strongest and smartest bouncer. As you may recall, early computer scientists invented the compiler as the translation layer between human writable higher level languages and the 1s and 0s that the computer can actually run. The Rust compiler, however, does more than just translate.

Where older manually allocated memory languages like C allow whatever bugs you write to end up in the compiled program ready to leak data or get exploited, the Rust compiler has an extremely strict set of rules that code must adhere to before being compiled. You physically cannot ship the bug because the compiler won’t let you build a program that isn’t responsible in regards to memory.

“I don’t see how you can hate from outside of the club. You can’t even get in.”

- Chris Brown on his 2011 hit Look at me Now, and, the Rust compiler to improperly used memory

So you get the speed of C, because there’s no garbage collector running in the background, but you don’t get the myriad memory bugs that have plagued C and C++ codebases for decades. The amazing Rust compiler catches crashes from accessing memory you already freed, security holes from forgetting to clean something up, all of it, before a single user ever touches the code.

This fabulous compiler is not a silver bullet. The issue is that Rust, with all its rules and requirements, is hard to write. Despite this however, developers love Rust. It’s been the most loved programming language in Stack Overflow’s annual developer survey every year since 2016, and every year it seems like more and more of the world’s software is written, or rewritten in Rust.

The receipts: Rust in action

The fast, safe, and beloved language is finally getting its flowers in the form of massive grassroots community growth, adoption by hardcore and influential dev teams, and endorsement by standards organizations and governments.

For years, “Rewrite It in Rust” was a joke. Any time someone on the internet mentioned a performance problem, a security bug, or really any problem at all, a Rust evangelist would show up in the comments and suggest, with complete sincerity, that the solution was to rewrite it in Rust. It became a meme, then a term of light mockery for a certain type of engineer who had discovered a new favorite language and would not shut up about it. The Rust community even has a mascot, Ferris the Crab, and a habit of spamming the 🦀 emoji into threads where it is not needed or wanted.

But as the years scrolled by, the Rust-hater became the Rust-curious after Mozilla rewrote a major service in Rust and wrote a blog about it in 2017. The Rust-curious turned to Rust-fan after Dropbox called it a “force multiplier” for their core file syncing service, and little by little Rust has started eating the world, turning skeptics into believers, one codebase at a time.

• Discord rewrote the service that tracks who’s online and in which servers, switching from Go to Rust, and saw latency improvements so dramatic the periodic spikes that plagued the Go version disappeared entirely.

• Cloudflare rewrote a core piece of their network infrastructure and got 25% better performance at half the compute cost. Cloudflare sits in front of about 20% of all web traffic.

• Microsoft has been rewriting parts of Windows in Rust for years. The reason is that roughly 70% of the security vulnerabilities Microsoft has patched since 2006 trace back to memory safety issues.

• The Linux Kernel added Rust as a supported language in 2022 and researchers estimate it could eliminate around two-thirds of the security vulnerabilities in the components written in it.

• Hugging Face rewrote their tokenizer library in Rust, and it now processes a full gigabyte of text in under 20 seconds on a standard CPU, dramatically faster than the Python-based tokenizers it replaced.

But don’t take my word for it, take Uncle Sam’s. The federal government published a report in 2024 recommending that the software industry move away from C and C++ toward memory-safe languages, naming Rust specifically. The NSA and CISA have issued similar guidance. When the feds start weighing in on what programming language you should use, the meme phase is probably over.

The trolls who mocked rust and spammed the meme were right that you probably shouldn’t undertake a full rust rewrite to change the color of a button, but wrong about most of the rest. Rust didn’t come with a flashy million-dollar marketing campaign; it came with pudding… in which there was proof that if your users want snappy, secure software (and they do) Rust can help make that happen.

Lets try this again

I think now we’re ready for that definition of Rust.

Rust is a statically-typed, compiled programming language that enforces memory safety through compile-time ownership semantics without requiring a garbage collector.

If you ask me, Rust adoption will continue to rise for its killer performance, tight memory safety, and growing presence in systems-level infrastructure, but also due to the rise of LLM-generated code. The fact that Rust is hard to write was a significant barrier to entry when actual humans were coding. But LLMs don’t feel that friction the same way; they can bang out thousands of lines of Rust no problem, which effectively lowers the cost of choosing it. And there seems to be a calcifying effect around language choices, with LLMs knowing the most about the languages that already have the most code written in them. Rust has a large, high-quality open source footprint, which means models are well-trained on it.

There will likely be downstream consequences when it comes to maintaining the inevitable deluge of rust-slop given how steep the human rust-learning curve is, but in any case, we see no signs of slowing Rust’s massive growth in popularity.

An AI model on its own can only talk.

A harness is the software wrapped around it that lets it actually do things: touch your files, run your tools, and remember what happened.

• An AI model by itself only answers a prompt. A harness is what lets it act: use tools, remember, and take steps until a job is done.

• Picture harnessing a horse: the horse is the raw power, the harness is what lets you put it to work without it bolting.

• The AI coding agents you’ve heard of (Claude Code, Codex, Cursor) are all harnesses.

• The frontier model is becoming a commodity (everyone rents the same few). Your harness configuration is what you want to own.

The next decade of software won’t be “an app with AI added on.”

It’ll be harnesses, and the build-vs-buy call is yours to make. So read this!

For the past 6 months I’ve done a bet with myself: do everything through agentic tools, change a line of code or text only when I absolutely have to.

At the beginning this made me incredibly slow, but as I progressed and turned into a power user, I started to see the value in harnessing AI models myself. Currently I am interacting with my computer 90% via Claude Code and I can see how harnesses have the potential to revolutionize how we think about software and computers in general.

Now let’s see why a raw model can’t do the job on its own, what a harness actually is, the everyday parts every harness is built from, and what all of it means for your company.

Why a Raw Model Isn’t Enough

On its own, an AI model does exactly one thing: you give it one input, it hands you one output, and then it stops. No memory of the last step, no ability to take the next.

That’s not the magic you feel in Claude Code or Codex. Those tools take dozens of steps on their own: reading your files, running things, catching their own mistakes, pulling what they need from memory or the internet, looping until the job is actually done. A raw model can’t do any of that by itself.

That repeat-until-done cycle (read what’s there → decide the next step → do it → check the result → go again) has a name. It’s the agent loop, and it’s the engine that turns a one-shot answer into finished work.

And the best ones don’t just act. They check their own work. Boris Cherny, who created Claude Code, says the most important thing for getting great results is giving the AI a way to verify its own work: a feedback loop that, in his words, can 2–3× the quality of the final result. That self-correction is a harness feature, not a model one.

This takes us from “answers a question” to “does the job”:

If the model is the easy part and what’s built around it is the hard part, the obvious question is: what is a harness?

So What’s a Harness?

Picture a wild horse. It’s raw power it’s nearly useless until you harness it: reins to steer it, blinders to keep it focused on the road, a saddle so it can carry weight.

A model is the horse. The harness is the software wrapped around it. It adds the hands (tools), the memory, the reins (guardrails), and the loop that lets it take many steps. That combination (not the horse alone) is what does real work.

An agent = a model + a harness. The agent is the working thing you actually use: a model with a harness wrapped around it. The model is the raw intelligence.

The harness is what puts it to work. LangChain (a popular toolkit for building these systems) frames it bluntly: the harness is everything that isn’t the model itself, and that “everything else” is where almost all of the engineering, and the magic, actually lives.

There’s a name for the work of building one, too. Mitchell Hashimoto (a veteran engineer, co-founder of HashiCorp) calls it harness engineering: “anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

So a harness is what that work leaves behind. Lessons about how the AI fails gets built into the wrapper so it stops failing that way (and instead finds new ways to fail :).

What’s Inside a Harness

At the center of the harness, we have the loop, the engine that keeps calling the model until the job is done. Plus a kit of 7 parts that allows us to steer the model’s behavior:

Tools. Without them, the AI model can only provide “talk”. In other words, it can only output text, images or audio. With them, it can interact with the outer world, such as reading files from your computer, executing code, searching the web or editing a document.

Memory. The AI forgets everything between sessions, so the harness gives it files to write to and read back: its long-term memory and to-do list.

The files are what let it remember anything at all and pick up where the last session left off. The simplest memory implementations are based on files, but depending on the complexity of your use case, you may need a more sophisticated solution based on vector or graph databases.

Context. The context window is what the LLM sees at a time, in each iteration of its loop. The problem is that it’s limited to 128K, 256K, up to 1M tokens. As the context window grows, the model starts to get confused and produce incorrect results, a problem known as “context rot.” The role of the harness is to keep the context window sanitized by adding/removing components at each iteration. Ideally, you want to keep the context with exactly the right information that gets the job done.

A sandbox. It’s a safe room where the AI can make a mess (run things, break things) without the risk of touching anything real in your business, such as deleting files, accessing sensitive data or even running malicious code on the computers from your private network.

The goal is to give the agent exactly as much access as it needs to get the job done. Otherwise, during its agentic loop, it can always decide to go rogue just to achieve its goals. It’s very common to start looking around for API keys to access data from your database or other services.

Guardrails. A big part of guardrails is the permission layer, which sets the rules for what the AI may do on its own: what runs freely, what needs your okay first, and what’s automatically denied. These need to be carefully balanced to avoid asking the human to accept each command (which adds a ton of friction, forcing the user to babysit the agent) while still asking for user input at essential points, such as deleting a file or changing one that’s not versioned.

Orchestration. For complex jobs, 1 AI acts as a project lead, delegates to a team of specialist AIs, each handling a piece and then pulls the results together. A caution from experience: don’t reach for the multi-agent systems too early. I once split a job across 5 or 6 specialist AIs, and a single, well-set-up one beat the whole team.

Interfaces. The same harness is reachable from your phone, laptop, browser, Slack, or WhatsApp.

The AI Tools You Already Know Are All Harnesses

Every popular AI tool you are using is a harness. Claude Code, Cursor, Codex: the same kind of model inside, a different harness wrapped around it.

Here’s what usually happens: when a product feels better than a plain chatbot (it remembers your project, fixes its own mistakes, actually finishes the task), that feeling is the harness doing its job. Two products can call the exact same model and feel worlds apart, purely because their harnesses are worlds apart.

And this isn’t just a vibe. In one public test done by LangChain, they changed only the harness around a coding agent (same model throughout) and it climbed from roughly 30th place into the top 5 on the Terminal Benchmark used to evaluate agents.

Before we get to what this means for your company, let’s clear up 3 words that get thrown around as if they’re the same thing.

So harness engineering is the last step: the whole AI application around the model. Which raises the real question: should your team buy or build its own harness?

What This Means for Teams

Claude Code is a harness someone else built for general coding. It’s superb at that. But it will never know your finance rules, your data, your guardrails or your customers. The moment your AI needs to do your job, a generic harness hits a wall.

Still, a harness you build becomes its own product, with its own bugs, issues and maintenance overhead. Owning the layer can give you an advantage, but it’s an ongoing investment, not a one-and-done build. The real question isn’t whether you can (Claude Code can build you a harness), it’s whether you should.

That’s why most people I know, including myself, are customizing harnesses (via skills and MCP servers) intended for coding, such as Claude Code, for their own use cases, or coupling them with Notion or Obsidian to transform them into their personal assistants.

But using coding harnesses for everything has one major drawback: they are optimized for coding, and the people building them will keep optimizing them for coding. This might lead them to behave more poorly with each version update.

Another huge drawback is that it’s almost impossible to build your own product on top of them. They are amazing as internal tools, but once you want to stitch a UI on top of them or distribute them to your users, you hit another wall.

That’s why we started seeing harnesses specialized for different domains, such as:

• Creative: Descript (video), Canva Magic Studio & Adobe Firefly (visuals), Figma AI (design)

• Legal: Harvey (drafting contracts), CoCounsel (reviewing contracts)

• Medical & Healthcare: Abridge & Nabla (generating clinical notes from doctor-patient conversations)

• Financial: I personally worked at ZTRON as a harness for financial advisors

• Productivity: Notion AI

But there is a middle ground between building and buying. As harnesses are being standardized, major frameworks such as Pydantic AI’s Harness, Pi or LangChain’s Deep Agents have recently entered the game.

They’re good open source starting points that provide the agentic loop, the 7 key parts and the option to easily add your own UI/UX and distribution.

You don’t need to build a harness tomorrow, but it’s important to know that you can build a custom harness when you’re ready, and it’s a piece of your stack that’s worth owning.

Harness in Conversation

“We’re still building out the harness around the model.”

We have the AI. Now we’re building the software that lets it actually do the job.

“That’s a model problem, not a harness problem.”

The AI itself is getting it wrong, versus we just haven’t given it the right tools or memory yet. (Usually it’s the second one.)

“We don’t want to be locked into someone else’s harness.”

We want to own the layer that makes our AI ours, instead of renting it from a vendor.

“We should switch to an open-source harness.”

Move off a closed tool like Claude Code to an open-source alternative you can see inside and bend to your needs, such as OpenCode or Pi.

Further Reading

• If this isn’t enough harness engineering talk for you, I’m publishing a series on harness eng soon on my Substack, DecodingAI.

• Letting an AI check its own work is the single biggest lever for getting good results out of it, straight from the engineer who built Claude Code.

• If you want the full parts-list of a harness, plus the test where swapping only the wrapper took a coding agent from 30th place into the top 5, it’s all in the anatomy of an agent harness.

• More on the “notebook” that lets an agent remember across sessions, in Anthropic’s guide to effective harnesses for long-running agents.

• Learn how OpenAI’s Codex actually works.

• More on keeping the AI’s context window clean, and avoiding “context rot,” in Anthropic’s guide to effective context engineering.

Turbopuffer is a search engine built on top of object storage (like AWS S3).

• AI applications need to quickly search through lots of unstructured data (text + embeddings). Cursor searches through your codebase, Notion AI searches through your documents.

• In the early days of AI applications, most vector search options (like vector databases) stored data on RAM to ensure fast query times. This turned out to be quite expensive.

• Turbopuffer offers a search engine on data stored in object storage (like AWS S3), and only pulls data into RAM when it’s needed. They claim this makes it 10x cheaper while still being fast.

• Competitors like Pinecone and Elastic also followed suit with “serverless” vector search tooling.

Search is one of the most competitive spaces in AI infrastructure. Turbopuffer reportedly crossed $100M in ARR recently, so their early bet on object storage is paying off.

Their story is one of an obsessive focus on knowing what can be done with the tools cloud providers like AWS + GCP have on offer. It’s a tale as old as 2006.

Separation of storage and compute

In 2006, AWS launched a simple product without fanfare. It let developers store + retrieve unlimited numbers of files, and it promised not to lose track of them:

All software does is basically manipulate files, and S3 (Simple Storage Service) was a bottomless filing cabinet.

Renting it was much cheaper than buying your own filing cabinet of merely moderate size.

AWS launched S3’s soulmate, EC2 (Elastic Compute Cloud) in a similarly low-energy way in August of 2006. It let you rent as many servers as you needed, whenever you needed them.

This pairing (the foundation of the Cloud) made developers rather thirsty. By separating compute from storage as separate cloud services, you could reimagine stodgy, ubiquitous infrastructure like databases.

The creators of Snowflake were two of those developers, and the analytics warehouse was a ripe first target. As Snowflake co-founder Benoit Dageville put it:

I always said that as older software guys we were at the mercy of hardware and its resources. The cloud was a game changer for analytic workloads that has lots of peaks and troughs in usage. It really needed that elasticity the cloud offered.

Him and his co-founder Thierry Cruanes left Oracle and started Snowflake in 2012, which today has an ~$80B market cap. Larry Ellison had no comment.

These two AWS launches from 2006 unlocked an untold number of novel data infrastructure companies to be built.

• Analytics + machine learning: Databricks, Snowflake’s nemesis for data engineering workloads

• Transactional databases: Neon, the transactional database (acquired by Databricks)

• Streaming: WarpStream, the real-time event streaming service (acquired by their competitor Kafka)

• Search: Turbopuffer

All have succeeded by rebuilding foundational data tooling on top of object storage like S3.

Enter vector search

AI agents make analytics workloads look quaint by comparison. Just the vector search piece is a perfect storm of how to run up a cloud bill:

1. Embeddings are big. If a chunk of text is 1KB, an embedding vector representing the meaning of that text could be 6KB.

2. Agents search more than humans. Way more. If you watch a coding agent work, it runs tons of searches. I usually only search “Oprah net worth” once a week.

3. Agents produce more vectors. More slop code + documents means the search index grows faster than it would if it was just people making stuff.

Search engines like Algolia or Elastic at this time were designed for a person searching in a search box on a website. They needed instant feedback, so data was stored in RAM. High cost was a tradeoff for low latency.

For agents using vector search, the tradeoff needed to be different. High cost was untenable, so the solution would be to trade a little latency.

Read more

Woah woah woah. Let’s back up.

What is a programming language?

Computers have the notable distinction of being at once one of the most intelligent inventions in human history and also being super dumb. They can technically do almost anything, but only if you tell them exactly what to do in exactly their language – the language of 1s and 0s.

See, a computer is a bundle of physical circuits that can be open (represented as 0) or closed (represented as 1), and all the data a computer uses and all the logic it performs is articulated to it in the language of 1s and 0s called binary; the OG programming language. It’s just ones and zeros all the way day.

Writing complicated logic with only two numbers at your disposal is obviously hard. Accordingly, telling computers what to do was a massive pain for many many years, so much so that it was generally confined to the domain of nerds at universities like Grace Hopper and Ada Lovelace. They’d write out the literal 1s and 0s the hardware understood, sometimes by physically flipping switches or feeding in stacks of cards with holes punched in them. This was, as you might expect, difficult, error prone, and a pretty far cry from the work you see modern software engineers doing at the specialty coffee shop.

As these early computer scientists wrote more code, they realized a lot of their code did the same things, like adding two numbers or storing a name, and they concluded they needed an easier way to write these common instructions. They landed on the idea of a “higher level” programming language that read like English, which would then be run through a translator called the compiler that turned it into 1s and 0s for the machine. Easy for humans to write, easy for computers to run, everybody wins! Thus the first mainstream programming language was born: FORTRAN.

Why are there so many programming languages?

We don’t talk about programming languages much here at Technically because, well, for the purpose of understanding the world of tech at a high level, we don’t really think it matters. Most languages are more alike than they are different, and they all do basically the same things give or take a few things. So, why even have more than one language? You just said computers only speak 1s and 0s right and so we made FORTRAN to solve that. Why do developers today write in over a hundred of them?

The answer is in tradeoffs. Since a language is a layer on top of 1s and 0s, each one makes slightly different design decisions on its journey to being English-like. The authors of FORTRAN made a thousand little judgment calls on your behalf. What gets to be easy and what stays hard? What happens automatically and what do you have to spell out by hand?

Some of FORTRAN’s decisions people liked, others they didn’t. So they wrote a different language, and then another, and then another, and each of these human-friendly programming languages prioritizes something different at the expense of something else. There is no best language, there is only the spectrum on which a host of tradeoffs sit.

For the purposes of understanding the wonderful world of Rust, we’re going to zoom in on one specific tradeoff: memory.

A trip down memory lane

When a program (some code) runs, it needs somewhere to keep the stuff it’s actively working with like:

• The user’s name

• The current score of your little game

• The contents of the text box you’re typing in right now

This is what memory is for. You can think of it as the program’s desk; not long-term storage like a filing cabinet (that’s your hard drive), but the open workspace where things sit while you’re actually using and working with them.

The desk needs to be managed: periodically cleaned and organized. After all, it’s small, and the program never stops working. In practice this means setting new data down, grabbing data back when it’s needed, and clearing off the old stuff to make room. This is the harrowed discipline of memory management.

There are lots of different ways to manage memory. Some approaches prioritize speed, and others deliver safety.

• By speed, I mean exactly what it sounds like. How fast the program runs. How quickly the page loads, how little the game stutters, how fast the trade goes through.

• By safety, I mean how well the language stops you from hurting yourself. A safe language makes it hard to write the kind of bug that crashes the program, leaks private data, or hands an attacker a way in. An unsafe language trusts you to never screw up, which, reader, you will.

By way of example, many higher level languages, like Python, manage memory for you automatically. That makes them safe and forgiving, but it costs in terms of performance because the program is spending energy doing memory housekeeping chores in the background while it runs. I.e. Python is considered slow.

Many lower-level languages, like C, are wicked fast because they don’t do any automatic memory management, but that means they’re hard to write (you have to manage the memory yourself) and prone to failure.

There are other tradeoffs inherent in different programming languages too, which won’t be the focus of this series, but are worth mentioning:

• Static vs. dynamically typed. Does the language require you to declare what kind of data every variable holds (a number, a word, true/false) before it runs? Static typing catches bugs early but is more rigid to write. Dynamic typing is faster and looser to write, but errors show up at runtime in production, where they hurt.

• Compiled vs. interpreted. Does the translation from code to binary happen upfront, or on the fly? Compiled languages do it all before the program runs, producing something fast and optimized. Interpreted languages translate as they go, which makes them more flexible and easier to experiment with, but slower when running.

• Ecosystem. A language comes with a community, a library of pre-built tools, and a job market. Python dominates data science not because it’s the fastest language (it isn’t) but because the tooling built around it is so mature that nothing else comes close.

In any case, the memory tradeoff often ends up being the big one - the granddaddy of them all, the primary question a developer must ask themselves before embarking on a new engineering expedition: Do you want it fast or do you want it safe? Which way western man?

You might be wondering why memory in particular is so important, such that (as I’ll demonstrate) someone built an entire new language around making working with it better. In part two, we’ll go deeper on why the memory problem is more consequential than ever in the age of high speed trading, AI, and online gaming, and what one cracked engineer at Mozilla decided to do about it.

• Data engineering pipelines

• RAG pipelines for AI products

• Sales pipelines

• Image processing pipelines

• Frontend app compilation pipelines

Let’s explore. I promise this post will not result in you using more tokens.

The Data Pipeline

Bronze, silver, and gold. Databricks’ marketing team uses this holy trinity to describe the medallion architecture for processing data.

Other companies like dbt have used staging, intermediate, and mart. I’ve even seen raw, cleaned, and curated. They all mean the same thing.

It describes how data is processed as it moves through the pipeline:

• Bronze is data that’s been ingested, usually in the most raw state (eg logs or events).

• Silver is the cleaned, joined, and standardized sets of data. This is where stuff like deduplication, filtering, and constraints are enforced.

• Gold is ready to be used by the business, in reporting or machine learning models.

Each step of the pipeline the data gets more refined + usable, following a set of principles. You can walk into any company following this 3-stage pipeline architecture, look at their data transformation code, and be able to make sense (hopefully :) of what they’re doing.

The RAG Pipeline

I once interviewed at a vector database company that had a pretty involved take-home assignment, that required me to explain a RAG (retrieval augmented generation) pipeline.

Coming from working in data, this was just one hop over, but it still felt foreign.

RAG systems let an LLM retrieve information from external datasets, and use that information to generate responses. RAG shows up every time an LLM like Claude does a web search. It’s so seamless we don’t even think about the underpinnings of what’s happening.

Notion is a great example. When you use Notion AI, queries are being embedded into vectors on the fly and it’s searching a vectorized version of your Notion workspace. You might be thinking “how the hell is it so fast?”. That’s part of the magic. This vector pipeline runs in the background (chunking, embedding, and storing in a vector db) so that Notion AI run your semantic (vector) search when it needs to.

During the ingestion stage, we add metadata to our documents (like title, author, etc) which helps add context to them. This will follow the documents through the rest of the pipeline.

Chunking breaks the documents into similar-sized pieces, so that they’re faster to search through.

Embedding is where we are transforming the text (or image / video other modal) into a vector.

Next we package everything together and store it in a vector database.

This is where that metadata becomes super helpful, because it can be used for cheap + fast filtering at retrieval time.

Every pipeline requires tradeoffs. In the data pipeline example, a set of rules like the Medallion Architecture helps us decide where to put different types of data transformation work.

In a RAG pipeline, the tradeoffs we’d think about are:

• Chunking size: Do you chunk per token or per document? What happens when you need to re-chunk?

• Embedding models: Do you use open source or self-hosted embedding models, or just use OpenAI? When do you switch to a new embedding model?

• Latency: Search demands speed. If you have a B2C product and the search sucks, users may bail.

If you want to go deeper, I highly recommend Notion’s blog on vector search.

The more I learned about RAG pipelines, the more they look like the same pipeline problem.

The Sales Pipeline

I work as an AE at OpenRouter, which means I manage a sales pipeline.

My sales pipeline looks eerily similar to just a data pipeline:

• Bronze layer: leads in my CRM without any enrichment. They could be cold leads or warm leads, but I have no idea. Some are missing job titles, phone numbers or (worse) their name.

• Silver layer: qualified leads. I know about them and they know about me too, how wonderful! I’m still qualifying them but at least they talk to me.

• Gold layer: This is where the magic happens, where those companies and leads become opportunities. All that work to build a business case, it’s all paid off here in the gold layer. Now I can go and close them as customers!

I’ve simplified the hell out of this for the bit, but I think it fits.

So where do tradeoffs come into play here? It shows up in the small decisions I make every day.

It shows up when I’m trying to protect my customer engineer’s time because the prospect sounds flaky. And it most certainly shows up when I need to forecast my sales for the quarter. We need to know whether a deal is moving forward or being left behind:

The Photography Pipeline

Years ago I got into photography and started doing paid shoots on the side. I used to just take photos on my phone and then edit them in the VSCO app, but when I started doing paid shoots I upgraded to a full frame (Sony A7) camera with everything in RAW format.

Photo editing is also a pipeline.

First, I’d take lots (hundreds) of photos, way more than I’d need. Then I’d edit in layers:

1. Bronze layer: Filter through them and make selections

2. Silver layer: play with exposures, shadow details, and more.

3. Gold layer: once the composition was right, I’d put the finishing touches on to get them delivery-ready.

What you See is Not What you Get

I’ve always felt I had a strong knack for drawing patterns and connections but really I think it comes down to how I simplify my approach and layer in a framework. In this case I drew a lot of connections from looking at them as pipelines.

Pipelines have workflow stages, and there are inherent tradeoffs about where (in which stage) you put the work. The order of operations matters!

What’s fun about pipeline thinking is that you can break any process down into a pipeline, and play with where to draw lines between stages.

But a pipeline is just one mental model. What’s your favorite?

If LLMs went away tomorrow, what framework would you fall back on to describe how things work?

Though for most of my readers (who for some reason I assume were born in the 90’s) this word may evoke a quaint yet hauntingly-long-ago visage of their suburban childhoods, it means something else entirely to a software developer.

The TL;DR

Sandboxes are isolated computing environments where you can run code that you don’t entirely trust. Think of them as solitary confinement, but for a program.

• Much of software today requires you to run untrusted code – code written by a Large Language Model or even a human you don’t know.

• Running untrusted code on your system is risky: it can breach your security, delete your data, and generally just mess with things.

• A sandbox puts iron walls around this untrusted code so it can’t mess with things, while still allowing it to run and (hopefully) accomplish its task.

• Sandboxes are absolutely exploding in popularity because of several different LLM-related use cases.

Sandboxes have been around for as long as I’ve been in tech. For years, products like Retool (my former employer) have needed ways to let their users run arbitrary code…without being subject to the risks of their users running arbitrary code.

But with LLMs taking the center stage, they’ve gotten a second wind for the ages. There are now dozens (dozens!) of sandboxes for LLM startups vying for the business of small companies and enterprises alike who need a place to run random code. And I will explain them to you.

Coding agents, RL training, and other forms of untrusted code

To understand why sandboxes are having such a moment, we must first detour to understand this concept of “untrusted code” a little more deeply.

Simply put, untrusted code is code that you, yourself, have not examined closely line by line. Because you haven’t examined it closely line by line, you don’t know what it does. And because you don’t know what it does, running the code in the same places that you have your other code running is very risky. Who knows what it’s going to do?

Imagine you’re a prison warden (if I have any readers who are prison wardens, let me know in the comments). You’ve got your hundreds of inmates who are, for the most part, playing pretty nicely together. Then you get a call that a new prisoner is on his way; you don’t know anything about him, just that he’s rumored to be a high-profile gangbanger. Is he well behaved? Could he incite a riot? Will he try to escape? Who knows.

With that uncertainty, you’re certainly not going to put him in Cell Block A with everyone else. Instead, you’ll cordon him off in solitary confinement where whatever he does won’t impact the orderly conduct of the rest of your subordinates.

In software engineering this is referred to as isolation. The prison is your infrastructure – the server your existing code runs on, the database it’s backed by, the APIs powering it. Everything for the most part is working well, and you don’t want to risk a new inmate fucking around with things.

So who are the gangbangers in our analogy? There are a few:

• Internal coding agents – developers using LLMs to generate code for new features, fixing bugs, etc. This code is untrusted, so it needs a sandbox to test it before merging into the rest of the codebase.

• Reinforcement Learning (RL) – when teams train their own coding agents, they need environments where the agents can play around and learn how to get better. Since the code they’re generating and running is (very) untrusted, they need a sandbox.

• (old school) Users – sometimes you want your users to be able to write code and run it on your systems.

Sandboxes give developers an isolated environment to run and test these outputs – these gangbangers if you will – where they physically cannot negatively impact other parts of your stack. If they mess up, if they turn malicious, if they start a riot, the scope of damage can never extend beyond the sandbox itself.

By the way, this gangbanging is not theoretical. Code can absolutely get nasty and mess with your stuff. You’ve probably seen examples on X of coding agents “accidentally” deleting someone’s entire database. And for RL, logs of coding agents in sandboxes often show them attempting destructive behavior because they’re basically try anything (that’s how RL works).

Read more

Within minutes, the agent was crawling the repository and shipping pull requests across multiple pages at once. Then it hit a wall.

For the parts of our site th…

Read more

Read more

Next.js is a web framework for React. It helps developers (and now agents) create web applications in React quickly and easily, as long as you follow a few rules.

• The magic we take for granted – type in a URL, see a website – relies on a million complicated things going on in the background

• Web frameworks help developers focus less on the logisti…

Read more

Intro to package management

The vast, vast majority of software, be it consumer apps like Snapchat and Strava, or B2B platforms like Salesforce and Workday, use open source software as building blocks. This is to say, they use code written and made public by other people to save themselves time when developing their own applications.

A classic example of a use case for leveraging open source code is if your app has anything to do with time, such as displaying the date and time to a user. Time is surprisingly complex: what time zone are users in, are they in daylight savings, do you want to display the day of the week as well? You could code up all this logic yourself, but it’s much easier to use code someone else already wrote to do this.

The world of package managers emerges when you ask: how do you actually use someone else’s code?

One naive way might be copy-pasting code from someone else’s app or website into your own codebase, line for line. This would work, but is very inefficient. What happens if the author makes changes? What if there’s a security vulnerability discovered down the road?

For these reasons and more, the most common way that developers of open source software distribute their code is by bundling it into packages and publishing them for the world to use via a package manager. You can think of a package as a nice wrapper around the code that someone has authored, boxing up your little (or a lot) bit of code nicely so you can ship it to others without things getting messed up.

🚨 Confusion Alert 🚨

The terms package, library, module, and framework are used mostly interchangeably in the industry, for simplicity, I’ll stick to package here.

Package managers are programs that deal with the logistics of these “packages” of code: in particular, fetching and installing these open-source software packages. They are used almost anywhere people (or robots) write, test, or run code. The key elements of a package management system are the package manager and the package registry. Let’s quickly review how they work.

If I’m a developer starting a new project and I want to use someone else’s code for something (like handling dates), one of the first things I’m going to do is ensure I have a package manager installed on my system. The package manager makes it extremely easy to install the packages that I need. Each language maintains one or more official package manager, such as pip for Python, and npm for Javascript.

For the example where I’m coding up an app where I need to display time to my user, if I was building in Python I’d use pip by opening up my terminal and typing pip install pendulum (pendulum is the package name). The package manager does a few things:

First, the package manager checks my system to see if pendulum is installed already. If it is, fantastic, it does nothing. If it is not, it goes out and downloads the package. But where does it go to get the package? It goes to the registry.

The package registry is a public, trusted repository of open source software packages on the internet. Each language maintains one or more official registries, such as PyPI (Python Package Index) for Python, not to be confused with pip, and the npm registry for JavaScript.

You can think of the registry as the warehouse where all of the boxed software goes to be shipped out. The authors of the software are (ideally) constantly uploading new and improved versions of their packages so users like you can benefit from the great wheels of progress.

This general process of ensuring I have the packages I need is referred to as dependency resolution – a dependency just means a package that your software needs in order to run – and it’s the core job of the package manager. And it’s a full-time job: as I code up more features, my dependencies will change, and the package manager needs to make sure what I need is installed at all times, and what I no longer need is purged from the system.

Over time, many package managers grew beyond just fetching code. See, going from code to real running software requires a few other steps. For example, after code is written and external packages are installed, something called a compiler or bundler needs to translate that code into a language that’s readable by the machines. After that, a different program actually needs to run the code, called the runtime. At least that’s how it was for a long time — different tools for different stages of the pipeline.

But newer tools like Bun in the JavaScript world started collapsing this entire toolchain into one fast program that handles everything. This bundling is important context for understanding what AI labs actually bought, which we’ll get to shortly.

The thing I want you to know is that for the entirety of my time building software, and for decades before that, the package manager was a thing you used manually, slowly, and pretty infrequently. Starting or pulling a new project, updating a package, or running some tests locally. It was not software that anyone loved or waxed poetic about, it was just a thing you had to do.

This is because coding — making your software do what you want it to do by typing out instructions — takes a long time when humans do it. For human engineers, package management only has to be as fast as humans can decide what packages they need and can use them in their development cycle. Until recently, this was fine, because humans were the only entities that could write code.

And then came the agents

LLMs, on the other hand, can generate code really quickly. AI-powered coding agents can now take a loose set of requirements for a feature or whole app, plan the implementation, and then code it up across a massively parallel fleet of agents. And though the speed at which they can generate code is fast, they still need to run that code: each member of this fleet needs to resolve package dependencies, install packages in isolated environments, run tests and code, and clean up after themselves after they’re done. Just like humans do.

Even AI features geared toward non-developers increasingly require the ability to quickly write and run code. For example, when I ask Claude to produce a Word document, it installs an open-source JavaScript package called docx-js, writes code that uses that package to produce a document, and runs that code all within an isolated environment in the cloud.

So, using package managers went from a slow thing humans did once in a while to a thing that needs to happen tens or hundreds of times a minute when it’s agents writing the code. Where code runs went from a permanent thing I’d think about once per project, to something more ephemeral that needs to be rapidly spun up and torn down many times an hour.

What this means is that package managers are now critical infrastructure for AI products. They’re in the “hot path”, as we say in the biz. Every time Claude Code produces a file, or Codex writes and tests a function, package managers and runtimes are doing work on every single invocation. If they’re slow, the product feels slow. If they break, the product breaks.

Anthropic and OpenAI both have whole suites of products that involve agentic coding, from terminal-based offerings like Claude Code and Codex to their desktop apps and more. I believe that the folks at these labs realized early on that a big bottleneck in the quality of their products was going to be the sluggish package manager ecosystem. So they bought the best ones out there. And the tools they bought were the ones that had already grown beyond just package management into all-in-one toolchains that handle package management, building, and code execution.

Read more

It is not the first time that such a paradox has shown up in the deployment of a new technology. In 1987, Robert Solow remarked that you can see the computer age everywhere except in the productivity …

Read more

As a technical person, but by no means a frontend engineer, I like to vibe code as much as I can - from growth experiments, to POCs, internal tooling, new designs, the list goes on.

It’s a balance, and I’m always trying to figure out what I should try to …

Read more

Hey friends, quick note for you:

There are a few sure things in life. Death, taxes, and website rebrands. We cannot help you with the first two, but…

ICYMI, we recently redesigned the technically.dev site. It should be a lot easier to read and look through now. We also brought back a crowd favorite: learning tracks. We’ve added new tracks like How AI Models Actually Work + From Spreadsheets to Databases.

And to celebrate, we’ve created a new All-access subscription there that gets you access to all learning tracks (and the entire Technically archives).

If you’re a paid Substack subscriber, you will get automatic access to this All-access subscription — just make sure to sign up on technically.dev with the same email as your Substack account.

If you’re curious to test the waters, you can start by creating a free account that lets you unlock a couple free posts a month. Enjoy!

Amidst the frenzy of AI, a new category of infrastructure vendor has emerged: The inference provider. This white-hot newish(ish) vertical is producing some pretty big headlines for a category that, as we’ll see, is often overshadowed by big AI labs like OpenAI and Anthropic. TogetherAI is in talks to raise at $7.5B, Fireworks raised at $4B last year, and Modal is in talks to raise at $2.5B – all of these are doubling and doubling every few months it would seem. NVIDIA splashed $20 billion for Groq’s inference chip technology in December, its largest acquisition to date.

So yes, inference is white hot. But what do these companies actually do? And why are they worth so much money?

Let’s dig in, shall we?

What’s inference?

AI didn’t take long to become totally ubiquitous. It answers your questions, summarizes your meeting notes, codes up your apps, and, if you’re a bad friend, writes your birthday cards. All of it, every AI product you touch, boils down to two things: training and inference.

Training is how a model learns. You take a massive amount of text and use it to produce a mathematical equation that captures patterns in language: what words tend to follow what, how ideas relate to each other, what a reasonable response to a question looks like. Models like GPT and Claude were trained on enormous amounts of text from the internet, and what emerged are systems that can produce generally fluent, useful language.

Inference is when the model actually does its job. Every time you send a message to ChatGPT and it responds, that’s inference. Every time Claude summarizes a document or an AI coding assistant autocompletes a function, that’s inference too. It’s the model taking what it learned during training and applying it to your input, in real time.

Training models has historically been the sexy part of AI, done by people in glasses, wearing turtlenecks, and holding PhDs. They are paid many dollars. Serving models, on the other hand is plumbing, but as it turns out, as every company races to add AI to their app, the plumbers are doing pretty well for themselves. Dedicated inference providers have emerged as a major force in the AI application stack, offering a convenient managed inference service for developers building AI-powered features.

In its purest and most managed form, the OpenAI and Anthropic (we’ll call them frontier labs) APIs are AI inference providers. They have both trained the models and set them up for you to use easily. You make an API call: (“write my wedding vows”) and get back an inference: (“Webster’s dictionary defines love as…”). So what are we talking about here? Why would you use something special?

Why use an inference provider?

As someone using AI or building into your app, you have two major choices. You can use a closed-source model like ChatGPT or Claude. These are proprietary models – nobody knows how they were trained – and the only way to use them is through the people who trained them, OpenAI and Anthropic. These labs (as well as other closed-source providers like Runway, Midjourney, and Google) are very good at training models, and generally their models will be the best on the planet, but also cost the most.

Then there are open source models. These are built by companies or the community, and released for all to use. The weights of these models (the key to the fancy prediction equation) and sometimes even the training code are open to the public. You can download and run them yourself or even tweak them if you’d like. The most popular ones are Llama from Meta, Qwen from Alibaba, and DeepSeek.

With open-source models, you have a choice in how you actually use them. You can self-host by spinning up your own infrastructure, loading the model weights, and managing everything yourself. Or you can instead use an inference provider: a company that hosts open-source models for you and lets you access them through an API, just like you would with a closed-source lab.

There are a few reasons a developer might use an inference provider over just calling the inference endpoints of the frontier labs directly, or running OSS models themselves.

Cost. The newest Frontier models are expensive. If your use case doesn’t actually need a state of the art model like GPT-5.4 or Claude Opus, you can run an open-weights model like LLaMA on an inference provider for a fraction of the price. For high-volume, straightforward tasks like summarization, classification, or extraction, you probably don’t need the best model on the market, and the savings add up fast.

Speed. The big frontier labs generally optimize for model capability over latency. If you’re building something where response time matters (autocomplete, real-time agents), inference providers running on optimized hardware can get you significantly faster performance.

Resilience at scale. If you’re big enough that OpenAI having an outage means your product has an outage, you have a problem. Inference providers let you route across multiple models and backends through a single API, so you’re not in hell it every time one provider has a bad day.

Native integration with your cloud. The public cloud inference provider offerings like AWS Bedrock or Google VertexAI have an advantage in the enterprise because their models and endpoints are colocated with your other infrastructure, which can matter to security and data-residency-conscious buyers. They also tend to offer the most straightforward paths to fine-tuning and customization, which is when you take a base model and train it further on your own data so it performs better for your specific use case.

All this, at least for me, actually reverses the question - why would you call the frontier labs’ APIs when the inference providers are cheaper and faster? There are at least a few reasons:

• You need the latest and greatest models (remember, the inference providers are often hosting the open weights models, which are older)

• Cost and/or latency are not a concern for you (congrats, happy for you)

• You’re a noob and didn’t know about inference providers (me, until recently)

The inference provider spectrum

Like many software categories, there is a spectrum from:

• Easy to use with fewer customizations and control for a lot of money...

• …to pure infra providers that you configure to do what you want, with full control (and responsibility over) the infrastructure for less money.

Let’s take a look at that spectrum.

Most Managed: First-Party Model APIs

I already touched on this, but the AI labs themselves provide inference endpoints and, as such, are technically inference providers. You call their API, and you get a response without managing infra. It’s the simplest way to add AI to a product, and where most teams start. You get access to the newest and best models, but you also pay per call (among other things), so it’s usually the most expensive.

• OpenAI: The company that started the current wave; their API format has become the de facto standard that most other providers copy.

• Anthropic: Makes Claude; strong enterprise adoption, and known for handling very long documents.

• Google (Gemini): Lots of models; deeply integrated into Google Cloud and Workspace suites.

Technically, the platform of the model provider isn’t the only way to access them.

Cloud Hyperscalers: Enterprise AI Platforms

Read more

This is a story from Giorgio Liapakis of wibci. If you have a story to tell, drop us a note at editors@technically.dev.

In January, I gave an AI agent $1,500, full control of a Meta Ads account, then walked…

Read more

Maybe. This increasingly popular deployment model goes by a few names (self-managed, customer-managed, customer-cloud-deployed), but we’ll call it BYOC (Bring Your Own Cloud), and if you’re building B2B software, it’s worth understanding what makes some BYOC offerings successful, and some a huge dumpster fire.

Trickiness aside, the BYOC ask from customers is becoming commonplace. As data regulations get stricter and security teams get more power over vendor decisions, more enterprise buyers are walking into sales calls with a version of the same question: “Can this run in our cloud?”. Those vendors that can confidently say yes are making buku bucks.

The SaaS deal

SaaS works because of a simple trade: as the customer you give up control, and in return, you get convenience. Instead of managing your own servers, you pay the vendor to do it for you. No servers to manage, no upgrades to coordinate, no infra team needed. The vendor handles all of that, and you get a website to log into. For most companies, this is great. You should probably stop reading here if your customers are all happy with this arrangement.

But “most companies” is not “all companies,” and the ones where this deal falls apart tend to have very, very, large budgets.

Mo money mo problems

For buyers in financial services, healthcare, defense, and large tech (among others), multi-tenant SaaS creates problems that aren’t really solvable with a better sales pitch.

🚨 Confusion Alert

Multi-tenant just means that multiple customers are using software that resides on a single physical (or virtual) server. Your data is in the same shared database as everyone else’s. If you use Gmail, that’s multi-tenant. So is X, Sheets, Claude, you name it.

Here are some of those problems:

• Data residency and sovereignty: some companies can’t have their data leave their own servers, period.

• Security posture inheritance: in SaaS, your customer’s security is only as good as yours…and they might not want to take a bet that you know what you’re doing.

• Performance and egress costs: SaaS requires moving a lot of data around the internet, which is expensive AF, in some cases, even more expensive than the software itself.

• Vendor lock-in: if your SaaS runs on one specific cloud provider, your customer is now locked into that cloud, even if they already use a different one.

If you’re a cool, lean, startup moving fast and breaking things, these may sound like lame problems to you. But these are Fortune 500 problems. Get ya money up.

The spectrum

For all of these reasons and more, companies want to keep things running in their own clouds, your software included. But what that means in practice is very squishy. There’s a whole spectrum of deployment models that blend vendor-managed and customer-managed infrastructure. Understanding where you sit on it is probably a good first step.

Fully managed multi-tenant SaaS. You run everything. Customer gets a login. Everyone’s data sits in the same general pool of infrastructure. This is the default, and it works great for most buyers.

Single-tenant SaaS. You still run it, but each customer gets their own isolated infrastructure like databases and API servers, in the cloud. Better for compliance and sometimes performance, but you’re still holding the data.

Hybrid Architecture. This one is a bit wonky, but worth mentioning. Basically, sensitive data lives in the customer’s account (called the data plane in this architecture), and non-sensitive data and functionality lives on centralized infrastructure hosted by the vendor (control plane). This can help alleviate some of the pains of fully self-hosted setups, such as a lack of observability for debugging, because the data plane can communicate error logs and such back up to the control plane.

Fully self-hosted (pure BYOC). This is the most extreme, but also most lucrative version of BYOC, and the one we’ll generally focus on here. The customer runs the entire software stack in their own environment. These days, that usually means you ship a containerized (fancy word for packaged) version of your software that runs on Kubernetes, which helps with installs and upgrades. But you lose visibility into what’s actually happening and debugging without cluster access is painful. Works if your customers have strong platform teams. Doesn’t if they don’t.

The economics of BYOC

If you’re selling a SaaS product at $50K/year to a mid-market customer, the BYOC version of that same product can go for $150-250K/year. Sometimes more. The functionality is the same. What the customer is paying for is the right to run it inside their own environment, on their own infrastructure, under their own security and compliance posture. So the obvious question is: why would they pay more for less?

Read more

Imagine my surprise, as I became a writer to write actual content, not to become a prompt engineer. The idea that I’d turn over my job to a bot (who, it just so happens, I’m afraid is coming …

Read more

I mentioned the NYSE above, but there are many stock exchanges (NASDAQ, LSE, SSE, etc..) that all facilitate the buying and selling of securities. In fact, markets are so important to society that even if you’re not an avid day-trader, you’re still constantly interacting with them…Uber connects drinkers with drivers, Facebook Marketplace connects people with used furniture, and your dad is trying to connect you with a job.

Let’s say you want to retire and sell your stock in $METH to pursue other philanthropic work. Who’d buy them, and how much should they sell for?

• Markets define the price people are willing to buy/sell things at (Price Discovery).

• Markets offer a platform for people to trade assets, as it’s possible nobody in your neighborhood wants to purchase your $METH (Liquidity).

But what if, instead of the price per share being illuminated by these markets, it indicated the probability of a discrete event? These are called prediction markets.

By pen and paper at the local cock fight or via centralized, scaled, and well-capitalized firms like Kalshi and Polymarket, prediction markets are different from trading equities:

• They are binary. The thing either happens, or it doesn’t.

• They resolve once a particular event occurs, an outcome is reached, or a time period has elapsed.

You can’t buy shares in $METH via a prediction market, but you can bet that $METH will trade between $122 and $124 per share on January 6th.

Today, we are going to sell a gun at Bass Pro Shops. Errrr, sorry, Claude keeps hallucinating. Today, we are going to review the billions of dollars flowing through these markets, how the legacy of FTX lives on, what percentage is sports gambling, and we’ll find out how much money Kalshi makes. Let’s learn a new way to gamble.

History/Primer

Kalshi and Polymarket launched in 2018 and 2020, respectively. While these two make up the current duopoly, prediction markets originate further back. One of the OG’s is the Iowa Electronic Markets (IEM), hosting prediction markets since 1988.

Betting on one’s “beliefs” can get people into trouble, but the wisdom of crowds remains a valuable predictive force. Take the 2004 paper from Wolfer and Zitzewitz:

“These markets have predicted vote shares for the Democratic and Republican candidates with an average absolute error of around 1.5 percentage points… The final Gallup poll yielded forecasts that erred by 2.1 percentage points.“

Yet… over all these years, something has been missing… preventing us from gathering predictions, building markets, scaling to millions of people, and leveraging them for personal gain. That missing piece was well capitalized crypto web applications that offer you free groceries, giving us the ability to bet on the next pope being trans. Just as Hayek intended when he wrote The Use of Knowledge in Society.

We’ll explore Kalshi in detail, but there are other projects/protocols in the space.

How does this all work?

Prediction Markets extend humanity’s surface area for gambling. Personally, I might wager $10 that I can drink 10 beers before midnight, and my wife’s boyfriend might not believe me. On one side, I say “Yes, I can finish ten beers” while he says “No, you can’t finish ten beers”. Replace me with Lebron James, beers with points, before midnight with the end of the game, and you have an actual market you can trade on Kalshi.

At Kalshi, a market refers to a single binary market that resolves to “yes” or “no”. An event is a collection of such markets, and a series groups together similar but independent events. For example:

• The highest temperature in Miami is a series.

• Each day of this series is an event.

• Each event contains markets on the temperature: [68° to 69°] or [69° to 70°].

Each market contains a “yes” and a “no” with an associated order book. What’s an orderbook you ask? Let’s get some terms out of the way…

Every trade on Kalshi is a match made between a maker and a taker. Just like in our “contrived” scenario that for sure never happened, makers/takers trade against another person on Kalshi, not the platform itself. Instead of buying shares in a stock, you buy a contract that resolves to $1 if you’re right and $0 if you’re wrong.

As price-sensitive rational actors, I’m willing to put up $10 to win $20, and so is my wife’s boyfriend. With these bets in hand, the event has an implied probability of 50% (10/20). In “event contract” terms:

• We break this down into twenty $1 contracts

• Each contract is an agreement that we both lock in $.50

• At resolution, the winner gets to keep the other’s $.50

As trading heats up, it becomes helpful to track activity with an order book.

There are many different ways to display order books. They typically show resting orders, whether someone is buying or selling, how much they are buying or selling, and when the order was placed.

The bids contain all the people looking to buy, and the asks contain all the people looking to sell. In the example above, the bids and asks have been ordered from best to worst price. The gap between the best bid (highest purchase price) and best ask (lowest selling price) is called the spread.

In a liquid market, like the Super Bowl, the spread is razor-thin (maybe 1 cent). In an illiquid market, the spread might be massive because nobody cares enough to take the other side. This is why Kalshi offers incentives for both liquidity and market making.

Looking back at our order book, when a Market Taker decides $0.52 is a steal, he trades 50 contracts with my mom (you can see her on the bid side). The price of the asset just “moved” to $0.52, and that bid falls off the book. That is Price Discovery, or better said, the market is assigning a probability. The degens have updated the likelihood of my liver failure to 52%. Things look different looking at an actual orderbook from Kalshi:

You’ll notice a “yes” and “no” side to this order book. Contracts on Kalshi can resolve to “yes” or “no”, and traders buy/sell both.

• On the yes side, we have 13 contracts for sale as low as $.44, and 58 can be bought for $.42 with a spread of $.02.

• On the no side, we have 58 contracts for sale as low as $.58, and 13 can be bought for $.56 with a spread of $.02.

Wait… that looks funny. Why is everything inverse of each-other? Why do the bids for “yes” and the asks for “no” have the same number of contracts and the prices $.42 and $.58 sum to $1? Because buying yes is the same as selling no.

Now that we have a grasp of resting orders, how does matching work?

Kalshi uses a price and time priority algorithm on their central limit order book to match orders. On the surface, this is as straightforward as it sounds, orders are prioritized based on price and then time of submission; however, building an exchange and processing these orders at scale is not so trivial. If you want to know more about matching engines, I’d highly recommend DataBento’s write up. On Kalshi’s exchange, orders must be fully collateralized, so trading on margin isn’t a thing… yet.

For a while, MIAXdx via miax was the clearinghouse for contracts traded on Kalshi’s exchange (a central place where transactions occur). MIAXdx used to be called LedgerX, but miax acquired and renamed it through… drum roll please… FTX’s bankruptcy proceedings! After a while, Kalshi was like “we want our own clearinghouse”, so they built and registered Kalshi Klear with the Commodity Futures Trading Commission in August 2024. Just to take this full circle, Robinhood recently bought none other than… LedgerX from miax!

The Data

I hit Kalshi’s markets endpoint and trades endpoint to get historical data on ~30 million markets, 203 million trades, and over $41,700,000,000 in total volume.

Where is all this volume coming from? Kalshi generates significant traffic directly to its website and app. It has also partnered with some futures commission merchants (FCMs), that facilitate futures trading by accepting contracts on behalf of their clients. You may know them as that place you moved your IRA into… Robinhood, that place where pre-teens trade… WeBull, and that other place you have your shit-coins with… Coinbase.

The top events by volume were the 2024 presidential election at over $535 million dollars, followed up by the 2026 Superbowl winner at ~$244 million dollars.

Wait a minute… the Superbowl… is this just… sports betting?

Is this just sports betting?

Kalshi is regulated by the CFTC (Commodity Futures Trading Commission) which supervises U.S. derivatives markets. When I say “regulated”, what I really mean is “not regulated”. The Commodity Exchange Act (CEA) established the statutory framework under which the CFTC operates. This gives the CFTC authority to prohibit the trading of Onion Futures, but also to allow 18 year olds to trade contracts on Kalshi. Kalshi even boasts about “Minimum Age to Register & Participate” being 18+ in their FAQ section where they directly compare themselves to… sportsbooks. Sportsbooks are at the mercy of state governments, with some states banning sports gambling entirely and others requiring bettors to be 18 or 21+ (typically 21+).

Cool, but… Kalshi is different. You’re trading contracts against your peers, and they can be on anything. It’s not just sports, right? I’m not trading against the house, right?

Over 82% of contracts are on… sports. Kalshi is a volume business, the more contracts traded, the more revenue they gross in fees. All the better to be the first gambling platform for 18 year olds. By the way, they offer parlays, making up over 5% of total volume!

That other thing about not trading against the house… from Kalshi’s article titled “Who am I trading against”:

“Another significant player on the exchange is Kalshi Trading. Kalshi Trading is a separate entity from Kalshi Exchange… they are a participant on the exchange just like everyone else.”

If it smells like a sportsbook and trades like a sportsbook it might be a **loud gunshot, author collapses**.

Back to The Data!

There is a power law distribution of volume in these markets. Bucketing total volume in $, increasing by an order of magnitude, displays this quite well.

80% of the $0 volume markets are Combos (a.k.a multivariate events a.k.a parlays). Each one is a unique market that passes through Kalshi’s RFQ system with many not finding someone to take the other side.

With the same volume bucketing, splitting the buckets by how they resolved, we see that as volume increases, the percentage of markets resolving to “yes” also increases.

This shows that your base rate for any particular market should air on the side of resolving to “no”. The relationship with volume makes sense, events with significantly more markets should spread volume thinly across those markets with only one, or a few, resolving to “yes”.

Within these markets, average contracts per trade hovers around 150-250. Except for a massive spike in 2024 due to some 1,000,000 contract trades placed on the U.S. election. The median sits far under this, typically under 50 for most months.

Fees: Sportsbook vs Kalshi

If a sportsbook is like roulette, winning money through the odds offered, Kalshi is like poker, where the house makes money from the rake, agnostic to who wins or loses.

At a sportsbook, you’ll find “even odds”, lines that have a 50% chance on either side, like the coin toss at the Superbowl. Instead of giving you even odds, they’ll offer a 52.4% chance of heads and a 52.4% chance of tails, higher than reality.

• In a fair market, if you bet $10 on a coin toss you’d expect to win $10 if you choose correctly… but a sports book, with higher odds, will only pay you $9.09

On a sportsbook, if two people bet $10 on opposite sides of a coin toss, 1 person walks away with $19.09, 1 person walks away $0 and the Sportsbook walks away with $.91 or 4.5% of the total amount wagered. That 4.5% is what people call the vig, juice, hold, etc…

For example, the Islanders vs Devils market is, conveniently, 52.4%/52.4% on a sportsbook. On Kalshi, contracts are trading at $.51 (51%). So you should trade on Kalshi because you’re getting better odds at 51% vs 52.4% at the sportsbook, right?

No! The sportsbook offers worse odds, but the Kalshi taker fee of $.35 offsets this:

• Kalshi

  • Bet $10.55 (Buy 20 contracts for a total of $10.20 + $.35 fee)

  • To win $20

• Sportsbook:

  • Bet $10.55

  • To win $20.14 ($.14 more than Kalshi for the same bet size)

This isn’t the full story for all markets because Kalshi provides a liquidity incentive and a volume incentive. In addition, the Fee Structure is NOT the same for every market and Kalshi does pay you a yield on positions that accrues daily.

Fees: The Math

If you prefer your math in video form, check out Sam on the Technically YouTube channel:

What fees is Kalshi making on all this volume? First, we’ll look at the fees charged to “takers”. The formula is:

fees = round up(0.07 x C x P x (1-P))

Where C is the number of contracts and P is the price (ranging from $0.01 to $0.99).

We can plot this with the fee as a function of P and C. The price increases linearly as the number of contracts increases; this is controlled by P*(1-P) which, as you can see from the right chart, shows how the fees decrease as the underlying probability moves further from 50%, making highly likely and highly unlikely contracts have the lowest fees.

What we’ve discovered is the Bernoulli distribution. The Bernoulli distribution models the outcomes of a single “yes” or “no” question (in our case, a market).

• The variance of this distribution can be modeled as P(1-P) where P is the probability of “Yes”; the Y axis of the right chart.

• Variance exists between 0 and .25,

• Entropy (uncertainty or randomness in a probability distribution) is maximized at P = .5.

Why doesn’t Kalshi implement a flat fee, so we don’t have to make graphs? Likely due to trading concerns:

• If a contract costs 98 cents, the maximum profit you can make is 2 cents. If Kalshi charged a flat 2-cent fee, you would make $0 profit… no one would trade it.

Maker fees are identical in slope, they are just scaled down due to the .0175 multiplier, one quarter of the taker fee: fees = round up(0.0175 x C x P x (1-P)).

After downloading all 203 million historical trades on Kalshi, I know the exact price every contract has traded at. I can plug P&C into those equations and derive the total revenue Kalshi has generated from all these contracts… $545.6 Million dollars.

Here’s Kalshi’s trading volume by implied probability month over month:

Here’s Kalshi’s revenue from fees month over month:

It’s clear these markets are exploding in popularity, while DraftKings, Fanduel, and Fanatics scramble to the party. The, “We are basically doing the same thing but now it’s sudo-regulated and 18 years olds can do it” party.

Resolutions

An interesting resolution was when Dallas and Green Bay tied in an NFL game. The market resolved to 50/50 rather than yes or no, 100 or 0… there is no concept of pushing or voiding bets in a prediction market. When things get unclear, Kalshi steps in. In the data, Kalshi marks these results as “scalar”, with over 170,000 markets marked as such.

Market resolution seems to be fairly manual on Kalshi. They have a markets team that thoroughly reviews outcomes. Each market has an authoritative point of reference. For example, the superbowl lists out several sources and contains rules specific to the event. Despite all that, they still couldn’t figure out if Cardi B performed and resolved the market to the last traded price.

Polymarket said “Yes she did perform” which highlights how they do resolutions differently using UMA’s optimistic Oracle… but we’ll save that for another time.

Conclusion

With that, I have 9 beers to drink, and I’m way over my word count.

Quick legal side quest: There is another Prediction Market called PredictIT that specializes in political prediction markets. PredictIT is run by a firm called Aristotle that performs data mining for political campaigns. It was launched in 2014 as a nonprofit educational project out of the Victoria University of Wellington, New Zealand. To operate, they acquired a no-action-letter from the CFTC just like the IEM had, as they agreed to abide by certain guardrails and serve academic purposes. Then, in 2022, PredictIT got shlebanngged by the CFTC for NOT operating in accordance with their agreement. In 2025, they 360 no scoped the CFTC in federal court, and the “Cadillac of Prediction Markets” is back baby.

Anyways, basically, all these players in the “event contract” game are submitting letters and letters to the CFTC to not take action against them for failing to meet reporting requirements that they’d otherwise be required to perform. So far, the CTFC seems to agree, citing the “limited applicability of traditional swap reporting rules to exchange traded event contracts”. There’s other stuff here, like how Kalshi and Robinhood are classified, but suffice it to say that there are many conversations to be had in the future on how to regulate, tax, and manage reporting on these “new” entities.

1. The annual Technically reader survey is open until the end of the week.

2. Last week’s post (on vibe coding + the maker movement) from made the front page of Hacker News and roused quite a convo. To continue that convo, tomorrow Sachin + friends will host a Substack live session at 3:30pm ET to discuss whether we’re making anything of value when we vibe code, among other topics.

Now on to Palantir + the Forward Deployed Engineer role. Let’s give a warm welcome to Sung, who’s done technical sales at multiple software companies (most notably dbt Labs), on his first Technically post.

The TL;DR

The startup ecosystem is seeing an explosion of companies coining themselves as, “We’re basically Palantir, but for X.” Underlying that idea is the Forward Deployed Engineer, or FDE – think of them like a customer-facing engineer working directly with prospects and customers. The FDE seems to be all the rage right now…but is it actually a good idea for startups to have them?

This post will run through everything you need to know about FDEs, what they do, secular trends that are causing so many companies to want to hire them, and whether they actually make sense for most businesses.

If you prefer this post in video form, check it out on Technically’s burgeoning YouTube channel:

What is a Forward Deployed Engineer (FDE)?

A Forward Deployed Engineer (FDE) is a highly technical, customer-facing role where software engineers are embedded directly within customers to solve real-world problems. Originally pioneered by companies like Palantir, the role has become essential for AI, enterprise SaaS, and data infrastructure firms where products are too complex to be “plug-and-play.” Instead, someone from the vendor has got to get in there and make sure it actually works.

How is this different then a conventional technical consultant?

Technical consultants – think Accenture and the like – have been around for decades. Isn’t an FDE the same thing?

A lot of people had that same question when Palantir coined the role and it can be summed up simply. FDEs do highly custom work – like a technical consultant – but then take it a step further by generalizing the implementation and lessons learned into a core product. In Palantir’s case, an example is *Foundry, “*the foundational data operations platform, which provides the core capabilities for data management, logic authoring, Ontology development, analytics, and workflow development.” In a startup’s case, you’ll notice they use terms like “platform” which is analogous to providing the lego blocks to build use-case specific software vs. building from scratch every time.

How is this role different from a software engineer (SWE)?

SWEs are primarily internal and have minimal interactions with customers. The FDE, on the other hand, takes on the mantle of owning direct customer relationships. There’s usually a distinction, sometimes as subtext, that FDEs need high technical ability and emotional intelligence (EQ) to be effective in the role. If you’ve been in the workforce for years, you’ll recognize this combination is rarer than people think (or like to admit).

Why is this Palantirization narrative so popular now?

We don’t know what we don’t know

Deploying AI in production is hard, brittle, and constantly evolves. There is literally no such thing as best practice right now. For example, people were raving about vector databases to reduce bloat for LLM models retrieving context to perform tasks. But now, mainstream LLM models don’t need that infrastructure overhead because they handle 1 million tokens in their context windows; vector databases aren’t so hot anymore. Similarly, testing AI applications is an emerging art called “evals” that is in very early stages to even have convention. This builds a lot of anxious hesitation for anyone, even those on the cutting edge. You can imagine this feeling is more pronounced in large enterprises.

Only a real person can clear the fog of war

This then motivates the question of what’s worth retrofitting (think: slapping AI chat bubbles in your app) vs. replacing entire people, processes, and existing subscriptions. There aren’t enough role models in the industry yet, so companies need a real human with deeply lived experience to make sense of the constant change. To make this emotionally grounded, it’s like what a lot of people do when researching health problems with AI. It may give convincing general guidance, but you’ll want a real, human doctor to make big decisions and catch things you didn’t think to ask the AI.

Why can’t you be like Cursor?

The above couples tightly with the fact that expectations for being a “successful startup” have increased exponentially. Being a unicorn ($1 billion valuation) startup gave you pedestal prestige. But now, it feels like you have to be a decacorn ($10 billion valuation) startup to attain that same cachet. To reach that decacorn requires fast revenue growth, and the easiest way to get there is to win bigger sales deals that are six-figures on average vs. the 4-5 figures a lot of startups even 2 years ago saw as convention. This biases them towards going all-in on large enterprises.

But first, explaining enterprise sales

To understand the role of the FDE we must first take a detour to talk about old school enterprise sales.

In short, it’s a highly custom sales motion requiring many months, persuading and aligning multiple stakeholders and departments at a company, custom contracting, and “white-glove” onboarding. Some examples include buying a fleet of airplanes by a major airline. The airline likely won’t feel comfortable with standard pricing and contract terms with the swipe of a monthly credit card subscription. For software, the enterprise sales motion above was likely expressed in how your company bought slack or Microsoft teams, buying hundreds or thousands of seats in a single contract.

Working with enterprises is very very difficult

Let’s get a bit more meticulous with how selling to large enterprises looks and feels. The above affectionately termed “the decagon of despair” illustrates why enterprises are slow to buy new software, even if they really want it. I’ll belabor the point with questions that a potential customer thinks through when they see a demo or thinking seriously about buying.

• Institutional Inertia: Why is this worth doing extra work on top of my busy job?

• Charging Models: Do we get economies of scale as we expand usage of the product?

• Audit: What internal governing body/accounting firm will yell at me if we get this wrong?

• Capability: Does it solve the problem with a reasonable level of effort?

• Security: Does this touch the public internet? You got RBAC and SSO? SOC 2 Type 2?

• Outdated Paradigms: This mental model is the only one this org runs on (think: on-prem only)

• Regulation: What external governing body will yell at us if we get this wrong?

• Procurement: What’s a reasonable price to value?

• Legacy: Retrofit vs. replace?

• Change Control: Who is the project manager that keeps progress daily and maps names to scope?

These questions swim through an enterprise buyer’s head no matter how good a startup’s product is. It can be summed in an adage we’re all familiar with: “Change is hard.” Most enterprises aren’t willing to change with fancy slides, a demo, and even an undeniably great product. Enterprise buyers commit to a complicated, immersive relationship, and you need a face like an FDE to instill trust that it’s worth it.

Read more

First, there’s been a lot of change with Technically. We’ve assembled a pretty killer group of writers covering topics in new depth, from Will going in depth on data centers to Christy explaining why AI uses so many em dashes. In fact, Sachin’s post about vibe coding and the maker movement was the first post from Technically to ever make it to the front page of Hacker News, 6 years after I started this thing. It’s weird to transition from only-writer to editor and sometimes-writer, but this is good change.

The change in the labor markets is not necessarily good change. Last week Block laid off 40% of their 10,000 employees, despite the fact that “our business is strong” and “gross profit continues to grow.” Jack said it’s because of AI…but is that really true? Or did Block just overhire in 2020 – like everyone else did – and the time has come to pay the piper? For those of us using AI day to day, it’s hard to say we’re getting a 40% efficiency gain (as if that would even translate to an entire organization).

Quibbles about disingenuous headcount reduction aside, everyone seems to believe that more of these mass layoffs are coming. The story goes that AI is going to make entire swaths of workers obsolete, rendering them useless corporate husks who will need to resort to “get ready with me as an unemployed father of 3” reels to pay the bills. Grim indeed.

But even this change isn’t so clear. Like happened with previous waves of technological disruption, entirely new fields are opening up thanks to AI. Notion just opened up a new role for a “Model Behavior Engineer” whose job is to own the quality bar for Notion AI products. It’s a wacky combination of technical skill, good taste, running evals, and all-in-all doing a suite of things that completely didn’t exist a few years ago. Plus, contrary to popular narratives, job postings for software engineers – whose work is allegedly “a solved problem” by AI – are up 11% this year.

In fact, we’re seeing this in a quickly changing Technically subscriber base. Over the past few months we’ve been getting a ton of signups from industrial companies, from pipe manufacturers to railroads. New people are interested in software and AI, and how they can use it at work to make their jobs easier.

Bobby said it best in 1964: The Times They Are A-Changin. I believe that if we’re open minded, are willing to change quickly, and hustle a little bit, we’ll all be fine.

Which brings me to you. To make sure we're covering the right things for the right people, from time we run reader surveys. In last year’s survey, we realized that no one (not even us) knew what evals were.

Lend us 2 minutes for a 6-question survey, to share where we can help you become more technical this year:

Take the survey

The Maker Movement was the spiritual predecessor to vibe coding. The parallels are hard to miss. Vibe coding has slop. The Maker Movement had crapjects, a term the community coined for 3D-printed objects that served no purpose beyond proving you could extrude plastic into a shape. The Claude Code of that era was a $200 printer from Monoprice and a breadboard.

The scene around making produced what were probably the first internet-native network intellectuals. Chris Anderson (who wrote the widely-read piece about the long tail) left his editor-in-chief role at Wired to start a robotics company called 3D Robotics. Cory Doctorow wrote Makers, a sci-fi novel based around characters who are hacking hardware and business models to survive in a world where everything is falling apart. These were people who gained influence by participating visibly in a making culture and writing about what it meant.

A lot of the intellectual energy of the AI era orbits around AGI: when it arrives, what it’ll do to jobs, whether it will be aligned. The Maker Movement had its own gravitational center, and it was the idea that making physical things with your hands could produce an internal transformation. You would become more creative, more entrepreneurial, more self-reliant. The object you made mattered less than what the act of making did to you.

Puritanism With a Soldering Iron

In 2018, the media scholar Fred Turner published a paper that put this ideology under a microscope. His argument was that the Maker Movement had reinvented the theology of the Western Frontier for the digital age.

The specifics of seventeenth-century Puritanism are obviously gone. Nobody at a Maker Faire was talking about predestination. But Turner traced the literary forms and the millenarian structure—the belief that a great transformation is coming, and that individual discipline will determine who makes it through. In the Maker narrative, the American landscape is economically barren. Jobs have disappeared. Institutions have failed you. And in this wilderness, the lone individual searches inside themselves for signs of the entrepreneurial spirit, the creative spark, evidence that they are among the elect who will build their way to salvation.

Turner’s observation extends well beyond 3D printers. You can trace this same pattern through almost every hobbyist technology scene of the past fifty years. Homebrew computer clubs in the 1970s. Punk zines in the 1980s. The early web in the 1990s. Each one developed a community of practice—what Brian Eno would call a “scenius”—where people played with tools that the mainstream considered toys. Each one generated its own salvation narrative: master this tool, transform yourself, become the kind of person who builds the future.

And each one operated with a useful kind of slack. The tools were unproductive on purpose. Nobody expected your Arduino project to ship to customers. Nobody expected your homebrew computer to compete with IBM. The whole point was that you had permission to fuck around, and the finding-out happened gradually, through play, over years. This is where the old Silicon Valley adage comes from: “What smart people do on the weekends, everyone else will do during the week in ten years.”

What’s Different About Vibe Coding

Vibe coding broke this pattern in a way that matters.

Every previous wave of hobbyist technology went through a scenius phase—a period where small groups of weirdos played with tools before anyone expected economic output from them.

Vibe coding skipped that phase entirely. It was deployed directly to the general public, and almost immediately into the codebases of enterprise companies and well-developed products. There was no protected playground period. There was no time to accumulate the weird, useless, playful knowledge that scenius communities generate. Instead, there was immediate pressure to one-shot yourself into a hit product or solve a complex use case on the first try.

This matters because the scenius phase is where the internal transformation actually happens. When you spend two years making useless Arduino projects, you develop instincts about electronics, materials, and design that you can’t get from a tutorial. When vibe coding goes straight to production, you lose that developmental space. The tool is powerful enough to produce real output before the person using it has developed real judgment. When I speak with people who are on Claude Code 12-14 hours a day, I feel like I’m speaking to someone possessed by something, attempting to grasp a different reality. In the case of scenius, the feedback loop that tethers you to reality was provided by other humans. Someone looked at your project and told you it’s pointless, or brilliant, or both. While in the case of vibe coding, the feedback loop is provided by the machine, and you’re constantly attempting to discern if you’re going crazy or if something genuinely valuable has been produced.

What it produces is something like hypomania: a state where your productive capacity genuinely increases. You’re not imagining that you’re getting more done, you actually are, but your evaluative faculty is unaccustomed to this mode of creation. You lose the ability to distinguish between “this is good” and “I feel good making this.” Everything feels like a breakthrough. The output is real but your relationship to it is distorted.

The speed and ease of vibe coding create a kind of evaluative anesthesia. You can’t tell if you’ve built something useful or just something that exists. In some way, this is the sober version of hippies in the 60s trying LSD for the first time: sometimes you may have a breakthrough, or you may have a breakdown, but regardless of which, this is the opposite of the salvation through making that Fred Turner talks about.

The Maker Movement’s Quiet Ending

There’s a second reason the old transformation-through-making metaphor doesn’t fit vibe coding, and it has to do with how the Maker Movement actually ended.

The central promise—that distributed digital fabrication would bring manufacturing back to America, that every city would have micro-factories, that 3D printing would decentralize production—simply didn’t materialize. What happened instead follows a pattern that Joel Spolsky described years ago in his essay on commoditizing your complement: cheap 3D printers and Arduinos made prototyping nearly free, which was genuinely useful. But the deep, compounding knowledge of how to actually manufacture things at scale continued to accumulate in industrial bases like Shenzhen. Prototyping got democratized. The cheap tools commodified one layer of the stack and made the layer beneath it more valuable by comparison.

You can watch something structurally similar happening with vibe coding right now. People are rapidly prototyping tools that threaten to displace entire SaaS business models. But the value generated by all that rapid iteration and prototyping flows upward. It accumulates at the model layer, in the training data, in the infrastructure. The vibe coders themselves risk becoming interchangeable, each one spinning up impressive demos without accumulating durable value of their own. The pattern rhymes: cheap tools democratize one layer, and the layer beneath captures the surplus.

A New Metaphor: Consumption

With both of these forces at play—no scenius phase to develop through, and value accumulating upstream rather than with the maker—the old metaphor of transformation-through-making doesn’t hold up exactly. We need a new one.

The metaphor I’d offer is consumption.

Specifically: consumption of a surplus intelligence. AI represents an enormous amount of available cognitive energy, and vibe coding is one way of expending that energy before it goes to waste. Think of it like a resource that’s being generated whether you use it or not—and vibe coding is the act of channeling that surplus into play, into exploration, into rapid creation that may or may not produce lasting artifacts.

This framing has started showing up in various places. Rachel Thomas compares the experience of vibe coding something to the dark flow state when you gamble. The idea being that you are getting addicted to the superficial experience of creating, which might start off as flow, but eventually becomes something you are addicted to rather than something that helps you grow.

Consumption almost always gets treated as a negative behavior, especially if you’re an entrepreneur or builder. Consuming is what passive people do. Builders produce.

I think this framing is wrong, or at least incomplete. There are several productive ways to think about what consumption actually generates.

Taste as a Residue of Expenditure

When production becomes lightning fast with low marginal costs (when you can spin up an app in an afternoon), the scarce resource shifts to knowing what should exist. The vibe coder who burns through dozens of prototypes, building things and immediately discarding them, develops a kind of pattern recognition that the models themselves don’t have. This is judgment about what’s worth building, what feels right, what users actually want. It’s a sensibility, and sensibility is notoriously hard to commoditize because it’s illegible. You develop it by making a lot of things and paying attention to which ones felt alive and which ones felt dead.

The value capture here looks like creative direction, curation, taste-making, advisory roles. You’re selling the discrimination you developed by making things and throwing them away. The ideas guy is back. At the extreme end of this path, you become the protagonist of William Gibson’s Pattern Recognition: someone who has such finely tuned aesthetic instincts that companies hire them simply to say yes or no to something already production ready.

Attention as a Combustion Byproduct

Expenditure that’s visible generates spectacle, and spectacle generates attention. When you vibe-code something in public—building fast, shipping immediately, iterating in front of an audience—the product you make matters less than the performance of making it. And undoubtedly, much of vibe coding today is pure signalling performance.

The recent wave of “built this in a weekend“ posts works on this principle. The product is often mid. Sometimes it’s outright disposable. But the act of making it, timing the release, and dropping it into the network at the right moment is a performance of surplus, and people watch performances. The value capture is audience, reputation, and the optionality those create in the form of future collaborations, job offers, investor interest, consulting gigs.

This is structurally identical to how content creators already operate. A YouTuber’s individual video is an expenditure. The audience accumulated across hundreds of videos is the asset. Vibe coding just adds another medium to the content creator’s toolkit: instead of expending effort on essays or videos, you expend it on apps and tools, and you capture the attention the same way.

Projects as Gifts

If you treat your vibe-coded output as gifts—open source tools, free utilities, shared templates, public repos—you’re creating the conditions to occupy an interesting or powerful position in the network. Think of the people who built the early web’s most useful free tools and resources: They became nodes that other people oriented around.

The gift economy has always been the underlying value capture strategy of open source, but the consumption frame explains why it works psychologically for vibe coders in a way that the usual advice of “build open source projects to get hired” doesn’t quite land. When you frame it as strategic career-building, it feels transactional and a little desperate. When you frame it as expending surplus, it feels natural. You have extra cognitive energy available through these tools. You spend it. You give away what you made. And the gift economy does what gift economies have always done: it creates social bonds, reputation, and reciprocal obligation.

Signal Capture Before Upstream Absorption

Every time you vibe-code something, you’re generating signal. Signal about what users want. Signal about which patterns work. Signal about where the model fails, what edge cases it misses, what instructions it misinterprets. That signal currently flows upstream to model providers for free. Your prompts, your iterations, your corrections—all of it becomes training data for the next generation of models. You are, in a very literal sense, performing unpaid labor for the infrastructure layer every time you build something.

But informational exhaust can be captured before it drifts upstream. If you can structure the signal you’re generating—as proprietary datasets, as documented feedback loops, as systematic records of what works and what doesn’t in a specific domain—you end up holding something the infrastructure layer actually needs and can’t easily replicate. Every vibe coding session produces this exhaust as a byproduct. The question is whether you let it dissipate or whether you collect it. The people who collect it end up building what you might call a data fortress: a position that gets stronger with every prototype, even the ones that get thrown away, because the knowledge of why they failed is the valuable part.

This is the spirit of what early makers were accomplishing in the scenius. Trivial as their output may have been, they were immersed in the production process and through that developed a tactile understanding of their medium. With vibe coding, that data is generated for free. Will you use it?

***

Consumption doesn’t have to be passive. Surplus can be spent well. The key distinction is whether you’re burning energy with some awareness of what the combustion produces—taste, attention, social capital, structured signal—or whether you’re just spinning up a dozen projects and wondering why none of them stick.

Personally, I find the consumption metaphor to be a good way to deal with the burnout that comes with constantly using AI for various things. A lot of people approach making things with the mindset of craft, and naturally extend this framing to vibe coding. That framing feels noble and it’s deeply familiar, but it’s also a recipe for burnout, because craft assumes you are reaching inside yourself and pulling something out. The whole emotional architecture of craft is transformational: you struggle, and develop mastery, and the object you produce is evidence of inner change. When the tool is doing most of the producing, that framework starts to collapse. You’re left reaching inward for something that the process never required you to develop, and the gap between the effort you expected to invest and the effort that was actually needed starts to feel like a personal failure rather than a feature of the technology.

The consumption framing sidesteps this entirely. You’re not reaching inward. You’re starting from the position that there is extra energy available and it needs to go somewhere. The question shifts from “what does this say about me as a maker” to “what’s the most interesting thing I can spend this on.” That’s a fundamentally different emotional posture, and in practice it’s a much more sustainable one.