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 after said job anyway) was an anathema to me, especially as I still believe there’s a beauty to 100% human writing that even the best AI tools can’t replicate.

And yet, here we were. The machines, allegedly, don’t lie -- so how is it possible that my content could have been both 100% human written and 36% AI written at the very same time?

I wasn’t alone in facing this mystery, either. This is a question many of my fellow writers have grappled with. In fact, a quick Google search shows many complaints from frustrated writers who want to know why AI detectors are flagging their original work.

So, how is this happening? Unfortunately, it has to do with how AI content detectors operate. So, let’s take a look at the process these detectors use and where the problems are coming from.

How do AI detectors work?

While I don’t outsource my writing to AI, I do outsource some basic research questions, so I’m happy to tell you that ChatGPT says there are around 15 to 30 widely-known tools used to detect AI content (as well as 10 to 20 academic and enterprise systems).

These AI detectors, of course, can’t read and understand writing, as LLMs can’t engage in human-like reasoning (at least not yet!). Instead, the AI detectors all employ a similar process. They use machine learning models to try to recognize the patterns that set AI-content apart from human content.

Typically, the creators of AI detectors train the models based on huge volumes of both AI writing and human writing, to enable the models to recognize major differences in sentence structure, style, and predictability.

New writing is analyzed with these patterns in mind, with detectors looking for the classic hallmarks of AI-written work versus human prose.

What do AI detectors look for when analyzing work?

So, what are some of the key patterns that tip off an AI detector that a fellow AI agent was the creator of the work it’s analyzing?

Let’s look at GPTZero, one of the more popular detectors, to find out.

GPTZero explains that it “was one of the first AI detectors to pioneer the idea of using ‘perplexity’ and ‘burstiness’ to evaluate writing.” So, what does that mean exactly?

• Burstiness. Burstiness (yes, it’s a real word) refers to variations in sentence structure, length, and complexity throughout the text. Humans tend to vary their sentences more, with a mix of long, short, simple, and complex sentences. AI-written works tend to have sentences that are more uniform in length, structure, and style.

• Perplexity: Perplexity measures how predictable your word choice is. AI models use words that are statistically likely to follow other words, which means their writing has lower perplexity. Humans tend to be less predictable. The fewer surprises there are in word choice, the more likely it is that the text is AI.

While GPTZero’s model is continually evolving and now incorporates a multi-layered approach with additional components, perplexity and burstiness continue to play a fundamental role in AI-content detection, not just for GPTZero but for other detectors as well.

Essentially, if a detector goes word-to-word and finds that the statistically probable word was used 90% or 100% of the time, it will flag that part of the text as being likely AI because a real human writer is very unlikely to always choose the exact word that’s most likely to follow the previous one.

Perfection can also be a factor, as AI doesn’t tend to make the types of mistakes people do in writing. For example, while it may hallucinate entire legal cases and get lawyers sanctioned, it is far less likely than I am to type “layer” when it means “lawyer.” When work is perfectly free of typos and grammar mistakes, this is a red flag.

This is a source of frustration for both myself and my fellow writers, who feel like sometimes being “too good” at self-editing can now cause a false positive.

How often are AI detectors wrong?

AI detectors can be wrong in two ways:

• The detector may miss the presence of AI text.

• It could falsely identify a text as being written by AI when it is not.

A false positive is what happened to me, and it happens a lot. In fact, research from the University of Pennsylvania showed “dangerously high” rates of false positives, and research published by Cornell found “the available detection tools are neither accurate nor reliable.” Inside Higher Ed provided a long list of similar studies showing problems with detection tools.

This isn’t a surprise because, after all, sometimes humans do write in predictable ways -- especially if they’re writing content about technical subjects where there are only so many ways to phrase things or if they’re writing SEO content that usually follows a somewhat standard format.

There are also other issues at play as well.

For one thing, AI models were trained to write, in part, by learning from content that’s on the web.

Since I’ve written over 5,000 blogs and SEO pages published on the web -- and my fellow writers dealing with false positives have written hundreds of thousands more pages -- it’s not a huge surprise that some of our content sounds a bit like AI wrote it. We may very well have contributed to teaching AI how to write in the first place.

There’s also the fact that some of the detectors that alert you to the presence of AI content conveniently just happen to have a solution: You can pay them to “humanize” the AI text for you. Of course, it’s probably just a coincidence that they happen to find so much of the text they analyze in need of that service.

For example, I put the first few paragraphs of this article, which was 0% AI-written, through Sidekicker, which found that 97% of my text showed signs of AI generation… and which offered me the chance to “Remove AI content.”

Unfortunately, when I went through the “humanization” process, I would have had to pay $1.95 for a seven-day trial to unlock my newly-machine-written “human content,” unless of course I wanted to just go ahead and subscribe to a monthly plan!

Fortunately for Grok, it wouldn’t necessarily have to pay this fee, as I asked Grok to write me 500 words on how AI detectors work and input that text (unchanged) into Sidekicker, which found Grok’s work was only 70% AI.

GPTZero did much better, finding my text was very likely “entirely human-written” while Grok’s content was 100% AI-Generated.

QuillBot, on the other hand, found my content to have 0% AI, and Grok’s to be 92%, so still fairly good.

And myPerfect Words thought my writing was 12% AI, including, oddly, my opening sentence, which included a personal story, while Grok’s text was 91% AI generated.

These results show just how important it is to find the right detector if you’re going to rely on these programs to help you evaluate a content’s source.

What happens if work is falsely flagged -- and are there solutions?

Unfortunately, given the nature of the world right now, what we end up with here is an AI tool, detecting AI-written content, which will presumably be rewritten to sound more human by a third bot -- because I guess the third bot is the charm.

And the consequences of this situation can be pretty dire for all the humans involved in the process.

If AI detectors make a mistake in an academic setting, students face disciplinary action. In the professional world, companies feel taken advantage of if they think human writers are trying to pass off AI content as original. Writers could also lose their jobs or spend a very angry hour or two revising falsely flagged text to keep the peace and keep the paycheck.

So, what’s the solution? There may not be a great one.

Research has also shown that people are pretty bad at detecting AI, especially with more advanced LLM models writing text, so editors can’t necessarily count on their own abilities to identify whether something is human-written or not.

Companies can require draft notes, review Google Docs histories, or use tools like Grammarly Authorship to see if text was pasted in or written. They can also work only with writers they trust who have a large portfolio of pre-AI work, which would be great for established writers but not so good for those trying to break into the business.

For their part, writers should make sure not to be formulaic, to vary their word choices and sentence lengths, and to incorporate personal anecdotes when they can.

I’ve even heard of some fellow writers throwing in a typo or two on purpose when they turn in their drafts, which, of course, is not something I’d ever consider in my own werk.

Read more

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 de…

Read more

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 hallm…

Read more

• 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; cor…

Read more

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.

They told me not to write this. They said “stay in your lane, Justin.” You just explain technical things, you can’t recommend gifts. You don’t know how to reach the hearts of loved ones. Well, I’ll be DAMNED if I don’t try!

By the way, I’m taking the last two weeks of the year off to go cook in a restaurant (literally), so Technically will be offline. I know it will be difficult to soldier on without my sweet voice hitting your inbox every week with technical explainers…but I have confidence in you.

Without further ado…

The Ohto CR02

Yea, I can type, but sometimes I like writing things down the old fashioned way. And nobody is better at crafting the instruments to do so than the Japanese. I tested 4 different Ohto pens and the CR02 was my favorite after a few days of furious scribbling.

It’s a ceramic rollerball, so it glides across the page. And at 0.5mm it’s the perfect thinness for my dainty preferences.

Price: $16

The Orbit Plus Turntable

It probably doesn’t surprise you that I’m a jazz guy (I even play drums occasionally). And the genre is best appreciated on vinyl for reasons that are set in the cosmos. Orbit makes affordable and high quality turntables that look great and are assembled in the USA. I’d recommend going for the Plus, which for an extra $150 gets you a much better cartridge.

If you already have speakers, great. If you don’t I can highly recommend the Kanto YU4 alongside their SUB6 subwoofer. They’re reasonably priced, sound great, and have a built in preamp plus bluetooth so you can stream from your devices if you so desire.

Price: $399

The Salomon XT-6

If you live in Brooklyn you already know that these were THE shoes of the early 2020s. And now that they are slightly less cool it’s the perfect time to wear them without judgement from your family. These things are literally the most comfortable supportive shoes I have ever owned, better than running shoes for sure.

I already own 3 pairs and unfortunately for my roommate there are probably more in my future. You can purchase them from Salomon or any other reputable retailer.

Price: $180

A neo-vintage Rolex Explorer 16570

Modern Rolex is so overdone. What you really want is stuff from the 90’s and 2000’s, when the bracelet links were hollow and Rolex was still a working man’s watch. The 16570 is perhaps the best of this era, sporting the 3185/3186 caliber movement that’s pretty much still in use in their modern GMTs.

They say you buy a Rolex when you’ve made it. I say, you buy a Rolex to fake that you’ve made it. Shake the hand of a potential business associate and they will hear the rattle of that old world craftsmanship. They think, wow, this is a man of eminent taste and respectability. This is a woman I could do business with. Before you know it, you are running for president.

You’re welcome.

Price: priceless (but actually around $8-9K)

The Bradford Chef Knife in AEB-L Steel

This has become my workhorse in the kitchen, and I barely touch my fancy super thin Japanese Bunka anymore. It’s sturdy and thick, but can hold a great edge (at least for a week or two, it does need a lot of sharpening). I love the composite handle, because I don’t have to worry about water getting in there like with my wooden handle knives.

Bradfords are proudly hand finished in Washington since 2012. They have a lifetime warranty (including sharpening) and are insanely reasonably priced for what you’re getting.

Price: $219

--

Be it a record player, a knife, or even a simple pen, I hope your gifts are well received. Happy holidays everyone.

Here at Technically, we believe that the holidays is about the grind — you’ve finally broken free from being the idea guy on the business side. As Charlie Parker said, “now is the time” — get out the laptop, heat up a hot pocket, and prompt away.

The holidays are for vibe coding. Idea people thrive in the holidays. Let’s dive in.

—

It’s nearing 2026, and you (probably) don’t need a software engineer to build the app of your dreams. I tested 4 of the most popular vibe coding tools to see which was the best. TL;DR:

• Replit was the most feature rich, well thought out, and powerful

• v0 was the best if you’re already a developer and want a technical interface

• Lovable and Bolt were pretty much objectively worse than the other two

Most importantly, I believe that the initial app building phase in vibe coding is largely commoditized across tools, and what makes any platform a better fit than another is largely pricing models and integrations.

In this post I’ll walk through my experience with each of these tools, covering:

• How they work, and important differentiating features

• Pricing, tokens, and how far you can get on a free plan (I paid for 2/4)

• How good (or bad) they are at fixing bugs

Throughout I’ll be using a very serious, very real set of prompts. As Art Vandelay, owner and CEO of Vandelay Industries, my team needs an internal dashboard to handle the importing and exporting of potato chips to the United States.

Here’s the prompt I started each tool out with:

I am the CEO of Vandelay Industries, a global firm that handles the importing and exporting of potato chips to the United States. I need to build an app for managing the internal operations of my business. The app should have 3 main views:

1) An inventory manager / CRM of all of our shipments of potato chips. This should be a table view backed by a database with columns for things like each shipment’s potato chip brand, size, monetary value, and who and where it is being shipped to

2) Analytics and charts on our shipments: top shippers, top brands, volume for this month, things like that

3) A map of current shipments and where they are located

From there I inspected each app and went through each bug one by one, prompting the model to fix it.

Thanks to our friends at Vercel, who make v0, for sponsoring this post + giving me a good reason to sit down with all of these vibe coding tools.

The below reviews are my own opinions, and as you’ll see I shoot you straight.

Replit

Replit was the most feature rich, felt the best thought out, and overall created the best and most polished finished app of all of the tools I tested. But it also took by far the longest, frequently set itself into doop loops, wasted tokens on nonsensical testing that didn’t work, and there’s no way to publish your app without paying.

Replit stat sheet

Initial prompting and planning

When you prompt Replit Agent it starts by generating a plan. In most vibe coding tools you can either toggle on planning mode, or the tool automatically defaults to it.

Another unique feature among the vibe coding tools I evaluated was this choice Replit gave me before building anything:

This brings me to my first main point, which is that despite building essentially an identical UI to the other vibe coding tools I tried, Replit took a really long time to build it: about 15 minutes or so. My sense is a lot of this time was wasted on the model getting confused, adding and then removing things, and unnecessary testing.

It’s extremely trippy watching a model create a codebase from scratch; it’s eerily similar to a human, trying stuff and getting errors, then fixing those errors and starting the whole thing over again.

Pricing structure

Towards the end of the app build, I got paywalled:

Replit’s pricing isn’t credit based, and instead calculates a cost per prompt based on how long the prompt took to resolve. For every prompt you will get a breakdown of how long it took, how many actions were done, and then how much your agent usage cost.

Here you’ll notice that 75% of my costs were for something called “Automated UI Testing” – this is one of the worst features in Replit by a mile and is unfortunately enabled by default. It essentially tries to automatically test your app using some sort of emulated browser:

The problem is that it doesn’t really work, takes orders of magnitude more time than your actual app building prompts, and ends up costing you extra money at phases where you didn’t even need testing. And it’s enabled by default, which it really shouldn’t be.

Overall the app cost about $6 for the initial build, and subsequent smaller bug fixes were usually $0.50 or less.

Final app

Anyway here’s what the final app looked like:

Despite the fact that I didn’t really specify a lot of functionality on this page, Replit was smart enough to add a lot of it for me: sortable columns, the ability to add a new shipment, the ability to edit and delete a shipment, etc.

The app started without any data, so I needed to prompt Replit to make a fake dataset and it did a good job:

The app has no data. Can you generate a mock dataset of potato chip shipments that matches the schema of the database?

The initial app was pretty good but had some bugs that needed fixing. For example, the sorting on the “destination” column didn’t work, so I prompted the model to fix it and it did correctly the first time.

Integrations

Like I said above, I believe (and you will see that) the initial app building phase in vibe coding is largely commoditized across tools. What made the Replit experience good for me was all of the other stuff. For example, their UI for editing the data in the database:

The Replit UI is built modularly via different tabs. The first tab has the preview of the app, and when you open a new one you can choose from all different sorts of “features” for lack of a better word:

To my knowledge this is far and away the most comprehensive suite of features for a vibe coding tool; but at the same time, probably overkill and too technical for the typical end user.

Publishing and deployment

Replit prices publishing like a cloud provider, and there is no free option for deployment. To publish you choose a machine configuration in the cloud, plus whether you want autoscaling and things like that. Again, to the typical non-developer, I’m not sure they’ll be able to accurately decide how many CPUs and GBs of RAM they’ll need.

If I had to personify the Replit Agent, it feels like that zany engineer friend of yours who chaotically works all night, zigging and zagging to build something, but somehow the final product is actually amazing.

v0

I think of v0 as the best vibe coding tool if you’re someone who can actually code. It tries to strike a very different balance between ease of use and customization, and leans heavily towards the latter. It also has the smoothest, fastest, and most accessible publishing / deployment flow of any of these tools. It’s from the team at Vercel so this does not surprise me in the least.

v0 stat sheet

Initial prompting and planning

Like Lovable, v0 was off to the races after I gave it the signature Vandelay Industries prompt. The only thing it asked was if I wanted to integrate with Supabase, their default database provider (to which I answered, yes, of course my dear). I’ll talk more about this Supabase integration, and why you might prefer this to how Lovable and Replit do theirs, in a bit.

The Supabase install ran into a brief hiccup and I needed to re-select my newly created database from the dropdown, instead of the model proceeding automatically once I completed the signup.

v0 built the whole app in about 4 minutes, and like Replit, it smartly intuited that it should build the ability to add, edit, and remove shipments. I ran into some overflow issues with the charts on the analytics page, and it took a couple of prompts before the model was able to fix it.

Though it didn’t automatically use it off the bat, v0 does have a planning mode, and you can also tell v0 to plan explicitly in your prompt. Otherwise the feature is hidden in one of the toggles in the prompt box:

Pricing structure

v0’s pricing is pretty straightforward – there’s a free plan where you get $5 in credits every month, a $20/mo premium plan where you get $20 in credits a month, a $30/user/mo team plan where you get $30 in credits a month, and then above that, business and enterprise plans that have different credit schemes. You can also buy any amount of credits on top of what you get from your monthly plan.

Building my app and subsequent fixes took <2 credits, so I was able to build the whole thing for free.

Final app

The final app looked a lot like the others, save for the navigation being on top instead of the side, and a curious use of emoji.

v0 also added sample data without me needing to prompt it.

Integrations

I mentioned earlier that v0 doesn’t have a built-in database, and instead defaults to a Supabase integration that requires you to create an external account there. It’s only a few extra clicks, but you do need to choose a configuration for your Supabase database (there are both free and paid options).

At surface level you might assume Replit’s and Lovable’s approach – building a database natively – is simply easier and better. But this is not entirely true. Like I said in the intro, v0 is engineer-leaning and prioritizes flexibility and customization over pure ease of use. The ability to choose which database you want to use – both in terms of the database itself, and in terms of the power, size, and configuration of that database – is important for a lot of people (like yours truly).

So if you want to use a different database – like let’s say Neon, or Redis, or even Vercel’s Blob storage, they have native integrations where you can do that in a few clicks. v0 also has few-click integrations for other things like Grok (and unrelated, Groq), fal, Stripe, etc.

Publishing and deployment

This is another area where v0 shines. Vercel made a name for themselves by making it as easy as humanly possible to deploy your app, and that’s exactly what you get with v0.

When you click publish, your v0 app automatically becomes a full-fledged Vercel project; you get all of the advanced features you’d get if you had built your app manually like automatic deploys, detailed logging, analytics, etc.

Lovable

Lovable was a lot smoother, faster on the initial build, and easier to use than Replit; I was also able to create and iterate on my entire app for free. But the final product was significantly less polished, there were glaring security issues (entirely Lovable’s fault), and the platform overall felt way less…mature?... than others I tested.

Lovable stat sheet

Initial prompting and planning

Like Replit, I asked Lovable to build a dashboard for Vandelay Industries. Unlike Replit, it kind of just started doing it without asking me for any preferences or planning or anything. The only thing I was prompted back was whether I wanted to to use Lovable Cloud, which is their out of the box backend (I said yes):

Lovable frames all of their backend services – database, authentication, and models – as a single “Cloud” product, whereas for Replit, each one of these is an individual add-on and treated as a separate product.

Within a few minutes I had my app, but the V1 was a lot less polished than Replit. One glaring example: Lovable used the wrong font color for the sidebar, so there was no way to see how to navigate between the shipments panel, the analytics panel, and the map panel.

Perhaps the analytics will show that nobody is clicking on any of the other tabs

I asked Lovable to fix it, and it took two prompts: the first time it thought it had fixed it, but it hadn’t. During the second prompt it got stuck in some sort of doom loop that required me to reload the page and start the prompt over. Also, the “map” that Lovable generated is, by most definitions I can gather, not a map:

I think of Lovable as vibe coding with guardrails. It’s a significantly simpler platform with more things taken care of for you, less detail given to you, and an overall more plushy, daycare-like feel. That’s nice if you’re building something simple, but less nice if you’re more technical or have more complex needs.

Pricing structure

I was able to build this whole app for free, which is nice…but looking into Lovable’s actual pricing left me with more questions than answers. Consider the Pro Plan, their cheapest:

So you start with 100 credits every month. But then you also get 5 credits every day, which can accumulate to up to 150/month; but is that including the 100 every month? Then there’s a completely different billing system for Cloud, their backend package, where you get up to $25 in “usage” (not credits?) every month. But, this usage deal only lasts until the end of 2025, then it’s going to be…something else. Credits can also roll over, but only on the cadence of your plan, so if you’re monthly, they only roll over for 1 month.

And what is a credit exactly? Well that completely depends. Lovable’s pricing page says there are two modes – default, and chat – and each burn credits differently. But wait, as of July 2025, agent is now the default mode, which replaces legacy mode. We are now up to 4 different modes, are you keeping track?

I want whatever this pricing team is smoking.

Final app

The final app ended up looking pretty similar to all of the other vibe coding tools. Almost like they’re using the same models under the hood…

Unlike Replit, Lovable did not intuit any features on top of what I explicitly asked for. So on this shipments page, there’s no way to edit, add, or remove data.

The analytics aren’t exactly useful, but then again, all of this data is fake…speaking of which, Lovable was the first vibe coding tool I used that automatically generated a fake dataset to populate the app with. I thought this was pretty clutch and it was nice to avoid having to prompt the model to do that.

Integrations

Like I mentioned earlier, Lovable bundles all of the usual backend pieces you’d need into one product they call Cloud. Cloud has its own pricing and usage mechanism, distinct from the credits system used for the actual vibe coding. There’s also a “native Supabase integration” but it’s unclear what relationship this has with Lovable’s own Lovable Cloud. And perhaps to only my own disappointment, there’s no smooth UI for editing the data in the database like Replit had.

Then there are a lot of other integrations: they’ve got Stripe, GitHub, etc.. “Integration” means different things for different vibe coding tools. Which brings me to Lovable’s security advisor. This thing – a valiant effort, for sure – attempts to scan your app and tell you if it has any vulnerabilities. And it actually works pretty well. For example, it scanned my app and noted that my database – yes, the one that I trusted Lovable to set up for me – had no security measures whatsoever and any hacker could log in and mess with my data:

On the one hand this is great, because most non-technical people vibe coding would have no clue that this is a problem. On the other hand it’s not great, because LOVABLE IS THE ONE WHO BUILT THIS APP IN THE FIRST PLACE. If the model knows that it’s bad for a database to have no protections, why didn’t it build the app correctly the first time around????

Publishing and deployment

Publishing your Lovable app doesn’t consume any credits in of itself, so if you were able to build your whole app for free like me, you can also publish it to the world.

Bolt

Bolt occupies a medium somewhere in between Replit and Lovable. It follows the “plan first, build second” philosophy (like Replit), but wasn’t very good at following its own plans. Pricing is token based and very opaque and confusing. Overall, it felt like their model was decent at doing what you asked, but would then create some sort of side effect that you didn’t want.

Bolt stat sheet

Initial prompting and planning

The Bolt prompt box on the site has a “plan” toggle that lets you have the model plan your app first, and you then review that plan, instead of going straight to implementation. For larger builds I would highly recommend always utilizing some sort of planning, for whatever reason models perform a lot better with a two step process like this.

This is what a generated plan looks like:

The model attempts to add detail to my pretty vague prompt, sketching out an initial requirements document. And from there you can tell it which functionality matters to you and which doesn’t (for example, I don’t have access to shipment location data).

There’s also a dropdown for choosing different models – which at first was exciting – but then I realized that you…don’t really have a choice.

Once you’re satisfied with the plan the model generated, you can click the “implement for me” button – although that button never showed up for me and I needed to manually prompt the model to implement the plan (fine). There’s a nice dedicated UI for showing the model’s progress through the plan:

All of this sounds really nice, and it would have been, except that Bolt didn’t actually follow its own plan. For example, in the plan the model put together, it specified:

3. Inventory Manager and CRM Table View

• Build interactive data table with sortable columns for all shipment fields

• Implement search and filter functionality across multiple columns

• Add pagination for handling large datasets efficiently

• Create modal forms for adding new shipments with validation

• Enable inline editing for updating existing shipment records

• Add bulk actions for managing multiple shipments at once

• Include export functionality to download shipment data as CSV

Hm yes, sortable columns, a modal for adding new shipments, inline editing, very nice, very nice. It didn’t build any of that, it just gave me a read-only table:

It took another cycle of prompting, planning, and implementing to add those features. Which is fine, but like, if you’re going to make a plan, stick to the plan the first time.

Then there was the analytics dashboard, which essentially made no sense:

For each of these nonsense charts, I needed to prompt the model to fix them. And then there’s the map. The map was no fun.

I shit you not, it took 5 cycles of prompting back and forth to try to fix this thing, and eventually I gave up because it seemed like it wasn’t in the cards.

Pricing structure

Bolt’s pricing is not straightforward. They are the only vibe coding tool in this post that charges by tokens instead of credits or some generic dollar value. For $25/mo you get 10 Million tokens every month, and unused tokens roll over to the next month (but not further than that). So what is a token exactly?

Great question. Bolt’s answer is essentially that we can’t really know for sure.

(Lucky for you, we’ve already written about what tokens are and how they work)

OK, so tokens are hard to explain, fine. But at least it’s easy to see how many tokens your work in the Bolt app is costing, right? Also no. Unlike all of the other vibe coding tools in this post, there is no way to know how much your prompts and responses in Bolt cost, even in terms of tokens. The expectation is that you prompt away and periodically check your account’s token balance, I guess?

Final app

The final app, after the planning fiasco and subsequent work required to compress the many columns into a layout that fits on one screen, looks pretty good:

Integrations

Bolt, like Replit and Lovable, has a native database. There’s a nice, if a bit primitive, UI for viewing and editing the data in your database:

Like Lovable, use of the database is priced separately from use of the model. And adding to the pricing confusion, the database is priced in relation to compute use, so you get a specific size of VM and hours of compute based on the plan you’re on.

Outside of their native database (and authentication) Bolt’s integrations ecosystem is less developed than others in this post – there is essentially just Stripe as far as your actual app is concerned (the rest deal with hosting).

Publishing and deployment

You can publish your Bolt app for free and they will support up to 333k web requests; if you upgrade to the $25/mo plan you get 1M web requests. Is this number actually enforced? I’m not sure.

Which vibe coding tool shall rule them all

To summarize, of the vibe coding tools I tried:

• Replit was the most feature rich, well thought out, and powerful

• v0 was the best if you’re already a developer and want a technical interface

• Lovable and Bolt were pretty much objectively worse than the other two

If I were starting a new project from scratch I’d use Replit or v0, and spend more time paying attention to how to plan well instead of just having the model go off and do what it thinks is best.

Pricing models vary wildly across tools, as well as how far you can get without paying and what it costs (if it costs) to deploy your finished app. Overall, for an app of low/medium complexity like mine, expect to pay ~$10-$15 to get a decent finished product that you’ve had some time to iterate on.

Have you used any of these tools? Have opinions on which is the best? Let me know in the comments.

Let me start by saying that I do not think AI is going to put massive swaths of people out of work. But that’s only going to be true as long as we are smart, adaptive, and embrace these new tools to make us all more productive and more creative. The problem is that there are tons of lazy people out there who are using AI completely carelessly, with such minimal oversight such that they are essentially writing their own pinkslips.

If you carelessly offload the core and soul of your job to AI, you cannot be surprised when someone decides AI can do it instead of you.

If you are a software engineer for whom Cursor now writes all of your code with minimal oversight or creative input from you, this is bad. If you are a marketer who is generating entire blog posts and page sites with vanilla Claude prompts, this is bad. If you are an SDR who has ChatGPT write all of your outbound emails with no customization whatsoever, this is bad.

At some point, your boss is going to realize that the AI is doing your job, not you.

The brain drain from junior talent and financial modeling

I see this pattern with more junior people the most. They are at a point in their careers where they have minimal experience and maybe more importantly minimal taste. The risk of overusing AI is huge here, because without going through the motions and developing that earned intuition for the mechanics of your work, you will never develop that taste. IMO at the highest levels, you are paid for exactly this.

I was talking to my friend CJ of the wonderful Mostly Metrics newsletter about how this manifests itself in finance. A lot of what finance teams at startups do is build financial models, which as any investment bankers in the audience can tell you, is something with a lot of manual, repetitive work; in theory a great candidate for some help from AI. Yes, some help. But CJ told me that he’s seeing more junior talent is offloading the entire financial model building process to AI and not building any parts of it from scratch anymore.

(I’ll admit, the use of the word “model” here is a bit confusing.)

This is not good. To intimately know how something works and develop an intuition for it, you need to do the work yourself. In this case, to build the model from scratch, to develop an understanding of what the sensitive variables are, and maybe most importantly, to be able to explain it to someone.

“Maybe I’m like an old man yelling at windmills just because I spent at least 10 years in the trenches doing that from scratch. But they’re skipping steps one, two, and three and jumping straight to four.”

Prompting an AI model to build your entire forecast for you will get you a quick answer, sure. But you didn’t build it, so you don’t understand it. What happens when the assumptions baked into the model change?

This is true across so many different disciplines. Just think about the explosion in vibe coding. It’s amazing that a single prompt in Replit can get you a working app. But if you don’t understand what’s going on in the app at all, don’t try to refine and improve it…what have you really created? And what’s stopping someone else from doing it better than you?

Something something Icarus flying too close to the overheating GPUs.

Use AI to augment your work, not replace it: the facked vs. cracked framework

When it comes to using AI, the best work products are the ones that combine your unique insight and creativity with the automation firepower from models. If the work product you’re creating is not in some way authentically you, or clearly borne of your handiwork, then you are giving up too much to AI and this does not bode well for your long term career prospects.

Across conversations with teams who are trying to use AI at work, plus some of my own experience, here are a few examples of facked vs. cracked uses of AI. In other words, finding the sweet spot where AI is helping you but not doing your entire job for you.

Finance

• Facked: prompt the AI model to build your entire financial model for you.

• Cracked: build the bones of the financial model yourself, use AI to automate repetitive spreadsheets copying and pasting and/or test new scenarios.

Marketing

Good marketers are using AI to help them generate better content faster, not entirely offload content creation…after all, who the fuck wants to read that.

• Facked: use vanilla prompts to generate an entire finished blog post of slop.

• Cracked: add style guide to context, use AI to generate a starting template, write and edit from there.

Software engineering

Before you say “OK, but this is a straw man,” no. People are absolutely doing this.

• Facked: offload massive features and parts of your codebase to AI without supervision.

• Cracked: tabbed auto-complete, heavily customized agents with clear guardrails, testing, and code review.

Sales (well, debatably)

SDRs are perhaps the most guilty party here. If there’s one really clutch thing to use ChatGPT for, it’s hyper-personalization at scale…and yet who is doing this.

• Facked: use vanilla prompts to generate a bare minimum amount of personalization, like “I noticed you just finished up an impressive 3 years at Meta.”

• Cracked: use models to do standardized deep research on prospects, store the data in Clay, use a second highly customized prompt to personalize based on research.

Use models, do not let them use you!

A great place to begin is starting small: pick a recurring, manual process to automate instead of trying to tackle an entire function or workflow. AI models work better when you give them a narrow scope, clear context, and a tight feedback loop. Find one specific, annoying thing you do every week, like summarizing meeting notes or categorizing customer feedback, and try to automate that.