I said vibe coders would hit a wall. The models lifted them over it.

Freshdesk told us our bill was going from £150 a month to £280. Yesterday afternoon I typed one paragraph into a coding agent.

“Freshdesk are putting up their prices. Build me a replacement small team helpdesk platform, with ticketing driven by emails and a knowledge base. We’ll host on AWS, and can build our own AI help bot based on our own RAG platform. Build this as autonomously as possible. Make your own technical decisions and choices, this is all standard stuff.”

Just under an hour of model time later, including a pause while my usage limit reset, there was a working helpdesk running on my machine. I have spent two hours in it since and have not found a bug. That is not proof of anything yet, and I will come back to what it does and does not prove. But it is enough to make me revisit something I wrote in January.

What I said in January

At the start of the year I wrote that vibe coders would hit a wall. The argument was that describing what you want and accepting whatever comes back works for a weekend project and fails for anything that has to survive contact with real users. Agentic engineers, the people who bring structure, specifications, tests and review to the process, would become the standard. Vibe coders would run out of road.

I still think the structure matters. What I got wrong is who has to supply it.

There was a step change in November last year, with Opus. With that model it became possible for a disciplined engineer to build almost anything quickly, provided they brought the discipline. Every post on this blog since then has been about what that discipline looks like. Fable 5.1 and GPT-6 Astra are another step, and it is a different kind of step. The discipline is now coming from the model.

What the model supplied

The prompt above is vibe coding by any definition I would have accepted in January. No specification. No architecture. An explicit instruction to make its own choices. Here is what Astra chose.

Django 5.2 LTS on PostgreSQL, server-rendered pages, Amazon SES v2 for inbound and outbound mail, S3 for raw message storage, SQS for delivery, Terraform for the infrastructure, Docker and a CI workflow. A shared inbox with ownership, priorities, private notes, saved replies and an audit trail. A public knowledge base with drafts, publication and revision history. An integration with our existing RAG platform for agent reply suggestions and a public help assistant, disabled by default and requiring a separate public-only tenant so nothing internal can leak through the bot.

Then the parts that separate a demo from a product. Inbound mail is idempotent, so a duplicate delivery from SES cannot create a duplicate ticket. Threading uses random reply-address tokens, so a quoted ticket reference does not let a stranger join a private conversation. Outbound mail sits in a durable queue with explicit states, and if a send times out after SES may have accepted it, the message is flagged as uncertain for a human to review rather than resent. Concurrent edits are rejected without losing the reply the agent had typed. Permanent bounces suppress further mail to that address.

Fifty-two tests cover all of that. The commit is 3,923 lines. The model wrote its own AGENTS.md for whoever works on the code next, and a README that plainly lists what it left out. No customer portal, no SSO, no multiple mailboxes, no CC participants, no ticket merging, no satisfaction surveys, no automation rules. It also states that no live email was sent, no cloud resources were created, and the local tests ran on SQLite rather than PostgreSQL.

That last paragraph is the point. In January I would have said an engineer has to bring the tests, the threat model, the failure states and the honest account of what is missing. Nobody brought them. They came with the code.

What I supplied

I should be honest about the prompt, because it was not naive. I named AWS. I scoped it to a small team. I pointed the model at our RAG platform, a codebase that carries its own module headers, specs and tests, and I cannot tell you how much of the result was shaped by reading that. Some, certainly.

But I have never used Django. Nobody at inmydata has. The framework, the outbox design, the uncertain-send state, the token-based threading, none of that came from us. And I suspect that if I had written “host it in the cloud” instead of naming AWS, the model would have chosen AWS anyway, because that is what it chooses.

So we now own a production system in a framework none of us has worked in, and I am comfortable with that. Two years ago that sentence would have described negligence. Today it is the ownership model, because the thing that will read this code and fix it is not going to be me. It will be Fable, reviewing Astra’s work, which is also how the security analysis gets done this week.

What is left of the engineer

Last week I argued that agentic coding collapsed the build cost and left the ownership cost intact. Harbour, which is what the model named it, went into the company GitHub organisation, so by my own rule it became a product at the moment of the first commit. I am now the vendor of a helpdesk.

At £280 a month the subscription is worth less than a day of my time a year. If owning this costs more than a few hours annually, Freshdesk was cheaper and this whole exercise was vanity.

Here is why I do not think it will. Ownership cost is roadmap plus incidents. A helpdesk for a small team has no roadmap. The features are known, the behaviour has been standardised for twenty years, and nothing about our support queue changes next year. The roadmap was Freshdesk’s problem, and the price rise is what their roadmap costs their customers.

That leaves incidents, and this is where the honest boundary sits. Adding Harbour to our AWS account costs under £5 a month. Our legacy platform has used SES for years to deliver reports and receive data. We already run the monitoring, we already deploy to AWS several times a week, and we already know what a dead-letter queue filling up on a Saturday looks like and how to find out. Ownership collapsed for us because it is marginal against operations we were already paying for.

For a firm without that, Harbour would be the failure MIT measured, load-bearing and unowned. McKinsey’s split says the same thing. Thirty-two percent of organisations have declined a purchase because they could build instead, but in technology firms it is forty-one. The build is available to everyone now. Running it safely is not, yet.

So that is what an experienced engineer is still for. Not the code, not the architecture, not even the tests. Deploying the result somewhere it will not fall over, knowing when it has, and getting it back. Eight months ago I would have given you a longer list.

What the subscription was buying

Turn that round and look at it from Freshdesk’s side. Every customer with an operations team was paying £150 a month for functionality that now costs an hour of compute and a marginal share of infrastructure they already run. The price rise did not create that gap. It made us look at it.

A price increase on commodity functionality loses the customers with an ops team first, and those were the ones paying reliably and never calling support. What a SaaS vendor is left selling is the ownership term, running the thing for the people who cannot. That is a real product, but it is a different product from the one their pricing page describes, and it does not get cheaper as the models improve.

How long the far side of the wall holds

Harbour is not live. Between it and Friday sit a security review by a second model, our pen test suite, the migration of two years of Freshdesk content, and a real deployment with real email. The argument in this post does not depend on any of that going well. It depends on what came out of one paragraph, which is on GitHub and will not change if the deployment goes badly. If it does, that is next week’s post.

What I cannot tell you is how long operations stays on the engineer’s side of the wall. This is speculation and I will label it as such. Everything I listed as still ours, monitoring, resilient deployment, incident recovery, is standard, well documented and heavily exercised. Those are exactly the conditions under which the models just absorbed everything else. It took less than a year for the value of an experienced engineer to be reduced to the last mile. I would not bet on the last mile lasting two.