For most of my career, writing software has meant making a series of compromises around a scarce resource: engineering time. We decide which features deserve it, which bugs can wait, how much we can afford to test, and which parts of a system are worth rebuilding. The code itself takes time to produce, read, review, and maintain.

Agentic development changes that equation. Not because models can generate a lot of code—that was already possible—but because they can increasingly work through an entire task: inspect a codebase, plan changes, implement them, run tests, investigate failures, and try again.

In my previous post on agentic engineering, I wrote about the difference between using agents responsibly and simply accepting whatever they produce. That’s a question about how to build software today. There’s a bigger question I’ve been thinking about: what happens to the software industry when producing and inspecting code stops being the expensive part of the job?

I don’t expect every prediction below to arrive at once, or evenly. Some may be wrong. But I think the direction matters more than the exact timeline.

Code review as we know it will become less useful

A pull request is largely a tool for helping people inspect changes that other people made. That makes sense when writing code is costly and reading it carefully is one of the few ways to catch mistakes before they reach production.

Now imagine an agent that can implement a change, another that can challenge it, and a third that can run targeted tests against the resulting system. As those tools improve, I expect the value of having a person read every line of every ordinary change to fall sharply.

That does not mean we should remove human approval or trust an agent that announces its own success. Agents can share assumptions, miss the same requirements, or produce tests that confirm the wrong behaviour. And in security-sensitive, regulated, or performance-critical systems, a human may still need to inspect particular implementation details.

What I expect to change is the unit of review. Instead of starting with a diff, reviewers will increasingly start with the intended behaviour and the evidence:

• What was the system supposed to do, and what was explicitly out of scope?
• What architecture or trust boundaries changed?
• Which tests, adversarial cases, and real-world observations support the result?
• What happens when it fails, and how do we reverse the change?

The diff will remain available when we need it. It just won’t always be the centre of the conversation. We may eventually look back at line-by-line review of routine changes as an odd way to spend an engineer’s attention.

The most expensive bugs will be the ones we asked for

We tend to think of a bug as a mistake in the implementation. An off-by-one error. A missing null check. A race condition. Something the programmer meant to do correctly but didn’t.

Those bugs aren’t about to disappear. But as agents get better at generating and checking code, I expect more of the costly failures to come from an earlier point: we specified the wrong behaviour, left out a critical constraint, or confidently accepted an assumption nobody had verified.

Imagine a client asks an agent to automate refunds. The resulting service handles retries, passes its tests, and ships. Three weeks later, finance discovers it treats a partial refund as a full reversal because nobody defined how tax, fees, and prior adjustments should work.

The code may do exactly what the specification said. The specification was the bug.

An agent can ask excellent questions and find edge cases that a busy team would miss. We should use it for that. But it cannot settle a disputed business rule by generating a plausible answer. The source of truth has to come from somewhere outside the implementation: people who understand the problem, policies we can inspect, representative data, and acceptance criteria tied to real outcomes.

If implementation becomes cheap, getting the question right becomes a much larger part of engineering.

The craft of writing code will shrink. The craft of building software won’t.

There will always be people who enjoy writing beautiful code by hand, just as there are people who enjoy making things that factories can produce faster. I expect there to be fewer jobs where typing the implementation is the main source of value.

That doesn’t mean good engineering becomes irrelevant. It means some of our current ideas about “good code” will need another look.

We have built many coding conventions around the needs of human readers: formatting, naming patterns, file organisation, the length of a function. Those things still matter while people maintain systems, and they remain useful context for agents. But I doubt we’ll keep treating every human readability convention as a universal measure of software quality when agents do most routine modification.

I’d put more weight on qualities we can verify regardless of who—or what—changes the code: clear interfaces, isolated failure modes, reproducible builds, meaningful tests, observable behaviour, explicit permissions, and changes we can roll back.

An incomprehensible system that only one model can safely alter would still be a terrible system to own. The goal isn’t to replace readable code with disposable code. It’s to stop confusing familiar formatting with evidence that the software is correct.

The PM–designer–engineer handoff will be harder to justify

A lot of our process exists because specialist time is scarce. Product managers translate business needs into tickets. Designers turn those tickets into screens. Engineers turn the screens into code. Then the work travels back through the chain for review and revision.

For some products, that division is sensible. For others, especially in small teams, the handoffs take longer than the work.

I expect agents to make that structure less rigid. One person with strong product judgment could explore requirements, generate and test interface options, build a working slice, and put it in front of users without waiting for three separate queues. The same person might bring in a security specialist, designer, or domain expert only where the risk or complexity calls for it.

That isn’t an argument that design or engineering knowledge will vanish. In fact, when an agent can generate ten convincing designs before lunch, the ability to tell which one serves the user becomes more valuable. The same is true of architecture, accessibility, security, and operations.

What I suspect will lose value is the role of passing tickets and status updates between humans and agents without adding much judgment. If an agent already knows the state of the work, a meeting whose sole purpose is to repeat that state becomes difficult to defend.

Agile’s emphasis on feedback and adaptation still makes sense to me. Some of the ceremonies we’ve attached to it may not survive.

Large companies won’t simply become small companies, either. Their legal obligations, existing systems, approval paths, and organisational politics don’t disappear because code gets cheaper. But smaller teams will have to question any process they copied from a company with a thousand engineers.

Tokens will become an engineering budget, not just an AI bill

For decades we’ve designed software around fairly predictable compute: processors, memory, storage, and network capacity. Agentic systems add a different kind of resource to manage: model inference, usually measured in tokens, with variable cost, latency, and reliability.

I don’t mean that binary computers are going away. They’re the machines running the models. I mean that more application logic may be expressed as work delegated to a model rather than rules that developers write in advance.

That changes how we think about efficiency.

The cheapest model per token may be the most expensive model for a task if it makes several wrong turns. A more capable model might use fewer attempts, produce better work, and save enough review time to justify its price. Conversely, using the most expensive model to rename a variable is a waste.

The useful measure is the cost of a verified outcome: inference, tool use, retries, evaluation, elapsed time, and the cost of fixing a mistake. Teams will need to make that calculation across different models and tasks, not just compare price lists.

Access matters, too. If the best models or large inference budgets remain scarce, well-funded companies will have an advantage. If capable models keep getting cheaper and more widely available, a tiny team could compete in areas that once required a much larger engineering department.

I wouldn’t bet on either outcome being permanent. I would want control over how my systems use models, what data they can access, and how easily I can switch providers.

Open source will have to offer more than a pile of reusable code

Open source gave us a way to share the cost of making and maintaining useful software. For years, discovering that someone had already built a good library could save weeks of work.

If agents can generate a large amount of ordinary application code on demand, that particular benefit becomes less compelling. I expect more teams to generate small components suited to their own requirements instead of adding a dependency just to avoid writing a few hundred lines.

But that doesn’t make open source obsolete. It changes what makes a shared project valuable.

A mature library isn’t only source code. It’s years of real-world failures, compatibility decisions, test cases, security fixes, documentation, and people willing to be accountable for releases. Agent-generated code does not automatically inherit any of that. Shared evaluation suites, open standards, reference implementations, reproducible research, and trusted data may become more valuable as code gets easier to produce.

Open-source maintainers may also face a new problem: a flood of plausible AI-generated contributions that cost almost nothing to submit but still cost something to assess. Good projects will need better ways to establish evidence and provenance, not simply accept more pull requests.

I expect the ecosystem to change considerably. I don’t expect the need for public, inspectable, collectively maintained software to go away.

Software interfaces may stop being fixed

Most of the interfaces we use are elaborate ways of explaining our intent to software that doesn’t understand it. Menus, forms, filters, settings screens, and dashboards exist partly so we can express a request in terms the system knows how to process.

A capable agent could reverse some of that relationship. Instead of opening five dashboards to answer a question about my business, I could ask for the answer and have the system produce the exact view, explanation, or workflow I need. Someone else, with a different task, might get a completely different interface over the same data.

I expect this to change internal tools first, where workflows vary widely and the cost of building bespoke interfaces is hard to justify. It could eventually change consumer software as well.

But fixed interfaces solve real problems. They teach us where things are, make actions predictable, support accessibility, and let us confirm exactly what will happen before we commit. I don’t want a payment screen that rearranges itself at the moment I authorise a transfer.

The interesting future is probably not “no UI.” It’s a mix of generated views and stable, well-designed controls, with the balance determined by how much predictability and trust the task requires.

This transition will take years, and it won’t be fair or tidy

Software isn’t replaced the moment a better way of writing it appears. We still maintain decades-old systems because they encode real business knowledge, connect to other systems, and keep working. Regulated industries, large enterprises, and companies with limited budgets will adopt agentic workflows at different speeds.

There will be awkward years when experienced developers are asked to maintain old systems while learning to supervise new ones. Junior engineers may have fewer routine coding tasks through which to learn, even though they’ll still need to understand databases, networks, failure modes, and how a real system behaves. We will need more deliberate ways to teach that judgment.

I also expect some uncomfortable changes to hiring. If a small team can ship more with agents, companies may need fewer people whose main job is straightforward implementation. They may need more people who understand a domain deeply, can work across disciplines, know how to test uncertain systems, or can make hard decisions when the model’s answer is convincing but wrong.

I’m less confident about the exact job titles than I am about the underlying shift.

What I’d build a team around

At Renderbit, I don’t want us to optimise for the most code generated or the most agents running at once. Those are activity measures. They can go up while the quality of our work goes down.

I’d rather build around a smaller set of abilities: understand the client’s problem better than the prompt does; define what correct looks like; know when an agent’s work needs independent proof; design boundaries that protect users and data; and operate what we ship long after the generating session ends.

In my post on ownership, I argued that an engineer should own the solution, not just the code. Agentic development makes that distinction more important now. Over time, I think it will change what we mean by software engineer altogether.

My main prediction is simple: when generating code becomes abundant, the scarce resource will be the ability to decide what should exist, prove that it works, and earn the trust required to put it into use.

Writing code is one craft. Building useful, dependable software is another. I’m much more interested in the future of the second.