I’ve spent the better part of the last two decades running or being a part of development teams, and as a developer I’m experimenting a lot with using AI tools, and I’m not alone, lots of people in the tech space are. So it comes as little surprise that these same teams are seeing the biggest impact from the ongoing shift to AI-native development.

A few weeks ago, I caught up with a dev manager friend, and without prompting, we jumped straight into a conversation about how fast everything is changing. For years, we’ve focused on building processes and procedures to help human teams collaborate and build complex software applications. But in the world of AI, the model is changing, and sometimes dramatically. What used to be a multi-person effort can now be a single human orchestrating multiple AI tools.

A perfect example: microservices.

The trend of breaking up complex applications into smaller pieces has been hot for a while now. It lets organizations build specialized teams around each part of the application and gives those teams more autonomy in how they operate. That made sense, when your team was all human.

But in an AI-first world, it can actually make things harder.

A single repository might only represent a slice of the full application. And if you’re using an AI tool to review code, it can’t easily load up the full context of how everything connects. Sure, you can help the AI out with great documentation or give it access to multiple repos, but at the core, microservices are optimized for distributed human teams. They’re not necessarily optimized for AI tools that rely on full-graph context.

That’s why, in some cases, building a more complex monolithic application may actually be a better approach for AI-native teams building with (and for) AI tools.

Another place I’ve been experimenting is in seeding AI with persistent context, so I don’t have to be overly verbose every time I assign it a dev task. I caught myself over-explaining things in prompts after the AI would do something unexpected or take an approach I didn’t want. So I started adding AI-specific README files at the root of my projects. Not for humans—for AI.

These files include architecture decisions, key concepts, and even logs of recent changes or commits. When I’m using Claude inside VS Code, for example, I sometimes hit rate limits. If I need to switch to another model like Gemini or ChatGPT to pick up the work, I don’t want to start from scratch. Those AI README files give them the full context without having to re-prompt from zero.

This is the kind of data that might be overwhelming for a human reviewer, but trivial for an AI model. And that’s part of the mindset shift. Developers are used to writing comments or notes that are for humans. But AI models benefit from verbose, detailed explanations. Concise isn’t always better.

AI also gives us an opportunity to finally shed some of the legacy technical debt that’s haunted development teams for decades. When Amazon first announced its AI assistant Q back in 2022, one of the headline features was its ability to upgrade old Java applications, moving from decades-old versions to the latest in minutes. Since then, I’ve seen multiple companies use AI to fully rewrite legacy systems into modern languages in weeks instead of years.

For some of the best programmers I know, this is a little distressing. They see code as craft, as poetry. And just like writers grappling with ChatGPT, the idea that AI can churn out working code with no elegance can feel like a loss. But beauty doesn’t always move the bottom line. Sure, I could pay top dollar for a handcrafted implementation. But the okay code produced by an AI tool that works, ships faster, and gets us to revenue or cost savings sooner? That’s usually the better trade.

And it’s not just the dev process, it’s entire products on the line. My friend put it bluntly: they used to rely on a range of SaaS tools because it wasn’t worth the effort to build them in-house. But now? A decent engineer with AI support can quickly build tools that used to require a paid subscription. That’s an existential threat for SaaS platforms that haven’t built a deep enough moat.

Take WordPress, for example. I know developers who used to rely on dozens of plugins, anything from SEO tweaks to form builders to table generators. Today, with AI support, they’re writing that functionality directly into themes or making their own plugins with AI. It’s faster, lighter, and more tailored to what they need. The value of external tools or those one-line NPM packages we used to reach for just to save time starts to diminish when you’ve got an army of AI bots doing the work for you. The calculus changes.

I always say in my talks that this is still the AOL phase of AI, it’s early. But what’s happening inside development teams is a preview of what’s coming for every other function in the business. We’ve spent decades refining human-first processes that work across teams, tools, and orgs. Now we’re going to have to rethink those processes, one by one, for an AI-first future.