Becoming an AI Engineering Team

In the world of AI Agents, Claude 3.7, and o1-Pro, engineering excellence will no longer be sufficient, and using engineering to build AI solutions simply guarantees that you’ll be behind the curve. We need a fundamental reassessment of ways of working as an engineering team – one with AI at the core, helping us achieve speed without sacrificing resilience.

In this post, I want to discuss what it means to work as an engineering team in the era of agentic AI. I believe we are on the cusp of significant changes in the way we as engineering organizations work, and if we don’t set some ground rules, we’re going to take “move fast and break things” to a hyperspeed that none of us will be able to control.

What does it mean, then, to be intentional with bringing agents into your engineering workflow? For me, it means accepting that agents will be integral members of your team. You and your team will need to decide where the agents fit. What work do you delegate to agents? Where do they act as consultants or reviewers? Finally, where do they become teammates and collaborators? Each of these choices carries with it a different level of trust as well as loss of control, and choosing to delegate not only means a deep level of trust in the agent but also prevents your team from doing (and collaborating on) that work.

Be intentional when deciding what roles agents play on your team – when do you delegate, collaborate, or consult?

For instance, you may choose to collaborate as a team in building out requirements and backlogs, using agents only to improve clarity and look for weak points and missing elements, but letting the team work together to build an understanding of the work and priorities involved. You might delegate initial API construction to agents based on specs your team has written, and which other agents have reviewed. You may have real-time agents reviewing code as you write it, looking for violations of team standards or code contradicting existing team decisions.

That last example shines light on two additional AI Engineering Team principles. First, defining a “way of working” as a team becomes critical, in a fashion in which AI Agents can understand. Agents are increasingly able to cause large “ripples” across entire code-bases when asked to create changes, and we want to make sure that we don’t enter an era of “merge hell” instigated by dueling AI Agents of different teammates both attempting to make what seemed to them relatively small changes, until the agents got involved. This is like a much more complex version of “tabs vs. spaces” wars that echoed across codebases until teams centralized linter configurations, and can be avoided by giving guidance to AI Agents and supervising their work. Second, AI Agents only know what you tell them – documenting your decisions, within the repo, becomes even more important in this new world. This is what will allow your AI Agents to understand not only the what, but the why, of your code, so when they create changes they can adhere to the spirit of the decisions behind the code and not just the code itself.

Ways of working, design principles, and system decisions all need to be framed as AI Agent inputs.

Understanding how your AI Agents work is important not just so you can better tune your “ways of working”, but also to avoid skill erosion on the team. Look for opportunities to collaborate with your agents on code, even in areas where you’ve fully delegated to them. Just like human pair programming, this can often sharpen your skills and teach you alternate ways of working. Even if it costs you productivity in the short-term, it ensures that when systems fail, your team will understand the code and how it was written well enough to troubleshoot. It ensures that when your AI subtlely over-promises in its auto-generated requirements, your team has a chance to catch the mistakes. When your agent-generated design assets violate brand directives or company design language, your team will have the skills to spot and fix them before they deploy.

Collaborate with agents, even when not strictly required, to increase team understanding of agentic ways of working and avoid skill erosion.

Finally, I recommend picking a process, not a tool. Engineering in partnership with AI is a discipline, a craft, and your team should be designing processes for accelerating progress with agents, and also for reassessing their use and which tools and models your team should be using. Things will be changing quite rapidly, and putting together these processes will provide consistent touch-points for the team as the world rapidly shifts around them.

Pick a process, not a tool, and prepare to reassess regularly.

These are just some of my early thoughts on integrating AI into an AI Engineering Team. We’re still early, and my team is experimenting now to understand how best to put thoughts like this into practice in real-world engagements. How are you and your teams using AI Agents in practice? How are you using them within your engineering work, and not just as components of projects you’re building?

#AIEngineering #AI #TechInnovation #AIInPractice #FutureOfWork #EngineeringExcellence #AIPrinciples