The future of software engineering: five bets from an agency owner

Nobody knows what this industry looks like in five years, and anyone who writes as if they do is selling something. What I can offer is reasoning. I run a software services business, I have to make hiring and pricing decisions now that only pay off later, and those decisions are bets whether I admit it or not.

So here are the bets, stated as bets. Each one has the mechanism I am relying on, what I am doing about it, and what would show me I was wrong. For what has already changed, start with is software engineering dead. This page is about what comes next.

The premise behind all five

One observation carries the rest. The cost of producing code has fallen sharply and will keep falling. The cost of knowing what to produce, fitting it into a real organization and answering for it has barely moved, because those costs come from missing information and from liability, and neither is a typing problem.

When one input to a business becomes nearly free, value moves to the inputs that stayed scarce. Every bet below is that sentence applied to a different part of a services firm.

Bet 1: fewer engineers per project, each with a wider scope

Confidence: high.

A project that needed a tech lead, four engineers and a QA person will be run by two or three people who each cover more ground. One engineer will take a feature from the client conversation through data model, implementation, tests and deployment, with the tool doing most of the typing at each stage.

The mechanism is coordination cost. Much of a six-person team’s time goes on handoffs: tickets, standups, explaining context, waiting for review. When one person with good tooling can hold the whole feature, those handoffs vanish. Small teams were always more efficient per head. They were limited by how much one person could physically produce. That limit has moved.

What I am doing: hiring for breadth. I ask candidates to scope a vague problem, then build part of it, then explain the trade-offs to a non-technical person. Narrow specialists in one framework are a harder hire to justify.

What would prove me wrong: if large generated codebases turn out to need more people to keep coherent than they saved to write, team sizes would hold. I see some signs of this on badly run projects. I think it is a discipline problem with a known fix, which is Bet 3.

Bet 2: pricing moves from hours to outcomes

Confidence: high on direction, moderate on speed.

Hourly billing ties revenue to effort. When effort per result drops every year, an hourly shop takes a pay cut every year for getting better. No owner tolerates that for long. Clients, for their part, have less and less reason to care about hours when they cannot judge what an hour produces any more.

A worked example of why the shift pays. A shop sells a data integration as a fixed outcome for $48,000. Today it takes 300 hours, an effective $160 an hour. Two years on, with better tooling and a reusable approach, it takes 200 hours. At the same price the effective rate is $240. On hourly billing at $160, the same job would have brought in $32,000.

Expect three models to carry most of the revenue: fixed-price projects with tight scope, retainers priced on capacity and service level, and productized offers with a published price. I cover them in value-based pricing and productized services.

The speed is uncertain because procurement departments like rate cards. Large buyers will keep asking for day rates long after it stops making sense. My answer is a higher rate with a clear explanation, and a fixed-price alternative on the same page of the proposal.

What would prove me wrong: if clients decide to capture the whole efficiency gain themselves and have the buying power to enforce it, margins compress and hourly survives as a commodity model. That will happen in the undifferentiated end of the market. It is a reason to leave that end.

Bet 3: review and architecture become the scarce capacity

Confidence: high.

Generating code takes seconds. Reading it carefully takes as long as it ever did. So the constraint on a team’s output moves from writing to reviewing, and from implementing a design to choosing the right one.

Architecture gains weight for a related reason. When code was expensive, a poor structural decision spread slowly, and you had time to notice. When code is cheap, a team can build a great deal on a bad foundation in a month. The cost of an early wrong call rises with the speed of everything built on top of it.

In practice I expect:

• Senior engineers spending most of their week on design, review and unblocking, with very little time writing code by hand.
• Review becoming a planned, budgeted activity with its own line in estimates, where it used to be squeezed in between tickets.
• Automated checks doing the first pass: tests, static analysis, a second model critiquing the first. Human review concentrates on intent, security and the boundaries between systems.
• Clients asking how review is done, and contracts starting to say so.

What I am doing: I estimate review separately and I protect it. When a deadline slips, review is the last thing I allow to be cut, because skipped review is where the expensive failures come from.

What would prove me wrong: tools that verify their own output reliably against real business intent. Verification against a written spec will improve a lot. Verification against what the client actually meant depends on information that is rarely written down, so I expect a person to hold that job for a long time.

Bet 4: maintaining generated code becomes a major line of work

Confidence: moderate to high.

A very large amount of software is being written quickly, much of it by people who could not have written it by hand and cannot maintain it: founders, operations staff, analysts, small internal teams. It works well enough to become important. Then it needs a security review, a second developer, a database migration or an integration, and nobody understands how it is put together.

Every earlier wave of cheap software creation produced the same aftermath. Spreadsheets that ran departments. Desktop databases that ran companies. Low-code apps that outgrew their platform. Each time, professionals were eventually paid to stabilize and replace what had been built. This wave is larger because the output is real code in real languages, which makes it both more capable and more dangerous.

For a services firm this is a durable offer: assess, stabilize, document, add tests, take over maintenance on a monthly fee. It suits a retainer, and the mechanics are in retainer pricing. The scoping is delicate, since you are taking responsibility for code you did not write, and the contract has to say exactly what you are and are not answerable for.

What would prove me wrong: if regenerating a system from scratch becomes cheaper and safer than maintaining it, maintenance shrinks. For small tools that will be true. For anything holding years of business data and connected to other systems, replacement has always been riskier than it looks.

Bet 5: the junior pipeline breaks, then gets rebuilt differently

Confidence: moderate.

Shops and employers are hiring fewer juniors because the tasks that trained them are automated. That saves money now and creates a shortage of experienced engineers later. I expect a visible gap in the supply of capable mid-level people within this five-year window.

Firms that kept training will have an advantage that is hard to buy. The training itself will look different: closer to an apprenticeship, with juniors learning by reviewing, testing and sitting beside seniors on client work, and producing less billable output in their first year.

What I am doing: a small junior intake every year, budgeted as a training cost and priced into senior rates. It is the most speculative money I spend and I think it is correct.

What would prove me wrong: if the tools become good enough teachers that a motivated person reaches senior judgment far faster than before. That would be good news for everyone, and I would be glad to lose this bet.

What I am not betting on

I am not betting on fully autonomous software development replacing services firms within five years. The blocker is accountability and context, and I see no route by which a client’s undocumented business rules and legal liability get absorbed by a tool.

I am also not betting that things stay as they are. The owners I know who believe this is a passing phase are mostly the ones with the highest share of hourly revenue.

How the bets fit together

Put the five side by side and a shape appears. A services firm five years on has fewer people, each more senior and more expensive. It sells outcomes and capacity. Its delivery is limited by review and design. A meaningful share of its revenue comes from looking after code that others generated, and from helping clients put AI to work in their own operations, which I cover in the AI consulting business.

Such a firm earns more per head and has less margin for error. An idle senior costs more than an idle junior did. A scoping mistake on a fixed price costs more than an overrun on hourly. The commercial disciplines, scope control above all, matter more as the engineering gets cheaper. If yours are loose, scope creep is the place to start.

For the headcount arithmetic behind Bet 1, see will AI replace software engineers. The rest of the series is collected in the AI hub.

Each of these bets pays off even if I have the timing wrong. Better pricing, tighter scope, a more senior team and a maintenance book are good business in any market. That is how I choose bets: I want the ones I would be glad to have made anyway.