Coding was never the bottleneck in building software. Even before AI.
So the idea that AI eliminates it and everything speeds up equally isn't quite what happens.
Traditionally, coding was only about twenty-five to thirty-five percent of the time it takes to build something - and that share is usually smaller once you’re past initial MVP and inside a production system.
The rest lived in architecture, requirements, review, QA, and implementation. If you take coding all the way down to zero, you're only saving that thirty-five percent at most and in the beginning only.
I did a big analysis on this for a client last week and the pattern held. AI makes you more efficient, and you can genuinely do more in less time - I talk about it all the time - and it’s only getting better.
But it hasn't replaced anyone. It's just moved where the effort goes.
What actually happens is that time shifts. Review wasn't taking that long before, but now it has to. You have to scrutinize everything much more closely, and architecture ends up taking more time, not less.
Skip the planning and the architecture to chase speed, and you're amplifying chaos instead of removing it. That plays out fine on a small personal project.
On an enterprise system a lot of people depend on, it gets hard to unwind.
The most surprising thing about AI in client conversations is the expectation that complex work should now happen almost instantly.
I have that same expectation half the time, and I have to ground myself back in reality. AI throws ten thousand pieces of information at me that I have to analyze, and I have to figure out what's completely wrong because it made a thousand assumptions I told it not to make.
I always think of Jurassic Park. They're reconstructing DNA, but they don't have enough, so they fill the gaps with something like frog DNA to complete the chain. AI does something similar. It gives you answers in a very confident manner, and where it can't fill the gaps, it just makes something up.
For most complex systems, AI is an amplifier. A little bit of chaos in the process gets amplified right along with everything else.
Clients tell us to use AI and get it done tomorrow. What happens instead is that my time shifts from creation to review and correction, and that takes just as long sometimes.
If you're taking AI's first response, it’s safe to say that most of the time, you're probably not using it well enough.
A lot of AI projects start with the wrong question.
People ask: Where can we use AI?
The better question is…Where is work harder than it needs to be?
If you’re a CTO, look for manual processes, repeated emails, people copying data between systems, chasing information, or waiting on reviews.
This is where AI can help remove friction.
Forcing AI into everything just to say you’re using AI tends to create noise and sometimes amplify bad patterns.
The AI news cycle is exhausting. And I think it's making leaders worse at making decisions.
It's just headline after headline. Did you see this? It can do this, it can do that. Terminators by tomorrow. And after a while it becomes genuinely anxiety-inducing, which is the opposite of useful when you're trying to make grounded decisions for your business.
My approach is to keep two separate feeds.
One for the moonshot hype, one for the grounded takes.
You need both, quite honestly, because the hype tells you what people are excited about and the grounded view tells you what's actually worth paying attention to.
What I've found is that if something shows up every single day for two months straight, there's probably some truth to it. But if it's a one-week headline, let it go. Come back to it.
The job of a leader is to live in the present while planning three years out. And you can't do that if every new model announcement sends you back to the drawing board.
A CFO building a business case around AI tools needs signals that are current, and the discipline to read them without letting every new announcement send you back to the drawing board.
Those two things are easy to confuse right now.
AI creativity is one of the most misunderstood parts of this technology.
Once someone explains the mechanics behind it, you can't see it the same way again.
Ask a model to finish the sentence "the sky is" and there are a thousand options sitting in its training data. What determines the answer coming back has far less to do with imagination than people assume.
Understanding how that selection works changes how you read every creative output these systems produce, and it's simpler than the marketing suggests.
Run the same automation a thousand times, and you get the same answer a thousand times over.
Run AI a thousand times, and you might get seven hundred and fifty different answers.
Deterministic is black and white automation. Probabilistic is how AI runs, and that's a feature of it working properly. The mistake people fall into is reaching for AI on problems that need the same result every single time.
From a governance standpoint, understanding the technology well enough to control that is where a lot of teams come unstuck.
Companies will spend years tolerating disconnected systems, then try to implement AI and realize they can't automate what's fundamentally broken.
The gaps were always there… AI just makes them impossible to ignore.
I think a lot of organizations operate in a state where things technically function only because people learned how to compensate over time.
And this isn’t something intentional. People just figure out how to get the work done and keep moving.
Not everything looks broken at first glance.
Work still moves through. Customers still get what they need. Reports still show up when expected.
From the outside, everything feels fine enough, so the friction never really gets named.
What I see most often is people tolerating small inefficiencies because they’ve become familiar with them.
Extra steps get absorbed into the day. Checks happen out of habit. Workarounds turn into routine.
After a while, no one remembers that it wasn’t always supposed to feel this way.
The reality is that those quiet gaps don’t stay harmless forever. They will sit there and hold until something like volume increases or timelines tighten. Then pressure shows up, and it feels sudden even though it’s been building for a long time.
When I’m trying to understand how an operation really works, I usually come back to one simple question:
What workarounds have become so normal that no one questions them anymore?
Those tolerated frustrations tend to point to the places that have been waiting for attention longer than anyone realized.
Nobody has ever asked me to fire their whole team and replace them with AI.
Though expectations sometimes get high enough that we have to bring them back down to reality.
Autonomously it can handle very repetitive things well. Decision-making is where you still want a human in the loop. Architecture matters more now than it ever has, and there's all sorts of governance you've got to put on top of any AI solution.
Any CTO scoping this out needs to understand its strengths, its weaknesses, and how it should be used.
The best version of a business often shows up when pressure forces sharper choices and faster execution.
Acquisitions create that pressure whether you’re ready or not.
Things can run well for a long time, and that’s usually the goal. You’re executing, hitting targets, and the business is moving the way it should.
Then an acquisition happens, and everything gets tested.
The strategy may be right, but now you have new systems, new expectations, new people, and new problems to solve.
What I’ve seen is that this kind of challenge forces a different level of thinking.
You start operating sharper.
You make decisions faster.
You pay closer attention to how things actually work.
I don’t know if you ever really look for disruption, but when the right kind shows up, it tends to bring out a better version of how you operate.
And I think that’s where a lot of growth actually comes from.
Hiring more underwriters isn't a scaling strategy. It's a cost strategy.
Real scale comes from codifying the decision, not the person making it.
Build the model. Document the framework.
Then your best underwriter's judgment lives in the process, not just in their head.
That's how you go from 50 decisions a month to 500 without doubling headcount.
There's a lot of conversation right now about AI replacing jobs.
Before getting too caught up in the headlines, I look at one signal.
Hiring.
The major AI companies are still growing their teams. If the narrative were true, that AI is eliminating work across the board, you'd expect those organizations to shrink as the technology matures.
They aren't.
That tells you something. The technology still requires people. There's still a lot of work happening behind the scenes that doesn't make it into the headlines.
The same pattern shows up inside companies exploring AI.
Some experiments won't pan out. That's not a failure, that's how new technology gets figured out. Teams try things, learn what works, and move on from what doesn't. That learning has real value even when a specific project doesn't go anywhere.
The problem isn't experimentation. It's when the experiments never connect back to the business.
Exploration without a tie to real decisions or measurable outcomes just drifts. At some point, a series of disconnected pilots isn't a strategy, it's activity.
The organizations getting real value from AI aren't the ones with the most projects. They're the ones who know what problem they're solving before they start.
The AI conversation is obsessed with capability, but the real constraint is power, cost, and infrastructure.
If you run IT, this is why the future may look like many cheap specialists instead of one giant system.
I think a lot of the AI conversation is centered around these massive, all-purpose models.
But when you really think about how businesses operate, that’s not usually what they need.
A lot of companies don’t need AI to do everything. They need it to work within their specific workflows and solve specific problems.
So the shift I see happening is toward more specialized systems.
Smaller, more focused, and a lot more practical to actually use and scale.
Aging technology is one of the quietest ways a company loses its best engineers.
And by the time it shows up in attrition numbers, the damage is already done.
No one wants to spend their time maintaining something that's a year old. In software development, twelve months is a hundred releases behind. The people working on it know exactly where that puts their skill set.
We've always made sure there's something new to work on, whether that's client work, internal projects, or hackathons. If the work isn't there, we create it, because nobody on our team should be sitting with a skill set so outdated they can't work effectively.
The harder version of this problem sits inside companies running their own internal dev teams.
When you're building technology for one company, you get pigeonholed into their systems pretty fast. Unless leadership is actively creating room to work on newer things, that legacy trap closes in gradually. It tends to show up as a people problem long before anyone calls it a technology problem.
It's always been an issue in the technology industry. The economy might be slowing the exits right now, but it doesn't change what engineers are feeling day to day.
The AI implementation your team built a year ago is already out of date.
And the workflow tools everyone was using to build them aren't far behind.
What's coming next is going to shift how enterprises think about data, privacy, and who actually controls the models they're running on.
The automation you can build today by pulling freely available data from across the web may not be possible in twelve months.
The landscape is moving faster than most roadmaps account for, which means your roadmaps and teams need to stay agile to keep up.