For the first time in a long time, I find it really hard to predict how AI will impact the IT business. There are two big reasons. First, AI is moving so fast that most predictions are out of date within months. Second, “IT” reaches into so many corners of society that it’s really a bunch of separate businesses whose only common thread is a strong tech component.
Still, I think we can sketch a few lines that help people in IT understand what the near future might look like, and get ready for what’s coming. In this piece I’ll focus on software development. I may follow up with articles on other areas, like staffing, IoT, or hardware.
Business teams are building their own tools
Over the past six months, I’ve seen strong evidence, at BairesDev and at many other large companies, of business teams taking care of their own needs for applications, workflows, and internal tools. In practice, they’re bypassing traditional R&D teams.
This isn’t about some petty rivalry. It’s the result of expectations the software industry has struggled to meet for as long as I can remember.
What business teams say
Ask business teams and you’ll usually hear some version of this:
- R&D is too slow, too rigid, or too far from the business. Anyone who’s worked in this industry has heard this complaint in one form or another.
- Their needs don’t get prioritized. When an R&D team serves several business units, a few of them tend to soak up most of its attention.
- It’s too expensive, and the real cost is hard to see upfront. That’s especially true for the cost of running the solution once it’s built.
What R&D teams say
To be fair, R&D teams have their own side of the story, and it’s just as real:
- Business teams don’t really know what they need until they see an early version of it.
- Business teams don’t understand the security side. They focus on features and skip things like roles, permissions, and auditing. Those still have to be built into the product, but from the business side they look like “overhead.”
- Iteration costs money. Every round of changes pushes up the price and the timeline. And when R&D tries to prevent that with a more formal process, like detailed requirements upfront, that feels like overhead to the business too.
Vibe-coding: promising, but risky
The result is that business teams everywhere are moving to a more self-service model. They go to R&D only for solutions above a certain level of complexity and handle everything else themselves through “vibe-coding”: describing what they want to an AI tool and letting it write the code.
The results vary a lot. They depend on the team’s technical skills, how complex the task is, whether the right data is available and, quite often, plain luck. And because security practices tend to be missing, the industry has seen its fair share of costly pilots that ended up exposing sensitive data or getting hacked. In the best case, you end up with apps that don’t quite work and ignore the company’s guidelines and policies, which are exactly the things R&D teams take pride in building into their processes.
My proposal: R&D builds the platform, not the apps
So, can we bridge the gap? I’ve been thinking about this for a while, and I’m convinced that, with today’s AI tooling, it makes sense to blur the line between business and R&D. Done right, that solves, or at least greatly reduces, the problems both sides complain about.
In practice, this means two things:
- R&D focuses on building and maintaining AI tools that business teams can use.
- The rest of R&D’s capacity moves directly into the business teams to champion those tools.
R&D’s job would be to build the tooling (agents, frameworks, data access layers, and so on) that makes sure business teams follow the right security practices, while keeping it all accessible in plain language. The same tooling would keep things consistent across apps built by different business units: user interfaces, permissions, data access, authentication, and auditing.
In other words, R&D’s main role would be to let business teams build their own software and processes with as little hands-on R&D involvement as possible, while staying within acceptable boundaries for engineering practices, security, and consistency. R&D would also keep a catalog of apps and initiatives, so different teams don’t end up building the same thing twice.
What changes for the teams
This doesn’t have to change headcount, but it does change how teams work and what they’re responsible for.
For R&D, it means shifting from building applications to building tools and frameworks. The R&D people closest to the business, like analysts and project managers, would be a better fit inside the business teams.
For business teams, it means taking on the challenge of building their own applications with R&D’s tooling. To pull that off, they should bring in the engineers R&D no longer needs and use them as “forward deployed engineers”: technical people embedded in the team who connect what the business knows with the technical know-how needed to get the most out of the tools.
Time will tell
That’s my proposal for where things stand today. I’ll keep an eye on how it plays out and share what I learn. If you’re seeing something similar in your company, or something completely different, I’d love to hear about it.
