I've noticed that every conversation about bringing AI into an engineering team carries an undertow of quiet anxiety. Not always voiced, but it's there. People want to know whether they're about to be made redundant by the very tools their company is now enthusiastic about.
That fear isn't irrational. Companies announce workforce reductions and AI investment in the same breath, sometimes in the very same press release. Whether AI actually caused those cuts or simply provided convenient cover for decisions that were already made is a separate question. The optics alone are enough to make any reasonable person nervous.
So let me address this directly, not as a talking point, but as a working position I feel strongly about: the right way to bring AI into a software team is to make the people on that team more capable, not to count how many of them you can remove.
Picture a developer who has spent three years on a particular product. She knows why the payment flow was built the way it was. She remembers the client call where a specific edge case came up, the workaround that got shipped on a Friday, the undocumented dependency that nobody has touched since. That knowledge lives in her head. It doesn't live in the codebase, and it certainly doesn't live in any AI tool.
I've always believed that a good developer reasons like a good detective. She looks at a piece of code and reads the decisions behind it, not just the syntax in front of her. The codebase is almost like a fossil record of choices, constraints, compromises, and priorities that were alive at a specific moment in time. AI tools trained on generalised data don't carry any of that. A model can tell you a hundred sensible ways to structure a payment flow. It cannot tell you why your particular client's payment flow was built the way it was, or what breaks downstream if you touch it.
This is where the replacement model actually fails, in my view. When you let experienced people go in favour of AI tooling, you don't just lose capacity. You lose the institutional memory that makes the codebase interpretable, and that loss tends to show up later, quietly, expensively, and at the worst possible moment.
The distinction between augmentation and replacement isn't philosophical. It's practical, and teams can feel which one they're living inside within about a fortnight.
In the replacement model, AI is brought in to reduce the number of people you need. Roles get consolidated. Timelines get compressed based on what the tooling promises rather than what the team can actually deliver. The engineers who remain are stretched across more responsibilities, and the tacit knowledge that used to live in conversations starts to disappear because there are fewer people having them.
In the augmentation model, the same AI tooling handles the parts of the job that were never the interesting parts to begin with. Boilerplate generation. Repetitive pattern matching. First-pass documentation. A developer who was spending forty minutes of her morning on scaffolding she could write in her sleep now doesn't have to. She gets that time back for the work that actually requires her, the reasoning, the judgement calls, the conversations with the product team about what a feature is really supposed to do.
That's not a small thing. It's the difference between a team that's burning out and a team that's engaged. And in my experience, engaged teams build better software.
When we talk about building custom software for businesses, the team question matters because it shapes every other decision. Here's how I'd frame the key principles:
The team is the product, not just a means to it. A codebase is only as good as the people who can read, extend, and reason about it. If you build something clever but then lose the people who understand it, what you have is a liability dressed up as an asset.
Speed comes from clarity, not from cutting people. One of the most common frustrations I hear from founders is that they can't figure out how many developers they actually need, or how long a first version will genuinely take. The honest answer is that those timelines get shorter when the team has good tooling and clear scope, not when the team is smaller.
Maintenance should never be a surprise. I hear often from founders who spent months and significant money on custom software only to face unexpected fees afterwards that weren't in any contract. A team that understands what it built, and that has been supported with the right tools throughout, is far less likely to produce that outcome. The knowledge stays in the room.
AI agents should do work your team designs, not replace the design process. There's a version of this where AI agents handle repeatable, well-defined tasks inside a workflow your team has thought through carefully. That's genuinely useful. There's another version where AI is handed ambiguous problems and the humans are removed from the loop. That one tends to produce confident-sounding nonsense, and it tends to produce it at scale.
Here is my opinion: a business that approaches AI adoption by asking "how do we make our team better at their jobs" will, over time, outperform one that approaches it by asking "how many people can we replace." The first approach builds something that compounds. The second one creates fragility that hides well until it doesn't.
I'm more convinced than ever that depth beats breadth. A smaller team that genuinely understands what it's building, that has the right tooling, the right support, and the institutional knowledge to make good decisions, will beat a larger, thinner team every time. AI makes depth more achievable, not less necessary.
I know which side of that I want to be building on.
TL;DR
