After I got the offer I had a heart-to-heart with the hiring manager, and he said something that’s always stuck with me. What I saw as my prestigious debut into the ranks of the engineer, he wanted to make sure I understood as essentially high-risk manual labor. How thankless success could feel, no matter how much work I’d put in, but more importantly, how severe — and public — the consequences of my errors would be.

“DevOps is a sharp blade”, he said.

By which he meant that when you slip up, when you accidentally remove access, overload a database, or delete an S3 bucket, it cuts deep. When Netflix or GitHub goes down, it’s generally not because a front-end engineer made a button the wrong color or because a backend engineer forgot about daylight savings. It is, without fail, usually a fuckup at the infrastructure level. These mistakes are catastrophic.

Infrastructure as Code (IAC) frameworks, which have gone from turbo-nerd side projects to ubiquitous in only a few years, help the people who build and maintain infrastructure make fewer of these costly and embarrassing mistakes. As the volume of code shipped explodes with the rise of AI-powered tooling, having dependable infrastructure to run it on only gets more important. As such, it has a special place in my heart, which is why I’m writing about it.

Before we get into how IAC helps, let’s back up and refresh ourselves on the basics of provisioning cloud infrastructure and how easy it is to get in trouble in the AWS console.

Ye Olde Way: Become Ungovernable

Your garden-variety application these days runs on infrastructure hosted by cloud service providers like AWS and Azure. Most applications need a database to store and retrieve data, a web server to host the web app you click around in, another server to host the API, and a long tail of other things like file storage, search indexes, network load balancers, etc. This plethora of infrastructure needs is exactly why AWS is such a big business; their customers need a lot of things.

You need a database? Sure, I’ll make you a database. On AWS, this is what it looks like to spin up a database.

There are similar menus for the other server types we need, and yet more menus to ensure they can talk to each other over the network and are securely open to the internet so your users can… use them. These menus exist because infrastructure is essentially infinitely configurable. There are simply very many knobs and buttons because every customer needs something slightly different. So you end up with a screen like this.

If your application requirements never change — you never need to handle more traffic, you never add more features, you never need to fix bugs or patch security vulnerabilities — this system works quite well. For my app that predicts how long Chicago train delays will last, this is exactly what I did! I clicked through menus to get the infra I needed and never touched it again.

But real applications differ in (at least) two key ways from my train delay app.

They evolve. New features, growth, and software updates all require changes to infrastructure. A series C company I talked to recently said they make about five changes to their infrastructure a week.

There are many people involved. Different teams need to make infrastructure changes at different times. That same company I talked to has one infra team member for each of their eight engineering teams.

If the infra team in question were to log into the AWS console to create, change, and maintain infrastructure 5 times a week for 8 different teams, a few things would break down badly. And as we know, when things at the infra layer break down, bad, bad, stuff happens. Here’s what you can expect to go down if you stick with click-driven infra management:

Collisions and chaos: Without a centralized and auditable place to make infra decisions, people step on each other’s toes. What to one team may be a routine database version bump may break core functionality in another team’s features. There is no way to tell what some configurations depend on, and nothing to stop two engineers from going in and making the changes that are optimal for their team at the expense of another one.

Quality issues: In application code, the pull request serves as the official proposal of a change, which almost always requires a review and approval before merging in. Provisioning infrastructure via the console lacks any review process, and thus bad configs can sneak in and go straight to production. You are just a single click away from disaster. This is pretty perverse given how dangerous mistakes at this layer can be.

Cost drift: Humans tend to create the infrastructure they need eagerly and tear down the infrastructure they don’t need lazily (shout out my old unused Google Cloud API server, which I get billed 53 cents for every month, luv u). Without a system to track what’s actually needed, resources tend to accumulate, and that costs money.

Unrecoverable disasters: When things do go wrong, and they always will, click-driven infra lacks a coherent way to step back through the changes that were made to return to a stable state. If you’re lucky, someone wrote down the plan and took notes on what they did. But let me ask you. Do you feel lucky?

The point here is that in ye olde days (or today for some companies), infrastructure lacked governance. Which is to say there was no central system to review and approve proposed changes, implement those changes, observe them, and roll them back if needed in a cost-efficient way. To solve this problem, infrastructure engineers borrowed from the very masters they serve: coders.

The Way Nouveau: Infrastructure as Code

The problems above are not unique to infrastructure; they’re just uniquely painful for infrastructure teams. The same needs for governance, including centralized management, observability, deployment, and rollbacks, exist for regular old “code’ and predate the management of cloud infrastructure by a few decades.

Things get complex when multiple engineers are working on the same, shared set of code. Ergo, people who write code need to review and approve changes to that code before it goes to production. They also need to understand change history and roll back when things go sideways. They did this by inventing and using Git, which allows users to collaborate on and govern code in text files. And it works! Git certainly has its issues, but it has become the de facto way engineers work on code together, and the world has remained intact.

Cool, easy. So let’s just do that for infrastructure, right?

The issue is that infrastructure isn’t code you write; it’s things out in the world, in data centers. It is real physical items. Git only works on text, on code. End of the line, right?

Wrong. The fundamental shift is to start thinking of infrastructure as code. By enshrining infrastructure requirements in text files, you make infrastructure tangible, unambiguous, and something on which multiple people can collaborate.

Enter Terraform

IAC has been around for much longer than it has been popular. In its purest form, IAC can be a script that spins up servers with command-line commands. Terraform, however, created by HashiCorp in 2014, really invented modern IAC and remains the most popular framework due to its strong community support and cloud-agnostic approach (it works with AWS, GCP, and Azure).

Its core idea is simple: what if you could describe all of the infrastructure your application needs in a text file, and then have a tool go out and make it real?

Here’s what that looks like. Say you still need that Postgres database on AWS. Instead of clicking through the console, you write this:

resource “aws_db_instance” “my_database” {

  engine         = “postgres”

  engine_version = “15.4”

  instance_class = “db.t3.micro”

  allocated_storage = 20

  db_name        = “my_app_db”

  username       = “admin”

  password       = var.db_password

}

That’s it. That’s your database. You open your terminal and run terraform apply, Terraform talks to AWS, and a few minutes later you have a running Postgres instance. Need to bump the engine version? You change 15.4 to 16.2 in the file, run apply again, and Terraform figures out what needs to change and changes it.

There are three layers to understand here.

Terraform itself is the framework. It’s the engine that reads your .tf files, figures out what infrastructure currently exists, compares it to what you’ve described, and makes a plan to reconcile the two. It doesn’t know anything about AWS or Google Cloud or Azure on its own, it just knows how to understand the state of the world and orchestrate changes.

Terraform Providers are plugins that teach Terraform how to talk to specific platforms. AWS maintains the AWS provider. Google maintains the Google provider. When you write resource “aws_db_instance”, the AWS provider is the thing that actually knows how to call the AWS API and create that database.

Terraform code itself is written by infrastructure engineers (or DevOps engineers, or platform engineers, depending on what year it is and how your company thinks about titles). They write tf files, commit them to git, open pull requests, get reviews, and merge. Just like application code. Once the .tf file is merged, someone can apply it, but more often this is done by a GitHub action in CI/CD.

This setup solves a number of the problems we talked about above:

Collisions go away because infrastructure changes now go through pull requests that carefully specify what depends on what. When Team X wants to bump the database version, that’s a diff in a file that Team Y can see, review, and flag before it goes live.

Quality goes up because changes get reviewed. A senior engineer can look at a proposed config and say “hey, you left this database open to the public internet” before it ever touches production.

Cost drift gets easier to manage because your .tf files are the source of truth. If a resource isn’t defined in code, it shouldn’t exist. Teams can audit what’s declared, compare it to what’s running, and kill the stuff nobody asked for. (My 53-cent Google Cloud server would not survive this process.) In highly automated shops, not only will Terraform flag infrastructure it doesn’t recognize, it will literally destroy it for you.

Rollback becomes possible because you have a version history in Git. If something broke after the last apply, you can see exactly what changed, revert the commit, and apply again.

One thing people especially like about Terraform is that it’s declarative. You describe the end state you want, not the steps to get there. You say “I want a database with these properties,” and Terraform figures out whether that means creating one, modifying one, or destroying and recreating one. One file to rule them all. If it’s not in the .tf file, it shouldn’t exist.

Now, I’m being slightly disingenuous here. The massive menu of options and clicks isn’t the only way to work with infrastructure in cloud providers. They also offer APIs, CLIs, and even their own cloud-specific IaC tools like AWS’ CloudFormation. But these lock you into a single provider’s ecosystem and syntax. Terraform was built broad by design, giving you one declarative language that worked across all of them, and a plugin model that let the community extend it to practically any API-driven service.

Everything everywhere all in code

To this point, we’ve been talking about real “capital I” infrastructure: databases, servers, networks. But it turns out engineers love the declarative, centralized governance that Terraform affords them. More and more companies are shipping Terraform providers that allow engineers to manage anything in their app declaratively via Terraform, not just servers.

Database tables in the warehouse are one example. Typically, you might see an infra engineer use Terraform to create a database, but let data engineers create tables by connecting directly to the database and running “create table order…” in SQL. This works, but again suffers all the consequences of being ungovernable. By setting up the data team to use Terraform, the folks closest to the data can enshrine and evolve table definitions in code and keep the warehouse in ship shape.

Another really interesting evolution in the utility of Terraform has been around permissions. Permissions – which engineers have which kind of access to which infrastructure resources – are notoriously ungoverned. People need permissions quickly, slacking whoever is the path of least resistance for admin access to broad swaths of company data. They also rarely give up permissions when they don’t need them anymore, and an admin looking to get a picture of who has access to what is in for a world of pain. You’ll never guess what I’m about to say, but managing permissions in Terraform makes for a more orderly, auditable, and safe operating model.

There are, of course, some downsides to managing infrastructure and other application objects via Terraform.

Centralization can kill local velocity. If you used to be able to create database tables in SQL, and now someone tells you you have to ask the infra team to make a .tf PR, that’s going to slow you down and be annoying. Ultimately, the benefit of using IAC is a more global benefit that accrues slowly at the company level, and for this reason, it can feel heavy for smaller application objects.

The best system will be centralized where it matters (databases, k8s clusters) and delegated where it doesn’t (you should be able to create and manage your own GitHub repos, which have very little downside potential). The middle is where being thoughtful is important.

You have to learn Terraform. If your org is cool and allows you to manage your own domain resources via Terraform, you still need to learn a new language, Hashicorp Configuration Language (HCL). Again, globally and over time, this is great, but in the short term, it’s kind of annoying. For that matter, depending on what you were using before, you may have to learn git. Pulumi, a series C startup, is making progress on this front, allowing engineers to write infrastructure specs in almost any language, but has some ground to make up if it wants to compete directly with Terraform.

Fear not the blade

When I PM’d our search functionality at Prefect, which was just before AI-coding tools really took off, we had a pretty typical eng team set up to make it happen: one backend engineer, one front-end engineer, and a platform team member who wasn’t exactly in the squad, but was our go-to for infrastructure-related requests. Early on, we identified the need to spin up some search infrastructure and let our platform guy know. Then, for a month or so, we built the feature while he worked on setting up Elasticsearch with about 20% of his time. After all, the application code was the slowest-moving part of this process; he had a few weeks before he really had to care.

AI is changing the role of infrastructure, platform teams, and Terraform in the workplace. If we built this same feature today, the front end and back end would be done in a matter of days, if not hours, and the bottleneck would move to the infra team. This is happening in every company that’s seriously adopting AI programming tools.

I see a few ways this could play out in the near future.

Hire more platform engineers. This is the default answer when certain capabilities become a bottleneck. It tracks to me that infra is theorized to be one of the last four jobs.

Let the AI write Terraform. This would close the productivity gap, and after all, it’s just code, right? This will probably happen to some extent, but it’s also dangerous (did you know that the blade is sharp??). If platform teams do this, it will need to come with appropriate guardrails and review steps.

Further job collapse (or, the democratization of DevOps). We’ve already seen AI collapse the product manager and engineer jobs into one. Product managers in title are increasingly expected to be able to vibe code MVPs and contribute to codebases directly, and engineers are expected to prompt LLMs into Product Requirement Documents. I think we’ll continue to see LLMs enabling sharp engineers to annex the territory of their former neighbors. With this evolution, engineers will not only be responsible for their application code, but also for the infrastructure and associated .tf code. Platform teams will shift to a higher-level strategic and enabling role, rather than authoring all the .tf code directly.

As AI floods production with more code than we ever thought possible, a strong foundation is more important than ever. DevOps is still scary. It was scary before Terraform, and it’ll be scary as long as infrastructure slips cut deep. But now, we have governance that helps us avoid the worst of the nightmares of yore.

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 logistics of those million things, and more on the actual website they want to build

• Most web frameworks are specific to a particular programming language, like Django to Python or Rails to Ruby

• Next.js is one of the most popular web frameworks today. It’s free and open source, but managed by the Vercel team

Pretty much every website or app you’ve loaded up in your browser is using a web framework of some kind, and they’re some of the most crucial parts of the open source infrastructure ecosystem.

Announcing: Computer Class

Computer Class is a new call-in show for helping you through the burning issues blocking you at work.

If you’re familiar with classic shows like Car Talk, Loveline, and Stavvy’s World, you know the drill.

Leave an anonymous voicemail to (575) 500-4680, and Technically correspondents will do their best to help you untangle it.

Please keep questions related to software, AI and work (especially startup) situations. Our expertise doesn’t (yet) extend to pet care or tax advice.

We think this will be very fun. To keep up the “anonymous” vibe, please speak in generalizations like a banker discussing a deal (“I work at a hyperscaler”, not “I work at AWS”).

(575) 500-4680

Background: what a web framework actually is

To understand Next.js, you first need to understand the general role that a web framework plays in the life and times of a developer. And to understand a web framework is to understand all of the crazy things going on behind the scenes when you load a web page. So what actually happens when you type `mail.google.com` into your browser1?

I’ll save you the hassle of thinking about really low level stuff, like signals traveling through the air and everything. Here’s the basic gist of what’s going on:

1. You type `mail.google.com` into your browser and hit enter

2. The browser figures out which IP address that `mail.google.com` URL maps to

3. The browser connects (or tries to connect) to the server with that IP address

4. The browser requests the web page from the server via HTTP

5. The server responds with either the webpage, or a reason it can’t return the web page

6. The browser shows you the webpage, or why it failed

These are the main steps, give or take a few. DNS – the dreaded and feared system that connects the URL with the IP address of your app’s server(s) – is responsible for the first two steps. Where web frameworks fit in are steps 3, 4, and 5 – when the browser requests the web page that you want, and the server sends that webpage back to you.

This all may seem simple on the surface, but is actually very not simple. A developer starting an app from scratch often finds themselves wondering:

• How do I pick which file of code gets returned for different URLs?

• What happens if someone requests a web page that doesn’t exist?

• How do I organize different pages to be under different URL routes? (e.g. `mail.google.com/filters/filter-1`)

• How do I restrict certain pages to users who have signed in?

Your server needs to act like an air traffic controller, deciding which planes land, when, and where. There are constant requests coming in from all different types of planes needing all different types of things, and building all of the programming logic to handle it is a lot of work. This is where a web framework comes in: it gives you a nice, comfortable environment that has the building blocks to do all of these things for you.

🚨 Confusion Alert 🚨

The term “web framework” can be very broad, and some developers might use it to refer to any framework that deals with web, including frontend frameworks like React or Redux. In this post, I’m explaining the more traditional version that deals with the basics of a web server.

Web frameworks are usually programming language specific, meaning that there will be different ones based on which programming language you want to use. A few examples:

• If your backend is in Python, you can use Django or Flask

• If your backend is in Ruby, you can use Rails or Rack

• If your backend is in Java, you can use Spring

• If your backend is in JavaScript, you can use Next.js, Angular, Meteor, so many…

If you use a framework like Next.js, there will be specific, codified ways of doing things; if you buy into their system, you can avoid all of the low level HTTP work and get apps up and running quickly. Each web framework has a different way of answering those questions above – some slightly different, and some very different – and which one a developer chooses is as much about their programming language of choice as it is about which answers they like and don’t like.

Opinionated web frameworks vs. general purpose web frameworks

In the universe of web frameworks, there are types that are more opinionated and less so. If picking a web framework is kind of like joining a club – you get structure and special privileges, so long as you agree to follow the rules – then opinionated web frameworks are clubs that have a lot of rules. Structure isn’t necessarily good or bad. The more you have, the easier it is to make choices and standardize on a good output. But if you don’t like the rules, you’re not going to have a good time.

To make this more concrete we can take a look at two popular Python web frameworks, Django and Flask. Django is an opinionated web framework, and Flask is an un-opinionated web framework. How does that manifest itself?

Django has a lot of rules:

• Files need to go in specific folders, or Django won’t recognize them or where to send them

• You need to create a specific file with a specific name to specify which URLs you want different web pages at

• To create web page templates, you need to follow Django’s specific syntax and file structure

But because those rules are so rigid, you can get a lot of value that you wouldn’t be able to get if you had complete flexibility. Django ships with a built-in admin panel for managing your user data and an ORM to play nice with your database of choice. Plus lots of other nice things like automatic sitemaps, an RSS feed, etc.

🖇 Workplace Example 🖇

When I was working at Retool, the Django Admin Panel was one of our biggest competitive alternatives that we had to sell against.

Flask, on the other hand, is not opinionated. You need to manually define every URL and what web page it maps to. You need to manually spell out every possible HTTP method that you want a URL to support, and hard code it. The building blocks are, in a sense, lower level – you can do a lot more with them, but it takes a lot longer to get started.

Opinionated isn’t better or worse: some projects, and some developers, are better fits for one particular type of web framework. It really just depends on a million factors.

Next.js is an opinionated web framework for JavaScript, specifically React

This lengthy (sorry) context brings us to Next.js. It’s a web framework like any other, but there are 3 main things you’ll want to know:

1. Next.js is highly opinionated. Like extremely so

Next.js is a textbook opinionated web framework. There are tons and tons of rules: where files need to go, what you need to name functions, etc. But the upshot is that it’s unbelievably easy to get started.

For example, if I want to create a new page for the technically.dev website at technically.dev/sponsorships, I need to create a sponsorships.js file in a folder names pages (or a folder named app in the newer versions). But Next.js takes care of all of the work of actually creating that page and serving it when someone types in that URL.

2. Next.js is specific to React

Most web frameworks are specific to a programming language; Next.js is specific to both a programming language (JavaScript) and another framework, React. If you haven’t heard of React, it’s a framework – some would call it, too, a web framework – for building interactive UIs, like the one you’re reading this in right now.

For better or worse, React is one of the standard tools that developers build frontends with today, and Next.js is all in on it. If you want to use Next.js, you need to use React.

3. Next.js is focused on performance

Unlike a lot of other web frameworks, Next.js focuses a lot of their feature set on helping you make your website faster and more efficient. A few examples:

• You can tell Next.js which pages a given page links to, and it will automatically preload them so if a user clicks a link, that next page (no pun intended) will load fast

• You can tell Next.js if you want something to render on the server or on the client

• Next.js handles caching automatically so your app doesn’t need to run requests every time someone loads a page

The TL;DR on all of this is that there’s a clear path to making your Next.js really fast and performant without needing to build tons of middleware yourself.

Personally, almost all of the projects I’ve built are in Next.js, including the award winning2 technically.dev website. It’s both easy to get started in and packed to the brim with advanced features.

Vercel vs. Cloudflare tickets on sale

Next.js is in a bit of an odd situation, in that it is owned and maintained by a for-profit company (Vercel) even though it itself is free and open source. This is not the case for any other web frameworks I’m aware of, save for maybe Gatsby. And because Vercel runs Next.js, they’ve been able to build a few very convenient integrations between the two.

Vercel provides a sort of frontend cloud – like AWS, but for your frontend, not just databases or app servers. So when you deploy your Next.js app on Vercel, you get a bunch of nice features like automatic API generation, really fast builds, plus the ability to automatically redeploy your app when your team makes any changes to the GitHub repository that it’s in.

Not everyone is happy about this situation. They feel that Vercel being for-profit is a conflict of interest with the open source existence of Next.js – and this leads to undocumented behaviors, lack of clarity around roadmap and releases, and an overall less vibrant OSS ecosystem around Next. Major security incidents, like this one, tend to reignite this perennial discussion (see, for example, this Netlify blog post).

This all came to a head recently, when thanks to the magical powers of AI agents, Cloudflare was able to “rebuild” Next.js themselves and release it. Their initial posts on X framed this release as a sort of “liberation” from the evil clutches of the Vercel team, which obviously bothered them. Jabs ensued, for example:

Now there’s at least some degree of Vercel <> Cloudflare beef, e.g. this recent spat about forking just-bash. You’ve got to love the internet, folks.

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 statistics. Erik Brynjolfsson later coined the term “productivity paradox” in 1993 to describe this very phenomenon. The massive investment in information technology through the 1970s and 1980s produced no measurable uptick in productivity growth. It took nearly a decade of organizational restructuring before the gains showed up in the late 1990s. We may be in a similar lag period with AI.

One answer to why this delay happens may lie in how early technology develops through the under-studied activity of kit-making.

A kit is a set of components that are meant to be tinkered with and have no single “correct” method of usage. Steam engines were famously kits. In 1763, James Watt was asked to repair a scale-model Newcomen steam engine at Glasgow University. The job led him to see how wastefully the Newcomen design used steam, and a year and a half later he hit on the idea of a separate condenser — building his first prototype using a brass surgical syringe as the cylinder. When he partnered with Matthew Boulton to commercialize the design, they didn’t produce finished steam engines. Instead, they sold engineering kits with extensive instructions that required on-site assembly. Boulton & Watt made a killing and transformed their age. Someone even named a startup incubator after them.

This rough template has foreshadowed technological revolution ever since. Whether in radio, automobiles, aircraft, electronics, or personal computers, communities of talented kit-building amateurs have disproportionately influenced early innovation. Michael Schrage, a research fellow at MIT’s Sloan School, puts this well: kitonomic innovation doesn’t follow the money, the money follows the kits. The proliferation of cheap kits signals a market sector ripe for revolution more reliably than the presence of expensive cutting-edge products. On the influence of kit-making on the information age, he writes:

So while there may be no “Steve Jobs of Kits” yet, there is surely no Steve Jobs without kits. There’s no Bill Gates or Akio Morita without kits either. Their market-transforming entrepreneurial leaps all emerged from kit-enabled cottage industries. The two Steves — Jobs and Wozniak — literally built Apple from kits. Gates and Paul Allen started Microsoft as a software systems supplier for DIY computer kit builders. Morita and Masaru Ibuka launched Sony with kits to turn AM radios into shortwave receivers. From the prewar “cat’s-whisker” playfulness of crystal radio kits to postwar floods of surplus electronics, kits became a medium, mechanism, and marketplace for next-generation invention.

Even within kits there is an important difference between amateurs tinkering to make money directly from the technology itself, and users repurposing kits to interpret a technology in a way that fits their own context. The first kind of kit-builder is someone like Wozniak at Homebrew, building computers because the computer itself is the product. The second kind is a farmer in 1915 Iowa jacking up the rear wheel of his Model T to run a corn sheller. He doesn’t care about the car as a product. He cares about shelling corn.

Users Interpret New Technology

There is an excellent paper by Ronald Kline and Trevor Pinch arguing that this second kind of creativity, what they call the “interpretative flexibility” of rural users, is what eventually led to the production of tractors and specialized trucks. Their framework comes from the Social Construction of Technology (SCOT) tradition, which holds that different social groups assign different meanings to the same artifact. What counts as a “working” technology is not settled by engineering alone. It is settled by what communities of users actually do with it.

The paper documents how the period from roughly 1903 to 1950 was dominated by rural users employing automobiles in ways that manufacturers never intended and sometimes actively discouraged. Farm men saw the car not merely as transport but as a general source of power. As early as 1903, a Kansas farmer advised readers of the Rural New Yorker to block up the hind axle and run a belt from the wheel to a corn sheller, grinder, saw, pump, or any other machine the engine was capable of running. Cars powered washing machines, cream separators, water pumps, hay balers, wood saws, cider presses, and corn grinders. From the paper:

“A rancher even used a Cadillac to shear his sheep. A Maine farm man put a car to so many uses in 1915 that tax assessors did not know whether to classify it as a pleasure vehicle or a piece of agricultural machinery. Farm men also used their cars as snowmobiles, tractors, and agricultural transport vehicles.”

Then kit manufacturers took advantage of this. Although firms brought out kits to convert the car into a stationary power source as early as 1912, advertisements for these kits did not appear in large numbers until 1917, during wartime shortages of farm labor and horses. Some companies simply sold a pulley to be attached to a jacked-up wheel.

Eventually, most kit manufacturers realized that jacking up one wheel put undue strain on the differential gear, since one wheel would spin while the other sat stationary on the ground. Most kits were therefore designed to overcome the differential problem, taking power from the crankshaft or rear axle instead. The Lawrence Auto Power Company in St. Paul sold a $35 kit consisting of a tie-rod, two pulleys, and a metal stand that could operate a feed grinder, corn sheller, silo filler, wood saw, and cream separator.

More elaborate kits allowed the car to act as an agricultural tractor. Food shortages during the war led the federal government to encourage farmers to “plow to the fences,” which gave added incentive to buy tractors or conversion kits. Kline and Pinch found three prewar instances where farm men yoked the automobile to the plow. The conversion kits that came out in a flurry in 1917 typically consisted of tractor-like drive wheels, a heavy axle, reduction gears, a larger radiator, and forced-feed lubrication, selling for $97.50 to $350. They counted twenty-two companies manufacturing these kits.

Then came what Kline and Pinch call “closure.” By the late 1910s and 1920s, manufacturers like Ford had observed these “creative” uses by people of the farm and ergo started producing dedicated tractors and trucks as specialized products. Ford told its dealers in 1916 that it did not want them converting Ford cars into trucks and other makeshifts not sanctioned by the company. Ford released its first one tonne truck in 1916, hoping to put an end to truck conversion kits. The American Tractor Association, a powerful trade group, even requested that the War Industries Board prohibit entirely the manufacture of kits that converted automobiles into tractors. Even though commercial tractors were available in 1918, widespread use of kits continued well into the great depression, until the New Deal when families had an influx of capital to invest in specialized farm equipment.

Post-closure, the social interpretation of the car as a vehicle for transporting people stabilized. The interpretative flexibility that Kline and Pinch described completely disappeared by the early 1950s. Farm people had stopped using their autos for grinding grain, plowing fields, or carrying produce to town. Instead, they bought tractors and pickup trucks in large numbers. These new artifacts were ones that manufacturers had developed partly in response to the new interpretations of the car that rural users had pioneered decades earlier. As Kline and Pinch put it, “The users, so easily overlooked in writing the story of technology, had made their mark.”

The interesting bit about this for our argument is that this general-purpose use of cars, where they were modified and repurposed as farm equipment, is not something that shows up in economic statistics from the time. Kline and Pinch note that most of the kit companies seem to have led a relatively short life. The Pullford Company of Quincy, Illinois, was an exception, bringing out a $135 kit in 1917 and advertising it continuously until at least 1940. But most of these businesses were ephemeral. The products they made were local solutions to local problems, sold in small quantities to a dispersed population of tinkerers. Government surveys of the era counted how many farms had automobiles, tractors, trucks, and stationary gasoline engines, but they did not count how many farms were using a jacked-up Ford to run a cream separator.

Living in Experiential Kit Time

The kit stage in the development of a technology is characterized by rapid experiments from amateurs and tinkerers. Most of these experiments turn out to be just interesting experiments or remain relevant for a short enough time that nobody bothers to record them. Healthy innovation cultures need the human capital that this tinkering produces. But that human capital is invisible to economic stats.

Just like how people throw away or don’t look at vibe coded projects, they don’t attempt to remember or productize the general-purpose uses they engineer during the kit era. The focus is on the act itself, on developing tacit skills through doing. There is a local development of skills in a small group, but it is rarely documented because there is no time to waste on documentation. And besides, chances are that the project is not worth documenting to begin with.

The subjective experience of kit making is similar to a religious procession or participation in Burning Man, where you have to be there and do the thing to understand what the hype is about. The memory it generates lives in the public and embodied layers, in islands of early adopters and makers willing to put up with the jankiness of this stage of a technology’s development.

Kits and the Firm

In his 1937 paper “The Nature of the Firm,” Ronald Coase asked a simple question: why do firms exist at all? If markets are efficient, why don’t individuals just contract with each other for every task?

His answer was that firms exist to reduce transaction costs. The costs of discovering prices, negotiating contracts, and coordinating production are often so high that it becomes cheaper to organize activity within a single entity. The boundaries of the firm are drawn where the cost of organizing one more transaction internally equals the cost of doing it through the open market. In simpler terms, if you had to bid on an hourly paid engineer every time you have some work to do, your organization will not get much done.

But Coase’s framing leaves out the other half of the ledger. Paul Lawrence and Jay Lorsch, in their 1967 book Organization and Environment, showed something that will sound intuitive to anyone reading this with a desk job: that coordinating activity inside a firm isn’t free either. As organizations take on more diverse work, their teams become differentiated — they develop their own time horizons, their own goals, their own ways of thinking about problems. The engineering team working on production ready software will move at a different speed and have a slightly different culture than the R&D team working on a new AI product.

Holding those worlds together requires integration: liaison roles, cross-functional teams, and formal integrator positions whose entire job is translating between teams that no longer share a common frame. The more differentiated you become, the harder and more expensive integration gets. Integration is expensive, but the ability to integrate different functions and teams is also a defensible moat for a company. You may know from your own working experience that not all companies are successful at integration. Successful companies solve for integration over and over again at different scales.

One way firms have historically reduced both kinds of cost (external transaction cost and internal integration cost) is by creating an accumulated memory layer of the experiments and skills from the kit phase. From the Kline and Pinch paper, you could think of the tractor as a product of the skills and knowledge that accumulated through the general-purpose use of cars by farmers in the 1910s and 1920s, combined with the evolution of the underlying engine technology. Ford didn’t invent the idea of using an automobile engine to pull a plow. Farmers did. Ford’s contribution was to take that scattered, tacit knowledge and embed it in an organization capable of producing a dedicated gasoline run machine at scale.

This integration of information and skill was possible because the environment had become less uncertain - prior to the Second World War, most families preferred to use automobiles over tractors so as to avoid additional expenditure. Then the New Deal provided families with capital to invest in farm specific equipment, which created a larger, more stable market for tractors.

Similarly, the first Apple computer was an accumulation of kit-stage experiments at Homebrew computing clubs, combined with the R&D capabilities of Xerox labs. Firms turn accumulated memory of the kit stage of a technology into flows of capital through products. That process is itself an integration feat — pulling differentiated knowledge from workshops, labs, and factory floors into a single coherent artifact. This is undoubtedly a capability that only exists for the organization and not the individual.

To summarize, a modern firm accumulates memory in the form of organizational design, documentation, and specialization, then turns that into flows of capital and productivity through products. The really good firms keep doing this over and over again. Each product cycle is a chance to absorb what was learned in the previous kit phase and formalize it into the integration machinery — the roles, routines, and shared vocabularies that let differentiated subunits cooperate on the next product.

The Firm and LLMs

The firm’s traditional advantage was twofold: it could internalize transaction costs the open market couldn’t handle cheaply, and it could build integration machinery to hold differentiated expertise together under one roof. LLMs erode both advantages, but not symmetrically.

On the market side, LLMs are rapidly making it cheaper for an individual to find specialists, evaluate contractors, synthesize scattered knowledge, and write enforceable specifications — these classic transaction costs are collapsing fast.

On the internal side, the picture is stranger. LLMs can automate some integration work, but they also accelerate the pace and volume of output inside each subunit, deepening the differentiation that integration has to span. The interpretive burden of reconciling AI-assisted outputs across teams lands on individuals rather than disappearing. At least for now, internal integration costs in most firms are going up, not down. Several surveys of AI use in the workplace have shown that people are producing more work than previously and dealing with task expansion, scope creep, and ‘AI brain fry’.

This brings us back to the question we started with. If AI is so impactful, why isn’t it showing up in the productivity stats? The Solow paradox answer is that firms haven’t reorganized yet. The computer took nearly a decade to show up in productivity numbers because the organizational work — flattening hierarchies, redrawing workflows, retraining workers, rebuilding integration machinery around the new technology — took nearly a decade to do. We are in the same lag now but with a different shape. Inside firms, integration costs are rising because differentiation between individuals and teams is accelerating faster than integration mechanisms can adapt.

The intensification of work that people feel with AI use points to this increasing integration cost. Outside firms, transaction costs are falling faster than people have habits for exploiting them — workers are not yet used to reaching past the org chart and engaging with markets constantly, and firms are not yet structured to let them. Caught in the middle, the output of AI is real but illegible to the statistics.

What comes out the other side of this lag is probably a bifurcation. Firms that can afford the integration machinery to harness AI across many differentiated teams and individuals will get very large, because the returns to scale on that machinery are enormous once it’s built — the hyperscalers are already showing what this looks like. Anthropic for example is not just a research lab, it’s also involved in consulting, economics and media.

Firms that cannot afford that machinery will get very small, because the falling transaction costs in the market make the solo operator with an LLM stack a viable competitor to the mid-sized integrated firm. A single person with the right tools is, in a real sense, running a differentiated organization of one, paying none of the integration costs that would have made that organization impossible a decade ago. The mid-market — big enough to need serious integration but not big enough to amortize AI-era integration infrastructure — gets squeezed from both sides.

The productivity gains from this transition will without a doubt eventually show up in the statistics. But they will show up as the rise of a few enormous firms and a long tail of very small ones, with the integrated middle hollowing out. By the time the numbers confirm it, we will already have moved on to arguing that quantum computing, or whatever comes next, is failing to show up in the stats — forgetting that the kit stage is always invisible, and the reorganization always takes longer than anyone expects.

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 build myself, vs looping in the engineering team. We have a culture of being as independent as possible, without creating burden on other teams.

The most common use case I encounter is shipping a new landing page. I can open Claude Code (or any coding agent), describe the goal of the page, and voila, I have an MVP. However, the vibe coded result is just that: an MVP.

The dilemma then arises: should I ship it myself, or should I loop in engineering?

I’ve found that answering that requires considering two factors: consequences and ownership.

You build it, you own it

Even if a coding agent wrote every line of code, I still own the resulting product. I own both the successes and the failures.

So I need to consider:

What happens when what I shipped breaks? A formatting bug on an internal dashboard is annoying, but a 404 on a live page serving millions of users is an incident.

You could call this the blast radius. Is an issue just a nuisance to me + my direct team, or does it extend to our users + customers?

Who owns making the fix? Whoever is paged at 2am needs to have all the context to fix the underlying issue. For most production web infrastructure, this person is likely not me, the marketer.

Ship internal tooling yourself

Some of the most useful tools I’ve built with coding agents don’t need an engineer, because they never touch production infrastructure. Internal tools for data analysis or customer research don’t need an immediate fix if they break.

For example, each of the tools below took less than 4 hours to create on my own, and could even be public on the web by being deployed to Railway. They save me + our customer engineers tons of manual research time.

While not perfect, internal tools help me both understand behavior and solve problems in a much more automated way than I would otherwise.

This type of tooling is internal, not a core part of the product, used weekly by a few people, and if it breaks, the blast radius is mostly just my own time.

A few examples of internal tools I’ve vibe coded:

Template verification tool

Before admitting a company into Railway’s partner program, we ensure they have a template that meets our best practices guidelines. Verifying this used to involve a support engineer launching the template and QAing it.

Now, I have an app to verify whether templates meet the standards by just entering the URL. This enables me to be self-sufficient and makes verification fairly instant.

Awareness campaign metrics dashboard

In 2026, Railway is prioritizing broad-market awareness. This means sponsorships + brand campaigns. These are notoriously hard to track, particularly because they depend on metrics that we can’t directly collect, like YouTube views. I built a dashboard where I can enter links of YouTube videos and OSS tools we sponsor, and with the Youtube API and public `npm` data, map their engagement metrics and release dates over our growth metrics to view correlation.

Content quality checker app

Community is everything to us - which is why we’ve invested in our affiliate program to reward users who share about Railway.

As an exploration, I looked into what it would be like to automate monetary rewards (we call them bounties) for user-generated content.

This app takes a link or plain text and audits the content against a set of criteria to check for authenticity and accuracy. Note: this isn’t live, and purely a POC.

Claude Code has completely changed my workstream - by investing just a few hours into vibe coding a tool that’ll help me do my core work, I’m able to make more informed decisions while burdening adjacent teams less with new ideas.

When you need engineering

Going back to vibe coding that landing page.

What if it’s not just a landing page, but a completely new section of the site, at a new subdomain, with new structure. That makes it a bit more complex.

I’d need to consider:

Traffic and scale. What happens to the site if it reaches 1M daily users? At Railway, our website infrastructure is maintained by our engineering team - so we have load handling, caching, CDN configuration, and graceful degradation already in place. These aren’t things as a marketer I’d want to setup or own.

Security. If the page collects user data or touches payments, this is particularly important. Even simple landing pages can be subject to attacks. There’s no way I would vibe code anything related to our Stripe integration, for instance.

Defensive thinking. I caught a gnarly bug once where all the buttons on one marketing page broke, because we switched from capital case to sentence case, but button paths were hardcoded to capital case. An engineer might’ve caught this with defensive programming, but the coding agent did not.

Monitoring. Anything user-facing should have tests and checks in place so if there’s an issue, I know about it before our users do.

All of these combine to form the underlying engineering system.

Wherever possible, I much prefer to ship within existing systems that my engineering team has already set up, vs adding new systems myself. This allows me to iterate quickly, while leaving ownership to the engineers.

A few examples where I could implement improvements myself on top of existing engineering systems:

• Implementing a new landing page for partners when launching our partner program in September 2025. It used existing design components, existing form integrations, and existing web infrastructure. The only truly new piece was the URL and copy.

• Testing a new banner within the product experience that promotes Railway’s referral program. The banner design existed, and the GraphQL query for new users was already exposed to the frontend to show it to only a subset of users.

Railway’s partners page, mostly vibe-coded by me

The key insight here: while I am no frontend or design engineer by any means, I could self-serve growth experiments both on the website and within the product that are visual and copy-based, without introducing new infrastructure complexity.

How I choose when to vibe code

There’s a time and a place for non-engineers making code changes (in my case to web properties) with agents. For many of us, the time is now, so let’s pick the place.

Start with tasks you own end to end. If you own the outcome and have all the context for any fixes required, coding agents enable us to ship things we don’t have the skillset or time to do by hand. Research, internal tools, and analysis all fall into this bucket.

For frontend (web) work, separate ownership. Engineering maintains the systems, non-engineers build on top of those systems, with review. The key question is not “can I build this page”, it’s “does the system this page would live on already exist”.

Engineering-heavy work, like actual product implementation, should be owned by engineers. Non-engineers might implement MVPs to illustrate strategy and vision, but ultimately the user-facing stakes require engineering rigor in a production system.

The biggest shift coding agents have facilitated is where the handoff happens.

Non-engineers (in marketing, growth, dev rel, product, etc) have far more leverage today than we did a year ago. But for our use of coding agents to be sustainable, we have to work within the right boundaries, so we don’t get our friends in engineering paged at 2am.

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 away.

The product was a small AI/marketing newsletter called Growth Computer, and the brief was to get qualified subscribers at the lowest cost possible - ideally under $2.50 per lead. So I built an agent that could generate ad images, publish and manage campaigns via Meta’s API, spin up landing page variants, and pull its own analytics. It decided what to create, what to pause, what to scale, and how to spend the budget with no human intervention.

For 31 days, the only human input was typing /let-it-rip into a terminal each morning. About 2 minutes of my time, compared to the 1-2 hours a day a human media buyer would typically spend managing a campaign like this.

It didn’t go fully as planned, but there were plenty of learnings.

And a good glimpse at the potential future of “work”.

If you’re a fan of a good Excalidraw walkthrough, watch Giorgio cook here:

Why bother

I run Wibci, an AI consulting business focusing on building tools for marketing and growth teams. About 12 months ago I tried building something similar using n8n, a marketing agent that could analyze performance, generate creative, and manage campaigns without me. It sucked, because the models just weren’t built for long-running tasks that chain together over hours, days or weeks. They’ve since gotten better at this (it’s a major focus area for AI companies right now), which is what made this experiment possible.

Since then we’ve had a couple of LLM step-changes, and I rebuilt the whole thing on top of Claude Code. For any tech workers living under a rock, this is Anthropic’s coding agent (but calling it a “coding agent” undersells it at this point). It can read and write files, run terminal commands, and delegate tasks to separate AI workers that run in parallel. Each conversation starts fresh with no memory, but it reads its own notes from previous runs, so it builds on what came before. Developers started using it for non-coding tasks so often that Anthropic shipped a non-developer version called Cowork in January. It’s basically a general-purpose agent runtime, and that’s how I used it here.

The inspiration was Project Vend, where Anthropic gave Claude control of a real vending machine in their SF office, nicknamed Claudius. It went pretty badly at first since it lost money, got manipulated by employees, and had an identity crisis where it insisted it was a human wearing a blue blazer. But it recovered once they added better tools and guardrails. Same energy here, except the vending machine is a Meta Ads account and the stakes are my credit card. What could go wrong?

How the daily loop works

I won’t go deep on the technical setup here (there’s a longer breakdown if you’re keen). But the basic architecture matters because it’s not specific to ads.

Every day, the agent runs through the same loop:

1. Wake up fresh. Each day is a new session with no persistent memory in the model itself. In other words, the model doesn’t know anything about what happened yesterday or prior to that.

2. Read its own history. It spawns a sub-process that reviews every daily log from the experiment so far, then summarizes the strategic context. Now it does know.

3. Pull fresh data. Performance metrics from Meta across multiple timeframes (full experiment, 7-day, yesterday, today).

4. Make decisions. Every decision follows a structured format.

5. Execute (or do nothing, since some days it explicitly chose inaction).

6. Write everything down. Updated logs, learnings, campaign history, then committed to git.

The key takeaway from this is that we’re applying some basic engineering principles to a marketing workflow, which is something that typically doesn’t happen in marketing teams.

Engineers document obsessively, since every code change has a diff, a commit message, a PR description. Marketers... don’t. Learnings live in people’s heads, maybe a compressed monthly report, but few write down why they paused that ad on a Tuesday.

This system forced a daily written record with hypotheses, confidence levels in those hypotheses, and revisit triggers. Over 31 days, it produced 5,500+ lines of reasoning. No human marketer would ever write that, but an LLM can, and more importantly it can read it all back the next day and build on it.

What actually happened

Week 1 - Discovery

The agent tested 10+ ad formats: whiteboard sketches, notebook pages, cardboard signs, magazine covers, iPhone notes, tweet screenshots. Most didn’t actually get into the wild, since Meta’s algorithm just refused to show them.

The ugly ads won, which was annoying but also not surprising. Whiteboard and notebook formats outperformed everything polished, and the first guardrails kicked in: pausing 2 underperforming formats that reached our maximum CPL threshold of $8.00. By the end of the experiment, the agent had tested ~50 ad variants across 8 format categories, and it kept coming back to these two ugly formats.

Here’s what the top performing ads actually looked like:

Not exactly award-winning creative, but they worked. The handwritten/sketch aesthetic felt native in a Meta feed full of polished brand content, which is probably why they got clicks.

While Claude was never given explicit instruction to do this exact scrappy style, I did provide some encouragement in the core rules to “get creative with format types and messaging”. Would this direction have emerged without those instructions? We’ll never know!

But as models get more intelligent, this type of proactive creativity will likely become common place.

Week 2 - A winner emerges

Day 12 was the breakout, where skills-whiteboard-v1 hit $1.29 cost per lead, which was well under the target of $2.50. The agent made its first scale decision and bumped the budget up 20% from $50 to $60/day (meaning more total ads), following its own pre-set rules. Here’s what that decision looked like in the logs:

Decision: SCALE daily budget

What: Increase from $50 to $60/day (20% increase)

Hypothesis: skills-whiteboard-v1 has sustained CPL below $2 with sufficient spend

Confidence: Medium-High. 3 consecutive days below target, but sample still small

Revisit trigger: If 7-day CPL rises above $3, reduce back to $50

The winning formula turned out to be a tangible offer (free skills pack, not just “subscribe to a newsletter”) + whiteboard format + targeting language visible in the image itself. “For Growth Marketers” baked into the creative, not just the copy.

Week 3 - The quality crisis

Any marketer (or perhaps model) can generate leads. But they need to be good leads to be worth the spend. The agent had PostHog analytics tools from Day 1 and could’ve checked who was actually signing up at any point, but didn’t bother until Day 16.

Turns out a chunk of leads were from completely wrong audiences. Cleaning companies, recruitment agencies, people who probably thought “growth” meant something different. They were never going to actually pay me, so spending on getting in front of them was a waste.

It tried to fix this with hard-qualifying ads, using copy that explicitly mentioned tool-specific language only a real growth marketer would know. Again, four of five got zero delivery since Meta’s algorithm doesn’t reward minor variations.

There was also a brief flash of hope on Day 20 where CPL dropped to $2.26 and it looked like a breakthrough, but it turned out to be attribution noise (Meta crediting leads to the wrong day/ad). New rule the agent came up with: never trust single-day data, always use 7-day rolling averages. Now we are thinking like a human!

Week 4 - The human ruins everything

After 21 days of hands-off operation, I made one manual change and added business email validation to the lead form on the website. Work emails only, seemed reasonable enough.

CPL spiked to $50+ and I reverted the change a few days later, but the account never fully recovered. The single biggest performance drop in the entire experiment came from the one human intervention, which is pretty ironic given the whole point was to test whether the AI could do it alone. And yet, this is exactly the kind of change a common sense marketer would make to improve lead quality, which underscores the limitations of the model (or at least the constraints I gave it).

Final score

$1,493 spent of the $1,500 budget, 243 leads, $6.14 cost per lead.

The target was $2.50, so by its own definition it’s a failure. But for a completely fresh ad account with one month of data, a niche Australian audience, and an unmonetized newsletter? If this were a new hire or an agency, you probably wouldn’t fire them after 30 days. You’d say “promising, needs more runway.”

(or maybe that’s just cope)

Three things the agent taught me

1. The paperclip problem is real

The agent knew the experiment ended at Day 30 since I told it as much in the system instructions, and so it played it safe. It doubled down on what was already working rather than taking creative risks, whereas a (good) human strategist would’ve experimented aggressively in weeks 1-2 and refined later. The agent just tried to ride out the month at a predictable rate.

It felt like it was just trying to maximize paperclips, optimizing the metric rather than doing what a good strategist would actually do.

The fix is obvious in hindsight though - don’t tell the system it’s a time-boxed experiment, frame it as an ongoing campaign. But that’s exactly the point. How you frame the objective shapes the agent’s behavior completely. “Minimize CPL over 30 days” produces very different decisions than “build a sustainable acquisition engine.”

Any AI system you deploy will optimize for exactly what you tell it to, not what you actually want. Thankfully nowadays this is usually as simple as updating a markdown file. But worth keeping in mind, particularly if you’re tinkering with OpenClaw at the moment.

2. It can’t do taste, but it can build heuristics

The agent produced ~50 ad variants and kept gravitating back to ugly whiteboard formats. No brand reference point, no swipe file, no clue about aesthetic direction. It had guardrails on quality (no typos in the creatives) but zero sense of taste.

What it could do was build its own quality filters through experience. After the lead quality crisis, it came up with what the logs called the “Local Pizza Shop Test”. I was trying to attract high performing growth marketers at billion dollar startups, not local businesses:

Would a local pizza shop owner who wants more customers understand this ad and want to click it? If yes, too generic. Rewrite.

It also built a “SO WHAT?” chain for testing whether ad copy had emotional depth:

“Save hours” → SO WHAT? → “Run more campaigns” → SO WHAT? → “Higher ROI” → SO WHAT? → “Hit your targets and your boss notices”

Neither of these were pre-programmed, the agent came up with them after reflecting on its own failures. It couldn’t do taste, but it could build heuristics. That’s kind of interesting.

3. The measurement trap catches AI even faster

The agent optimized for cost per lead because that’s what I told it to optimize for, and it had no concept of lead quality until I forced the issue on Day 16.

Then when I tried to fix quality myself (the email validation gate), it caused the worst performance of the entire experiment. Same trap that human-run campaigns fall into - optimizing for what’s measurable rather than what matters. Main difference is an AI agent just does it faster and with more confidence, which honestly makes it more dangerous.

What this means if you’re not a performance marketer

The ads are kind of a distraction. The interesting part is the loop:

1. Read state (previous decisions, learnings, metrics)

2. Fetch fresh data

3. Apply rules

4. Act (or don’t)

5. Log reasoning

6. Clear context, repeat tomorrow

This works for any periodic task with clear success criteria, so you could swap “Meta Ads” for SEM, SEO, financial reporting, or sales outreach and the architecture would be identical. The channel is just a variable.

Projects like OpenClaw have blown up with the same core idea. Give an agent tools, an environment, and some guardrails, and it’ll figure out the rest.

Where humans stay essential is setting the right objectives (see: paperclip problem), taste + brand judgement, and defining what “quality” means beyond the metrics. And knowing when to break the rules, which is arguably the most human skill there is.

The one-person growth marketing team is getting closer since AI handles the operational overhead that used to require headcount, and the strategist with good taste and clear thinking becomes more leveraged.

But we’re still early, and creative quality is still a bottleneck. Although we’re probably 6 months + 1 model release away from this being solved, and suddenly Zuck’s vision of hands-off advertising is around the corner.

So now what

This was a $1,500 experiment on a newsletter that not many people read, so the results are directional, not definitive.

But the system worked. Context persisted across 31 sessions, decisions were coherent, and the agent built its own heuristics from its own mistakes. The daily reasoning logs are more detailed than anything I’ve ever written for a client campaign (which says more about me than the agent to be fair).

If you’re running any kind of recurring workflow where you pull data, make decisions, and act on them, the loop pattern here probably applies to your work already. The hard part is figuring out what to actually optimize for, and clearly articulating that. Since as this experiment showed, your agent will take you at your word and if you haven’t thought it through properly, you might not like where that leads.

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.

Part 2 will cover some more practical tips I’ve discovered for getting better words out of models, like style guides.

📢 Thanks to our sponsor: Rippling

But first, a bit of a unique event to share with you:

Rippling, where seemingly all of my friends work, is hosting a Cocktails & Career Advice event with The Bearded IT Dad (yea, that’s his name). They’ll be having a ton of fun with a professional mixologist walking you through a mini cocktail-making class, live on Zoom.

And of course on the business side, there will be discussion about how IT pros can advance their careers and continue to grow while dealing with all of the challenges they deal with in our line of work. Isolation, burnout, feeling stuck, and technology that’s changing all the time.

The event is on March 10th, 6p ET / 3p PT. The first 350 registrants will get a free cocktail kit sent straight to their home so they can follow along with the class, and they will also be raffling off an Xbox Series S for one lucky attendee.

You can RSVP here before cocktail kits run out.

Act I, formation

Writing has been a pretty central part of my adult life for as long as I can remember. This is ironic because I wrote the worst college essay you’ve probably ever read, a generic high-school-slopfest about Eric LeGrand and perseverance, something which I know nothing about. In all fairness, I was a child.

A few years later there was some promise though. I visited the camps in Poland in 2013 as part of my two religious years abroad, and wrote a note about my experience that I shared with my family. My grandmother still talks about this to me every few weeks…so I must have done something right.

But it was really at my first post-college job – toiling away at a one-and-out VC fund that was going nowhere fast – when writing clicked. After internalizing some righteous indignation at Jeremy Levine on a conference panel, I somehow got my first piece published in VentureBeat, which was not entirely defunct back then.

You can tell I was young because I was still afraid to curse on the internet.

After this I was off to the races. I ended up publishing several more pieces in VB, a few in CrunchbaseNews, and some private help for a few companies I had met (strangely, 2 out of 3 of them got acquired by Nike??). In fact, writing is what landed me my first startup job at Algorithmia. This post, which I wrote for and with their team (for free of course), was what got me in the door.

And then eventually writing became my career. At Algorithmia I just sat down and wrote blog posts for a year. Then after a brief detour at DigitalOcean to live out my fantasy of being a data scientist, I sat down at Retool and wrote blog posts for 2 years. Somewhere in the middle I started Technically, where I’ve been writing blog posts for like 6 years. Along the way were a few wins: tens of thousands of subscribers, reigns on the front page of Hacker News, and the occasional viral tweet.

I owe my entire career to writing, no two ways about it. It’s one of the core parts of my identity, and the thing I think I’m best at (though you’re free to disagree). And though I’ve got a VP title and more responsibility now, I’ll always be a writer at heart.

Act II, skepticism

I regale you with this narcissistic drivel to put you in my shoes and understand how I might have felt when the first version of ChatGPT came out. Everything was all wrong.

First, the vibes were just way off because the writing sucked. The only thing worse than no writing is bad writing. And I was used to dealing with bad writing, particularly from the agencies I had worked with at Retool that offshored technical tutorials to slop factories that charged a few cents a word and gave you exactly what you paid for. When you see profoundly bad writing you feel anger; knowledge that the person that created this didn’t care about it pretty much at all. The models invoked this emotion, even if it wasn’t their fault.

Early technologists face a perennial dilemma: release too early and cement permanent skepticism, or release too late and watch someone else beat you to it. Early ChatGPT was firmly in the first bucket. I believe the early wave alienated so many writers because of how crude the initial product was, passable to the typical tech worker but so obviously trash to anyone who wrote for a living.

Second were obvious ethical concerns. I don’t mean this in an objective sense (many of you know I have a tattoo of Sisyphus on my leg) but in a personal one; my own code of what felt right was clearly offended by these models. Are you really going to outsource your creative process to a model, goading it to produce the same bullshit it’s producing for everyone else, and completely deserting your soul in the process?

Then there’s the obvious problem, that these models were trained on the writing of me and everyone else who writes. Only sheer hubris would allow me to contend that my words in particular carried weight in the weights. But the fact remains that OpenAI trained these models on my and my fellow writers’ work, without our consent, and have paid us $0 in return (alas, I don’t work at the NYT). Whether you believe this is evil or not, the ethic-vibes of using it as a writer felt way off.

For these reasons and others, I didn’t use AI models at all for the first few years they were around…despite spending my whole career at technical companies. Didn’t want anything to do with them. Even to this day, I probably use AI tools less than you’d expect.

Act III, introspection

Over time, a few things changed.

First, the models got better. You could get output that wasn’t actively offensive and started to resemble something that might be useful to you at work. Getting rid of the knee-jerk anger reaction I’d developed to bad writing – like I mentioned, honed over work with many shitty agencies – played a big role in opening me up. These ChatGPT words weren’t good, but they weren’t so bad as to make you angry.

Second, through talks with friends, myself, my therapist, and whatever happens in my unconscious mind when the sandman comes, I was able to get more in touch with what exactly writing meant and what in particular was the creative process for me specifically.

When I write, what is the creative act?

Is the creative act the thinking about the format of the post, and how it’s organized? Is it the content itself? Is it the writing of the content, or the typing on the keyboard? Is it the editing? The sharing and publishing?

The answer is yes, these are all part of the creative act. There are all of these important scaffolds around the words themselves; the creative act is definitively not just the writing of words. Look no further than Robert Gottleib’s relationship with Robert Caro if you want to understand editing, for example, as the creative act. Writing is best viewed as a living ecosystem of process, some directed and some cyclic, all connected and imbuing the final product with a different piece of its eventual soul.

When I really introspect about why Technically had a modicum of success or why my technical writing was in demand, if I’m being really honest, it’s not really my words in the traditional sense. I don’t make the best jokes, my prose isn’t the most beautiful, I’m not the most witty, and I’m certainly not the best researched. When I read writers like Matt Levine, Father Karine, I think: these are good words. That’s not really my thing.

I think I just pick the right things to write about. My instinct for the right level of detail, the context a reader needs and doesn’t need, and when the story should start and end, is very good. Technically worked because I was more technical than most and less technical than most; I found a sweet spot that really worked for really smart, ambitious people who just weren’t technical but wanted to be.

This, by the way, is why I pretty much never edit my writing materially. Passing over particular word choice and flow is just not going to do much, that’s never been my strong point. The real work is in choosing what to write about, laying out the sections and their order, and deciding what the reader needs to know to know what you want them to know. I pretty much never agonize over words.

Act IV, acceptance

I regale you with this self-effeating tale because it explains why there are ways to use models that reinforce your creative process instead of outsourcing it. For me the words are not really the point, the structure and thought is; this is a great use case for AI models.

This is pretty much how I use AI for writing today, for the limited amount I use it. The hard part of writing (again, for me) is the upfront scaffolding work: what do I want to say, what order should it be in, what details do I need. How I actually articulate that is a fine task to give a model a shot at. In practice (part 2 of this post, forthcoming) this manifests itself in very detailed prompting and the use of personalized style guides.

I have had some decent success with this, but mostly in ghostwriting for other people. For my own writing, despite models getting better and better, I’m increasingly finding that I’d rather just do it myself. This post you’re reading now is a perfect example:

• I dictated what I wanted to say in ~25 mins to my phone while I was in the car

• I took the transcript, combined it with my style guide, and gave it to Claude

• The output was completely unusable and made me sad

• I ended up writing the entire post from scratch

I have said that AI will replace you at your job if you let it and I still believe this. If you use vanilla prompts, treat models as oracles instead of tools, and completely outsource your creative process to them, your bosses will eventually do so too, rendering you useless. For most people, it’s clear that there’s significant alpha in using models to help with writing.

For me though, for using my voice under my name saying something I want to say, I still like to do it the old fashioned way.

For most of us, even most engineers, this grey box is a sufficient level of detail on the datacenter, and that’s by design. Cloud service providers (CSPs) make it so you don’t need to know anything about the computers that serve your HTTP request or store your data. This is the fundamental value proposition of the cloud: you take care of the code, we’ll take care of the hosting.

But aren’t you curious?

Datacenters… So hot right now

Datacenters are the subject of renewed public attention, for better and for worse. On the bright side, datacenter investment is broadly holding up the US economy. A Harvard economist estimated that datacenter and related tech investment accounted for 92% of US GDP growth in the first half of 2025, despite being just 4% of total GDP.

On the other hand, all this datacenter construction has prompted major pushback from communities worried about their effect on the environment, utility availability, and property values. Over $64 billion in datacenter projects have been blocked or delayed due to local opposition. In Warrenton, Virginia, residents voted out every town council member who supported Amazon’s proposed datacenter. A nationwide poll found that only 44% of Americans would welcome a datacenter nearby, making them less popular than gas plants, wind farms, or even nuclear facilities.

So, what’s a datacenter?

When you search for the best Thai food near you, or post “happy brithday!” on your auntie’s Facebook wall, these requests are ultimately handled by a datacenter. The task you’ve set in motion by clicking the search button travels through the air, to your router, through a whole bunch of cables, to a computer in the datacenter that needs to actually retrieve Thai spots and then send those results back to you. These computers that do the heavy lifting behind the scenes, which are called servers, are the lifeblood of the datacenter. The datacenter is where thousands of servers that power your favorite application call home.

More than just pad see ew reviews flow through datacenters: critical time-sensitive information like bank transactions, visa applications, and medical records all rely on datacenter operations. When these critical centers of infrastructure have outages, businesses, institutions, and economies are hit hard. All this to say: keeping servers on, secure, and reliable is very important. Every aspect of the datacenter, its location, people, technology, and design, is in service of this goal. So let’s take a tour.

Getting there and getting in

You’ll probably need to drive to the datacenter, because datacenters are in the middle of nowhere. As we’ll learn in a bit, these operations depend on fiber access for fast networks, but also take up a ton of space, so cheap land is helpful. For this reason, datacenters are often on the outskirts of larger metros - think northern Virginia outside DC, and Oregon outside Portland.

Not just anyone is allowed into the buildings that run the economy. Modern datacenters employ biometric identification methods, a two-door “man-trap” to avoid anyone sneaking in behind you, a strict no phones / personal possessions policy, and the requirement that any guests be accompanied by staff at all times. With the price of GPUs these days, perhaps Ocean’s 18 will see Danny and co. get through all these mechanisms to steal a pocketful of chips.

Let’s get physical

In the main hall of the datacenter, the first thing you’ll notice will be the sound. A low but loud hum that comes from all sides at once. These are the mole people. Just kidding. These are the cooling fans! Computers do their best work at about the same temps that humans do - between 64 and 84 degrees Fahrenheit. This requires, among other things, a ton of fans. They blow cool air up from the ground to the front of the servers, and another fan blows hot air from the back of the servers out into the exhaust. The difference between the “cool aisle” and the “hot aisle” can be over 30 degrees.

Looking around, you’ll see rows and rows of tall cabinets. In scale, these fall somewhere between library shelves and narrow streets. The cabinets themselves are about 6 feet tall and 2 feet wide, and they’re arranged in rows that can stretch hundreds of feet. This is where the servers live. But before we get to the servers themselves, let’s talk about how all of this is organized.

Servers are housed in cabinets called racks. A standard rack is 42U tall, “U” being the unit everyone uses, equal to 1.75 inches of vertical space. Do the math and you get about 73 inches, or just over 6 feet. The 42U standard exists for practical reasons: it’s tall enough to pack in a lot of compute, but short enough to fit through doors and elevators, and a technician can reach the top without a ladder.

Inside a rack, you’ll find servers stacked like drawers. A typical server is 1U or 2U tall, so a single rack can hold somewhere between 20 and 42 servers, plus switches, power distribution, and cable management. The width is standardized at 19 inches (the actual mounting rails are 17.75 inches apart), which means any server from any manufacturer will slide into any rack. This interchangeability is the whole point, which we’ll get to in a second.

Read more

January was a month of change for us at Technically. In addition to some fascinating writing about AI + neuroscience, why AI models use so many em dashes, and what people are actually using AI for, we brought on a whole new roster of writers that I’m excited to introduce you to. You’ll be hearing from them a lot for the rest of the year.

Some highlights:

New on Technically

AI and neuroscience

Available as a paid post on Substack, and now in its permanent home in the AI, it’s not that complicated knowledge base.

The way we train and use GenAI models today strongly resembles how the pathways in the human brain actually work. In fact, many neuroscientists and AI researchers believe the key to unlocking real superintelligence will lie in our ability to better understand and exploit that connection.

This post explores a few ways in which this is true and explains some of these rather complicated ideas in more simple language.

How are companies actually using AI?

A guest post by Kenny Ning from Modal — available as a free post on Substack, and now in its permanent home in the AI, it’s not that complicated knowledge base.

Everyone talks about AI use cases, but who’s actually spending money on what? Kenny analyzed real cloud spend data from Modal’s top 100 customers to find out which AI applications are growing fastest.

The three biggest growth areas: coding agents (apparently properly rated), LLM inference for low-latency use cases, and computational biology. Meanwhile, AI art and video generation is flattening — a possible sign the market is maturing from consumer novelties into serious B2B applications.

If you aren’t familiar with Kenny’s work, he’s someone you should follow. He started his career in data science at Spotify and then Better Mortgage before following his former fearless leader Erik to Erik’s new company, Modal. Modal is absolutely ripping and Kenny has his fingerprints on much of the interesting things they’ve published. He also low key shreds on piano with me sometimes.

AI and the em dash

Available as a paid post on Substack, and now in its permanent home in the AI, it’s not that complicated knowledge base.

Anyone who uses AI models knows they have this very strange obsession with em dashes. BUT WHY??? The culprit might be a mix of training data from older books (when em dash usage peaked in the 1860s), Medium’s auto-conversion of double hyphens, and the simple fact that an em dash is just one token while alternatives like “, and” take three.

This wonderful new post comes courtesy of another new Technically contributor, Christy Bieber (no relation). She has been freelance writing for almost 20 years on topics ranging from personal finance to real estate to AI and em dashes, proving the old adage that “you can do anything with a JD other than be a lawyer.”

We’ve got a few more authors we’re going to introduce next month, and are still looking for more. If you’re an expert on anything remotely related to software and AI and want to write about it, let us know! We will pay you!

From the AI Reference: Training Dataset

Following on the em dash saga, you might be wondering: what exactly was in the data that made AI fall in love with this punctuation mark in the first place?

Let’s talk a little bit about the very thing responsible for that: datasets.

Training Dataset

Training datasets are the collections of examples you show an AI model so it can learn to recognize patterns and make predictions. Think of them as the textbooks and practice problems that teach AI models how to do their jobs.

The dataset is your way of saying to the AI: “Here are 50,000 examples of the task I want you to do. Figure out the patterns, and then apply what you’ve learned to new situations you’ve never seen before.”

Here’s what makes a good dataset:

• Representative examples that cover all real-world scenarios the model will encounter

• Accurate labels — mislabeled examples confuse the model (if 10% of your “cat” photos actually show dogs, your model will learn that some dogs are cats)

• Sufficient volume — more data usually means better performance, but with diminishing returns

• Clean data — blurry images, corrupted files, and duplicate examples hurt performance

The famous saying in AI: “garbage in, garbage out.” Your model is only as good as your data. Which explains a lot about why AI loves em dashes so much — if the training data was full of them (older books, Medium articles), the model learned that’s what good writing looks like.

Are you using AI at work?

We’re still collecting real examples of how people are putting AI to use in their day-to-day jobs. Automated something annoying? Built a workflow that stuck? Got your team on board? Reply to this email and tell us what you’re doing.

We want to hear what’s actually working.

If you’ve been keeping up with the online discourse about AI writing, you may be surprised that I put an em dash in this post. That’s because so many human writers are steering away from this once-common punctuation mark, which is now viewed as a hallmark of writing written by chatbots.

In fact, AI bots love the em dash so much that it can be hard to get them to write content without including it, even when you give the bot explicit instructions not to do so. LLMs can be so funny sometimes.

Of course, this raises the question of why em dashes are all over AI-written content — and whether human writers should give up this once-beloved punctuation mark entirely, so their content isn’t immediately clocked as being written by an LLM.

Why does AI love the em-dash so much?

AI’s love affair with em dashes seems to have a simple explanation: The data used to train large language models was full of em-dashes. The AI is simply mimicking the writers that it learned from.

In fact, there’s some evidence to suggest that the content AI was trained on included significantly more em-dashes than you might expect. And weirdly enough, their prevalence seems to have become a deep bias that’s embedded into how LLMs understand the flow and structure of writing.

AI-training material may have used an overabundance of em-dashes

One theory behind AI’s love of the em-dash is that the later-generation AI models, which rely on it much more heavily than earlier iterations, were trained on older books that included more em-dashes than most modern writers would.

Early on, most AI models were trained based on a mix of public data on the Internet, as well as based on content from pirated books. However, in a quest for better quality training data as the tools evolved, AI models started scanning older texts. Curating the massive data trove that is the internet has been a major focus of AI Labs for more recent model generations, and finding quality text from books was certainly part of that.

The exact timeline for when this happened is something of a mystery, but Anthropic started in 2024, based on court documents, and other AI labs likely made a similar move somewhere between 2022 and 2024.

If AI labs digitized mostly older books, which is a common belief largely because of expired copyrights, their AI programs may have been fed writing with significantly more em dashes included in it — especially as studies show the use of that use of the em-dash peaked in the 1860s.

It may not have been the books alone, either.

Another theory suggests that AI may also have picked up em-dash use from Medium, which automatically converted two hyphens (--) into an em-dash since the company’s founder was a fan of typography. Since Medium may have been seen as a source of high-quality writing by LLMs (and ergo upweighted in training by labs), AI may have determined that the em dash is a key feature of high-quality prose.

The brevity theory

There’s also another competing theory as well. Some suggest that AI favors em dashes because of brevity.

AI models think in tokens, or small chunks of text, and they constantly have to evaluate the next token to use. The more tokens the model uses, the more chance there is to make a mistake, so AI models prefer to use fewer tokens to reduce loss

An em dash is just one token, while other alternatives, like “, and”, actually add up to three tokens. As a result, the em dash ends up being favored to improve efficiency.

Consider the difference between these two sentences:

AI is fast, and it can produce massive volumes of content quickly.

Versus:

AI is fast — producing massive volumes of content quickly.

The em dash removes filler phrases like “and it can,” which humans may prefer to use for better flow, but which add lots of extra tokens. The second sentence ends up shorter, more direct, and denser with meaning, so AI bots tend towards that approach by default.

This preference for brevity ends up being reinforced during fine-tuning, when models are rewarded for responses that humans find to be clear, helpful, and concise rather than rambling or inefficient. AI models choose the em-dash to keep things short, then learn that using em-dashes is the right thing to do.

Sam Altman announces a fix — but it may not be foolproof

For em-dash haters frustrated with the challenge of training out the em-dash, there was reason to hope in recent months.

In November 2025, Sam Altman, CEO of OpenAI, announced on X that custom instructions to avoid the em-dash would now be followed.

However, responses from X users show that the results haven’t been perfect.

Unfortunately, this problem may actually get worse before it gets better — if it gets better at all. The big issue now is that newer models are training on the output of previous generations.

As more content on the Internet contains an over-abundance of em-dashes thanks to the rise in AI-generated content, this stylistic tic could result in an Internet that’s absolutely filled with even more em-dashes. It becomes a self-perpetuating cycle.

This actually creates the risk of model collapse, as newer models amplify the idiosyncrasies of old ones. For those who don’t like AI writing — and who fear that it will replace them — that may be a good thing. But, for those who are frustrated with AI slop and who don’t think LLMs are going anywhere any time soon, seeing the writing get worse could be a major source of frustration.

Should real human writers stop using em-dashes?

For now, the fate of the em-dash hangs in the balance, and the question becomes — should human writers abandon this punctuation entirely and leave it to the bots?

That’s ultimately a judgment call. Many writers are pushing back, refusing to let AI change the way they write and think.

The key may be to use them sparingly and to make sure your writing otherwise clearly signals that your text is written by humans for humans. This can mean injecting personal experiences and emotional depth that chatbots simply haven’t been able to master — at least not yet.

• I used ChatGPT to build me a workout plan

• I vibe coded a NYT cooking inspired recipe generator

• I had AI write me a song about the Python 3.14 release notes

It’s not just people using AI anymore; corporations want to vibe code a recipe app customer support platform too. According to Menlo Ventures’s “2025: The State of Generative AI in Enterprise”, AI spend in 2025 was $37 billion, up 3.2x from the year before. $18 billion of that spend was on something called AI infrastructure.

AI infrastructure spend

I happen to work at one of these providers called Modal. Thankfully, we can go deep with our data in a way you can’t with an industry report:

• Actual (not self-reported) spend over time at the company level

• We can infer detailed use cases from customer conversations and sales notes

In the spirit of not letting AI replace me, I went through each one of our top 100 or so customers and bucketed them into one of the following use cases:

• LLM inference: running custom or open-source LLMs to build chatbots, document parsing, or low-latency code generation

• Computational biology: predicting molecular structures or protein folding (thus concludes all the comp bio buzzwords in my arsenal tyvm)

• Audio inference: transcription, text-to-speech, generative music

• Image / video inference: running custom or open source models to generate ghibli images of yourself and things like that

• Coding agents: vibe-coding apps and tools

This methodology requires human judgment and isn’t perfect. It doesn’t take into account customers with multiple use cases. I’ve also taken some liberty in excluding some outlier customers that skew the data in an unhelpful way. Here’s what I learned…

Coding agents are (apparently) properly rated

Menlo’s report describes coding as AI’s first “killer use case”, and we’d have to agree. We’re seeing the fastest spend growth among coding agent companies like Cognition and Lovable.

We’re also seeing other customers use the same technology that powers coding agents (sandboxes) in new use cases like reinforcement learning. We expect this category to continue to grow.

LLM inference is increasingly self-hosted

At Modal, we think of LLM inference as three different types of workloads:

• Offline - batch, analytical processing, asynchronous

• Online - interactive, low-latency, synchronous

• Semi-online - mix of the above two

Choosing OpenAI or another closed source provider is like choosing a Toyota Camry; a middle-of-the-road option where you may not want to think too hard about mpg or top speed or acceleration. You just want to get the job done reasonably well.

But if you’re building a business, customizing performance of your offline / online / semi-online workload matters more and more. These companies might choose the “OS stack”: pairing an open-source like Qwen with an open-source inference engine like vLLM that gives them that level of customization.

The spend we’re seeing from LLM inference companies using the OS stack has skyrocketed over the last 6 months. Reducto is solving the PDF extraction problem at scale (they parsed the Epstein files). Decagon is using online, low-latency voice chat in their core AI customer service product.

Science is still alive

The US may not be a measles-free country for long, but computational biology startups aren’t discouraged. A small, but steadily growing share of our spend is towards science use cases like drug discovery. And to think that all this time, I thought running reproducible experiments was only relevant in e-commerce (that’s what you get when you spend 10 years as a data scientist in tech).

B2B is so back (even though it never left)

Even though Modal has thousands of paying customers, we are but a small slice of the AI infrastructure pie. Still, slicing spend by the categories above can give us a uniquely detailed view into how some of the fastest growing AI companies are spending that sweet sweet AI money.

Overall, the AI market has matured. It’s moved from generating AI spongebob memes to writing 30% of a $32 billion dollar company’s code. If 2025 was AI’s experimental college phase, 2026 will be the year it’s going to start looking for jobs. Something tells me it’s going to ace the interview.

This post is going to explore a few ways in which this is true and explain some of these rather complicated ideas in more simple language.

Neural networks, the basis for everything

The obvious place to start is neural networks, the architecture for pretty much all of the AI models that you use today like the GPT family, Claude, Nano Banana, and the like. Obviously the first word – neural – likens these models to the animal brain. The human brain has something in the range of 86B neurons, which are specialized cells that transmit nerve impulses; essentially the core unit of how our brains transmit information and signals. The idea is that neural networks work in kind of the same way.

And indeed, you’d be hard pressed to find an explanation of neural networks that doesn’t make an analogy to the human brain. Take, for example, Technically’s very own breakdown of neurons from the prolific Nicole Errera:

Neurons are the basic building blocks of AI architectures, modeled after the actual biological neurons that transmit signals throughout the human brain. Remember, AI models are essentially pattern investigators; they find the underlying pattern in the data. You can think of these neurons as the mathematical functions that are doing this hard investigative work, getting into the weeds of the data and figuring out what’s going on.

The math performed by individual neurons is actually pretty simple – it’s usually just basic multiplication and addition that you could do with a calculator. So how are AI models able to capture such complex patterns, like the ones involved in language and vision? The trick is to string together a lot of neurons – like hundreds of millions of them.

So in practice, the neural net in a model like GPT-5 does, at least loosely, resemble how a mammalian brain works. This is no accident. If you trace the history of the neural network you’ll end up back in 1943 (when I was born), when Warren McCulloch (neurophysicist) and Walter Pitts (mathematician) wrote a paper proposing a mechanism for how neurons might actually work.

To illustrate their hypothesis they modeled a simple neural net using electrical circuits. Further attempts culminated in a breakthrough at Stanford in 1959 when MADALINE (it’s an acronym) became the first neural network applied to a real world problem – eliminating echoes on phone lines. So in short, the fact that neural networks (roughly) approximate how the brain works is not an accident, this insight is core to their entire historical origin.

Now any neuroscientist worth their salt will tell you that there’s more that we don’t know about the brain than there is that we do know. The true inner workings of this organ are still really a mystery. And so it would be naive to argue that neural networks work in the same way that the brain works. But it’s safe to say that they’re inspired by what we do know about how the brain works, at least loosely.

Read more

My sources tell me it’s not too late to say happy new year.

2025 was the year everyone started to use AI at work. 2026 is the year we figure out how to get the most out of it, vibe code things that actually work, and steer clear of hallucinations (unless you’re into that kind of thing, in which case you might get oneshotted by ayahuasca).

So here’s what we’ve been up to for the past month.

New on Technically

2026 vibe coding tool comparison

Available as a free post on Substack (courtesy of Vercel) and now in its permanent home in the AI, it’s not that Complicated knowledge base.

All hail vibe coding, savior of the Ideas Guy. But which vibe coding tool should you use? I tested 4 of the most popular options by building the same app on each: an internal dashboard for Vandelay Industries’ potato chip import/export operations.

For each I cover how well they work, any quirks to watch out for, plus pricing and how far you can get on a free plan.

The AI user’s guide to evals

Available as a paid preview on Substack, and now in its permanent home in the AI, it’s not that Complicated knowledge base.

As non-technical people build more and more stuff with AI they are starting to run into the same issues as software engineers – it’s hard to know when things are working or not. This guide to evals gives you the background you need to start adding effective monitoring to your AI system.

Based on my conversation with eval expert Hamel Husain, this post covers:

• Why evals matter: moving from “I think the bot is getting better” to “hallucination rate dropped from 15% to 3% this week”

• Look at the data: why you need to examine your failures before writing fancy tests

• Assertions over LLM judges: why simple keyword checks beat complex AI-judging-AI setups

• A practical 4-step workflow: vibe check, spreadsheet, simple fixes, then targeted evals

This one is pretty practical.

AI will replace you at your job if you let it

Also available as a free post on Substack and in the AI, it’s not that Complicated knowledge base.

Like you, I’m extremely tired of the recurring headlines about “AI replacing the workforce,” written almost exclusively by people who know nothing about AI and have never been part of said workforce. And yet… many people are using AI so carelessly that you won’t be able to blame their bosses when they decide AI can do the work in their stead.

I believe that staying ahead is going to mean really taking the time to use AI intelligently, customizing it to your needs, tweaking your prompts, and keeping an iterative mindset. AI will only replace you at your job if you let it.

From the AI Reference: Prompt Engineering

If you weren’t in the loop and got too caught up in the holidays of it all, we recently launched the AI Reference—a companion to the Technically Universe focused specifically on AI concepts. This month’s featured term is one everyone using AI tools should understand:

Prompt Engineering

Prompt engineering is the art of talking to AI models in a way that gets you the results you actually want. It’s the practice of crafting inputs that reliably produce the outputs you’re looking for, whether that’s generating marketing copy, analyzing data, or answering customer questions.

Here’s the thing: AI models are incredibly powerful, but they’re also incredibly literal. Ask ChatGPT “write about dogs” and you might get a 500-word essay about canine evolution. Ask it “write 3 bullet points about why dogs make good pets” and you’ll get exactly what you need. That difference in specificity is prompt engineering in action.

Why this matters:

• Good prompts can save you money, time, and frustration when working with AI

• The more context and structure you provide, the better models can give you what you actually want

• Think of it as learning to communicate with a very smart but literal-minded assistant

• Key techniques include few-shot prompting, chain of thought reasoning, and setting clear constraints

Coming up this month

We’ve got three posts on deck for January:

• AI for PMMs: automating customer segmentation. A look at how product marketing teams can start using AI to segment customers.

• What’s fine-tuning? A breakdown of what fine-tuning is and why it comes up so often in AI discussions.

• How AI chips get made: An overview of how the hardware behind modern AI systems is produced.

Are you using AI at work?

We want to hear what’s actually working. If you’ve automated a tedious task, built something useful, or helped your team adopt AI without chaos, send us a reply and share your story.