The new team

16 April 2026 // Nils Janson

Don’t use AI as a robot to solve problems with code; by robot I mean someone who just follows instructions and does exactly as told. There is no AI agent that behaves like that, as there is no human either. Just stop micromanaging your agents and invite them to solve problems together with you.

It’s easy to treat AI agents as if they behave deterministically, but that is not the case. The same prompt made twice to the same agent will most likely give two similar but different solutions. Just as two colleagues will have two different solutions given the same instructions.

Over the past year of using AI agents daily, I’ve gradually stopped treating them like rigid tools and started treating them like colleagues I can solve problems with. Recently I took on a bigger challenge to build something more complex, took to use Gastown to manage a team of agents. And there it was, I was an engineering manager again, I had to lead a team and not micromanage a team.

My career arc had me go from developer to manager and then back to developer again, which for me are just different types of leadership. From leading teams, I had to learn that I can’t be in every detail (micromanage). I had to trust the engineers to solve problems to their best ability, and I learned so much from how they came up with solutions I hadn’t thought about.

Instead of micromanaging the how, we need to focus on the why and the outcome!

A successful team

When I have been in teams with clear and scoped goals and where the team made the decisions, that has been the most rewarding times. I always had the vision that this is how I was leading teams; sometimes it worked, others not so well.

Let’s break down what makes an effective team:

• A clear goal aligned with the company vision with a clear boundary (scope).
• Empowered to make decisions within their scope.
• Diversity; different experiences and backgrounds. Gives you many different lenses to view problems through and more ideas to combine.

As a manager you help by defining the goal with the team, set the scope, ensure there are guardrails and give them trust.

The trust issue

Below I’m talking about trust in the code delivered by agents, I’m not addressing the new attack vectors that our new tools expose us to, such as prompt injection.

A lot I hear and read about agentic coding comes down to trust. Agents keep doing strange things, which is to be expected from LLM since they are not deterministic. But also this behavior is why the agents are helpful, they can come up with interesting solutions and ideas. Let’s contrast this with team members, they also make mistakes, they don’t always follow policy and rules. We interpret instructions in documents in different ways, if you ever have written instructions you know this. We are only humans after all.

We addressed the variable actions of humans with automation.

• We started to use CI/CD pipelines over install/deployment documentation.
  • building artifacts
  • testing (unit/integration/smoke)
  • code style (linters)
  • compliance
  • and more.

And with adopting a DevOps mindset we added continuous improvements to the flow. One of my guiding principles is that I would not see the same problem twice in production. You add a check like a new test in the automation (CI/CD) to ensure the same problem doesn’t occur again. Over time this builds robustness into the flow.

Organizations with good automated processes will be better positioned to introduce agentic workflows. I worked at a bank that automated all the processes to be compliant as a bank instead of traditional handover checks. This bank has then been able to adopt AI in their workflow to a big degree, a culture of automation and let developers focus on customer value showed to make this transition faster.

My point is that the trust issue with agentic coding is not new and processes you already have in place can help building this trust. If you don’t have these practices in place, I think you will need them before you can embrace an agentic workflow.

So just as an Engineering manager you have to give up some control and rely on the guardrails you have set up and be able to act quickly when something does not go as planned.

Here are some patterns that are applicable on both people and agent teams:

• Establish good patterns in the code, if there are good patterns the next team member making changes will follow them. Like having the sr. engineer make the first version of a service.
• Use Architecture decision records (ADR) and have your agent read them. (or they might live in the agents.md file now). When you make a decision add it.
• Readme.md to explain the project and code. See what my colleague Albert wrote here

The dream team

We now know what a successful team needs, and it’s time to build one. As an engineering manager, I have the power to hire my dream team with the exact skills required, it’s just that the hiring process is a bit faster these days.

I start the conversation with the agent by explaining my vision and what the end goal looks like. From there we iterate towards a smaller goal that takes us towards the vision and end goal. Breaking it down to smaller parts, just as a regular project can go into sprints if that is your way of working. Using the plan mode of Claude code for example. Here I also ask the agent to challenge me and come with ideas and suggestions.

You and the agent together decide what kind of team you need. Here you can assemble your dream team and give them different personalities. Using Gastown this was really fun. To decide what skills and personalities you want.

To help me decide features and prioritize them I needed a PM as a partner so I gave one agent the PM personality and asked it to research our business area and make a road map, with the context that we should demo to the investors. As a partner to the PM I had the Solution Architect agent. With a plan and high level architecture I let the team get to work. Work was handed to the frontend expert, the backend dev, the business logic expert and the devops agent. It was magic to see them start sending messages between themselves to create API’s and contracts between the component of the system. And there was also the QA agent that validated the PM’s requirements, when a bug was found it logged issue back to one of the agents, who fixed it, then back to QA. A regular dev cycle.

Now we have a team and a well defined goal. It’s time to set the team to work and for you as a manager to trust the team and guardrails. Now my job as a manager is to unblock, provide information and guidance and adjust the goal from the learnings we get from building.

And as with any team, they will make mistakes, now it’s important that we learn from the mistakes and practice continuous improvement by updating automation, guardrails and instructions just as you would with any other team.

Continue like this with appropriate size of work and you can build amazing things.

You don’t know it all

One note on using the agents to learn, challenge you and explore new solutions. As a Engineering manager I think that you are missing out on many opportunities if you don’t use the amazing people in your team. I don’t know it all and makes many assumptions. A good team should challenge solutions and assumptions from the manager. Now since agents kind of are setup to do what you tell them, you need to inject some personality into them and ask them to challenge ideas, plans and instructions. Then you can use the agent to improve your ideas and solutions. Don’t give the solution use your team to find a solution.

You are now a manager

Whether you wished for it or not you are now an engineering manager. And if you as an engineer learn the skills of the engineering manager, you will be more effective in your use of agentic coding!

Go take your team to a whole new level!