Article summary
When ChatGPT went mainstream, the narrative was clear: anyone can build an app now. Software engineering, as we know it, is over.
My Bias
I’ll be honest about my bias. I run a software consultancy with about 100 software engineers. I have skin in this game. But from my front-row seat, what I’ve watched is not what the narrative predicted. Everyone improved. But the technical people improved dramatically more.
Think of AI like a power tool. Hand a circular saw to someone with no experience, and they don’t make a small mistake. They cut off a finger. In software, that’s a security hole nobody notices, a misconfigured server, or a system that collapses under real traffic. Hand the same tool to a skilled carpenter, and they get the job done better and faster. The tool didn’t close the gap between novices and experts. It widened it.
Leaning Into AI
I’ve watched our engineers lean into AI, realize they could write code faster than they could review it, and then do what engineers do: they engineered a better process. They automated the review. They established patterns to capitalize on the speed. They didn’t just use the tool. They redesigned the workflow around it. That’s not something AI gives you. That’s a skill you bring to AI.
On paper, the data says software jobs should be first on the chopping block. Anthropic’s own research shows AI could theoretically automate 94% of tasks in computer and math occupations. That’s the highest of any field. But observed usage covers only 33 percent. The gap exists because, as the tools get more powerful, they get harder to use, not easier.
Will that gap close over time? To me, that’s not the interesting question. The interesting question is whether we’ll ever be able to make meaningful use of these tools without technical people. I don’t see it.
The Hard Part
Writing code was never the hard part of software engineering. The hard part is figuring out what to build, what to avoid building, and what’s at stake when you get it wrong. The worst outcome isn’t that nobody uses your software. It’s that someone does, and data gets lost, productivity halts, or sensitive information gets stolen.
In the long run, maybe AI displaces a significant number of workers. But great software engineers will be among the last to go. Not because they write the code, but because they understand the system.
In a technical revolution, I’m betting on technical people.
Hi Michael, as a fellow leader in a software consultancy, I’ve looked up to AO for wisdom for many years. I am wondering what’s your take on the impact AI is having on the FBSC model based on an hourly rate.
As delivery gets faster and producing the same value requires less hours and smaller teams, is this putting pressure on the business model? Are you foreseeing a change on what is valued and charged for with alternative project models?
We are looking at the potential upsides (and profits) of a FP contract, however all the downsides of that model persist. Do you have any thoughts on this?
Thanks in advance,
Alex
Great question, Alex. We’re working through this too, so I’ll share where my head is rather than pretend we have it figured out.
In our experience, budget was always the bottleneck, not ideas. Clients always had more they wanted to build than their budget allowed. That makes me think about the Jevons Paradox. When the cost of producing something drops, demand doesn’t just increase proportionally. It increases at a rate that more than offsets the efficiency gain. Coal got cheaper and we didn’t use less of it. We used dramatically more. I think software development follows the same pattern. As AI drives the cost of delivery down, we can help people who couldn’t afford us before. And we’ll do significantly more work for the same budget for larger clients. The pie gets bigger.
On fixed-price: I think there’s real opportunity today to do more FP projects, and we’re experimenting with some. There’s potential to make more profit on those projects. But that comes part and parcel with the risk. And I don’t think believing you can crush it with FP contracts is a sustainable long-term play. Eventually everyone that lasts will be fast. The speed advantage is temporary. Ironically, as a client in a time of this much change, I’d rather pay T&M.
FBSC still works in my opinion. What changes is how we estimate. We need to track at the level of higher-level features, not tasks. And one interesting shift: in the past, if you got way behind on scope or budget, your only options were increase the budget or cut scope. Now you have a third option. Push more of the design and implementation onto the AI and allow for less fine-tuning time. That’s a new lever that didn’t exist before.
Thanks for the thoughtful question. Happy to keep the conversation going.
Thank you Michael for the quick and thoughtful answer, I appreciate your insights!
It is refreshing to see an optimistic take from someone who is in the frontlines. I agree on the Jevons Paradox, and we are already seeing how we could potentially start servicing smaller clients, but we are already seeing some disadvantages:
– Utilization rate and profits have been best on larger, long-term engagements. Fragmenting the same billable hours into more projects has calendar and billing inefficiencies that impact our margins.
– The sales effort required tends to scale with the number of clients, regardless of size, so we are seeing more investment for the same return.
– When a client demands more speed we would’ve addressed this with an increased team size and enjoy the added revenue that that would entail. Nowadays with this third lever you mention, we have lost a few opportunities to upsell on projects.
I have strongly advocated for FBSC models with clients, but without any adjustments, it seems that the equation needs rebalancing. On the expense side, besides my previous points, we are also facing added costs per seat in terms of tooling and tokens (with a model based solely on hours, sometimes it feels like we are spending more to be paid less!)
On the income side, without changing the model, it seems like the only lever left to compensate for this is increasing the hourly rate.
Hopefully this is not too much of a pessimistic take. I would love to have your thoughts on the resiliency of the model given these issues and how changing the way estimations are done could have a positive impact. I’m unsure if the only real solution is to increase our rates.
Happy to keep the conversation going as well, thanks!
Alex
Alex, really good follow-up. And to be clear, the squeeze you’re describing is real. These aren’t theoretical concerns; they’re the actual margin pressures that show up when delivery gets faster but the business model hasn’t caught up yet. So let me try to take these one at a time.
Based on what you’re describing, I don’t think you’re seeing a problem with FBSC. I think you’re seeing a segmentation problem. Your existing clients are getting the same outcomes in fewer hours, which compresses revenue on work you already know how to win and deliver. And newer, smaller clients that AI makes it possible to serve are carrying more overhead per dollar. If this is true, those are two different cost structures, and they probably need different rates.
On the upsell concern. In my experience, most clients who care deeply about their product aren’t using AI to compress the timeline and walk away with the same thing cheaper. They’re using the headroom to do more. More refinement, more edge cases handled, more ambition in what they ask for. The clients you’re losing upsells on may not be your best clients.
On the rate question. If your team is delivering more value within the same budget, that’s your case for expanding the budget over time, not just raising the rate. The conversation with the client becomes “look what we accomplished this cycle, let’s be more ambitious next cycle.” That’s a different lever than a rate increase, and it’s one clients are more likely to say yes to.
Great conversation. Appreciate you pushing on this.
Thank you, Michael!
After many years of relative stability in our business model and ways of working, these recent developments have been, to say the least, very interesting. They have brought both significant challenges and new opportunities, and we expect this dynamic to continue for some time.
With things changing so rapidly, it has been difficult to define long-term, viable adjustments to a model that has historically worked well. Looking to companies we admire, like AO, for guidance has been incredibly valuable. Greatnotbig and Spin have consistently been excellent sources of insight, and I truly appreciate how openly you have shared your thinking and experiences over the years.
I always look forward to any insights you share in the future, and I would be glad to exchange perspectives as we navigate this path ourselves.
Best,
Alex