It's AI Month at Work: The Conversation
April is “AI Month” at work, and we’ve seen great engagement with our Learn and Build tracks. The conversations have been inclusive, featuring both strong advocacy for AI and thoughtful critiques on its potential impact on the enterprise.
One critique stood out to me recently. It’s a core question for AI-assisted software development: when the "software" is highly diverse, how can you ensure the solutions maintain consistency and are easy to support and operate? Why not just use the enterprise platforms we already have?
The Broken Promise of Citizen Development
For years, that question was answered by major enterprise platforms. Their promise was a consistent solution framework that delivered 80% of what you needed, leaving the last 20% for you to implement. This gave rise to the term “Citizen Developer.” Leaders loved the idea of accelerating business value without needing dedicated development teams, just talented business users.
Unfortunately, it hasn't worked out that way. That "last 20%" proved much harder than promised. Often, people executing the workflows (especially in government contexts) were too busy doing their actual jobs to reengineer or digitize processes.
The irony? Businesses responded by hiring specific skillsets for these platforms, creating dedicated teams, and standing up governance processes. We ended up right back where we started, but with different layers of complexity. Instead of democratizing software value, we pushed the complexity into the organizational stack: now we have platform-specific dependencies and high license costs draining budget from hiring talented people.
The math simply doesn't work: if you spend 60% of your budget on a tool designed to do 80% of the work, but can’t afford the talent to complete the remaining 20%, the resulting software often fails to meet the need or provide more value than it costs.
Enter AI: The Rise of Personal Software
This is where AI-accelerated development comes in. Over the past three years, AI has enabled people across the entire skill spectrum, from individual developers to business users. The paradigm is different now: the output provides immediate value and speed.
This speed has given rise to the term “Personal Software.” The core idea is that making software for yourself is now so easy, there's little incentive to settle for an 80% solution. Why risk fighting with a platform when you can type what you want and get a solution that is much closer to 100% and costs far less in time?
This is leading to an explosion in what I call “highly-aligned business solutions,” not just “custom” development. The goal should be to create a solution that perfectly fulfills the alignment objectives of the business workflow.
Managing Sprawl: The Engineering Focus
However, there’s a new danger. If I, as a new AI developer, let a tool like Claude Code do everything, I might end up with codebases in Python and Typescript, unchecked dependencies, inconsistent GUI, and no real sense of data flow. Personal Software quickly scales into enterprise data sprawl. This pattern isn’t new; we see it in every major technology shift.
The reason the Personal Software paradigm is so interesting is that it’s a microcosm of the entire enterprise software problem. If we can solve how to manage the scale and sprawl for personal software, the enterprise context becomes much easier.
This shifts the focus from a math problem (AI) to an engineering problem (workflow). It’s a problem we can frame, baseline, design, deploy, and measure.
Instead of worrying about new fragmentation, we need to shift our focus to:
- Tying workflows and processes together.
- Smoothing friction for a wider variety of users.
- Linking enterprise guidance to workflow and software consistency.
- Developing safe spaces for people to learn, experiment, and level up.
By embracing these four engineering steps, we stop being reactive to the "warning" and become proactive architects of controlled, valuable innovation.
And, if Personal Software is an engineering problem, then Continuous Delivery (CD) is the operating model for solving it. CD, especially as championed by people like Bryan Finster and others (minimumcd.org), provides the framework to standardize the processes for personal software development—from initial concept to reliable deployment—making it the essential first step toward achieving those four engineering goals.
Are you talking about how to manage the explosion in highly-aligned business software in your organization? Or are you worrying about how these tools will lead to more fragmentation?
Focus on delivering "happy paths" for your users to see value, and you’ll have less to worry about.