Agentic development is making code cheap. That's changing everything.

The economics flipped

For most of the history of software, code was expensive in a very specific way: not because typing was slow, but because changing your mind was slow.

A bug in production wasn't a five-minute fix. It was find the developer who wrote it, hope they're available, read enough context to understand why the thing exists, make a change without breaking three other things, test it somehow, deploy it carefully, and pray. A small UI tweak could be a half-day. A "simple" integration could be a sprint.

That shaped how businesses thought about software. You spec'd carefully because rework hurt. You bought off-the-shelf when you could because custom build felt like a marriage. You treated the codebase as an asset you'd better not disturb.

Something shifted in the last eighteen months. Not gradually — noticeably.

What actually changed

The first wave of AI in development was autocomplete on steroids. Useful, overhyped, and mostly about writing the first draft faster.

The second wave is different. Agentic development — tools that don't just suggest the next line, but read your project, run your tests, try a fix, see it fail, adjust, and come back with something that passes — has changed the unit economics of maintenance.

A bug report that used to queue behind two other tickets can now look like this:

1. Someone describes what's wrong, ideally with a screenshot or steps
2. An agent reads the relevant files, reproduces the issue, proposes a fix
3. Tests run automatically; the agent iterates until they pass
4. A human reviews the diff — five minutes if it's a styling fix, longer if it touches money or permissions
5. Ship to staging, sanity-check, deploy

We're not talking about replacing developers. We're talking about removing the idle time between understanding a problem and having a candidate solution. The boring middle — context-switching, grep-ing, "oh wait it's actually in the other service" — compresses dramatically.

When that happens, code stops feeling precious.

Cheap code, and why that word isn't an insult

"Disposable code" sounds reckless until you realise most businesses already treat plenty of things as disposable.

The spreadsheet Karen built to track rush orders? Disposable — she'll rebuild it if it breaks. The one-off script that reformats supplier CSVs? Disposable. The internal dashboard someone knocked up in a hack week? Disposable, until it isn't, which is a different problem we'll come back to.

What's new is that custom application code is sliding toward the same category — if you have guardrails.

Guardrails, in practice, mean:

• Automated tests for the rules that matter: pricing, permissions, anything a customer will quote back at you in an email
• A staging environment where changes land before production
• Review on the sharp edges: auth, payments, data deletion, anything that sends email to a customer
• Version control and deploy history so you can roll back in minutes, not hours
• Monitoring that tells you something broke before your ops manager's phone rings

With those in place, "throw it away and regenerate" becomes a rational option. Not for everything — but for a surprising amount of UI, boilerplate, and glue code that used to absorb days of careful hand-editing.

The codebase becomes less like a handmade piece of furniture you’re afraid to sand, and more like a set of instructions you can re-run. The specification — what the software must do, what must never happen — is the asset. The generated implementation is increasingly replaceable.

That's a mindset shift as much as a technology one.

The rise of the home-built app

You can see the same force from the other direction.

Platforms like Lovable, Bolt, v0, and Replit aren't just for developers anymore. A business owner with a clear idea and a free afternoon can describe an app — "a dashboard for our field team to log job notes and photos, with a manager view filtered by region" — and have something clickable by teatime.

Lovable in particular has leaned into this "describe it, get an app" loop for non-technical founders and ops leads. The output is often impressively polished: auth flows, database, hosting, a URL you can share on Slack. For validating an idea or aligning a room on what "good" looks like, it's genuinely useful.

We wrote recently about what happens when that prototype has to work on a Tuesday morning — when real customers, Xero, and permissions enter the picture. That article still stands. The new bit is volume: more businesses now have a home-built app in production, or half in production, than at any point in the last decade.

Sometimes that's fine. A lightweight tool for a team of six, low stakes, easy to rebuild? Cheap code doing its job.

Sometimes it's a ticking clock. The app works until it doesn't — when the founder who built it goes on holiday, when you need SOC2 answers, when you realise customer records live in a database nobody can export.

The pattern we see: the first 80% is nearly free; the last 20% still costs what it always cost, unless you designed for it upfront.

What agentic development is good at (and what it isn't)

It's worth being precise, because the hype cycle is exhausting.

Agentic tools are very good at:

• Fixing bugs with clear reproduction steps
• Refactoring repetitive code
• Adding tests around existing behaviour
• Translating "make this screen match the Figma" into working UI
• Chasing down lint errors, dependency bumps, and the small maintenance tasks that used to fill the gaps between "real" work

They're still unreliable at:

• Knowing your business rules without being told
• Deciding what should happen when a PO references a customer that doesn't exist in the CRM yet — that's a policy call, not a code call
• Integration design across five systems with different source-of-truth semantics (we've written about that separately)
• Security architecture, especially permissions that need to survive an audit
• Knowing when not to build something

The last one matters. Faster coding makes it easier to build the wrong thing quickly. Discovery doesn't get less important when generation is cheap. If anything, it gets more important, because the cost of skipping it is now "a working app that solves the wrong problem by next week."

Two kinds of software, two kinds of "cheap"

A useful split:

Expensive-to-get-wrong software

Customer-facing portals. Pricing engines. Anything touching money movement. Systems that hold the only copy of contractual data. Tools regulated industries depend on.

Here, code can still be cheaper to change than it was — agentic workflows help — but you don't treat it as disposable. You invest in foundations: clear domain model, integration boundaries, audit trails, tests on the rules, someone on call who understands it.

Cheap-to-iterate software

Internal dashboards. Workflow experiments. Prototypes. Glue between systems where the spec is stable and the stakes are low. MVPs you're using to learn, not to bet the company on.

Here, disposable is a feature. Ship, learn, regenerate, or throw away without ceremony.

Most businesses need both categories on the go at once. The mistake is applying the wrong category's economics by accident — treating a Lovable prototype like production infrastructure, or gold-plating an internal tool that should have been a two-week experiment.

What this means if you're not a developer

Three practical takeaways:

1. Ask "what are the guardrails?" not "which AI tool?"

The tool matters less than whether changes are tested, reviewed, staged, and reversible. A mediocre stack with good guardrails beats a flashy AI-generated app with none.

2. Separate the idea from the implementation.

If someone on your team built a useful thing in Lovable over a weekend, the valuable part might be the workflow they discovered, not the repo Lovable generated. Before you pour money into "finishing" it, ask whether you're validating an idea (cheap) or committing to a platform (expensive).

3. Bug response is a competitive advantage again.

When your competitors still queue fixes behind a two-week sprint, and you can turn around low-risk changes in hours because agents handle the grunt work and humans review the edges — that's not a developer perk. That's ops responsiveness. Customers notice.

What hasn't changed

AI didn't repeal Tuesday morning.

Software still has to talk to the systems you already pay for. Someone still has to decide who can see margin. Backups still matter. When the courier API times out mid-label-print, a human still needs a fallback.

What's changed is the cost of iteration on top of those foundations — and the number of people who can participate in the first draft.

We're building client systems with agentic workflows in the loop now: faster bug turnaround, more disposable UI layers, the same insistence on discovery, integrations, and production guardrails we had before the tools existed.

If you've got a home-built app that's outgrown its weekend, or you're wondering whether your team should lean into this or proceed carefully, say hello. We'll tell you straight which parts should stay cheap and which parts deserve to be built to last.