On August 15th, Cursor became part of SpaceX.

Sixty billion dollars. In stock. Days after SpaceX went public. It’s one of the largest acquisitions in the history of developer tools, and if you use Cursor to build things, it’s worth reading the announcement they wrote about it.

“SpaceX is building the computing capacity needed to scale intelligence far beyond what exists today. Cursor will be one place where that intelligence becomes useful.”

Cursor’s own post about joining SpaceX referenced the computing infrastructure repeatedly. The prize, in their framing, was this: access to “the largest fleet of GPUs in the world.”

“One place. Where the compute becomes useful.”

Read that again and let it land. In the story Cursor tells about its own $60 billion exit, the product you use every day (the editor, the agent, the thing you pay for) is a place for GPUs to become useful.

You are not the customer in that sentence.

You’re the demand 🛰️

The gold rush had a tell, and this is it.

I opened this whole series months ago with the California gold rush, the observation that the people who got reliably rich weren’t the miners, they were the ones selling shovels. Levi Strauss, Samuel Brannan,…

I thought that was the end of the analogy. It wasn’t.

Because in 1849, something happened underneath the shovel sellers that almost nobody ‘remembers’. The men who got truly wealthy weren’t even selling shovels to miners. They were the ones who controlled the thing every shovel seller, every miner, every merchant ultimately depended on: the supply lines. The water rights. The land the whole thing stood on.

Wells Fargo didn’t pan for gold. It moved the gold, banked the gold, and controlled the infrastructure the entire economy of the rush ran through. When the gold ran out, the miners left, the shovel sellers folded… and Wells Fargo became one of the largest financial institutions on Earth.

The layer beneath the shovels is where the durable money always was.

In the AI coding rush, the shovels are Cursor, Copilot, Lovable, Bolt. And the layer beneath them (the water rights of 2026) is compute, or in short… GPUs. The fleets of silicon that every single one of those tools rents time on.

SpaceX just bought a shovel to get closer to selling water! 💧

“You are not the customer in that sentence. You’re the demand.”

Subscribe now

Share

Why this should change how you choose your tools.

Here’s the part that matters for you, practically, on a Tuesday.

When a company’s real business is consuming compute, its incentives quietly invert. It doesn’t want you to use fewer tokens. It wants you to use more. Every reasoning loop, every agent that runs for an hour, every “let me re-check that whole codebase”, that’s not a cost to be minimised anymore. That’s the product working as intended.

Look at what happened in the exact same window as the acquisition, per the builder chatter this month:

A user burned through nearly 50% of a $200 Cursor plan in three hours. Called it unsustainable. Went and built his own tool.

Cursor raised usage limits and auto-mode costs, and a thread titled, and I promise I’m not making this up, “Enshittification Comes for Cursor” hit the front page, describing intrusive UI changes, forced model selections, and unexpected token burn.

None of this is villainy. It’s gravity. When the entity that owns your tool makes its money on compute consumption, “use more compute” stops being a bug in your bill and starts being the strategy on their roadmap. 🎢

You are, structurally, holding a meter that the house now has every reason to run faster.

The billion dollar question

Everyone is asking who wins the compute war.

1. SpaceX and xAI and Cursor on one side.

2. Anthropic and Google renting SpaceX’s own GPUs on another.

3. Musk assembling a full-stack play while the industry watched benchmarks.

4. Memory prices up 500% in twelve months.

It’s a arms race, and it’s crazy to watch. But there’s a billion dollar question underneath it:

What if your app didn’t need the arms race at all?

Every tool in the current paradigm has AI in the code path, which means every app they build is a permanent, metered consumer of the compute layer. Forever. Every change, every fix, every feature re-runs the model against the codebase and spins the meter. Your app’s ongoing cost is chained to the price of GPUs, and the price of GPUs is now set by people whose entire thesis is that demand goes up and to the right.

READ THIS ONE MORE TIME:

If your app needs a frontier model every time it changes, you don’t own an app. You own a subscription to someone else’s compute.

The Makyo bet was never really about being cheaper . It was about severing that chain.

1. AI runs once, to translate your intent. Fractions of a cent, on the smallest model that does the job.

2. Then a deterministic compiler, no GPU, no inference, no meter, assembles the app. When you change something, you change the intent and regenerate.

3. The frontier model isn’t in the loop. The compute arms race isn’t in your cost structure.

Your app doesn’t rent water rights but it sits on ground you own. 🏔️

I’m not pretending we’re outside the AI economy. We still use models and we rent compute to run the translation step. But there’s a categorical difference between using compute once at build time VS depending on it forever at runtime. One is a tool, the other is a leash.

The caveat.

Let me not oversell this.

SpaceX owning the largest GPU fleet in the world is, in the near term, going to make some things genuinely better and cheaper. More compute capacity can mean lower prices, faster models, more capable agents. If you’re building throwaway prototypes where being wrong is cheap, an ocean of subsidised GPUs is good news for you.

And Makyo isn’t immune to any of this either. Memory prices up 500% touches everyone who runs anything. We’re a young company betting that determinism beats brute force over a long enough timeline, and “long enough” is doing real work in that sentence. The arms race could subsidise the vibe-coding path so heavily that the economics I’m describing take years to bite.

I just don’t think “hope the infrastructure stays cheap forever” is an architecture. It’s a wager on someone else’s balance sheet. 🎲 A tool used by millions of developers just sold for sixty billion dollars, and in its own goodbye letter it described itself as a place for compute to become useful.

That’s not a criticism of Cursor. It’s a description of the game. The durable money in every gold rush lives one layer beneath the shovels, in the water, the rails, the ground itself. This time the ground is made of GPUs, and the people who own it are now the people who own your tools.

The question the acquisition quietly poses to every builder is simple.

Do you want to build on top of the compute layer... or do you want to owe rent to it forever?

PS: We made the architectural call to keep the frontier model out of the runtime long before a rocket company bought an editor for its GPUs. It’s a strange feeling to watch a $60 billion deal turn your quiet engineering decision into something that looks, in hindsight, like a bet on exactly this.

Arthur Co-founder,
Makyo

Build something useful.

Our waitlist is open: Get the early access here:

Join the Waitlist

SOURCES:

• SpaceX closes Cursor acquisition ($60B): https://techcrunch.com/2026/08/15/spacex-officially-closes-its-cursor-acquisition/

• Cursor’s own “joining SpaceX” post: https://cursor.com/blog/joining-spacex

• SpaceX doubling revenue on Anthropic + Google compute deals: https://techcrunch.com/2026/08/04/spacex-doubles-revenues-on-anthropic-and-google-compute-deals-starlink-growth/

• “Enshittification Comes for Cursor”: https://news.ycombinator.com/item?id=49362593

• Cursor raises usage limits / auto-mode costs: https://www.reddit.com/r/cursor/comments/1vsqshp/anyone_got_this_email/

• Memory prices up 500%: https://www.latent.space/p/ainews-memory-prices-up-500-in-12

• Musk’s full-stack coding play: https://pub.towardsai.net/grok-4-6-x-cursor-elon-musk-just-bought-his-way-into-the-ai-coding-war-15a1292d4121

Answer the poll above to help me see your experiences!

Every so often, someone does the boring (yet in depth) version of something you’ve been ranting about (in this case, me) and hands you a peer-reviewed paper out of nothing.

That happened to me this week.

Researchers at York University and the University of Calgary took 1.1 million Reddit posts about AI coding tools, Claude Code, Cursor, Copilot, Codex, and systematically sifted them down to 446 posts and over 6,000 comments about one thing: security and privacy. The paper was accepted at one of the most respected automated software engineering conferences in the world.

They weren’t looking at whether AI writes buggy code(that’s old news)

They were looking at what the tools themselves do once you give them access to your files, your systems, your production database.

And what they found is genuinely something… 📄

The catalogue of things nobody approved.

Let me just give you the numbers, because they hit harder than any metaphor I could write.

Of all the security-related complaints, 43.1% involved unauthorized file operations. The tool doing things to your files you never told it to do. Break that down:

• 28.3%: the AI removing project directories or files without authorization

• 8.8%: modifying files without explicit consent

• 5.7%: reaching outside the active workspace to touch things it was never pointed at

In one case the paper singles out, Claude Code ran chmod +x on scripts, changing file permissions… without asking. Rare, the authors note, but when your tool can silently change what’s executable on your machine then “rare” is not the word you want to be relying on… do we agree?

Then there’s the category they call operational safety… 23.9% of security posts. This is the production stuff. The paper cites Replit removing a SaaS production database, and Cursor deploying to production despite an explicit instruction not to.

AN EXPLICIT INSTRUCTION NOT TO…. and it did it anyway.

Because of course it did, you cannot instruct your way out of a probabilistic system.
“please don’t deploy” is a suggestion to a thing that doesn’t take suggestions, it takes tokens and produces likelihoods. 🎲

“You cannot instruct your way out of a probabilistic system. ‘Please don’t deploy to production’ is a wish, not a constraint.”

And the one that made me actually wince, a privacy failure they call a context integrity breach:

A user of Claude Desktop reported receiving messages that came from another user’s session.

Someone else’s conversation, appearing in theirs….

I don’t say that to pile on Anthropic, these are the growing pains of an entire category moving faster than its own foundations. I say it because it’s the perfect miniature of the whole problem.
When the system is opaque and probabilistic all the way down, the failure modes aren’t just bugs. They’re surprises. And surprises are the one thing you cannot have in software real people depend on.

This stopped me

After a million posts, the researchers made recommendations, 6 of them. I want you to read the second one exactly as it appears in the paper where they advise:

“Enforcing security and privacy guardrails at an architectural level.”

And then the lead author, Professor Gias Uddin, said this to The Register, and I’ve read it about 20 times now:

“Prevention is better than cure; that is, security and privacy mechanisms should be built into the design before a tool is given broad access.”

READ THIS ONE MORE TIME:

“Built into the design. Before the tool is given access.”

Not bolted on, not validated after and not caught by a guardrail watching the output. He explicitly says: Built into the architecture, so the dangerous thing was never possible in the first place.

That is the entire argument I’ve been making across this whole series, except now it’s got a university logo on it and a conference acceptance and a sample size of 1.1 million. 😅

And if you’re happy with the knowledgeplease subscribe

Subscribe now

Secure defaults

The paper’s kindest, most sensible recommendation is this: the safe option should be the default, not something the user has to configure.

Uddin puts it very clear: users can’t be expected to know which permissions are risky, which files need protecting, or whether the tool is quietly doing something it shouldn’t. So the tool makers have to own it.

He’s completely right. And here’s the uncomfortable engineering reality underneath it:

You cannot make a code-generating AI secure by default,
not really.

Because the AI generates the code that sets the defaults. Every time, fresh probabilistically. You can ship it with better system prompts, better warnings, better permission dialogs and all of that helps at the margin but the choosing whether your database is public or private is the same thing that hallucinates a function name after ten rounds of dialogue. The paper even quotes a developer on exactly that: after more than ten rounds, “it starts to hallucinate and secretly modify code outside the requirements.”

Secure-by-default and generates-the-security-config-probabilistically are in tension. You can’t fully have both.

Unless the defaults don’t live in generated code at all.

MAKYO

This is the Makyo bet, stated as plainly as I can and honestly I am not telling you this because I want to promote anything, but its because we truly feel that we are going in the right direction, maybe the only right direction before others join along, so you’re the first…

The security posture of a Makyo app isn’t generated. It lives in the primitives, the pre-built, human-designed blocks the compiler assembles. A primitive that handles data was built once, correctly, by person who thought about permissions when nobody was rushing a demo. The AI never touches it. The AI describes intent; the compiler assembles from blocks whose defaults were set long before your session started.

So when the paper says “limit access to sensitive files by default”, that’s not a feature we add. It’s a consequence of the AI never being in the file-operation path to begin with.

When it says “require clear approval before consequential actions”, a deterministic compiler simply cannot emit an action the primitives don’t define. DELETE FROM customers after ten rounds of dialogue isn’t blocked by a warning, it’s not a thing the system can produce.

When it says “make it easier to see and review what the tool is doing”, the whole thing is a visible blueprint, not ten thousand lines of generated code you’re scrolling through at midnight hoping to spot the chmod.

I’m not claiming we’ve solved security. Nobody has, and anyone who tells you they have is selling something. What I’m claiming is narrower and, I think, more honest:

We simply moved the defaults out of the model’s reach so the model can’t get them wrong. 🛡️

Screenshot of Makyo Interface

Two Canadian universities read more developer complaints than any single human could process in a lifetime, and arrived at a one-line conclusion: build the safety into the design, before the tool gets access.

I’ve been saying a clumsier version of that sentence for six months. It’s strange and slightly humbling to watch it come back as a research finding.

The industry spent two years asking how do we make the AI safe enough to trust with everything? The paper, with a sample size that’s hard to argue with and suggests a better question:

What if the AI was never given the thing it could get catastrophically wrong?

That’s not a smaller ambition.

It’s just the one that starts with the architecture instead of the apology.

PS. Somewhere in that 1.1 million posts is every founder who found out after the fact that their tool had more access than they thought. We built Makyo for the version of that person who hasn’t found out yet.

Arthur Co-founder,
Maky

o

Build something useful.

Join our Limited Waitlist

Subscribe now

Last week, Cursor users noticed something on the usage page.

The cost information was gone.

Not moved. Not redesigned. Removed, from the usage dashboard and from the CSV export. The forum thread that followed was long, engaged, and unusually polite for people asking a simple question: how much am I actually spending?

I want to be careful here, because I don’t think this was malicious. Product teams remove things for all kinds of reasons. Maybe the numbers were confusing, maybe the model routing made per-request cost hard to attribute.

But think about the timing for a second…

We spent the last six months watching every platform tighten quotas, introduce metered billing, and admit the flat-rate era was over. Developers responded by building their own cost trackers, TokenMaxxer, Aireceipts, Limits, a local proxy that cut one guy’s bill by 68%. An entire cottage industry devoted to answering one question the tools weren’t answering.

And then the meter got turned off… 🧾
Might be a coincidence…

But htat’s the story everyone noticed.

Yet another story only a small group noticed happened in the same window, at a conference stage in San Francisco, and its a hundred times more important…

READ THIS

A UC Berkeley professor stood up and told AI engineers to go read something from 2001.

At the AI Engineer World’s Fair, Frank Coyle, a computer science professor who teaches generative AI at Berkeley gave a twenty-minute talk that became one of the most-watched of the event.

His argument, roughly: large language models are excellent at probabilistic reasoning. But agentic systems built on them need something LLMs cannot provide themselves, a set of hard, machine-enforceable rules about what things are and how they relate.

He called them ontologies. And he pointed out they’re not new. They go back to Aristotle. They ran through the entire history of AI and most recently they were the foundation of the Semantic Web, Tim Berners-Lee’s early-2000s vision of a web where meaning was structured and machine-readable, not just formatted for human eyeballs.

The Semantic Web was, for about fifteen years, the most polite way to say “failed idea” in web development. RDF. OWL. Schema.org. Beautiful in theory. Dead in practice.

And yet the concept wasn’t wrong.

But somebody had to sit down and maintain all that structure by hand, forever, and nobody wanted the job.

One developer summarised the vibe on X in July: you have to be over 40 to even discuss ontologies. 😅

And now, in 2026, it’s the most interesting idea at an AI engineering conference.

“The industry spent two years trying to make the model smarter. It is now quietly trying to make the world around the model dumber. Simpler. More rule-shaped.”

Why this is the most important thing that happened this month.

Coyle described the goal on one of his slides as “a bounded set of rules around an unbounded loop”.

Read that again, because, well because I want you to remember these nine words.

A bounded set of rules... around an unbounded loop.

The loop is the LLM. It’s unbounded by nature (it will keep going, keep generating, plausibly guessing). You cannot fix that by making it smarter.
A smarter guesser is still a guesser.

So you put rules around it. Not suggestions in a prompt, not “please don’t do that”. Rules a machine enforces, deterministically, that the model has no ability to argue with.

And it isn’t just an academic making this point. Neo4j’s CEO used his keynote to describe the same shift in commercial terms: moving away from heavy agents with hand-wired connections to every data source, toward much lighter agents sitting on top of a shared structural layer that holds the actual meaning of the business.

He called them thin agents.

A thin agent. On a structured, deterministic substrate. 🙂

I read that and had to put my laptop down for a minute.

Last week I wrote about the Duct Tape Economy, the entire industry of policy engines, secret catchers, memory patches and test healers that now exists to protect us from our own AI tools.

The ontology revival is the same instinct, reaching for a much older, much better roll of tape.

And to be fair to it: it’s a real improvement. A rule a machine enforces is categorically stronger than a guardrail that hopes. The Latent Space piece framing this correctly identifies what’s driving it, after the 2025 wave that suggested anyone could create software, the penny dropped. Somebody has to maintain the software.
So 2026 is turning into a return to engineering discipline.

I agree with all of it.

I just think it stops one step short.

The step it stops short of.

Here’s the uncomfortable bit.

If you bolt an ontology onto a system where AI still writes the code, you’ve built something better, a reasoner that checks the model’s work, catches contradictions, keeps the loop honest.

BUT the code is still generated. The architecture is still improvised. The ontology is a referee, not a foundation.

—> It’s a seatbelt in a car with no crumple zone.
—> Enormously better than nothing.
—> Still bolted to a structure that wasn’t designed for the crash.

The second (or maybe equally) most important line in this piece:

If the rules are real, why is the AI still writing the thing the rules have to check?

Because there’s another arrangement available. You can take the same insight (deterministic structure beats probabilistic guessing) and put it underneath instead of on top.

The structure isn’t a validator. It’s the thing that builds the app.

1. The AI describes intent

2. A deterministic compiler assembles the result from primitives that were designed correctly, once, by people.

There’s nothing to check afterwards, because nothing unchecked was ever produced. That’s the Makyo bet, and I’ll be honest, reading a Berkeley professor and the CEO of Neo4j independently arriving at “thin agents on a deterministic layer” was the strangest kind of validation. Nobody in that room has heard of us. They got there from a completely different direction.

Now the part I don’t enjoy writing.

There’s a company called Keystroke that open-sourced their internal agents platform this month. In their launch post, the founders named the thing that killed their previous approaches:

Visual no-code tools that become impossible to maintain at scale.

That criticism lands closest to home for us, not for Cursor. Because a no-code interface is what we’ve built on top of our compiler, and “unmaintainable at scale” is exactly what happens when a visual builder accumulates cases nobody planned for.

Our answer is that maintainability lives in the primitives and the intent, not in the boxes and arrows, regenerate from a changed sentence rather than untangling a canvas. I believe that. I truly do. I also know that belief hasn’t been stress-tested by a thousand agencies yet.

And there’s a second problem we haven’t escaped either.

The Semantic Web died of maintenance. Someone has to keep the structure current, every entity, every relationship, every edge case.

In our architecture, that someone is us, not you, which is the right way round. But it’s still a real, permanent, unglamorous job. One AI developer suggested online that agents might eventually maintain their own ontologies, updating definitions as they hit edge cases.

He also said it’s still a hard problem. He’s right. ⚙️

Recap

Two things happened in the same week.

1. A company removed the number that tells you what your building actually costs.

2. And a room full of AI engineers started reading papers from 2001, looking for a way to put hard rules around a system that only knows how to guess.

One of those is a UI decision. The other is an entire industry quietly changing its mind about what intelligence needs in order to be useful.

The meter going dark doesn’t bother me that much.

It’s what people reach for when they can’t see the meter anymore that tells you where this is going.

PS: We started building the compiler before ontologies were fashionable again, mostly because we couldn’t find another way to make regeneration safe. It’s a bit disorienting to watch the industry arrive at your architecture from the opposite direction, twenty-five years late and entirely by accident.

Arthur
Co-founder, Makyo

Build something useful.

HERE IS OUR WAITLIST. JOIN AND TRY OUT MAKYO WHEN WE ARE READY TO GO LIVE

JOIN OUR WAITLIST

Share The Logic Layer

Subscribe now

Share

Here’s what I saw:

1. A skill that filters “AI slop” out of code written by coding agents.

2. A monorepo template built specifically so AI agents can work in it without wrecking the place, complete with scoped rules and strict conventions.

3. A command-line tool whose only job is to tell you which agent session burned which tokens.

4. A credential gateway to keep secrets away from agents.

5. A dedicated persistent machine so an agent doesn’t lose its state between sessions.

All shipped in about seven days. All by working builders and all solving problems those builders are actually hitting.

I want to be careful here, because the easy version of this post is smug and the easy version is also wrong. Every one of those tools is good work and the people making them are not confused. They are doing exactly what competent engineers do when a workflow keeps hurting: they build the thing that makes it hurt less.

But step back far enough and the list stops looking like a set of products and starts looking like a diagnosis.

The shape of the problem

My observation: every one of those tools sits downstream of the code being written. The slop filter runs after the slop. The convention enforcer catches the agent after it’s already reached for the wrong pattern and the cost tracker tells you where the money went, which is a fundamentally retrospective sentence.

BUT none of them prevent anything… they contain things!

That’s not a criticism of the tools yet it’s the only place those tools can sit.
The case is: if a model is generating your code, the code doesn’t exist until the model makes it, so anything you want to enforce has to happen after the fact. You can filter, lint, review, scope, sandbox, and audit but what you can’t do is stop the output from being unpredictable, because unpredictability IS the mechanism. It’s not a bug in the model. It’s what a model is.

An entire product category formed this month around cleaning up after a step nobody is willing to change.

Share

Subscribe now

So collectively we’ve arrived (in my opinion) at a strange place: the fastest way to build software now requires a support crew of five other tools to stay maintainable, and we mostly just accepted that as the cost of doing business.

Why the bill goes up while prices go down

The token tracker is an interesting one.

The price of inference has been falling, year after year. So by any normal logic, the cost of building with AI should be collapsing. Instead, builders are shipping instrumentation because they can’t account for their own spend.

The reason is that cost stopped tracking price and intead started tracking process. When you ask a coding agent to change one thing, it doesn’t change one thing. It re-reads the surrounding code, reasons about it, and regenerates a great deal more than you asked for. Do that fifty times over a project’s life and you’ve paid for the same codebase to be written and rewritten dozens of times, most of it identical to the last version.

The logical takeaway from this is that you’re not buying software but you’re actually renting the model’s attention, again and again, on the same material…

A cheaper model does not fix this. It makes each round of the same waste marginally cheaper, which feels like progress right up until the invoice arrives.

Month six is where the bill actually lands

Agencies feel this before anyone else, because agencies live beyond the first month’s demo’s. Solo builders can abandon a project that got weird, an agency can’t. There’s a client, a contract, and a support expectation attached to a thing that was assembled by a process nobody could or can fully reconstruct.

What I hear from agency owners is consistently the same shape.

1. The build was fast and felt like a win.

2. Then the change requests started, and each one took longer than the last.

3. Then someone left and nobody remaining could explain why a particular piece worked.

4. Then the maintenance hours quietly ate the margin, and by the time anybody did the math on it, the profitable project had been unprofitable for four months.

Those are good teams with good discipline but its the result when the artifact you’re maintaining was never designed, but produced.

The build was never the expensive part. The maintenance was. It always was.

INFRASTRUCTURE

All of this downstream tooling is trying to reintroduce structure after the fact. Which means everyone already agrees structure is the answer. The disagreement is only about when it arrives.

We put it first.

With Makyo, the AI never writes code. It writes intent, a compact, structured description of what the application should do. That intent is validated against a schema before anything is built, so an invalid configuration gets rejected before it reaches the compiler at all. Then a deterministic engine expands that intent into a working app using primitives that were already written, already typed, already tested, by people.

—> The AI is the translator
—> The compiler is the engineer
And the compiler is not permitted to guess, because it isn’t a model.
So either the intent is valid or it is not. Either the primitive exists or it doesn’t. The failure mode is “this didn’t compile” not “this compiled confidently and wrongly”.

That’s also why the economics come out differently. We’re generating a small structured description, not thousands of lines of code, so the token cost per app stays flat as the app gets more complex. Regeneration is cheap enough to be uninteresting. The expensive engineering was front-loaded into the primitives once, by humans, instead of re-derived by a model every time somebody wants a different button.

You don’t need a slop filter if slop can’t get in. You don’t need convention enforcement if the conventions are the substrate. You don’t need to instrument your token spend if the spend doesn’t compound.

Join our waitlist here

What I’d actually suggest

If you’re running an agency right now, do the boring version of this exercise.

Pull your last five client projects —> add up real maintenance hours, including the Slack messages and the emergency Fridays —> multiply by your rate —> compare it to what you billed!

I did that in early 2025 and the numbers were bad enough that it changed what I do for a living.

You don’t have to switch anything to run that math. But once you’ve seen it, the growing shelf of cleanup starts looking like what it is: an industry building increasingly good buckets instead of all the leaky ones!

Makyo is in closed alpha with 50 agency partners now, and the waitlist gets founding-member terms when we open access. If you’re managing five or more client apps and month six is where your margin goes to die, that’s exactly who we built this for.

→ Join the waitlist at makyo.ai

Build something useful.

Arthur

Leave a comment

Share

Last week, a developer posted something on Hacker News that I haven’t been able to stop thinking about.

His Cursor agent almost executed “DELETE FROM customers" in production.

Almost. He caught it. And his response (this is the part that matters) wasn’t to stop using AI agents. It was to build an entire policy enforcement engine to wrap around them. It’s called Kastra. It exists so that the next time an AI tool tries to delete a customer database, something deterministic steps in front of the bullet.

Read that again slowly:

He built a deterministic system... to protect himself from his probabilistic one.

And he’s not alone. He’s part of something much bigger that nobody has named yet.
He’s part of a trend. 🩹

Subscribe now

Welcome to the Duct Tape Economy.

Spend ten minutes on Hacker News right now and count the products being launched. Not AI app builders but the tools built to survive AI app builders:

• Fence: literally described as “Jiminy Cricket for AI coding agents”. A conscience, sold separately.

• HeimWall: catches secrets before you paste them into Claude or Cursor. Because apparently we needed a bouncer for our own clipboard.

• Scopewalker: measures codebase complexity, built because agents “routinely create 1000+ line files and overloaded functions.” A smoke detector for spaghetti. 🍝

• TeamBrain, Afair, Sync.md: three separate memory patches, born from the same wound: “Cursor forgets what you did 20 minutes ago”. That’s an actual Medium headline from an actual developer who built an actual external memory system just to make his tool usable.

• Aireceipts: itemized cost receipts for AI coding agents.

• Limits, an iOS app just to track your usage caps.

• Kotro, a local proxy one developer built that cut his Cursor API bill by 68%. Sixty-eight percent. He had to build his own infrastructure to make the pricing survivable.

• 9lives: a self-healing test runner, because agents kept breaking Playwright tests with every minor change.

• Termaxa: an agent gate. Which, in a twist so perfect I couldn’t write it as fiction, silently stopped gating, and the developer only found out later. The guardrail needed a guardrail.

Every one of these is a real product, launched in the last few weeks, by smart people solving real pain.

And every one of them is duct tape 🩹

“You can tell how broken a tool is by the size of the industry selling armor for it.”

Share

Subscribe now

2 Fast 2 Furious.

We’ve seen this movie before. It had cars in it. In the 1950s, American cars were rolling sculptures. Gorgeous. Fast. Furious and obviously: Chrome everywhere.

But structurally indifferent to whether you survived them. Safety wasn’t the manufacturer’s problem, it was yours, and it was sold separately. An entire aftermarket existed for it: seatbelts you installed yourself, padded dashboard covers, add-on brake improvements, third-party mirrors,…
The industry sold speed and style; the duct tape economy sold survival.

Then the philosophy flipped: Crumple zones, integrated seatbelts, collapsible steering columns, safety stopped being an accessory and became architecture, designed in, not patched on top of it.

And the funny thing is that the aftermarket safety industry didn’t lose to better duct tape. It lost to cars that didn’t need it.

I’ll repeat this because its important:

The duct tape didn’t get better. The architecture made it unnecessary.

Subscribe now

Share

Why the duct tape can never win.

Here’s the mechanism underneath all of this.

Every guardrail tool on that list shares one assumption: the AI is in the code path, and we can’t change that, so let’s contain it.

Policy engines contain what it executes. Memory layers contain what it forgets. Secret catchers contain what it leaks. Complexity meters contain what it bloats. Cost trackers contain what it burns.

Contain. Contain. Contain. Until you have a Matryoshka as an app (image below)

But probabilistic systems don’t respect containment, they route around it. That’s not a flaw, it’s simply what “probabilistic” means. The Termaxa story is the whole thesis in one incident: the gate silently failed, and nobody knew until after.

When your safety layer sits outside a system that guesses, your safety is also a guess.

The sandbox escapes hitting Cursor, Codex, Gemini CLI and Antigravity this month made the same point at the security level. The armor keeps needing armor.

And you pay for every layer. In subscriptions, in tokens, in setup time, in the low hum of anxiety that something is silently ungated right now.

A question for Agencies

If you run an agency shipping client apps, the Duct Tape Economy is your bill. You’re not just paying for Cursor or Claude Code, you’re paying for the policy engine, the secret scanner, the memory patch, the token tracker, the test healer, and the senior developer who babysits all of it.

That’s not a tool. That’s a bandaid with a subscription model. 💸 So what would a tool look like that needed none of it?:

• Without “better guardrails”

• No policy engine, because a deterministic compiler can’t execute what the primitives don’t allow. DELETE FROM customers isn’t blocked. It’s unexpressible.

• No memory patch, because the intent persists by design. There’s no session ten where the system forgot session one. The blueprint is the memory.

• No secret catcher, because credentials live in configured primitives, not in generated code the AI might paste anywhere.

• No token tracker worth installing, because the AI only translates one sentence of intent. There’s barely anything to track.

• No self-healing tests, because the same input produces the same output. Healing implies breaking.

This is what we’ve been building at Makyo. Not a better AI coder with better armor.

But finally a system where the armor has nothing to do. 🛡️

“DELETE FROM customers isn’t blocked in our architecture. It’s unexpressible. That’s the difference between a guardrail and a foundation.”

The 1950s car industry thought the answer to danger was a braver driver. The duct tape economy thinks the answer to probabilistic chaos is more probabilistic tools watching the first ones.

We think the answer is the same one the car industry eventually found: stop selling armor. Change the architecture.

PS: When we started building Makyo, we made a list of the safety tools we’d need to build alongside it. The exercise ended early: every item on the list turned out to be a symptom of a decision we hadn’t made yet. We made different decisions instead. The list is empty.

Arthur
Co-founder,
Makyo

Build something useful.

“Six weeks”

That’s the whole timeline. A builder posted his story on r/vibecoding this week: vibe-coded a stamp-cutting app, shipped it, watched it grow, got acquired. Six weeks from first prompt to exit.

I read it twice. Standing up, for some reason, some posts do that. And if I’m honest, my first reaction wasn’t analysis. It was envy! Six weeks. I’ve had support tickets open longer than that.

Then I got to the part where he explains why he sold. He sold because he was done with the idea. He sold because the app had no durable moat, and because he could feel the maintainability problem coming. His workflow for fixing bugs was copy-pasting issues into Codex and hoping. Every new feature, same ritual. He was the owner of a growing product he couldn’t actually hold... so when someone offered to take it off his hands, he let go.

If you thought this was a story about an exit. It isn’t. Or… it is, but the exit is a symptom.

When you sell something because you can’t hold it, that’s not an exit. It’s an evacuation.

Share

The Maintainer’s Discount

Here’s the mechanism, and once you see it you’ll see it in every “vibe-coded and sold it” story this year.

Every codebase is worth two numbers: what it earns, and what it costs to keep alive. Vibe-coded apps look spectacular on the first number and are a black box on the second. The owner can’t read the code. The AI that wrote it has no memory of writing it (each session starts from zero, last month’s decisions are simply gone). So the true maintenance cost isn’t knowable. It’s discoverable... one broken deploy at a time.

Buyers price that in and sellers feel it coming. That’s why the smart ones sell early, before the second number surfaces. The acquisition isn’t validation of the product. It’s a transfer of risk to someone who believes they can absorb it.

Call it the Maintainer’s Discount: every AI-improvised codebase now trades below what its traction says it’s worth, because whoever inherits it has to pay for the archaeology.

Nobody builds a padded room for something they trust

It’s not just solo builders quietly pricing this in. Look at what the infrastructure crowd shipped the same week on Hacker News.

1. Sandboxes for AI agents, isolated rooms where they can run without touching anything real.

2. A deterministic orchestration tool for coordinating agents (a single Rust binary, durable mailboxes on disk, no cloud, someone wanted certainty badly enough to skip the entire modern stack for it).

3. Code-review pipelines built specifically to inspect what the coding assistants just wrote.

4. Dashboards for watching three coding agents at once, because apparently one wasn’t chaos enough.

I mean this with respect. These are good tools, built by people solving real problems.

But step back and read the pattern. An entire ecosystem is building guardrails, sandboxes, and review layers around AI-written code. The industry has quietly concluded that probabilistic code needs deterministic supervision. They’re just bolting the supervision on after the code exists, which means every one of these tools is doing forensics. Inspect what the AI improvised. Hope you caught it.

The opposite bet

We made the opposite bet at Makyo. In our minds, if probabilistic code needs deterministic supervision, don’t supervise. Prevent!

We built our app builder in such a way that the AI never writes code —> It writes the intent: a Blueprint describing what the app should do, in a form a human can actually read. Then a deterministic compiler assembles the real app from pre-tested, type-safe components. The same audited parts, every time, in every project.

So there is no mystery second number. Nothing improvised ever shipped, which means there’s nothing to discover at month six. And the Blueprint is a moat precisely because it can be held, you can read it, change one line of it, and regenerate the whole app. No archaeology.

Above: A sneakpeak preview of MAKYO before we launch live

If you run an agency

The builder in the story had a luxury you don’t have.

He had one app and one owner. When the maintainability wave came, he could step off the board. You have twelve clients, each with a retainer, each with a promise attached. An agency can’t get acquired out of its maintenance obligations. They compound. Every vibe-coded delivery you ship adds a second number to your books, one you can’t read, and your client doesn’t know exists.

He sold his app in week six.

Your clients arrive at their month six with your name on the invoice. The moat is being able to keep the promise, quarter after quarter, without the thing rotting underneath you.

Build like you plan to hold it.

YOUR TO DO: Open one app you’ve shipped in the last six months and try to explain, out loud, what happens when a user logs in. If you can’t, you already know your second number is out there waiting. Join the waitlist at Makyo.ai and build the next one on a Blueprint you can hold.

Wishing you exits you chose, not evacuations you needed,

Arthur
Makyo
LinkedIn | Makyo: Vibe Building, not vibe coding

If this reframed how you look at “vibe-coded and acquired” stories, hit the restack.

Share

Subscribe now

Somewhere in your network is an agency owner shipping their twelfth black box this quarter.

JOIN OUR WAITLIST: Makyo.AI

Six thousand engineers went to San Francisco last week and came home saying the same two words.

Software factory.

The keynote track was literally called that. Warp’s CEO stood on the main stage and said: “software engineering is becoming factory engineering'“. A company that just calls itself Factory defined the term as automating the entire loop (triage, spec, build, review, ship, monitor). Microsoft has one named Foundry. And the word that dominated every hallway was “loop”. The conference opened with a talk about the art of stacking them.

I went in ready to roll my eyes at another metaphor. I left thinking the factory framing is the most honest thing this industry has said about itself in a year. They’re right. The old picture: one developer, one agent, chatting their way to a feature, is already dead. Software is going to be built by standing systems that run without you watching. That part is just true now.

But sit with what these factories actually automate:

Every one of them automates the labor.
The loop of humans-and-agents doing the triage, writing the code, reviewing the code, testing the code, catching whatever the last agent quietly broke. At the conference, the surprise story was that evaluations “came roaring back”…. evals as a governor on the machine. There’s a whole emerging discipline now called
”harness engineering”. There are human-in-the-loop review gates. There are forward-deployed engineers whose entire job is to stand the factory up and stop it drifting.

Look at what all of that machinery is for.

It exists to inspect parts nobody trusts.

“A factory that has to re-inspect every part it makes is not a factory. It’s a workshop with a bigger QA department and better lighting.”

Subscribe now

We have run this exact experiment before. Two hundred years ago, with guns.

In 1785, a French gunsmith named Honoré Blanc laid a table of musket locks in front of officials, disassembled them, mixed the pieces into piles, and rebuilt working locks from parts picked at random. Thomas Jefferson, then ambassador to France, watched him do it and understood immediately that he was looking at the future. The French guild of gunsmiths understood it too, which is why they strangled it, interchangeable parts meant the master craftsman was no longer the point.

Jefferson carried the idea home and handed it to a young inventor fresh off the cotton gin. Eli Whitney took a government contract for ten thousand muskets, took the money, and by 1801 had delivered exactly zero. Called to Washington to explain himself in front of the outgoing and incoming presidents, he set up a table, picked lock parts “at random” from piles, and assembled them into finished muskets while the room watched. Jefferson wrote that Whitney’s pieces fit together so perfectly you could just grab the first ones that came to hand. Whitney walked out with his funding renewed and his reputation saved.

BUT….

The demo was rigged. Whitney had marked the parts beforehand so he knew which ones fit. He was careful never to actually take the locks apart, he only swapped whole locks between stocks, where the tolerances were loose and forgiving. Historians went back to the surviving Whitney muskets a century later and found no real interchangeability at all. He delivered the guns eight years late. He never once built the thing he demonstrated.

The real thing, true interchangeable parts showed up decades afterward, inside government armories, built by people whose names you have never heard, out of gauges and tolerances and a grinding manufacturing discipline that nobody in any room ever stood up and clapped for.

The demo was theater. The factory was discipline. And for two hundred years we have remembered the demo.

Share The Logic Layer

You know where this is going, because you have watched the modern version. The app built live on stage in thirty minutes. The room goes quiet. The thing works. That is Whitney’s table of marked parts. It works exactly once, beautifully, under conditions someone arranged in advance. Then you take it home, month six arrives, you try to change one screen, and nothing fits anything anymore. Not a bug. Not bad luck. The architecture is rigged.

We all learned the correct lesson as kids, with LEGO. Every brick fits every other brick because every brick is identical and was made before you ever opened the box. You never once filed a brick down to make it fit! That is interchangeable parts. That is the whole idea, and a six-year-old holds it in their hands without being taught.

Then we grew up and started building software the medieval way, hand-carving every single brick to order, and we called it progress because the carving had suddenly become free.

Free carving still leaves you with a pile of bricks that don’t fit.

Share

So here is the industry’s actual answer to the pile: automate the carving, then build an enormous inspection line to catch the misfits before they reach production. Loops to re-carve. Evals to govern. Harnesses to hold the whole thing together. That’s what most “software factories” are right now, the assembly line built first, the interchangeable parts skipped entirely.

But the assembly line was never the invention. The parts were. Ford’s moving line in 1913 was only possible because interchangeability had already been solved a hundred years earlier. You cannot run a line on parts that need hand-fitting. You just get a faster way to manufacture things that don’t fit.

Which means most of what’s being sold this month as a shiny new engineering discipline is the cost of missing interchangeable parts, rebranded as a virtue. Harness engineering is the tax you pay for letting a model carve bespoke code. It’s real work. It’s skilled work. And almost none of it would need to exist if the parts were certified before they hit the floor.

(I’ll admit I shipped two vibe-coded apps I was genuinely proud of in the demo and quietly stopped touching a few months later, because I could no longer tell you how any of it worked. Both are still live. I’m a little afraid to open them.)

This is the entire reason we built Makyo the way we did.

We moved the AI to the other side of the line. It doesn’t carve code. It writes the order. You describe what you want in plain language, the model produces a Blueprint, a declarative spec, intent expressed as structured data and a deterministic engine assembles the app out of a library of pre-validated, type-safe components. The parts are inspected and certified long before your prompt ever arrives. The model literally cannot invent a new behavior; it selects from parts that already passed.

We call the place where that switch happens the Determinism Boundary. Above it, the AI is cheap, probabilistic, creative, that’s the fun part, the part that should feel like magic. Below it, everything is bit-for-bit deterministic. Same Blueprint, same app, every time. No governor required, because nothing unverified ever reaches the floor.

That isn’t a workshop with better lighting.

That’s a factory.

Three things worth taking with you:

• The demo is not the factory. If it worked on stage in thirty minutes, that’s evidence about the demo, not about month six.

• A “software factory” that re-inspects every part it produces has automated the labor and skipped the invention. The invention was always the parts.

• The only way off the inspection treadmill is to standardize the parts before the AI touches them, not to build a bigger, smarter machine for catching misfits.

Here’s the question I’d sit with if I ran an engineering team right now, watching my best people slowly turn into harness engineers:

How much of what you’re calling “the new discipline” is just the price of parts nobody ever bothered to standardize?

• YOUR TO DO: open one app you vibe-coded more than three months ago. Try to change a single thing. Time how long it takes. That number is your inspection tax and it only ever goes up. When you want to feel what building on interchangeable parts is like instead, the waitlist is open at makyo.ai. Early access is limited, and we’re letting builders in in small batches on purpose.

Build things that still fit at month six.

Arthur
Makyo Vibe Building, not vibe coding | makyo.ai
Build Something Useful

Share The Logic Layer

This month, the best coding model in the world stopped existing.

Not deprecated on a roadmap. Not “sunset in Q3, plan accordingly.” Anthropic shipped Fable on a Tuesday and by Friday a government had called it a security risk and the access was gone. Not for some users, either. Restricting it cleanly to a subset of people turned out to be impossible, so the call was to switch it off for everyone. Three days, top of the benchmark to nothing.

I almost filed it under model politics and scrolled on. And it is politics, partly. But that’s the fire alarm, not the fire. The thing worth staring at is what it exposed about the apps the rest of us keep shipping.

Because the line everyone quoted that week had nothing to do with export controls. It came from “@shadcn”, and it was about building:

treat intelligence as borrowed.

Use the best model while you’ve got it to write durable plans and specs, he said, then run them later on something cheaper, or something you actually control. Read that as a builder, not a model-watcher.

That’s not a workflow tweak but more of a gap between renting and owning and most of what we ship right now sits on the renting side.

Here’s what everyone is slightly scared of when presenting a demo:

A vibe-coded app isn’t a thing you made. It’s a transcript of a conversation with a model.

Share

The model wrote the logic, the styling, the permissions, all of it, in one pass. So the app doesn’t really exist on its own, separate from the model that produced it. It’s model-shaped (you feel this the first time you re-prompt a fix and the thing comes back subtly, unaccountably different).

That’s borrowed intelligence = the thing that built your product was rented by the token, and the artifact it left behind inherited the lease. And models change, they get deprecated and they get price hikes or like with Fable 5 they get a quiet safety patch that shifts how they behave. Or, apparently, a government turns one off on a Friday. Whatever the cause, you’re holding something that can’t carry forward on its own.

We all knew the kid who built the most elaborate sandcastle right at the waterline. Beautiful for an hour. Then the tide came in, because the tide was always coming in…Vibe coding is like building at the waterline and acting surprised by the water crushing you castle.

And the only repair tool you’ve got makes it worse.

If and when the foundation moves, you can’t patch a vibe-coded app the way you’d patch real software, because nobody, including you, holds the mental model of how it fits together. So what you do is, you re-prompt. You hand the old model’s work to a new model and ask it to fix things. Some of you might call it a “fix” but it’s not, it’s at best a re-roll of the dices!

(We went deep on this in the security piece: every re-prompt quietly reintroduces regressions in subsystems you never touched) so to put it in perspective, you’re not maintaining a product at that point, you’re renegotiating a lease with a landlord who keeps changing the locks.

Here’s another number from this same month, and it should bother you more than the Fable headline did. Someone benchmarked the frontier models on real engineering work. The ranking came out: newer was better, and better cost more, roughly 1.5x for every step up the ladder. This leaves you here: the token bill keeps climbing while the codebase keeps decaying, and the model strong enough to re-roll your fixes is the exact one you can least afford to keep running. So it’s fragile and it gets more expensive at the worst possible moment, right when you’re leaning on it hardest…

I’ll let you process this for a bit, read it again:

The token bill keeps climbing while the codebase keeps decaying, and the model strong enough to re-roll your fixes is the exact one you can least afford to keep running. So it’s fragile and it gets more expensive at the worst possible moment, right when you’re leaning on it hardest…

Now ask yourself this question: What part of this app survives its model being switched off on a Tuesday? If the honest answer is “nothing”… then “you don’t have a product, you have a really good prompt and a countdown timer.”

The real/sustainable fix I believe is not a better model, it’s boundary.

1. Borrow the intelligence, let any model express what you want built but just don’t let the model build the thing.

2. Keep the rented part (intent) apart from the part that has to be yours (execution).

This is what we have done with our new App Builder Makyo which we now accept waitlisters for: we drew that line on purpose: the AI expresses intent, and a deterministic compiler assembles the result out of pre-validated primitives that people already built correctly.

—> The intent is borrowed. The structure isn’t.

—> You can swap the model or the vendor, let the frontier ship ten more releases, and the app underneath doesn’t flinch, because no model ever held it together to begin with.

I know how that sounds and I’m not selling you the compiler here but I’m pointing at a line the whole industry is backing into without admitting it.
- Satya Nadella, the CEO of Microsoft said a version of it the same week: a frontier with no stable ecosystem around it won’t hold.
- The Databricks people were poking at the same rot from another direction, structural decay when you build on ground that keeps moving. Different rooms, same week, same wound.

If I’m honest, I almost wrote this as a victory lap. Told you so, we built it right. Then I opened my own side-projects folder and found two apps I’d vibe-coded over a weekend and never touched since, both pinned to a model version I’m not even sure still answers the same way. I don’t own those either. I’ve just been lucky enough not to have to find out yet.

The model is the most borrowable thing in your stack. Build like it! One question before your next build, and let it sit…

What in your stack is still standing if its model disappears this Friday?

YOUR TO DO: Take one app you shipped on Lovable, Bolt, or Cursor. Answer honestly what survives if the model under it changes. If the real answer is “I’d have to regenerate it”, that’s not an app you own, it’s a lease. Reply and tell me what you found. Happy to read and provide access to our Limited Waitlist!

Build fast. Just build something that outlives the prompt that made it.

Arthur
Head of Growth, Makyo Join the waitlist: makyo.ai

If this piece resonated, then you might learn something form these ones too:

→ A Full Vibe-Coded Bloodbath: the security crisis isn’t a bug, it’s what happens when the model also generates your permissions.
→ The AI Forgot Why It Built What It Built: borrowed intelligence has a memory problem, and so do the apps it leaves behind.
→ Vibe Coding: The Speed You Need, The Debt You Don’t: the build was the cheap part. The lease is what compounds.

LINK TO WAITLIST:

https://makyo.ai/

Subscribe now

Share

In 1954, the chairman of the U.S. Atomic Energy Commission stood in front of a room of science writers and made one of the most famous predictions in the history of energy.

Nuclear power, Lewis Strauss said, would make electricity “too cheap to meter.”
So cheap it wouldn’t be worth billing you for.

Seventy years later, nuclear plants are among the most expensive infrastructure projects humans build. And yet the atom split exactly as promised but everything around the reaction compounded. Safety systems on top of safety systems, complexity feeding complexity… With the big realisation that the cost wasn’t in the fuel...

It was in everything required to control it.

Here I go about Sam Altman again, but it’s very much worth noting. In July 2025, Sam Altman stood in front of the Federal Reserve and reached for a phrase.

“It does in fact look like we’re about to deliver on ‘intelligence too cheap to meter’. We’ve been able to drive down the cost of each unit of intelligence by more than a factor of 10 each year for the last five years.”

And yet… he knew something else… he knew. In another speech he called it “an old phrase from the energy industry that didn’t quite work”.

He borrowed the most famously broken promise in energy history... on purpose.
So let’s check the meter. ⚡

The price went down. The bill went up.

Both of these things are true at the same time:
Per-token prices have collapsed. Altman isn’t lying, a unit of intelligence costs roughly 10x less every year. And yet... your monthly AI bill went up. GitHub Copilot moved to usage-based billing because the flat-rate model was “no longer sustainable”. PCWorld declared this month that “the $20 AI subscription era has become untenable.” Cursor, Claude Code, Codex, all tightened in the same season ( mentioned this in the laste episode of the Vibe Cofing Chronicles)

But now, how can the price fall 10x a year while everyone’s bill rises? Simple.
We stopped paying for answers and we started paying for thinking.

READ THIS ONE MORE TIME:

“We stopped paying for answers. We started paying for thinking.”

Leave a comment

Let me elaborate on this:

• A standard model predicts the next token and gives you the output.

• A reasoning model generates a hidden monologue first with thousands of internal chain-of-thought tokens of considering, second-guessing, self-correcting before you see a single word.

and the research numbers on this are wild:

• A standard LLM query: ~0.42 Wh of energy.

• A reasoning model on a complex prompt: ~33 Wh. That’s a 70–100x multiplier per interaction.

Reasoning models consume dramatically more tokens per task while charging 10–80x more per token. The inflation multiplies twice. Agentic workflows, the “let it run for an hour” sessions every vibe coder loves burn 5 to 30x more tokens per task than a normal chat.

So in conclusion: the unit price fell yet the units exploded and the meter never stopped running, on the contrary… 🧾

The table nobody at the pricing meeting wants to see.

This chart from SemiAnalysis has been making the rounds this week, and it deserves a slow look. It models provider gross margin per subscription plan, by how heavily the user actually uses it.

1. A claude-pro user at 1% utilization? The provider keeps 95% margin. Lovely customer. Probably uses it to write emails.

2. A claude-pro user at 20% utilization? 0%. Break-even.

3. A claude-max-20x user, the $200 power plan at just 10% utilization? Already underwater. At full utilization: -900%.

4. And a chatgpt-pro-20x user running hot? -1650%.

For every dollar that user pays, the provider spends $17.

So who are the high-utilization users? They’re the vibe coders. The agent-runners. The people letting reasoning models grind through codebases for six hours a day. The exact customers these tools were marketed to... are the customers the economics can’t survive. Notion’s CEO said AI costs already ate 10 points of his 90% margins. Anthropic is reportedly losing money on its most generous plans. And the shovel sellers aren’t repricing out of greed. They’re repricing because the meter was lying.

“Nuclear power didn’t get expensive because the atom failed. It got expensive because of everything needed to control it. AI is the same: the model is cheap. The thinking is not.”

Subscribe now

The bet we made, and yes, it sounds backwards.

Here’s where I tell you the thing that made people look at us funny for a year. The whole industry is building one way: brilliant model, dumb glue. Put the smartest, most expensive reasoning model in the middle, let it think, plan, write, fix, re-fix and wrap a bit of scaffolding around it. BUT every improvement means more thinking —> more thinking means more tokens —> more tokens means the meter spins faster on every single task, forever.

We built Makyo the opposite way: A very smart script with a very dumb AI.
The AI does one small job: translate your sentence into structured intent. A few hundred tokens. A task where the cheapest, fastest models (those nobody brags about anymore are already excellent). No reasoning required. No hidden monologue. No paying the model to argue with itself. 🙂

Then a deterministic compiler which is human-written, zero tokens, zero probability and it turns that intent into a working app from pre-built primitives. Same input, same output, every time. The industry’s cost per app compounds with complexity. Ours is the price of one translation.

When tokens get cheaper, our costs fall too, we just never needed them to.

The expensive part of intelligence isn’t being smart. It’s overthinking. We removed the overthinking.

🗳️ POLL — before closing:

Seventy years ago, a man promised energy too cheap to meter, and the world built reactors so complex the promise inverted.

Today the same phrase is back, and the same inversion is happening in fast-forward: the fuel got cheap, the thinking got expensive, and the people using the tools most are the ones the economics quietly can’t afford.

The meter is still running.

We just decided to build something that barely needs one.

PS, Someone on Reddit asked whether you could build a real app interface with something as small as Gemini Flash Lite. Our honest answer: with our architecture, yes because the model only translates, it never builds. That question is the whole thesis in one sentence.

Arthur Co-founder, Makyo

Build something useful.™

Join our waitlist and be the first to optimize your building!

🗳️ POLL — place at top: If you could describe your app in one sentence and have it regenerated completely — would you trust it?

There’s a moment in every hero’s journey that the storytelling textbooks call the revelation.

It doesn’t arrive as a solution. It arrives as a reframe. The hero doesn’t find a better weapon. They realise they’ve been fighting the wrong enemy.

For three weeks, I’ve been writing about vibe coding’s costs, the token bills, the compounding debt, the system that resists change. I’ve been diagnosing the problem from every angle I know how to.

And the diagnosis kept pointing to the same root.

Not the AI. Not the tools. Not the founders building with them.

The assumption. The assumption that code is the artifact that matters.

Every tool in the vibe coding category is built on the same belief: the job is to generate code, and the AI’s quality is measured by how good that code is.

So the entire arms race is: bigger context windows, smarter models, better prompt engineering, more expensive tokens, is an arms race to generate better code faster.

But what if the code was never the point?

What if the point was always the intent, the clear description of what the app should do, who it’s for, what it needs? And what if code was just one way of expressing that intent, a particularly fragile, session-dependent, hard-to-maintain, expensive-to-navigate way?

What if there was a different expression? One that a deterministic system, not an AI, not a guesser, could turn into a working app with the same reliability that a calculator turns numbers into answers?

This is the question Makyo was built to answer.

Time for the big reveal: here’s what we built.
And why.

The architecture has three layers. They don’t look like any vibe coding tool you’ve used.

Layer 1: Intent. You describe what you want in plain language. One sentence. The AI reads it and produces a small, structured YAML file, a precise description of your app’s entities, fields, views, and actions. Not code. Intent. The AI’s job ends here.

This is where the cheapest model works fine. Fractions of a cent. Because expressing intent in structured form is something even the smallest models do surprisingly well. You’re not asking it to reason about architecture. You’re asking it to translate.

Layer 2: The compiler. A deterministic script, written by humans, not AI, reads the intent YAML and assembles a working app from pre-built primitives. Same input, same output, every time. No hallucinations. No probability. No session memory required. The compiler doesn’t guess. It follows rules.

This is the part of the stack we spent a year building before we let the AI near it. 90+ primitives. A Rust-powered grid that can calculate thousands of rows in milliseconds. 30+ action types. Themes. Forms. Repeaters. Webhooks. All pre-validated. All inspectable.

Layer 3: The no-code interface. Everything the compiler produces is visible. The data grid. The actions. The workflows. The logic. You can see it, edit it, change it without touching code, without prompting the AI, without understanding what the compiler did underneath. You can also regenerate the entire app from a changed intent sentence.
New entity. New field. New workflow. One sentence. Regenerated cleanly.

“The intent is the source of truth. The app is the output. The AI is the translator. We keep AI out of everything except the part it’s actually good at.”

Subscribe now

What this means for the problems in the previous three parts.

Token costs: when AI only writes intent, not code, the cost per app collapses. We’re running intent generation on 4o-mini or even smaller systems. Fractions of a cent per app. Competitors burning frontier model tokens on thousands of lines of generated code have a unit economics problem that compounds as they scale. We don’t.

Compounding debt: there is no codebase to accumulate debt. The app is generated from primitives that were built correctly once. The intent is small and human-readable. Changing anything means changing the intent and regenerating, not navigating sessions of AI-generated code looking for the thing you need to touch.

The system that fights back: the compiler doesn’t fight back. It follows rules. It produces the same output for the same input. If something is wrong, it fails clearly and we fix the compiler. There is no session 10 where the AI has lost track of session 1. The intent was always there.

The sneak peek.

We are not launching today.

But we promised to show you something, and we keep our promises. Here is the one-sentence prompt we tested last week:

“I want subscribtion management tool for my software business. It should measure the signups, ticket sales, app usage per month and financial metrics.”

One sentence. The intent layer produced a structured YAML in seconds. The compiler assembled:

No code written. No session memory required. No spaghetti. No compounding debt. No security defaults the founder didn’t set deliberately.

The same sentence, run again tomorrow, produces the same app.

That’s the thing we’ve been building.

We’re opening the Makyo beta to a small first group.

Not everyone. Not yet. We’re starting with agencies and operators, people building apps that real businesses will actually run on, where the system fighting back isn’t an annoyance, it’s a crisis.

If that’s you, if you’ve read all four of these pieces and felt something land, the waitlist is below.

We’re not promising magic. We’re promising a different architecture. One where the AI is a translator, the compiler is the engineer, and the intent is the thing that lasts.

Join the Makyo Beta Waitlist →

This has been The Vibe Coding Chronicles, four weeks, one arc, one question: what comes after vibe coding?

We think we know. We’ve been building it for some time now. Time to find out if we’re right.

Arthur Co-founder, Makyo Build something useful.

Subscribe now

Leave a comment

This week: What happens when the debt stops being theoretical?

There’s a particular kind of failure that doesn’t announce itself.

It doesn’t crash or throw an error, it doesn’t send you a notification, BUT somehow… it resists…
You open the codebase you built three months ago and you need to add something small. A field. A filter. A status option. And you envision it shouldn’t take more than an hour. So full of confidence and good will… you make the change.

Shouldn’t have done that…
Something else breaks, you fix that. But now the original thing stops working and before you know it, you spend a day going in circles. The app is working perfectly for its users but it is working against you. The system which seemed very friendly…strikes back.

This is the moment the vibe coding gold rush literature doesn’t prepare you for. The tools are brilliant at the beginning, at the generation, the launch, the demo. They are almost completely silent about what the system becomes six months later.

So let me name it.

Developers call it Darth V… I mean, “spaghetti code”.

Code where the connections between components have lost their reason. Where things are wired together in ways that made sense at generation time, in one specific session, for one specific purpose and now nobody, not you, not the AI, remembers why.

The academic literature calls it the flow-debt tradeoff. The arXiv paper published in December 2025, Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use describes it very well:

“The flow-debt tradeoff arises when seamless code generation occurs, leading to the accumulation of technical debt through architectural inconsistencies, security vulnerabilities, and increased maintenance overhead.”

I call it the system that strikes back. And once it starts fighting, the token cost problem becomes the least of your problems.

The Empire.

Session one: you build the core feature. It works. You’re thrilled and happy!

Session two: you fix an edge case session one didn’t handle. The AI reads the codebase, makes the fix. It doesn’t know why you built what you built in session one, only that it exists.

Session three: you add a new feature. It needs to touch something from session one. The AI makes a reasonable decision about how to connect them. It works again!

Session four: something in session two broke when you added session three. The AI fixes it but something in session one breaks.

By session ten, you are paying a frontier model to navigate a structure it built but doesn’t remember building, to fix interactions between components it has no record of designing, to add features to a system whose intent exists nowhere in the codebase.

Anthropic confirmed the mechanism in their April 23rd postmortem. Claude Code had been shipping a bug for two months where the model was dropping its own reasoning history mid-session: “Claude would continue executing, but increasingly without memory of why it had chosen to do what it was doing.” (their own words)
That bug was fixed. But the codebase problem it describes is permanent.

The AI doesn’t remember session one when you’re in session ten.
The code remembers. The intent doesn’t.

“The code remembers. The intent doesn’t. And after session ten, you’re paying frontier model prices for an AI that’s as lost in your codebase as you are.”

The Rebellion.

December 2025: CodeRabbit analysed 470 open-source GitHub pull requests comparing AI-assisted and human-written code.

AI co-authored code had 1.7x more major issues overall.
2.74x more security vulnerabilities.
75% more misconfigurations.

AI generates plausible code, statistically likely, contextually reasonable without the architectural memory that would make it coherent across sessions.
Google’s DORA metrics documented a 7.2% decrease in delivery stability correlated with increased AI adoption.

And here is the one that I find most quietly revealing: A 2025 Stack Overflow study found that 66% of developers list “AI solutions that are almost right, but not quite” as their top frustration. 45% say debugging AI-generated code takes more time than expected.

The cruelest outcome in software is “it works until it doesn’t”.
It ships until it breaks.
It looks finished until someone actually depends on it.

The Hope

In the r/vibecoding community this week, a comment went up that got almost no attention, 2 upvotes in a thread with 2,200.

“I don’t think vibe coding is dying. People are just hitting the part that didn’t get talked about enough. Getting to ‘it works’ is fast now. Getting to ‘I actually understand what’s going on’ is still hard. The bottleneck just moved.”

That’s the most honest thing I’ve read about this in months. The bottleneck moved.

It moved from writing to understanding. From generating to maintaining. From shipping to explaining to the next person why it works the way it works.
And all the token costs, all the usage limits, all the quota tightening, they are happening precisely in the phase where the bottleneck now lives.

You’re paying more, for a harder problem, with a tool that is brilliant at the part that came before.

🗳️ POLL — place before closing: What’s your current relationship with a vibe-coded app you’ve shipped?

Share The Logic Layer

Next week is the last part of this series.

I want to stop diagnosing and start showing.

Not a solution but an architecture. A way of thinking about what comes after vibe coding that starts from a different assumption: that the code was never the point.
The intent was.

What if the thing that persisted wasn’t the code? What if you could change everything about an app by changing one sentence? I honestly cannot wait to show also what we’ve been building. But its not ready yet. We’re almost there.

And next week, for the first time, I’m going to show a glimpse of what it could look like…maybe…hopefully…passionately…L

Leave a comment

Subscribe now

PS: A founder we spoke to last month spent 22 days trying to modify a feature in an app that had taken him 4 hours to build. He said: “I’m scared to touch it.” We are building Makyo specifically for the person who said that.

Arthur
Co-founder, Makyo
Build something useful.

This week: what’s actually inside that bill.

There’s a moment in every gold rush that the history books skip over.

It’s not the discovery. It’s not the stampede and it’s not even the crash itself.

It’s the moment the miner sits down with a piece of paper and adds up what the last six months actually cost. The equipment, the food, the shelter, the failed tunnels, the time, and realises the number on the left is smaller than the number on the right.

That moment is arriving for vibe coding. Slowly but steady and quietly…. In spreadsheets and Stripe invoices and late-night Reddit posts from people who built something real and are now living inside the consequences.

Last week I wrote about the visible cost(the token bills, the subscription stacks, the shovel sellers repricing their shovels). This week I want to write about the invisible cost. The cost that only becomes visible once you’ve already shipped your app.

The $20–$200 per month you spend on AI coding tools is the cost of building. That number is real and it’s rising and everyone’s annoyed about it, but the actual cost of vibe coding, the one that compounds, is the cost of having built… and they are completely different numbers!

The One Big Beautiful Bill.

A Q1 2026 meta-analysis across 101 sources studied AI-assisted development in practice: what it costs, how it breaks, what happens over time.

Their finding on technical debt: vibe-coded applications accumulate technical debt at roughly three times the rate of traditionally developed software.

Not because AI writes worse code than humans, because it doesn’t but the speed of generation removes the friction that used to force you to think before you shipped.
In short, pretty on the outside, but….

In traditional development, the friction was the feature. You wrote code, someone reviewed it, someone else reviewed it, you tested it, you argued about it, and then, only then, it shipped. That process was slow, expensive, and deeply annoying…

But at least, the team understood what they were building… Vibe coding collapses that process into: does it work? ship it.

Functionality becomes the finish line. And everything that isn’t functionality: maintainability, architectural consistency, the ability to change things six weeks from now… becomes “something we’ll handle later”.

Later is arriving. Now.

“Technical debt used to compound at the speed of developers. Now it compounds at the speed of inference.”

Here’s how non-linear debt actually feels in practice:

1. Early in a vibe-coded project, adding a feature takes an hour.

2. Three months later, the same category of feature takes five hours.

The feature stayed the same, but every change now requires regression checks across code nobody fully understands, touches components that are connected in ways nobody documented, and risks breaking dependencies nobody remembers adding.

GitClear analysed 211 million lines of code changes between 2021 and 2024. They found an 8x increase in duplicated code blocks attributable to AI tools. Refactoring the thing that keeps codebases healthy dropped from 25% of changed lines to under 10%.

The code works. It just gets harder and harder to change which means every token you spend after month three is fighting against the codebase you built in month one.

The shovel gets heavier as you dig.

OR

Subscribe now

A funny sounding stat

84% of professional developers now use AI coding tools at least weekly.
29% trust them.

The gap between those two numbers(55 percentage points) is the most expensive thing in software right now. Developers using tools they don’t believe in, building systems they can’t fully explain, shipping features they can’t guarantee, and hoping the thing they’re building holds together long enough to become someone else’s problem to maintain.

Simon Willison put it better than I can. Writing on May 6th, 2026, eight days ago:

“If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was designed around the idea that it takes a day to produce a few hundred lines of code.”

What breaks is the governance layer. The review. The comprehension. The shared understanding of why the code does what it does. AI didn’t just speed up the writing. It sped up the accumulation of things nobody fully understood.

The printing press was invented in 1440.

Within 50 years, more books existed than in the previous thousand years combined. It was extraordinary. It was also, for a generation, chaos. Errors proliferated, misinformation spread and quality collapsed before it recovered.

The tools arrived before the standards, the editing practices, the institutions that would eventually make books trustworthy. The printing press wasn’t wrong but the governance layer just hadn’t caught up… see the resemblence?

Vibe coding is the printing press moment for software.

The generation speed is extraordinary. You can compare it with a Bengal Tiger.
The governance layer (the review, the comprehension, the architectural discipline) is not. And you can compare it with a kitten.

More importantly for you: the cost of that gap isn’t in your token bill. It’s in what you’re building on top of foundations you haven’t checked.

Next week: I want to show you what happens when those foundations give way. The systems that actively fight back. The moment the tool you built starts working against you.

PS: The thing that first made us decide to build Makyo differently wasn’t a security incident or a token bill. It was watching a founder spend three weeks trying to add one field to a form in an app that had taken one afternoon to build. The field took longer to add than the app took to create. That ratio only goes one direction.

Arthur Co-founder,
Makyo
Build something useful.

It’s 1848 and someone just found gold in California.

Within months, 300,000 people dropped everything and went west. Farmers, teachers. ministers, people who had never held a pickaxe. The promise was simple: the gold is there, the tools are cheap, and anyone can find it.

And here’s the thing, that promise was true.

There was gold. And lots of it. The early miners did find it, fast, with almost no experience and so the first wave got rich. And while the newspapers covered the wins, nobody wrote about the people who arrived six months later, dug for a year, spent everything they had on equipment and food and shelter, and left with less than they came with.

The gold rush wasn’t a lie. It was just... not really what you think it was… at least not for everyone.

Now think about today…
Does a neuropathway starts to form after reading about the goldrush? Do you start to realize something? Exactly.

Leave a comment

Today, we are living through the software version of 1848.

“There’s a new kind of coding I call vibe coding” Andrej Karpathy posted on February 2nd, 2025. “Where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

It hit 4.5 million views, the New York Times covered it, Collins Dictionary named it Word of the Year.

And by early 2026, Gartner estimated the vibe coding segment at $4.7 billion, growing 85% year over year.

And again… the promise is real.

You can describe an app in one sentence and have something running in twenty minutes.

A warehouse owner can revolutionize his shipping software.
A designer with zero technical experience can build her first app.
Linus Torvalds (the creator of Linux) used Google Antigravity to vibe-code a visualizer tool and wrote in the README: “The Python visualizer tool has been basically written by vibe-coding.”

If Linus is doing it, then the tools must be really good…right?

But here is what the gold rush coverage always leaves out.

Here’s something that will either surprise you or feel very obvious: The people who got reliably rich in the California gold rush were not the miners.

They were the ones selling shovels.

Levi Strauss made denim trousers for miners, he became a dynasty.
Samuel Brannan bought every pickaxe and shovel he could find before announcing the gold discovery, he became California’s first millionaire.

The miners got the dream. The shovel sellers got the economics.

In 2026, the shovel sellers are Cursor, Claude Code, GitHub Copilot, Lovable, Bolt, Windsurf, Codex. And this month, every single one of them changed their pricing.

GitHub Copilot announced it was moving to usage-based billing on June 1st, 2026. Their official explanation deserves to be read slowly:

“Today, a quick chat question and a multi-hour autonomous coding session can cost the user the same amount. GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable.”

No…longer…sustainable…

Translation: we priced the shovels wrong. Now we’re fixing it.

Cursor shifted to metered billing.
Claude Code introduced stricter session quotas.
Copilot, Windsurf, Antigravity, Codex, all tightened simultaneously.

The r/vibecoding community with 583,000 people, posted “RIP Vibe Coding 2024–2026” and it hit 2,200 upvotes in three days.

The tools didn’t stop working… but the bill arrived…

"The gold rush wasn't a lie. It was just incomplete"

Here’s the number that stopped me this week.

The average serious vibe coder now spends $70 to $250 per month on AI tools. Most don’t realise it because each platform bills separately. Cursor Pro, Claude Pro, ChatGPT Plus, Copilot, Midjourney for assets, Hosting,… That’s $840 to $3,000 per year before you’ve written a single line of business logic yourself.

Just the subscription cost…

One AI agency reported burning 170 million tokens in two days on Cursor while another burned 28 million tokens generating 149 lines of useful code. A third switched to usage-based pricing and watched his first two prompts cost $0.61 and $0.68.

“Is this normal?” he asked on Reddit.

The answer, it turns out, is yes.

A debugging session with extended thinking can eat half your daily quota before lunch. A single afternoon of iterating on a complex feature can cost more than a monthly subscription. The AI doesn’t just fix what you asked, but it rewrites three adjacent things while it’s there, charges you for all of them, and sometimes introduces the next bug while fixing the first.

One developer asked Cursor to fix an authentication bug. It generated 2,847 lines. The actual fix was 40 lines. Ratio of useful code to generated code: 1.4%.

He paid for the other 98.6%.

I’m not writing this to make you feel bad about building with AI.

I’m writing it because I think the tools are extraordinary and I think the conversation about their cost is almost always incomplete. We talk about the subscription price but somehow we don’t talk about what builds up underneath it.

The shovel price is rising and that part is visible and now everyone’s annoyed about it.

But what happens after you’ve bought the shovel, after the feature is built, the app is live, the clients are using it? That’s the part the gold rush coverage leaves out.

And that’s what I want to write about next week.

The token bill is the cost of building. The thing that comes after is the cost of having built.

PS: We’ve been building Makyo for a couple of years now and I hope it will break the internet. I have a good feeling it might… Soon we’ll be doing the beta testing, and then we’ll know for sure… if we’ve built the real shovel.

Arthur Co-founder, Makyo

Build something useful. ™️

They open Claude. Describe the change. The AI reads the codebase, ten thousand lines it wrote itself, over three months, across forty sessions.

It starts working.

An hour later, two things that used to work don’t anymore.

They ask Claude to fix them. It does, but suddenly something else breaks…

This is the moment.

Not the launch, neither the security incident, nor the token bill….

This is the moment vibe coding actually ends, when the cost of adding one feature becomes higher than the value of the feature itself.

And that on a Tuesday night…

The house always gets harder to renovate.

There’s a concept in urban planning called induced demand or “the idea that building more roads doesn’t reduce traffic, it generates it”. More capacity creates more usage until the system is just as congested as before, only bigger and more expensive to maintain.

Frederick Brooks wrote about the software version of this in 1975. The Mythical Man-Month. His central observation: adding people to a late software project makes it later. Not because the people are bad — because complexity grows faster than capacity. Every new component added to a system creates new interactions with every existing component. The work doesn’t grow linearly. It grows exponentially.

Brooks was writing about teams of engineers with full context of the system they were building.

He wasn’t imagining a system where the builder has no persistent memory between sessions.

What Anthropic quietly admitted last week.

On April 23rd, Anthropic published a postmortem about Claude Code quality degrading over the past two months. (link)

There are 3 separate issues, all shipping in the same window and all hitting the same users.

But the one that made me take an extra breath was the second one.

On March 26th, they shipped a caching optimisation. The idea was simple: if a session had been idle for over an hour, clear the old reasoning history to reduce costs when the user resumed.

But there was a bug….

Instead of clearing the reasoning history once, it cleared it on every single turn for the rest of the session. After the session crossed the idle threshold, each new message told the API to keep only the most recent block of reasoning and throw everything before it away.

So Claude would continue working, executing tool calls, writing code + making decisions without any memory of why it had made the decisions that came before…

READ THIS ONE MORE TIME…

Claude would continue working, executing tool calls, writing code + making decisions WITHOUT ANY MEMORY of why it had made the decisions that came before…

“Claude would continue executing, but increasingly without memory of why it had chosen to do what it was doing.” ~ Anthropic ~

That’s Anthropic’s own description.

The obvious result:
- forgetfulness,
- repetition
- odd tool choices that made no sense in context.

They fixed it April 10th.

But here’s the thing: that bug is a perfect description of what vibe-coded codebases feel like to work in, even when everything is functioning correctly.

The spaghetti problem nobody names.

When you vibe-code an app across multiple sessions, you’re not building a system. You’re actually accumulating outputs.

• Session one: the core feature.

• Session two: a fix for the edge case session one didn’t handle.

• Session three: a new feature that requires touching the thing from session one.

• Session four: something broke in session two when you added session three.

Each session, the AI reads what’s there but it doesn’t know why it’s there, it doesn’t know what decision led to what structure, it has no memory of intent, only the artifact of previous outputs.

This is what developers mean by spaghetti code 🍝

= Not messy code but code where the connections between things have lost their reason.

Where changing one part pulls unexpectedly on three others because nobody, not the original author, neither the AI, remembers why those parts were connected.

And now layer the token cost problem on top of this.

The Reddit thread this week: 2,200 upvotes, 583,000 member community, was full of people hitting usage limits mid-feature.

Cursor, Claude Code, Codex, Copilot, all tightening simultaneously. The top comment was a masterclass in model routing, use R1 for planning, Gemini Flash for repo scanning, Kiki for UI.

Sophisticated? Yes.

But notice what that advice assumes: that you understand your codebase well enough to know which part needs which model.

Most vibe coders don’t. Because the codebase was generated, not understood.

So you’re paying more tokens to ask a model to navigate a structure it built but doesn’t remember building, to add a feature that will pull on connections neither of you can fully trace.

The cost isn’t really the tokens.

The cost is the compounding confusion.

The third thing Anthropic shipped.

While they were dealing with the memory bug, they also added a system prompt instruction to reduce verbosity in preparation for Opus 4.7.

“Keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail.”

A sentence. Literally one instruction to be shorter.

It caused a 3% drop in coding quality across both Opus 4.6 and 4.7. (Reverted four days later)

I find this extremely fascinating and a little unsettling to be honest…

The model’s intelligence isn’t just in its weights, it’s in how much room it’s given to think. Constrain the output and you constrain the reasoning. Make it shorter and you make it dumber, not because it knows less, but because it has less space to work through what it knows.

Which means every time you’ve hit a token limit mid-session, every time the context window fills up and the AI starts summarising instead of remembering, every time you start a new session because the old one got too expensive, you’ve been doing the same thing Anthropic accidentally did with that system prompt.

Constraining the thinking to save the cost.

And getting slightly worse output every time.

Subscribe now

What this actually means if you’re building something real.

I’m not saying stop building with AI. I’m saying the problem that’s making your codebase feel impossible to extend isn’t you, and it isn’t really the AI either.

It’s that the tools were optimised for the moment of creation (fast, cheap, impressive) and not for the moment six weeks later when you need to change something.

The memory problem Anthropic shipped by accident in March is the memory problem every vibe-coded codebase has by design:

• No persistent intent

• No record of why.

• Just the output of decisions nobody fully remembers making

Brooks knew in 1975 that complexity compounds, he just didn’t know we’d one day build systems where the architect forgets the blueprint between sessions.

I wonder sometimes what it would look like to build apps where the intent was the thing that persisted, not the code, not the session, not the reasoning history that gets dropped after an hour of idle time.

Where regenerating from intent was cheaper than debugging what the AI forgot it built.

Maybe that’s the product. Maybe that’s just what’s obviously missing.

PS: We made a decision early at Makyo that intent should be the source of truth, not the generated output. We didn’t fully understand how right that felt until we read Anthropic’s postmortem this week.

Arthur Co-founder, Makyo Build something useful.

Get on the waitlist: here

On April 21st, a security researcher published his findings about Lovable, the vibe coding platform valued at $6.6 billion with eight million users. He’d found a critical vulnerability on March 3rd. With nothing more than a free account and five API calls, he could access any other user’s project on the platform.

Their source code. Their database credentials.
From real apps, businesses and with real users that have laid their trust in them.

He filed a report through the bug bounty programme. He waited but Lovable patched it for new projects, but never fixed it for existing ones. The follow-up report was marked as a duplicate, then closed.

He published 48 days later.

Lovable’s public response came the same day, and this is the part I haven’t been able to stop thinking about. They said they “did not suffer a data breach”. They called the exposed data intentional behaviour. Then they blamed the documentation, then the bug bounty partner, then, within hours of all of that, they issued a partial apology.

Cybernews called it: “Lovable goes on an ego trip denying the vulnerability, then blames others for said vulnerability.”

But honestly? I’m not here to talk about Lovable’s PR crisis. What I want to talk about is the 48 days. Because the 48 days is not a Lovable problem. It’s the entire Vibe Coding category’s problem. And it points to something structural that nobody in this space is being honest about yet.

The oldest failure in the world just got a new name.

In 1911, Frederick Winslow Taylor published The Principles of Scientific Management, the book that convinced a generation of factory owners that if you optimised every single motion, every hand position on the assembly line, you’d get a perfect system. Output was the metric. Speed was the proof. What Taylor didn’t build in and what nobody thought to ask him about, was the failure mode. What happens when an optimised system produces something wrong, fast?

The answer, in factory after factory across the early 20th century, was consistent: you don’t find out until it’s already shipped.

Vibe coding is Taylor’s system applied to software. The AI optimises for generation speed. The metric is a working output. The proof is a rendered UI, a form that submits, a database that accepts and writes. And what nobody built into that process (what the model was never asked to consider) was the threat model.

What happens when the optimised system ships a security flaw?

The answer, in app after app in 2026, is exactly the same as Taylor’s factories.

You don’t find out until someone else does.

On January 28th, a founder launched Moltbook, a social network for AI agents. He said publicly that he hadn’t written a single line of code. The entire platform was vibe-coded.

It launched on a Tuesday.
By Friday, it was breached.

Security firm Wiz discovered the production database had been left with public read and write access, a misconfigured Supabase deployment, row-level security never enabled. The AI had scaffolded it with permissive defaults during development, and the founder had deployed it exactly as the AI left it. He didn’t know to check. The model didn’t tell him.

• 1.5 million API authentication tokens,

• 35,000 email addresses,

• Private messages

Gone… in three days.

What’s actually happening underneath all of this.

Here’s the thing I’ve been trying to find the right words for, because I think it’s the real story and it’s easy to miss if you stay focused on the incidents.

When AI writes code, it writes the security posture too.

Not deliberately or maliciously but rather statistically. The model predicts the most likely output given your prompt.

You asked for an inventory app —> you got an inventory app. You didn’t ask about row-level security, so the model didn’t mention it.

The default was permissive so the app shipped permissive.

Ever heard of the Invisible Architecture Problem? When you vibe-code an app, you describe what you want and somewhere in that build(in the database settings, the permissions, the packages it decided to install), it also made a hundred decisions you never saw and you weren't asked and it didn't flag them. They… just…. happened… quietly, underneath the thing that looked finished.

Imagine asking someone to build you a house in a week. They do it. It looks beautiful the floors, the windows, the light coming through exactly the way you imagined. You move in. Your family moves in and six months later, during the first heavy rain, you find out the foundation was poured without checking the soil underneath and suddenly the next day, half of your house is sunken in mud. The builder didn't skip it to cut corners. He just didn't know the soil needed checking. Nobody told him. And you didn't know to ask. The house looked finished, and houses that look finished feel safe, until they dont.

The data is hard to look away from. Georgia Tech’s Vibe Security Radar has been tracking CVEs directly attributable to AI-generated code since May 2025.

In January 2026, they found 6.
In February, 15.
In March, 35.

And they estimate the real number is five to ten times higher than what they detect. Escape.tech scanned 5,600 live vibe-coded applications and found 2,000 critical vulnerabilities, 400 exposed secrets, and 175 instances of PII, medical records, payment data, all sitting open in production.

A Q1 2026 assessment of over 200 vibe-coded apps found that 91.5% contained at least one vulnerability traceable to AI hallucination.

91.5%.

let that sit for a minute.

And here’s what makes this even more uncomfortable: the people who built those apps aren’t reckless. They’re operators and agency owners and consultants building real things for real clients who trust them. They didn’t set out to expose anyone’s data. They built on top of a system that was never designed to be secure by default, and that system never told them that.

Bolt.new ships with row-level security off by default.

70% of Lovable apps had it disabled entirely.

86% of AI-generated code samples tested by Georgetown CSET failed to defend against cross-site scripting, one of the most basic, most documented vulnerability classes in existence, the kind that’s been in the OWASP Top 10 for twenty years.

The AI didn’t document its reasoning and there is no author to ask why.

Conveniet, right?

There is no author.

What this actually means for how we build.

I want to be honest about something, because I think it’s easy to read an article like this and arrive at the wrong conclusion.

The conclusion is not: AI tools are dangerous and we should slow down.

The conclusion is: security is not a feature. It’s a consequence of architecture. And if the architecture generates everything, including the permissions, the defaults, the database configuration, the packages it decided to install without telling you, then the security posture is also generated.

Probabilistically and without accountability.

But there’s a different way to sequence this. What if the primitives themselves were pre-validated? What if permissions weren’t generated, but instead they were configured, deliberately, inside a no-code interface a non-technical person can actually see and understand? What if AI’s job was only to express intent, and a deterministic compiler assembled the result from building blocks that humans had already built correctly?

Then security isn’t something you audit after the fact. It was never in the model’s hands to get wrong.

This is exactly the architectural bet we made at Makyo, not because of this data, which is newer than our decision, but because the logic pointed here before the numbers confirmed it. When the compiler is deterministic and the primitives are pre-validated, the security surface is defined by people, not predicted by a model.

I’m aware that sounds like a pitch. I’m not trying to pitch you. I’m trying to name the architectural choice that the whole industry will eventually have to make, and explain why we made it early.

The question I keep coming back to is simpler than all of this.

We built an entire category of tools optimised for the moment of creation and we got extraordinarily good at that moment. Karpathy named it. Collins made it word of the year. Gartner says 60% of all new code will be AI-generated by the end of 2026.

But we didn’t ask what happens three days after the launch.

Or 48 days.

Or when someone finds the open database, or the hardcoded key, or the package the model hallucinated that someone had already registered as malicious payload, a real attack vector now called slopsquatting, because they knew the model would suggest it.

The vibe-coded table is assembled and it looks right.

Whether the joints hold, that’s a different question entirely.

PS, We’ve been building Makyo’s primitives with the assumption that the person deploying the result might not know what row-level security is. That assumption changes a lot about how you design a platform. The Lovable incident didn’t surprise us. It clarified us.

Arthur Co-founder, Makyo

Build something that lasts. Build something useful.

Click here to sign up for our waitlist today

It was a Tuesday afternoon, Polo was sharing his screen. He’d been working on the compiler for four days, barely sleeping (it’s the way he gets when something clicks).

He typed a sentence.

“I want to build an inventory app for a spa’s retail products.”

Hit enter.

The AI responded in seconds. Not with code but with: 40 lines of pure and beautiful structure:

• A small, precise description of intent.

• Fields, relationships, basic workflows.

• What the app is, not what it does.

Then the compiler ran.

No AI. No model. No probability. A hard-coded machine reading the structure and assembling a working app from 90+ primitives we’d spent months building.

Same input.
Same output.
Every…
time.

I watched it happen and felt something I hadn’t felt in months of building.

Certainty.

2. The problem nobody wants to say out loud is:

Every AI app builder in the market right now (Lovable, Bolt, v0, Cursor,…) has AI in the code path.

And after using it for some time, I understood that that’s not a neutral architectural choice, but it’s more of a bet.

The bet in vibe coding is: if the model is smart enough, and the prompts are tight enough, and the user is patient enough, the output will be good enough.

And for 90% of the app? The bet pays off. The UI renders beautifully, the demo looks finished and you feel productive every single minute.

Then you try to change something.

Or deploy it.

Or hand it to a real user.

And the bet comes due.

“AI-generated code is a probability distribution. It looks right so it might be right and it’s expected to work, maybe.”

“AI in the code path” means: every time you generate, you’re getting the most statistically likely code for your prompt. That doesn’t mean you’ll get the architecturally correct code for your system.

Those are different things. And the gap between them is where projects go to die.

3. The alternative

Here’s the thing nobody in this space is saying clearly enough:

The problem isn’t that AI generates code.
The problem is that AI generates code before the architecture exists.

There’s a different way to sequence this.

What if the AI only ever wrote intent? A small, structured description of what the app should be, not how to build it. And then a deterministic compiler, built by humans, turned that intent into a working app using primitives that were already tested, already typed, already correct?

AI writes the what. The compiler builds the how. The runtime executes the result.

The AI never touches the code path. The AI never has to be right about architecture. The AI just has to understand what you want.

“The moat in AI app builders isn’t the model. It’s the runtime. And runtimes don’t hallucinate.”

4. Why this changes the economics entirely

When AI only writes intent (not code) the token cost per app collapses.

We’re running intent generation on 4o-mini. Fractions of a cent per app. Competitors burning frontier-model tokens on thousands of lines of generated code have a unit economics problem they can’t solve without raising prices or cutting quality.

We don’t have that problem.

Which means we can offer unlimited regeneration. We can let users iterate freely. We can rebuild the app entirely from a one-sentence change and it costs us almost nothing.

Because the expensive thing isn’t the AI. It’s the runtime. And we front-loaded that cost into the primitives.

That’s the bet we made.

5. The thing that scares me about saying this

We’re in closed alpha.

And I’ve watched a lot of founders in this space get the validation dopamine hit, someone big says something that sounds like your thesis, and you want to stand up and shout us, it’s us.

I’m trying not to do that.

What I’ll say instead is this:

The architecture is real, the bet is placed, the compiler doesn’t hallucinate because it can’t, it’s not a model, it’s a machine.

Either the JSON is valid or it isn’t.
Either the primitive exists or it doesn’t.
Either the app runs or it fails cleanly and we fix the compiler.

That’s a different failure mode than “the AI wrote something confident and wrong”…

Different failure modes produce different companies.

“Vibe coding treats AI as the engineer. We treat AI as the translator. The compiler is the engineer. And the compiler is not allowed to guess.”

6. What comes next

We’re opening the beta in the coming weeks. Small. Deliberate. Agencies and operators first, people building apps that real businesses will actually run on.

If that’s you, you already know why this matters.

1. If you’ve ever deployed a vibe-coded app and spent three weeks explaining to a developer why it broke?

2. If you’ve ever hit the 99% wall on a project that looked finished at 90%?

3. If you’ve ever wondered whether the AI-written code your product runs on is a foundation or a facade?

You’re the person we built this for.

Tell me: what’s the thing AI got wrong that cost you the most time?

Leave a comment

Subscribe now

Join the Makyo Beta Waitlist → First access goes to agencies and operators who are done rebuilding what AI broke.

P.S. The compiler is four days old and already more reliable than three months of prompting. Polo would say that’s just what compilers are. He’s probably right.

Arthur Co-founder, Makyo, Build something useful.

Oh… by the way… here is a little sneak peak:

I was in Bali. The fan was on. I had three browser tabs open, a half-finished proposal, a Slack thread going nowhere, and the n8n automation I’d been debugging for two hours.

Then my phone lit up with a screenshot from my co-founder.

Andrej Karpathy, the man who named vibe coding, the ex-Tesla AI director, the person whose opinions move markets, had just posted something.

2.3 million views

I read it once

then again, then again and again….

“When I built menugen ~1 year ago, I observed that the hardest part by far was not the code itself, it was the plethora of services you have to assemble like IKEA furniture to make it real…”

I put my phone down.

I’d felt this. You’ve felt this. Anyone who has ever tried to ship something with AI has felt this, that specific particular exhaustion of the moment you realise the code is the easy part.

It’s everything else.
The DevOps, the auth, the payments, the domain, the database, the API keys that expire, the docs that lie, the moment you try to go from working on my laptop to actually deployed and real and the whole thing becomes a different job entirely.

Karpathy called it “assembling IKEA furniture”. That’s the most accurate metaphor I’ve read. Flat-pack instructions for a table that’s also somehow on fire.

He then said something more interesting.

He said: I look forward to a day when you could simply tell your agent: “build menugen”, referencing a blog post, nothing more, and the agent would just... do it.

“There should be no need to visit web pages, click buttons, or anything like that for the human.”

He’s describing a world that doesn’t exist yet.

“It’s now just barely technically possible”, he wrote, “and expected to work maybe”.

The phrase “expected to work maybe”, is the most honest four words written about AI development in 2026!

Because here’s what Karpathy is actually pointing at and I want to stay with this for a moment before I say anything about what we’re building.

He’s not just talking about agents being smarter. He’s talking about a fundamental redesign. For an agent to do what he describes, every service it touches has to become readable/interpretable to the agent.

Every API has to have agent-native ergonomics.
Every app has to be able to tell the agent what it can do, not have the agent guess by clicking around like someone’s dad trying to use an iPhone for the first time.

The web as it currently exists is not built for this.

Apps built with Cursor today? Invisible to agents.
They are though beautiful, functional but invisible. The agent lands on them the way a tourist lands in a city with no street signs, it can figure it out, eventually, with enough retries, but it was never designed for this.

That’s the wall Karpathy is describing.
Not a capability wall but an architecture wall that has a dead end.

But here’s why I get uncomfortable.

Because what Karpathy is describing, an app that an agent can navigate, understand, and operate without human intervention, is something we’ve been quietly building towards at Makyo.

I say “quietly” because we’re in closed alpha,
I say “building toward” because we’re not done,
I say “uncomfortable” because the temptation when someone like Karpathy validates your thesis is to stand up and shout us, it’s us, we’re building this…

And I don’t want to do that.

Not because it’s not true (I hope it is), but because the honest version is more interesting…

With Makyo our goal is to build apps differently. Not with generated code that an AI wrote and only an AI understands but with a deterministic blueprint, a structured manifest that a hard-coded machine uses to assemble the app.

The AI translates intent, the machine builds!

The result is an app that is, by architecture, agent-readable. It knows what it can do, and it can tell it to an agent without guesses, no DOM scraping, no token waste, and no retries…

We call this WebMCP compatibility, and it’s not a feature we added, it’s a consequence of how Makyo works.

Which means... when Karpathy describes the future he wants, the architecture he says has to exist for agents to work without humans clicking around.

That’s what we’re building, that’s what we are aiming towards!

And personally, I’m very excited, but also very anxious….

Now, here’s why I’m anxious:

Karpathy said it’s “just barely technically possible”. That phrase should be tattooed on every founder building in this space right now.
Just barely
Maybe
Expected to work

He’s not pessimistic, he’s honest! And in a world full of people claiming they’ve solved the agentic web, full of decks with confident arrows pointing up and to the right, that phrase is almost radical.

We’re not going to stand here and tell you we’ve solved it.

We’re going to tell you we’ve made a bet on how it gets solved. And the bet is: Deterministic architecture
Intent translation
—> Apps that know what they are and can say so

The vibe-coded IKEA table is already on fire,

And we’re trying to build the factory…

Makyo is in closed alpha, deliberately small, deliberately selective. If you’re an agency building client apps and you’ve ever stared at a deployed app wondering why the agent can’t find the submit button... we should talk.

Reply to this email. Or find us at makyo.ai.

P.S. Karpathy’s post got 2.3 million views. Patrick Collison quoted him. The comment section was full of builders nodding slowly. If you’re in that comment section, you already know what this essay is about. We see you!

Arthur
Co-founder of Makyo
Build Something Useful.

I was tired of the calculator demos.

So I ran an experiment. I posted on r/vibecoding and asked one specific question: What is the most complex thing you’ve actually built?

Not “what are you proud of”, not “show me your landing page”, I wanted something complex, actually built and more importantly also shipped!

Three hundred comments and 218K views later, I had my answer.

• Warehouse management systems.

• Law firm client onboarding portals.

• Real estate CRMs with automated document generation.

• Multi-tenant SaaS platforms.

• Internal ops tools replacing $80K/year software subscriptions.

• Healthcare intake workflows.

My first conclusion: The era of toy apps is over.

Non-technical operators, founders, agency owners, ops leads, solo consultants are building enterprise-grade software. With AI and without engineers and they are shipping it into production environments where real businesses run on it.

Honestly, that’s incredible…

But hiding in those 300 comments was something only a few people dares to put in their LinkedIn handles and posts… Most talk about about how AI changed their life, but many have

A dirty little secret.

Subscribe now

2. The 99% Trap

One comment stopped me cold.

“It feels like it’s the last 1% that takes 99% of the time, or I just always assume I’m in the last 10% when it’s really the first 10%.”

And every builder in that thread knew exactly what this person meant.

Here is why it happens.

Tools like Cursor and Lovable are extra(ordinary) at the first 90%, and all goes well when you design it, the UI renders beautifully, the basic CRUD operations work and the demo really looks like a finished product.

The AI writes code fast enough that you feel productive every single minute of the session.

Then you try to deploy it…

You try to connect it to your real data schema,
you try to add role-based permissions,
you try to route sensitive data through the correct security layer…
you try to make it actually handle edge cases that real users will hit on the first day…

And suddently….
a big beautiful wall appears…

you get bug after bug after bug after bug and suddently you don’t know how to go vibe code yourself out of that mess…

Because AI generates confident, clean-looking output for problems it has only half understood. It creates a false sense of progress so convincing that you don’t realize you’re at 10% until you’re deep enough into the project that stopping feels worse than continuing.

That last 10% isn’t a polish phase but actually the entire structural foundation. And AI, as currently built, doesn’t have a solid grip on it.

The problem isn’t that AI is bad at code. The problem is that AI is spectacular at making incomplete code look complete.

3. The Shadow Economy

Here’s another comment that told me everything I needed to know about where vibe coding actually stands today.

Context: a fellow builder who shipped a large-scale warehouse management system, which is a very impressive piece of work, and he disclosed something important in his comment:

“I cheated and hired a developer to review my code and teach me best practices.”

He called it cheating.

I personally think it isn’t cheating, it’s something completely different.
It’s the hidden tax every serious vibe coder is quietly paying.

When real business operations are on the line builders stop trusting the vibe-code.

They go find a senior developer. They pay $100, $150, $200 an hour for someone to look at the architecture and tell them whether the AI built something real or something that looks real until it breaks in production.

This is sort of a Shadow Economy of vibe coding. It doesn’t show up in the marketing copy for any of these AI tools neither does it appear in the success stories.
But it’s running underneath the entire ecosystem… a quiet, expensive acknowledgment that AI-generated code is often a structural liability the builder can’t evaluate themselves.

The AI gets you to vibe code 90%. A human engineer is being paid to determine whether that 90% is a foundation or a facade.

4. Context Blindness

The big issue: one comment in the thread diagnosed the problem more precisely than almost anything I’ve read in a technical blog post.

A builder describing their frustration with Claude in a complex pipeline:

“He just doesn’t get it... He doesn’t think or know about these little gotchas in the pipeline. I let him go on a sprint and he added a package that toggled a health permission we simply needed to block.”

Read that twice.

The AI didn’t fail to write code. It wrote code confidently, at speed, across a sprint, and introduced a security regression in the process and it did so because of fundamental context blindness.

This is the core architectural problem with every AI coding tool in use today.

LLMs predict the next token. That is, precisely and only, what they do.

They do not hold a mental model of your deployment environment.
They do not understand your data schema constraints.
They do not know which permissions are invariants versus configurations.
They do not remember the decision you made three sessions ago about why that package was excluded.

There is a critical difference between generation and orchestration.
Generation is producing code. Every AI tool does this well.
Orchestration is understanding the system the code lives inside, its security posture, its data contracts, its dependency constraints, its failure modes and generating code that respects that system at every step.

Current AI tools generate. They do not orchestrate.

That gap is where the 99% tax lives. That gap is what the senior developer is being hired to bridge.

5. The Cure Is Architecture-First

Now lets talk about a cure if I can call it that or how you can stop paying a senior developer $150 an hour to check your AI’s homework.

The problem isn’t that the AI is writing code, it’s good at writing.

The problem is that it’s writing code before the architecture is defined and then you’re left to trying to reverse-engineer structural integrity from generated output.

That process doesn’t work at scale,
it doesn’t work in production and it doesn’t get cheaper the further into the project you are.

What serious builders actually need is a different sequencing.

Vibe Coding is: prompt → generate → hope the structure holds.
Vibe Building is: define the logic layer → constrain the generation → ship something that can be maintained.

The logic layer isn’t documentation or a comment in the code. It’s a machine-readable, enforced definition of what the application is allowed to do, its data schemas, its permission model, its component contracts, all defined before the AI writes a single line of implementation.

When you build this way, the AI doesn’t drift and it can’t hallucinate a bad architecture because the architecture already exists as a constraint it operates within.

And this is exactly what we’re building at Makyo.

A platform that composes applications from deterministic JSON primitives, pre-validated, type-safe building blocks that the AI orchestrates rather than invents.
The AI still moves fast. But it moves fast inside a structure that enforces correctness.

There is no context blindness,
no permission regressions,
no spaghetti that looks like architecture until it doesn’t.

The Logic Layer is not a safety net you install after the code is written.

The Logic Layer is the foundation you build on before the code exists.

6. Build Fast. Architect to Last.

Three hundred comments on a Reddit thread confirmed what the shadow economy already knew: the builders are serious, the projects are real, and the tools have a structural gap that human developers are being paid to quietly fill.

That’s not a sustainable model for anyone building on it.

Stop paying the 99% tax.

If you’re building anything that actual users, or actual agents will depend on, the architecture has to come first.

Speed without structure is just expensive rework at a later stage.

Join the Makyo Alpha waitlist. We’re opening access to the first cohort of builders who are done paying for the privilege of fixing AI’s architectural mistakes.

Build fast. Architect to last.

The Logic Layer is published by Arthur, Co-founder and Head of GTM at Makyo.ai. We write about the shift from Vibe Coding to structured, deterministic Vibe Building and the infrastructure serious builders actually need.

Leave a comment

I expected hobbyist experiments. Half-finished side projects. Novelty.

What I found was a functioning economy.

• A privacy-first AI meeting transcription tool built for local deployment.

• A multi-agent coding platform with sandboxed orchestration.

• An AI diagramming tool for cloud infrastructure.

• A pixel art editor with a built-in tilemap engine.

• An accessibility hub for switch-access users.

• A SaaS product for audio A/B testing in professional mastering workflows.

These are not demos. These are products. Real products, shipped by real people who eighteen months ago would have needed a development agency, a $50K budget, and months of back-and-forth to produce any one of them.

This is the movement we’ve been building toward on The Logic Layer.

But there’s a layer underneath it that most people aren’t talking about yet.

And it changes everything.

What We’ve Been Building Toward

In our first article, we drew the line between Vibe Coding and Vibe Building.

Vibe Coding is chaos with output, prompt in, code out, ship it, iterate.

Productive. Exciting. And structurally fragile. The apps that come out of pure vibe coding are often unmaintainable at the seams, brittle where prompts didn’t quite connect and stochastic in ways that only reveal themselves three months into production.

Vibe Building is the evolution.

Vibe Building:

• AI-assisted creation with a logic layer underneath,

• deterministic composition,

• structured outputs,

• apps that can be extended and maintained after the AI has left the room.

Not just generated, but architected.

That distinction matters more than most people realize.

The gap between Vibe Coding and Vibe Building is the gap between a prototype and a product. Between something impressive and something durable.

If last two articles were the diagnosis, then this is the prognosis.

What the Reddit Thread Actually Was

Let me reframe that thread, because I think most people reading it saw the wrong thing.

Sociologically, it wasn’t a showcase… It was more of a ritual.

A public proof-of-work wall, a decentralized demo day and a peer-to-peer validation ceremony for a new class of person who didn’t exist three years ago:

The AI-native solo operator.

No VC.
No pitch deck.
No team.
No roadmap slide.
Just: here’s what I built.

And look at what they built: Assistive technology, privacy tools, developer ops infrastructure, creative editors, niche SaaS, multi-agent platforms,…

These aren’t toy apps, they’re the opening salvo of what I’m calling:

The Cambrian Explosion of Software = a moment where the supply of software products is growing faster than at any point in history, driven not by engineering teams but by individuals with AI copilots and enough clarity of purpose to ship.

The bottleneck was never intelligence. It was never creativity. It was access.

Vibe coding broke that barrier and in doing so, it created the conditions for its own next chapter.

Share The Logic Layer

The Explosion Creates Its Own Problem

Here’s the thing about explosions: they create debris

When the barrier to building collapses, everything gets built.

The precise and the generic.
The original and the derivative.
The perfectly positioned and the hopelessly vague.

We are entering a ‘Clone War’s phase where every successful micro-product spawns ten imitations within weeks, niches saturate, prices compress, and the advantage of shipping first shrinks from months to days.

Share

In this environment, the question stops being can you build it?

Because EVERYONE can build it…

The question becomes: do you know what to build? For whom? Positioned how? Distributed where?

Look at that Reddit thread again through this lens:
Incredible execution, beautiful products, genuine achievement by people who would have been frozen out of software creation two years ago.

And almost none of them were discussing:

• Why this product for this specific person at this specific moment

• What makes it defensible against the clone that will appear next month

• How to convert a proud build into a revenue engine

• What the distribution strategy is beyond “I posted it on Reddit”

• What the second product in their portfolio should be

The supply of products is exploding!
The supply of strategic clarity is not.

That asymmetry is the business opportunity of this moment and the reason the next great builder platform isn’t just about generating code faster.

The Role of the Builder Is Transforming

Here’s the uncomfortable truth I’ve been circling:

The builders in that thread are extraordinary! But the role they’re playing is changing underneath them, whether they notice it or not.

The current loop looks like this: vision → prompt → output → review → iterate.
The human is the intelligence in the loop.
The judgment.
The taste.
The direction.
The closer.

That loop is compressing.

Not because humans are being removed, but because the tools are getting good enough that the loop can run faster, with less friction, with less manual review at each stage.
And so the AI agent isn’t replacing the builder, but it’s changing what the builder needs to be. It’s changing his identity!

The builders who win in the next chapter are not the ones who prompt the fastest, they’re the ones who:

• Know which problem is worth solving before the agent starts

• Can evaluate output not on surface aesthetics but on structural durability

• Understand how a product fits into a market, not just a codebase

• Think in portfolios, not products

This is the shift from executor to architect.
From prompter to director.
From builder to strategist.

And the platform that serves this new kind of builder needs to be built accordingly.

What a Platform for the Next Builder Looks Like

Every current vibe coding platform has the same hidden assumption embedded in its architecture:

A human is in the loop, prompting, reviewing, deciding at every step.

That assumption shapes everything, the interface, the feedback loop, the output format, the pace of iteration,… And these are brilliant and powerful platforms, to say the least, but they have one big flaw. They were designed for the builder as executor.

The next big platform will be designed for the builder as architect.

Now, you might ask, what does that actually mean?

It means deterministic composition over stochastic generation.

Not “here’s some code, good luck” but AI constrained to produce structured, type-safe, pre-validated building blocks that compile into real, maintainable applications.

i’ll say this again: Structured, Type-safe, pre-validated blocks that compile into real + MAINTAINABLE applications.

Apps that can be handed to an agent for extension, handed to a collaborator for modification, handed to a future version of yourself without needing to reconstruct the entire mental model from scratch.

It means a logic layer that’s first-class, not hidden underneath the UI.

• Where the data models are consistent.

• Where the architecture is legible.

• Where what got built is expressed in a structure that both humans and agents can reason about.

It means composability by default. What you build here should talk to what exists there. It needs open protocols, clean interfaces and NOT walled gardens.

The next Vibe Building platform needs open architectures that treat the builder’s work as a node in a larger system, not an island.

When you design a platform around these properties, something unexpected happens: it becomes more powerful for creative builders, not less.

Because what makes a system readable to an agent running at 3am with no human in the loop is the same thing that makes it readable to a builder who doesn’t want to babysit their tools at 3pm.

Clarity and structure aren’t constraints on creativity. They’re the foundation that makes creativity last.

This is the Vibe Building thesis made concrete.

The Logic Layer isn’t just the name of this newsletter, but it’s the design requirement for what comes next!

Share The Logic Layer

One More Thing, And This One Will Change How You See The Web

I’ve been hinting at something in this article that I want to name before I close, because it connects to work I’m publishing in a different context this weekend.

This week I posted something on LinkedIn that’s been getting traction:

The internet just broke in two.

For 30 years, we built the web for one kind of user: the human. We measured success in clicks, dwell time, aesthetic beauty, emotional resonance. Don Norman called it User Experience (UX), and it shaped everything.

That monopoly is over.

We’re now entering what I’m calling The Great Split, the web physically splitting into two distinct layers.

A Surface Web optimized for humans: video, emotion, design, narrative.

And a Deep Web optimized for agents: logic, APIs, structure, clean data contracts.

Most companies are spending 100% of their attention on the Surface Web and to a human, their sites are masterpieces! Here’s a perfect example of a masterpiece website made for the Surface Web: https://mitchivin.com

But to an AI agent, increasingly the first buyer in any procurement decision, those same sites are beautiful noise...

The agent can’t read the pricing, can’t navigate the menu, can’t execute the transaction, it’s lost in the beauty of something that wasn’t designed for it.

This weekend, I’m publishing the full manifesto on The Great Split and what I’m calling AX, or Agent Experience = the design discipline for the era when agents are primary users, not secondary ones.

But here’s why it matters in this newsletter, right now:

The platform built for the next generation of builders, the architects, the strategists, the AI-native operators needs to produce apps that live in both worlds.

Beautiful on the Surface Web, for the humans who will use them.
Readable on the Deep Web, for the agents who will operate them.

And that, is not a feature but an architectural commitment!

Leave a comment

The Movement

We are at an inflection point that comes once or twice in a generation.

The r/vibecoding community now well past 320,000 members proved something the traditional software world didn’t believe: the desire to build is more widespread than anyone imagined.

The barrier was never intelligence or creativity.
It was access.

Vibe coding broke that barrier open.

What comes next is the infrastructure for what the builders become on the other side of it. Not just faster code generation but a platform with the logic layer built in, where what you create is durable, composable, legible to agents, and designed to outlast the prompt that produced it.

The Cambrian Explosion is here.
The Clone Wars are coming.
The builders who survive both are the ones who stop thinking like coders and start thinking like architects!

That’s what this newsletter is for.

And the platform we’re building at Makyo? That’s what it’s designed to make possible.

The Logic Layer is published by Arthur Makyo, Head of GTM and Co-founder at Makyo.ai, we’re building the platform for AI-native builders: structured, deterministic, designed for architects, not just prompters.

If this resonated, forward it to one builder who’s proud of what they made. And if the AX / Great Split thread interests you, watch the AI[re]Generation Channel this Saturday, that’s where the manifesto drops and thats where you’ll understand how the future looks like.

Reply with what you’re building. We read everything.

PS: If you want to get on the waitlist to the first who gains access to Makyo, click here

Arthur

It wasn’t a bad hire. It wasn’t a failed marketing campaign. It wasn’t even a lost client.

It was saving money.

Let me explain.

In March 2025, a client came to me with a standard request: a marketplace app connecting service providers with customers. Think Uber, but for home repairs.

Traditional developer quotes: €15,000 - €50,000
Timeline: 3-6 months
My vibe-coded MVP: €300
Timeline: 3 weeks

I felt like a genius.

By May, the app was live. By June, we had 200 users. By July, everything was on fire.

Here’s the P&L that nobody talks about when they post their “I built an app in 3 weeks!” screenshots:

Month 1-3: The Glory Days

• Build cost: €300 in API credits

• Maintenance: €0

• Client happiness: 10/10

• My ego: Inflated

Month 4-6: The Slow Burn

• New features requested: 7

• Features shipped: 2

• Hours spent debugging: 127

• Cost at my hourly rate: €8,400

• Client happiness: 6/10

• My ego: Deflating

Month 7-9: The Reckoning

• Hired traditional developer to audit code

• Developer’s first words: “We need to rebuild this”

• Rebuild cost: €12,000

• Total project cost: €20,700

• Original traditional dev quote: €15,000

• My ego: Gone

I paid 38% MORE to vibe code than I would have paid a traditional developer.

And I’m not alone.

“I built an MVP for a few hundred dollars. Traditional devs wanted tens of thousands. Felt like I won the lottery. Then reality hit around month 6.”
~ From my analysis of 287 Reddit comments on r/vibecoding

Share

The Seduction of Speed

Let me show you what everyone sees:

ISO Weather App: Built in 3 weeks. 1,400 downloads. $260 in revenue.

Protin Tracker: Simple iOS app. $65 in first 2 weeks.

Stocktaper: Full research platform. Successfully launched premium features.

These are REAL successes. Real apps. Real users. Real money.

The posts get hundreds of upvotes. The comments at first are celebratory. And somehow it feel like anyone can build anything now….

But once you look closer (even by looking at the comments), you’ll start seeing a different picture.

Loo, I’m not criticizing these founders, content creators,…. They did something incredible. They shipped.

But the viral screenshots hide the maintenance tax. And that tax is brutal.

Don’t miss Article 3: The Security Audit That Should Terrify Every Vibe Coder. Subscribe to get the full series.

The Hidden Costs Nobody Tracks

Let me show you the real cost breakdown that took me weeks to calculate.

Most agencies track:

• API credits

• Build hours

• Client billable time

But they’re missing the iceberg beneath the surface:

Hidden Cost #1: The Security Audit Bomb

Last month, I paid a security researcher to audit 5 apps I built with Cursor and Lovable.

Result: 5 out of 5 failed basic security.

Not “could be improved” failed.
“Your entire user database is publicly accessible” failed.

The most common issue? Supabase Row Level Security (RLS) policies set to USING (true).

In plain English: The AI wrote “anyone can read anyone’s data” because it made the frontend stop throwing errors.

“AI wrote [USING (true)] so the frontend wouldn’t throw permission errors… dumps emails, hashed passwords, everything.”
— Security auditor

Cost to fix: €2,400 (48 hours @ €50/hr)
What I budgeted for security: €0
Lesson learned: AI optimizes for “make it work” not “make it secure”

Hidden Cost #2: The Debugging Death Loop

Here’s something nobody warned me about: AI-generated code creates self-reinforcing debugging loops.

The cycle looks like this:

1. User reports bug

2. I prompt Claude to fix it

3. Claude “fixes” it by breaking something else

4. I prompt Claude to fix THAT

5. Claude rewrites a core function

6. 3 features that depend on that function break

7. I spend 6 hours finding what changed

8. I roll back to yesterday’s commit

9. Original bug still exists

10. Repeat

One Reddit user called it “the most frustrating addiction”

They’re not wrong. I’ve had days where I spent 8 hours prompting and ended up with a WORSE codebase than I started with.

“Getting into a loop of ‘debugging’ - prompting all day… it kept creating duplicate systems that didn’t talk to each other.”

Share

Average debugging loop cost: 4-6 hours per incident
Incidents per month: 8-12 (based on my tracking)
Monthly cost: €3,200 - €4,800
What I budgeted: Maybe €500?

Hidden Cost #3: The Refactoring Burden

AI doesn’t refactor. It patches.

When you ask it to add a feature, it doesn’t think “where does this fit in the existing architecture?”

It thinks “what’s the fastest way to make this work?”

Over time, this creates what one developer called
“parallel systems that don’t talk to each other”

Here’s a real example from my marketplace app:

Month 1: Built user authentication
Month 2: Asked AI to add “service provider profiles”
Month 3: Asked AI to add “customer profiles”

The result:

• users table (original)

• service_providers table (redundant)

• customers table (also redundant)

• user_profiles table (I don’t even know why this exists)

Four tables storing the same data. Zero shared logic. Complete chaos.

“Yes, works fine but requires non-stop refactoring and a lot of tests.”
— r/vibecoding, on the maintenance reality

Cost to untangle this: €4,200 (3 days of developer time)
What I budgeted: €0
Preventable? Yes, with architecture-first approach

Hidden Cost #4: The Context Window Cliff

Around 166 files, something breaks.

Not the app but the AI’s ability to understand the app. Which is even worse.

Users report hitting a wall where the AI:

• Forgets what it built 20 prompts ago

• Rewrites existing functionality instead of using it

• Can’t understand how new code connects to old code

• Requires manual copy-pasting of files into chat boxes

One developer told me: “I spend more time managing the AI’s context than actually building features”

Cost of context management: 2-3 hours per day
Monthly cost: €2,400 - €3,600
What I budgeted: “Wait, this is a problem?”

This is Article 2 of the first of 5 series. Subscribe to get the rest of the series delivered to your inbox.

The Agency Death Spiral

Let me show you the math that’s quietly killing agencies who’ve gone all-in on vibe coding.

Here’s how it plays out:

The Sales Pitch:

• Agency to client: “We can build your MVP for $5,000”

• Client: “Everyone else quoted $20K+”

• Agency: “We use AI. We’re faster.”

• Client: signs

The Build (Month 1-2):

• Agency spends: $300 in API credits

• Agency spends: 20 hours @ $150/hr = $3,000

• Total cost: $3,300

• Profit: $1,700 ✅

• Agency thinks: “This is amazing!”

The Maintenance (Month 3-6):

• Client requests: “Can you add user roles and permissions?”

• Agency estimates: “Sure, 8 hours”

• Actual time: 32 hours (debugging spaghetti code)

• Cost: $4,800

• Client requests: “The search is slow”

• Agency estimates: “Quick fix, 4 hours”

• Actual time: 16 hours (database query optimization nightmare)

• Cost: $2,400

• Client requests: “Can we add email notifications?”

• Agency estimates: “8 hours”

• Actual time: 24 hours (AI keeps breaking existing email system)

• Cost: $3,600

Total maintenance cost: $10,800
Original profit: $1,700
Net profit: -$9,100

The agency LOST money on this client. And they still have a fragile codebase that will generate more support requests next quarter.

“Every hour spent refactoring ‘spaghetti code’ is an hour you’re not shipping new value. You’re paying your developers to clean up after the AI.”
From Article 1 of this series

Share The Logic Layer

Now multiply this across 10 clients.

The agency that looked profitable in Month 2 is bankrupt by Month 8.

And they don’t understand why, because the P&L looks great when you only track API costs.

The Real Cost Calculator

Let me give you the formula I wish I had 12 months ago.

Traditional Development Cost Formula:

Total Cost = Upfront Build Cost × 1.5  
(1.5x accounts for reasonable maintenance)

Vibe Coding Reality Formula:

Total Cost = (Build Cost) + (Maintenance Cost)

Where:
Maintenance Cost = (Build Cost) × (Complexity Factor) × (Time Factor)

Complexity Factor:
- Simple CRUD app: 2x
- Business logic (workflows, permissions): 5x  
- Complex multi-sided marketplace: 7x+

Time Factor:
- Month 1-3: 0.5x (honeymoon period)
- Month 4-6: 2x (reality sets in)
- Month 7-9: 4x (death spiral)
- Month 10+: Consider full rebuild

Let’s run my marketplace example:

Build Cost: €300
Complexity: Marketplace (7x multiplier)
Time: 9 months

Month 1-3 maintenance: €300 × 7 × 0.5 = €1,050
Month 4-6 maintenance: €300 × 7 × 2 = €4,200
Month 7-9 maintenance: €300 × 7 × 4 = €8,400
Rebuild cost: €12,000

Total: €25,950

Traditional dev quote: €15,000

I overpaid by 73%.

What Good Architecture Actually Costs (And Saves)

I don’t want to end this article on doom and gloom.

Because there IS a way to get speed without the death spiral.

The secret is in something one Reddit comment nailed perfectly:

“I’m starting to maintain my first full opus 4.5 webapp & if you did a good job on the architecture, have a proper testing & monitoring setup, this is as smooth sailing as having an app on the internet can get.”
— r/vibecoding, on why architecture matters

Share

Notice what they said: “If you did a good job on the architecture”

That’s the variable. Not the AI model. Not the tool. The ARCHITECTURE.

Here’s what changes when you lead with architecture instead of code:

✅ You spend more upfront (€800 vs €300)
✅ You think about structure before building
✅ You use pre-built, tested blocks (no security fails)
✅ You can SEE your logic (no spaghetti archaeology)
✅ Changes are predictable (no surprise breakage)
✅ Maintenance is boring (which is good!)

The Makyo Math

This is why we are building Makyo.

Not because vibe coding is bad. Because code-first is the wrong abstraction for most business software.

When you build with Makyo:

Month 1-3:

• Visual logic builder (see what you’re building)

• Pre-tested blocks (auth, payments, workflows)

• No code generation = no spaghetti

• Cost: Flat agency pricing (predictable)

Month 4-6:

• Client requests changes

• You click and drag in visual editor

• Changes show impact BEFORE you commit

• Debugging: minimal (blocks are pre-tested)

Month 7-9:

• You’re shipping features, not fighting fires

• Client is happy (features ship fast)

• You’re profitable (no surprise costs)

• Code is… wait, there is no code

What This Means For Your Agency

If you’re running an agency that’s adopted vibe coding, I need you to run this exercise:

1. List your current client projects

2. Calculate actual time spent on maintenance (be honest)

3. Multiply by your hourly rate

4. Compare to what you charged

5. Calculate real profit margin

If you’re like me 12 months ago, you’re going to see red numbers.

And you have three options:

Option A: Keep vibe coding and accept the maintenance tax
Option B: Go back to traditional development (slow, expensive)
Option C: Try architecture-first with tools like Makyo

I spent 9 months on Option A. Lost money. Lost sleep. Lost clients.

Option B wasn’t feasible (can’t compete on price).

Option C is where I am now. And I wish I’d started here.

Subscribe now

Ready to See the Difference?

We’re currently in Alpha with 12 agency partners stress-testing Makyo on real client projects.

What they’re reporting:

• 80% reduction in maintenance hours

• Zero security audit failures

• Clients approve changes in visual editor (empowering!)

• Flat pricing = predictable costs = profitable projects

We’re selecting 5 more agencies for our next Alpha cohort.

Ideal fit:

• Managing 5+ client applications

• Using Cursor/Lovable/Bolt currently

• Bleeding on maintenance costs

• Ready to try architecture-first

What’s Next in This Series

This is Article 2 of 5 (possibly more, you keep asking great questions).

Coming up:

Article 3: “The Security Audit That Should Terrify Every Vibe Coder”
→ 5 out of 5 apps failed. Entire user databases exposed. Here’s what I found.

Article 4: “The AI Agent That Deleted My Production Database”
→ The debugging loop that turns genius coders into hostages.

Article 5: “I Analyzed 287 Comments. Here’s What Nobody’s Saying Out Loud”
→ The 7 unspoken truths from the trenches.

Discussion

What’s YOUR vibe coding horror story?

Drop it in the comments. Let’s crowdsource the real costs nobody’s tracking.

Specifically:

• What did your MVP cost to build?

• What did maintenance ACTUALLY cost?

• What surprised you most?

• Would you do it again?

Leave a comment

Thanks for reading The Logic Layer! This post is public so feel free to share it.

Share

About this series:
I’m Arthur, co-founder of Makyo. I spent 18 months analyzing what happens AFTER you vibe code an app. This series shares what I learned (the expensive way) and what we’re building to fix it.

Subscribe to our waitlist or reach out to us.
[LinkedIn] | [Waitlist]