Is software engineering dead? An agency owner's honest answer

No. Software engineering is alive, and more software is being written now than at any point in my career. What is dying is a specific way of making money from it: selling undifferentiated implementation by the hour. If that sentence describes most of your revenue, or most of your working day, your unease is well placed and this page is for you.

I run a software agency. I have run it for fifteen years, through the offshore price wars, the no-code wave and two recessions. From this chair the question stops being philosophical. I have payroll to make, hiring decisions to take and proposals to price next week. This is what I see, and what I am doing about it.

The short answer

Three things are true at the same time.

1. Producing code got far cheaper. A competent engineer with an AI coding assistant gets working code for a well-described task in a fraction of the time it took by hand.
2. Everything around the code costs what it always did: working out what to build, fitting it into the systems and the organization that already exist, and being accountable when it breaks.
3. Most of the industry’s pricing, hiring and career ladders were built on the assumption that the first item was the expensive part.

The profession survives. Those assumptions are finished. The rest of this page works through what that means for billing, hiring, pricing and careers.

What actually changed

For most of the history of this trade, the bottleneck was translation. An engineer knew roughly what the software should do and spent most of the day turning that intention into syntax that compiled, passed tests and matched the conventions of the codebase. Skill showed up as speed and accuracy at translation. We hired for it, we billed for it, and we built seniority ladders around it.

That translation step is now cheap. Describe a function, a migration, a test suite or an admin screen clearly, and a model produces a plausible version in seconds. Often it is right. When it is wrong, it is wrong in ways an experienced engineer catches quickly and an inexperienced one misses entirely. Hold on to that second sentence. Most of what follows depends on it.

The second-order effects matter as much as the first:

• Prototypes are nearly free. A client with no engineering background can produce a clickable, half-working version of their idea in a weekend. They arrive at the first meeting with it.
• Unfamiliar stacks are less of a barrier. An engineer who knows one language well can be productive in another much sooner, because the tool handles the syntax while the engineer handles the reasoning.
• Boilerplate stopped being a line item. Scaffolding, glue code, simple CRUD and first-draft tests used to fill real hours on an invoice. They now fill minutes.
• The volume of code went up. Cheap code means more code. Every line still has to be read, understood, secured and maintained by someone.

That last point is the one optimists and pessimists both skip. Code is a liability as much as an asset. Making it cheaper to produce does nothing to make it cheaper to own.

What did not change

Deciding what to build

A client rarely knows what they need. They know what hurts. Turning “our ops team spends two days a month reconciling orders” into a system that fixes the problem takes interviews, reading ugly spreadsheets, noticing the exception nobody mentioned, and telling the client that half of what they asked for should be dropped. A model can help draft the spec. It cannot sit in the room, read the politics, or take responsibility for the call.

This work was always the most valuable part of a project. We just hid it inside the hourly rate and gave it away during sales.

Integrating it

New software has to live with old software. It has to authenticate against the client’s identity system, write to an accounting package with a strange API, survive the nightly batch job nobody documented, and comply with whatever the client’s security team decided last year. Generated code is written against the world as described in the prompt. Production is the world as it actually is. The gap between the two is where most project hours now go.

Owning the outcome

When the system double-charges four hundred customers on a Saturday, somebody’s phone rings. That person needs to understand the system well enough to fix it, have the authority to make the call, and carry the commercial consequences. Accountability does not automate. Clients pay for the name on the contract and the person who picks up. That is why the paperwork matters more as code gets cheaper, and why I would read through the contracts hub before taking on work where generated code plays a large part.

What this does to billing by the hour

Here is the arithmetic that keeps hourly shops awake.

Take a customer portal with invoicing. Two years of estimates say 400 hours. At $150 an hour, that is a $60,000 project. Now the same team uses AI assistance properly and delivers the same portal in 260 hours.

Billed by the hour, the shop got better at its job and was paid $21,000 less for the same result. Every dollar of the productivity gain went to the client. The shop now has 140 free hours it has to resell just to stand still, in a market where every competitor has the same free hours.

Billed at a fixed price for the outcome, the shop earns an effective $231 an hour ($60,000 divided by 260) and keeps the gain it created by investing in tools and training.

Hourly billing was always a deal in which the client carried the risk of overruns and the agency gave up the reward for efficiency. That trade made sense when efficiency improved slowly. It makes no sense when the tools improve every few months. How to price when your team is getting faster, and what to say to the client who asks for the AI discount, is in agency pricing after AI. The mechanics are in billable hours, and the alternative in value-based pricing. The Bill hub covers the full set of models and where each one breaks.

One warning. Moving to fixed price moves the overrun risk onto you. You only keep the gain if your scoping and change control are tight. Shops that switch pricing models without fixing their scope documents trade one way of losing money for another.

What it does to project pricing

Clients have read the same headlines you have. They now open negotiations with “surely this is faster with AI”. Sometimes they are right. The honest answer has three parts.

First, the implementation portion of a typical project is smaller than clients think. On a well-run build, writing the code was perhaps half the hours. Discovery, design, integration, testing against real data, deployment, security review and handover made up the rest. A large saving on half the project is a moderate saving on the whole.

Second, the saving is uneven. Greenfield work on a common stack speeds up a lot. Work inside a fifteen-year-old system with no tests and undocumented business rules speeds up very little, because the constraint was always understanding, and understanding is still slow.

Third, the price should follow the value of the result and the risk you carry. A client who pays $60,000 for a portal that saves them $300,000 a year has a good deal at $60,000 whether it took you 400 hours or 260.

What I do in practice: I price the outcome, I show the client a scope with clear boundaries, and I offer the efficiency back as more scope or a faster date, which clients usually value more than a discount. When a client insists on hourly, I raise the rate to reflect the output per hour, and I say so plainly.

What it does to junior hiring

This is the part that worries me most, as an owner and as someone who learned the trade from the bottom.

The classic agency was a pyramid. A few seniors made decisions. A wide base of juniors did the routine implementation, billed at a lower rate, and learned by doing. The margin on juniors paid for the bench, and the best of them became the next seniors.

The economics of that base have broken. Say a junior costs $95,000 a year fully loaded and bills 1,400 hours at $90, bringing in $126,000. The work that filled those 1,400 hours was scaffolding, simple features, bug fixes and tests. A senior with good tooling now produces that work as a by-product of their own. Clients have noticed, and they push back on paying $90 an hour for a person to do it.

So shops hire fewer juniors. That is rational for each shop and bad for the trade, because seniors are made from juniors. In ten years somebody has to be the person who can look at generated code and know it is wrong.

My position: keep hiring juniors, in smaller numbers, and change the job. A junior in my shop now spends more time reading and verifying than typing. They review generated code against the spec, write the test cases a model would not think of, reproduce bugs, and sit in on client calls far earlier than they used to. They are less billable in year one and more useful by year three. I treat the gap as a training cost and I price it into the senior rates. The Team hub covers the staffing side, including bench management when utilization drops faster than headcount.

What clients ask for now

The enquiries in my inbox have shifted in four ways.

Rescue work. A founder or an internal team built something with AI tools. It demos well. It falls over with real users, real data or a security questionnaire. They need someone to make it production-grade, and they are surprised the last 20% costs more than the first 80%.

AI inside the product or the process. Clients want document processing, support triage, internal search or workflow automation built on language models. This is real engineering with unfamiliar failure modes, and most clients have nobody who can run it. It is a growing line of work for services firms, which I cover in the AI consulting business and, from the practitioner’s side, in what an AI implementation consultant does.

Smaller teams, bigger briefs. Clients who once wanted six people for a year now want three for six months and expect the same result. They are often right to.

Proof of accountability. Procurement asks how generated code is reviewed, who owns the IP in it, and what happens when it fails. Clean answers win deals.

What is dying, and what is growing

The left column has one thing in common. In every row, the seller’s contribution could be described fully in a prompt. If your offer can be written down as a complete instruction, a tool will fulfil it and the price will fall toward the cost of the tool.

The right column also has one thing in common. Every row involves judgment under uncertainty, with a name attached.

What an agency owner should do

In order, because the order matters.

1. Find out how exposed you are. Split last year’s revenue into three piles: hourly implementation, fixed-price or outcome work, and advisory or ownership work such as architecture, discovery and maintenance with a service level. If the first pile is more than half, you have a pricing problem that will show up as a revenue problem.
2. Stop passing the whole gain to clients. Move new work to fixed price or to retainers priced on capacity and outcome. Where you must stay hourly, raise the rate. The pages on value-based pricing and retainer pricing have the mechanics.
3. Tighten scope before you fix prices. Fixed price without change control is a donation. Get your statement of work and change request process in order first.
4. Sell discovery separately. The thinking you used to give away in sales is now the scarcest thing you have. Put a price on it.
5. Reshape the team slowly. Fewer, broader engineers. Juniors hired for judgment and trained on review. Do the headcount maths before the market does it for you. I walk through it for a 20-person shop in will AI replace software engineers.
6. Pick one AI offer and sell it properly. An audit, a pilot, or an implementation retainer. One offer with a price and a scope beats “AI” on the homepage.
7. Check what you already own. Years of finished repositories sit in most agencies as a written-off cost. Some of that code has become an asset. See what your old code is worth.

If you do only one of these, do the second. A shop with average engineers and sound pricing will outlast a shop with brilliant engineers on hourly billing.

What an individual engineer should do

I hire engineers, so take this as a description of what I now pay for.

Get very good at reading code. Review is the new bottleneck. The engineer who can read 800 lines of generated code and find the one wrong assumption is worth more than the one who can write 800 lines by hand.

Move toward the problem. Learn a domain: logistics, healthcare billing, insurance, payments. An engineer who understands how a claims process works can tell when a spec is wrong. That skill does not come from a model.

Own something in production. Carry the pager. Run a migration. Handle an incident. Accountability is what clients and employers pay a premium for, and you only learn it by holding it.

Use the tools seriously. Refusing them out of pride is a career-limiting choice. Using them without checking the output is a worse one. The valuable habit is fast generation followed by sceptical verification.

Learn the commercial side. Know what your work costs and what it earns. Engineers who can scope, estimate and talk to a client about trade-offs are the ones I keep when the team gets smaller.

If you have been laid off, or you can see it coming, the honest version of what is happening and what to do next is in software engineer layoffs. If you are thinking of going independent, start with how to become an AI consultant.

Where I could be wrong

Everything above rests on one observation: the tools are excellent at producing code and weak at knowing whether it is the right code for a messy real situation. If that gap closes, and models become reliable at scoping, integrating and verifying their own work inside real organizations, then more of the right-hand column moves to the left.

I do not expect that soon, for a plain reason. The hard part of those tasks is information that never makes it into a prompt: the undocumented rule, the client’s real priority, the thing the last vendor broke. Getting that information takes trust and presence. And somebody still has to sign the contract and carry the liability.

I would still plan for the tools to keep improving. The safe direction is the same either way: move your revenue, and your skills, toward the parts of the job that need a person with a name. My reasoning about the next several years, labelled as bets, is in the future of software engineering. The rest of the AI hub covers each piece in more detail.

Software engineering is changing shape faster than at any time I have seen. The work that remains is harder, better paid per hour and more interesting. The businesses that keep charging for the part that became cheap are the ones in trouble.