zachdavis@zachdavis9h ago

At @cxodev we like to talk with clients about the need for AI "transformation" rather than AI "adoption". Transformation conveys a degree of change that adoption alone does not. Far and away the most common pitfall we see is teams adopting AI tooling but not changing the way they work. It's hard to get real change out if you're not putting real change in. @levie calls this "process reengineering"; changing workflows to take advantage of AI rather than "just layering on agents into the existing flow". It's a great name, and it's worth examining whether your approach to AI fits this moniker. We believe that the engineering function is a great place to start AI transformation. Because of the highly verifiable nature of software development, as well as the fact that models are very good at writing code, if you can't transform the way your engineering team works with the current tools, you're going to have a hard time doing it anywhere else. And also, you're going to learn a ton from making agents successful in your software development lifecycle (SDLC), or perhaps making your SDLC successful with agents, that can be applied to other functions as well. That last point, that maybe you need to adapt your SDLC to agents instead of the other way around, that's process reengineering. Other functions within your company probably don't have anything nearly as well defined or obsessed over as the SDLC. But I assure you there is a process lurking in there, waiting to be reengineered, and that's where you're going to find real leverage. The most AI-forward companies aren't just adopting tools broadly, they're using what they learned from reengineering the SDLC to rethink processes and workflows across the organization around the joint capabilities of humans and agents.