What AI does to a services business, from someone running one

In fifteen years of running a software services business I have been told the business was finished by offshore outsourcing, by no-code tools, by website builders and by clients hiring in-house. Each of those took a slice of work away and left the rest worth more. AI coding tools are a bigger change than any of them. I take it seriously, and this hub is my working out of what it does to a shop like mine.

I am writing from the owner’s chair. I have no stake in the tools being wonderful or terrible. I have payroll, a pipeline and a pricing model, and I need to know what happens to each.

The one change everything follows from

The cost of producing code has collapsed. The cost of everything around the code has stayed where it was.

A capable engineer with an AI assistant turns a clear description into working code in a fraction of the old time. That part is real and it keeps improving. What the tools do not do is find out what the client actually needs, fit new software into fifteen years of existing systems, or pick up the phone when production fails on a Saturday. Those jobs depend on information nobody wrote down and on accountability that needs a name.

So the question “is software engineering dead” has a clear answer from where I sit. The profession is fine. The business model of selling routine implementation by the hour is failing, and a lot of agencies are built on it. That page is the long version of the argument, and the place to start if you read only one.

What it does to the money

Hourly billing ties revenue to effort. When the effort per result falls, an hourly shop earns less for doing the same job better. A project that took 400 hours and now takes 260 pays $21,000 less at $150 an hour, for the identical deliverable. The client keeps the whole gain.

That single mechanism is why pricing is the first thing to fix. The work of moving to outcome fees, retainers and packaged offers belongs to the Bill hub, and it depends on scope documents that hold, which is the subject of the Scope hub. I mention them here because owners tend to respond to AI by buying tools and training engineers. Both are useful. Neither helps if the pricing model hands every improvement to the client.

What it does to the team

A job is a bundle of tasks, and the tools take some tasks and leave others. I go through the list one by one in will AI replace software engineers, then do the headcount arithmetic for a 20-person shop. The short result: fewer engineers per project, a more senior mix, and review as the new bottleneck. Whether that means lost revenue or better margin depends on pricing again.

The hard part is the junior end. The tasks that trained new engineers are the tasks the tools do best, so the bottom rung of the ladder has narrowed across the industry. That shows up as hiring freezes more than as dramatic cuts. Where cuts do happen, the causes are mixed, and I have tried to separate AI from interest rates and plain over-hiring in software engineer layoffs. That page is written for two readers: the owner deciding what the cuts mean for talent and client budgets, and the engineer who was cut and is deciding what to do next. The people side of running a shop through this is in the Team hub.

Where it is heading

I do not trust forecasts, including my own. I still have to make decisions now that pay off in three to five years, so I have written down the bets I am making and what would prove each one wrong. They are in the future of software engineering: smaller teams of broader engineers, pricing by outcome, review and architecture as the scarce capacity, and a large new line of work maintaining code that was generated quickly by people who cannot look after it.

I chose those bets because each one is good business even if my timing is off.

The work that is growing

Every mid-sized company has been told to do something with AI, and very few have the people to do it. That is a services opportunity, and software firms are well placed for it, since most of the work is integration, data handling and testing.

It only pays if you sell it as a concrete offer. The AI consulting business sets out the four that sell: a fixed-fee audit, a pilot with a pass mark, an implementation retainer and a fractional AI officer, each with the price built up from hours and risk. If you are an individual engineer, or an owner starting this line from nothing, how to become an AI consultant covers the first three engagements, how to show proof before you have a portfolio, and what the contract has to say.

The delivery role itself gets its own page. What an AI implementation consultant does describes a good engagement stage by stage, shows how day rates are built, and gives buyers seven questions that separate people who have delivered from people who have read about it. It also covers when an agency should partner for this work before hiring for it.

The asset in the archive

There is one consequence of all this that runs in the owner’s favor and that most have not noticed. As code generation spreads, original code written by people, in private, with a real history behind it, has become scarce. AI labs need it for training and for testing. Agencies have years of it in repositories they wrote off long ago.

What your old code is worth explains why, what makes one repository more valuable than another, and why you should leave the commit history alone. It also explains the limit: this applies only to code you own. Whether you own it was decided by the IP clause in a contract you may not have read since you signed it, which is one more reason to spend time in the Contracts hub.

How to use these pages

If you own a shop, read the pillar, then the headcount page, then the consulting business page. That order takes you from the problem, to its size in your own numbers, to a new line of revenue.

If you are an engineer, read the pillar, then the layoffs page if it applies, then the consultant pages.

Everything here is argued from how a services business makes money. You will find worked examples with the arithmetic shown, and no survey figures, because the published numbers on this subject are mostly guesses that age badly. The mechanisms hold up better.

My overall position is plain. The work is still there, and the part of it that remains is harder and better paid. The owners in trouble are the ones still charging for the part that became cheap.