Will AI replace software engineers completely?

No. AI tools take over a large share of the typing and a small share of the deciding. Somebody still has to define the problem, check the output, fit it into existing systems and answer for failures. The number of engineers needed per project falls, while the amount of software the world wants keeps rising.

Which software engineering tasks are most exposed to AI?

Tasks that can be fully described in a prompt and checked quickly: scaffolding, CRUD screens, simple migrations, first-draft unit tests, documentation and translation between languages. Tasks that depend on context nobody wrote down, such as legacy integration, production debugging and requirements work, are the least exposed.

Should a small agency cut engineers because of AI?

Usually the first move is to fix pricing and stop backfilling, long before layoffs. If you bill by the hour, faster delivery cuts your revenue, so reprice first. Then let attrition and a hiring pause reshape the team. Cut only if the pipeline cannot absorb the freed capacity within a couple of quarters.

Are senior engineers safe from AI?

Seniors whose value is judgment, system design and client trust are in a strong position. Seniors whose seniority is mostly years of typing in one framework are less safe than their title suggests. The dividing line is whether you decide what gets built or only build what you are told.

Will AI replace software engineers? A task-by-task answer

The question gets asked as if a job were one thing. A job is a bundle of tasks that happened to be convenient to give to one person. AI tools do some of those tasks very well, some badly, and some they cannot attempt. So the useful answer goes task by task, then adds up what is left.

I run an agency and I have had to do this sum for real, with names attached. This page shows the working. The broader argument about the business model is in the pillar, is software engineering dead.

The test for whether a task goes

A task moves to the tool when two things are true:

It can be described completely in writing, with no context the writer forgot.
The result can be checked quickly by someone who knows what correct looks like.

Scaffolding a service passes both tests. Deciding whether the client needs that service at all fails the first. Fixing a race condition that appears only under production load fails both.

Everything below follows from that test.

Which tasks go, which stay

Task	What happens to it	Why
Boilerplate, scaffolding, CRUD screens	Mostly goes	Fully describable, quick to check
First-draft unit tests for existing behavior	Mostly goes	The behavior is already defined by the code
Translating code between languages or frameworks	Mostly goes	Clear input, clear output. Verification stays human
Documentation and code comments	Mostly goes	Low cost when slightly wrong, easy to review
Simple, reproducible bug fixes	Speeds up a lot	The tool reads the stack trace faster than you do
Features in a well-tested, conventional codebase	Speeds up a lot	Conventions and tests give the tool rails
Features in an old system with no tests	Speeds up a little	The constraint is understanding the system
Deciding what to test and what could go wrong	Stays	Requires imagining failures nobody described
Requirements and scoping conversations	Stays	The information lives in people’s heads
Architecture and data modelling	Stays, grows in weight	Cheap code makes structural mistakes spread faster
Code review	Grows	More code is produced, and somebody must vouch for it
Integration with client systems	Stays	Production differs from the description of production
Production incidents across several systems	Stays	Missing context, time pressure, real consequences
Security and compliance sign-off	Stays	Liability needs a named person
Estimating and pricing work	Stays, gets harder	Old estimates no longer predict hours
Client communication and trust	Stays	Clients buy from people who answer the phone

Two patterns stand out.

The tasks that go are concentrated at the junior end of the old ladder. The tasks that stay are the ones we used to call “senior” and often failed to bill for properly.

And review grows. This one surprises people. If a team produces three times the code, somebody has to read three times the code, or the shop ships work nobody understands. Reading is slower than generating. In my shop review time is now the constraint that sets delivery dates.

The verification problem

Generated code fails in a particular way. It looks finished. It follows the conventions, has tidy names and passes the tests the same model wrote for it. The error, when there is one, is a wrong assumption: about a null value, a time zone, a permissions rule, a retry that charges a card twice.

An experienced engineer finds these because they have been burned by each one before. An inexperienced one approves the pull request because it looks like good code. That is the whole reason seniority still commands a premium, and the reason “one junior with an AI tool replaces a senior” does not work in practice. The tool raises everyone’s output. It raises the cost of bad judgment as well, because mistakes ship faster.

What this means for headcount at a 20-person shop

Here is a worked example. The numbers are illustrative. Use your own.

A 20-person agency has 14 engineers: 3 senior, 6 mid-level and 5 junior. The other six are two project managers, a designer, a QA lead, and two people in sales and operations including the owner. Each engineer bills 1,400 hours a year at a blended $140 an hour.

Billable hours: 14 x 1,400 = 19,600
Revenue: 19,600 x $140 = $2,744,000

Now assume half of those hours were implementation tasks from the top rows of the table, and that with good tooling those tasks take 40% less time. Half the hours shrinking by 40% means the same body of work now needs 20% fewer hours.

Hours needed for the same work: 19,600 x 0.8 = 15,680
Hours freed: 3,920, which is 2.8 engineers at 1,400 hours each

What happens next depends entirely on how the shop gets paid.

Response	Revenue	Engineers needed	What it takes
Do nothing, bill hourly	$2,195,200	11.2	Nothing. You lose $548,800 a year
Sell 25% more work at the same rate	$2,744,000	14	A pipeline a quarter larger, in a market where rivals have spare capacity too
Reprice to fixed or outcome fees	$2,744,000	11.2	Tight scoping and a decision about 2.8 engineers
Reprice and sell more	Above $2,744,000	14	Both of the above. The only version where the shop grows

The first row is where a shop ends up by default. Faster delivery on billable hours is a pay cut you gave yourself. The fix is pricing, which I cover in value-based pricing.

The third row is the honest middle case. Revenue holds, and roughly three engineers’ worth of capacity is spare. In a 14-engineer team that rarely needs a layoff. Normal attrition and a pause on backfilling get you there within a year or so. If the pipeline is weak as well, the timeline shortens, and you should read how to lay off employees before you need it. Doing it late and badly costs more than doing it early and well.

The mix changes more than the total

Even where total headcount holds, the shape of the team moves. The old 3-6-5 team was built to push implementation down to the cheapest capable person. The team I would build for the same revenue now looks closer to 5 senior, 5 mid-level and 2 junior.

That team has a higher salary bill per head and a lower total. It also has a higher output per person, which only becomes margin if the pricing captures it.

Three practical consequences:

Mid-level engineers are the ones to watch. A mid-level engineer who is growing toward ownership, taking client calls and reviewing well is a future senior. One whose value is fast, accurate implementation of tickets is doing the task most exposed to the tool. Have the conversation with them early and give them a path.

Juniors need a redesigned job. Fewer of them, hired for curiosity and care, trained on review and testing. You are paying for a senior in four years. If nobody trains juniors, the supply of people who can verify generated code dries up, and that hurts every shop.

The bench gets more expensive. A smaller, more senior team means each idle person costs more. Utilization planning matters more than it did. The mechanics are in bench management.

What does not shrink

Project managers, designers and QA do not disappear in proportion. If anything, QA and product thinking gain weight, because the volume of shipped code rises and the question “is this the right thing” gets asked more often per week.

Sales capacity needs to grow. Shorter projects mean more projects per year for the same revenue, and each one has to be won, scoped and contracted. A shop that halves its delivery time and keeps the same sales effort runs out of work.

For an individual engineer

Look at your last month and sort your hours using the table. If most of them sit in the top six rows, your job is exposed even if your employer has not noticed yet. Move toward the bottom rows on purpose: ask to run a discovery, own a service in production, take the hard reviews, learn the client’s domain.

If your employer is cutting, the steady version of what is happening is in software engineer layoffs. My longer-range reasoning sits in the future of software engineering, and the full set of pages on this topic is in the AI hub.

A specific list of tasks is being automated, and both the job and the team are being rebuilt around what remains. Shops that do this deliberately keep their people and their margin. Shops that wait have it done to them by their clients’ procurement departments.