Code isn't cheap, but POCs are

I keep hearing the phrase "code is cheap."

I don't know who came up with it. Whoever it was clearly has not seen an Anthropic bill.

I get what they mean. The cost of writing a line of code has cratered, AI does most of the typing, you know the rest. Fine. But the phrase is combative in a way that doesn't help anyone, especially the engineers in the room. "Code is accessible" lands better. Less swagger, more honesty.

Either way, here's the line my friend Guillaume gave me that finally cracked it open. "My young daughter can write code. That doesn't make her an engineer."

Right. Because what got cheap isn't engineering. It isn't even code, really. What got cheap is the proof of concept. The hacky working thing that demonstrates an idea. The artifact a product marketer like me used to need a skilled developer to build.

The better phrase: POCs are cheap now.

I'd know. It's what I do.

What "POCs are cheap" actually means

A few months ago, if I wanted to demonstrate a feature idea, I had three options.

Write a long, careful spec doc and hope it gets read. Build a Figma mockup that looks done but can't be clicked through. Or beg an engineer for an hour of their time to mock something up.

Now I have a fourth. Vibe code a working version myself (using that term exactly once for SEO purposes, after this it's AI-augmented development, which is the same thing but sounds fancier and is harder to dismiss in a board meeting).

The trick isn't that I learned to code. I didn't. The trick is that the model carries the technical load and I carry the product judgment. I describe the idea the way I'd brief a senior engineer. I read what comes back. I push it around until the thing in front of me matches the thing in my head. Two hours, maybe three. Then I share it.

Andrej Karpathy coined the term in February 2025. The internet had opinions about whether you're "really" coding when you do this. The internet had the wrong question. The right question is whether the artifact moves the conversation forward. It does. Reliably. Every time.

Guillaume's daughter isn't an engineer. But she could prototype an idea now. So could her teacher. So could your PMM.

The pattern in reverse

Here's the part I didn't expect.

My engineering friends are doing positioning work that's better than some of what I used to ship.

Not all of it. They're not going to take my job. But specific pieces of the work, the parts where you're hunting for the right angle on a feature, or the right way to describe the thing to a customer, or the competitive line that makes the demo land, my engineering friends are coming back with strong drafts.

The pattern is the same as mine, mirrored.

We give them the foundation. ICP. Personas. Buying habits. Competitors. The way our customers actually talk about the problem. They feed all of that to an AI alongside the feature they just built, and they come back with positioning angles I would have spent a week generating in a marketing-team workshop.

The AI didn't do it alone. It needed the context. That context is the part marketing actually owns. But the synthesis, the moment where you stare at the brief and try to find the line that makes everything click, the AI is good at that when you give it the right inputs.

Same dynamic as my POCs. The AI carries the load. The human carries the judgment about what's actually right. Different role on each side of the team.

What this means for how teams work

This isn't a "marketing should learn to code" article. Or a "engineers should learn marketing" article. Those framings miss it.

What's actually happening: the collective brain of a small team got a lot bigger. AI-augmented development gave the non-engineer access to working prototypes. AI-augmented positioning gave the non-marketer access to sharp angles. The crafts haven't moved. The boundary fence got a lot of new doors.

The teams that figure this out fast end up with shorter feedback loops. The PMM walks into the roadmap meeting with a working prototype. The engineer walks into the launch meeting with three positioning drafts. Nobody is starting from a blank page. The conversation skips the first 60% and goes straight to the part where the team is actually deciding something.

The teams that don't figure it out keep treating these as one-way streets. The PMM writes the brief, the engineer writes the code, neither of them touches the other's work. Same speed as five years ago. Worse, even, because everyone else is moving faster.

The tradeoff I owe you

POCs being cheap doesn't mean they're free of risk.

The biggest risk isn't the code. It's the meeting after. A working POC creates the illusion of completeness, and the natural next question is "let's ship it." That's where teams get into trouble. The code I write in an afternoon is not the code anyone should run in front of customers. Gartner warned that "prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%" by 2028. They're right about what happens when nobody draws the line between POC and production.

Draw the line out loud. The POC is the conversation. The product is what gets built afterward, by engineers, with rigor. The engineer's positioning draft is the spark. The launch copy is what marketing builds afterward, with craft. Don't ship either of them straight from AI to the customer.

Back to the Anthropic bill

I want to be honest about one more thing. Code isn't cheap. Tokens cost real money, and I've watched my team's bill climb every month as we lean harder into this workflow. The cost just moved. It used to be developer hours. Now it's compute. The math still pencils out, by a lot, but pretending the cost vanished is how teams end up with quarterly surprises.

Guillaume's daughter still isn't an engineer. She can prototype an idea now. So can my PMM team. So can my engineer doing positioning. The titles don't change. The toolkit does.

That's what we should be saying out loud, in the meetings where the org chart still pretends those three jobs live in three different rooms.

Code is accessible. POCs are cheap. The team is bigger than the headcount.

In the next post, I'll walk through exactly how I build these prototypes: Claude Code, Upsun, and the specific skills, plugins, and MCPs that let a product marketer ship something a real engineer can react to in an afternoon.