Directing AI Native Development

Press enter or click to view image in full size

Photo of the garden at Great Fosters by Adrian — Just behind those trees is the M25

I’ve gone AI native, I have figured out how to get the tools to do what I want and produce good results with minimal input and minimal error or hallucinations. That doesn’t mean they can do everything, but I know where they do work well, and where the ever-receding boundary is of things they can’t do yet. I’m directing multiple agent swarms that are defining, building and testing products in a structured way, I’m not micro-managing the code produced by a single LLM, and I’m not throwing the entire problem at the LLM in one go and hoping it will figure out what I wanted.

As a director level manager of a swarm of agents, I own a “user need” and have a problem to solve to meet that need. I discuss product ideas and options in an open ended set of chats with OpenAI or Claude on my phone or laptop as they occur to me. I’m my own product manager, or sometimes I’m working with someone else who more deeply understands the problem domain. I get those chat sessions to save product or feature documents, which I upload to be worked on by my agent swarms.

I structure the teams I need to spawn (not hire) that will own development, testing, deployment, analysis and iteration of each module or domain. The modular structure minimises cognitive load for each team, and the agent specialisation further minimises cognitive load for each agent. For each module they can solve for tightly defined closed problems like architecting the component and external API choices, building front ends, building back ends, implementing databases, defining and running Behaviour Driven Development tests, packaging builds, deploying canary builds and A/B tests, analysing the results, tidying up the artefacts, and prioritising bugs and issues. The agents work together in a hive-mind with a shared memory structure, sharing to-do lists and calling off work between themselves.

That’s not much different to directing teams of human engineers, but without the negotiating for headcount, or hiring managers and engineers and waiting for them to get started and get things done. It’s like when we went from negotiating with suppliers and procurement teams and ops teams, waiting weeks to get a computer in a datacenter that we kept for years, to making an API call and getting one in the cloud in seconds, that we keep for a few hours. Now we can get as many specialist engineers as we need in seconds, for just as long as we need them.

That’s why I think AI Native is a good name, similar to when we started to call ourselves Cloud Native engineers in the early days of cloud computing. We knew how to do operations, so we knew what to ask the cloud for and debug what we got, but we didn’t have to do it ourselves any more, or wait for another human to get around to it.

A “sprint” for an AI Native team will take an hour or two from the point where you define what outcome you want. Most of your own time will be spent reading the BDD tests after a few minutes of planning to make sure they are what you want it to do, and getting a live demo of the working module or latest iteration and getting things you don’t like fixed towards the end. What can you do while you wait? Read email, doom-scroll social media? Playing around with the current build of the product and filing issues on it could be useful, but I’ve taken to practicing guitar while I watch progress.

Some people trigger an agent-swarm team to work through reported issues automatically. They resume the hive-mind context from the previous build, add some new tests to reproduce the issue, then make the tests pass and push out a new build.

What else changes? The build vs. buy tradeoff moves heavily towards open source and building it yourself. If the thing you want isn’t freely available in the programming language you are using, create your own implementation.

There’s far less typing. For me, this is a huge win, as my hands hurt after too many decades of keyboard time. For people with disabilities, they should be able to not only get more done, but also build their own AI native tools and affordances that are customized to their own needs.

The implementation itself can be replaced module by module in a few hours, keeping the design ideas and tests that define its behaviours. This is akin to building from spec rather than building from source. We’ve just moved up a level. Some people complain that it’s a non-deterministic way to produce a product, but think about when you build code and pull in a new version of a compiler, interpreter or one of the many libraries you depend on, you are also making a non-deterministic system. The AI native systems I’ve built have many more and far better defined tests than what I’ve seen human developers produce. This is the key difference that makes it work.

Some of the operations people got upset back in 2011 or so when we explained how we didn’t use an ops team to get our work done in the cloud, and someone called it NoOps. There will be developers who don’t like this NoDevs story as well. Eventually operations people learned to code and became DevOps, running their own Cloud Native systems, and hopefully developers will focus on learning product manager skills and directing their own AI Native teams.