What AI really is doing to software development (and developers)

Overview

A newly released report from Faros crunched two years of live, in-the-wild data about AI usage and adoption. The results are eye-opening. No question AI is having a major transformative effect on software dev. But many of the gains are being drastically offset by losses elsewhere in the dev cycle ... and many of those losses are invisible and insidious.

Register Now

Transcript

Foreign what exactly is the broader adoption of AI doing to the software development process?

That is a question Pharos research just spent two years gathering data for they harvested telemetry from 22,000 developers in 4,000 teams and from that created the AI engineering report for 2026 and they drew some pretty striking conclusions.

AI is writing more code than people are at this point and it's having a real effect on productivity. The bad news is this progress is coming at costs that undermine those gains, and they're costs that we ignore at our peril.

And they may not be what you think they are. For a good single snapshot discussion of this, you can check out this slide from Faro's blog post for the report output overall, they note, is up. There's more actual work getting done, but so is code churn.

A lot of the code being generated is thrown out and the number of customer facing incidents and documented bugs is also jumping to quote More AI generated code in the code base correlates with more bugs per developer, and that relationship is strengthening as adoption deepens.

What's more, the changes to the code are quote, getting larger and more complex. That doesn't just mean bigger pull requests, but more files touched overall. And that means more incidental complexity for each change because there's more code being generated and plowed through, whether by people or machines.

The amount of time it takes to evaluate code at each step of the process is also going up by as much as 225%. To quote from the report.

Again, work is not just taking longer to complete, it is spending more time in a state where no one is working on it at all. Another big takeaway is that a lot of this work doesn't get finished.

To quote more threads opened, more work abandoned mid flight, and a development environment where beginning is easy but finishing is hard. So while there's more work being done with code, less of that visualization value with it is reaching the customer or the user.

Now the easy takeaway from all of this would be okay, don't use AI. Unfortunately, that is pretty much a non starter. Whatever many of us think about AI, it has become an entrenched force in the development workplace. Wishing it away won't happen.

And what's more, abandoning it too often means leaving not just tools but whole skill sets on the table.

The skill sets that have evolved in recent years around making productive use of AI tooling like creating good harnesses or setting up models for code generation versus writing tests or documentation.

So to that end, the report makes some concrete suggestions for using AI in ways that would minimize these issues. And a lot of these suggestions are changes in practice, not just attitude.

For instance, to quote set PR size guidelines for your coding agents and enforce them, meaning pull requests should have narrow scopes to make them easier to review.

And that directive should not just be part of the agent harness, but something that the devs themselves make part of their own activity. But here's the thing.

If there's one thing I've learned about software development, it's that the culture of a given organization is the hardest and slowest thing to change.

Sometime back I read a blog post from developer Dan Liu, who keeps a blog well worth reading, by the way, and he wrote some criticisms about then relatively new language Julia. And his criticisms weren't so much with the language, but with the development culture around it.

That, in his view, made it hard for the people making the language to deliver quality and consistency. And those were two things that mattered for a language and aimed at scientific and mathematical work.

As he notes at the end, technical fixes can be easy, but process and cultural fixes are almost always hard. That's the biggest takeaway for me from this study. The fixes being recommended are unbalanced, the right ones, because they're about process and culture.

But that also makes them harder to implement because they require the most amount of individual and collective practice.

Now, maybe the fact that the use of AI is still relatively new in organizations means the processes and culture around them are still malleable. People are still getting used to all of this.

There's a fair chance the energy and churn around AI use means the way we use and think about it still has room to evolve in a good direction. Because, frankly, I hope it does.

If AI is not going away, and it sure doesn't look like it is, and it's going to continue to be offered to us in its current form, which looks inevitably likely.

The least we can do for ourselves is find the most specific, narrowly applied ways that it can be made useful. So let me know what you think. Leave a comment below. Don't forget to follow David Serdar and InfoWorld on Facebook, YouTube, and InfoWorld.com.