We use the four levels of AI adoption not only to make individual growth visible, but also as a tool in our personnel planning. It allows us to identify for each project team where the strengths are and where there are gaps.
For example, if a team consists mainly of Level 1 and 2 developers, we know that we should add Level 3 or 4. Someone who not only works AI-first himself, but also takes the team along. That makes the difference between “using AI with it” and “really integrating AI into your way of working”.
'Mixing levels', consciously and strategically
We assemble our teams with different levels of experience in the AI field. For example, a typical Blis Digital team has:
- one product owner or architect at Level 4
- 1 or 2 experienced developers at Level 3
- developer (s) at Level 2
Why? Because we believe in the power of knowledge transfer within the team. By allowing experienced AI users to work together with colleagues who are still growing, people learn in practice. Not through training, but through real projects and side-by-side work. We explicitly don't work with “AI specialists” who teach others how AI works. We integrate AI expertise into every role, because this is the only way it becomes an integral part of your process and therefore of your profession. So a Level 2 developer learns from Level 3 and Level 4 developers. Designers learn from designers, architects learn from architects.
Teams as a hybrid human-AI unit
What we really started doing differently is looking at a team as a hybrid composition: a collaboration between people and AI. Not as separate tools, but as full-fledged team members with their own limitations and strengths. This also means that we have started to reformulate roles. The job titles are the same, but the practice has completely changed. A tester who has tests generated and run with an LLM agent works at a different level of abstraction than a tester who clicks everything himself. A developer who 'engineers' an AI prompt to boiler plate-generating code works differently than someone who writes it out manually.
So the old testers and developers eventually no longer exist at all. We require a different mindset from the 'new' ones. You have to be willing to let go of work, to delegate to AI and, at the same time, to continue to take responsibility for the result. Not easy, but necessary.
We've also noticed that in our own product teams. In one project, a Level 3 engineer worked on a complex new position with a tight deadline. Instead of building everything himself, he split the task: he built the core algorithm himself, but had the peripheral components — logging, API links, validation — generate an AI agent. In half a day, he had something working. Without AI, this would have been at least two weeks of work.
Smaller teams, more ownership
So teams are getting smaller. And we've known for a long time: smaller teams work better. They make decisions faster, have fewer transfer times and less knowledge and information is lost. And AI ensures that they can do more work than larger teams before, provided they are people with an overview and who have control over the tooling.
In my experience, two people who work effectively with AI ultimately have more control over the process than a larger team of specialists. Because much of the coding work is done by AI, there is also no reason to delay refactoring. As a result, the project also builds less. technical debt on.
In my view, the ideal project team will be a team of two: an engineer and a consultant. Or, if that's a better fit, a developer and product manager. These are then no longer classic 'builders', but designers of a solution. People who work together, based on their expertise, on a product at a high level of abstraction and thereby outsource a large part of the work to AI.
Although these core teams are small, that does not mean that they operate in isolation. They can still rely on the expertise of specialists — such as UX designers, security experts, testers or cloud architects — to support them where necessary. These specialists also use AI in their work, but are often less deeply involved in the specific domain of the product in terms of content. In this way, specialist knowledge remains accessible without hampering the agility of the core team.
The challenge is to find a good balance between efficiency and human continuity. It is therefore fine — and sometimes even desirable — to hire two engineers and two product specialists, even if the scope of the work does not immediately seem to require it. Continuity, cooperation and shared ownership are at least as important as scalability.
AI as a factor in project planning
Perhaps one of the biggest changes still lies in how we plan projects. Where we used to estimate how many people and hours were needed, we now also take into account the extent to which AI can take over or accelerate tasks.
For example, a module that traditionally took three weeks can sometimes be completed in five days with a Level 3 engineer and a smart AI agent. Or, a test cycle that normally lasted ten days is compressed to three days with the help of automatic test generation.
AI is now a resource. Not a tool that you use, but a capacity that you include in your planning. And that means that our resource planning has become more flexible, but also smarter. We are not only looking at capacity in people, but also at the AI skills of those people. And that makes a difference, especially with tight deadlines.
To real speed
Through AI, we've also revised our view of agile. The traditional agile setup — with separate roles, ceremonial meetings and a lot of communication — is less and less suited to how we work today. Sometimes, in presentations, I show a slide with the classic agile picture full of puppets and arrows on one side, two people and a handful of AI agents on the other. And then I ask the question: which setup delivers value faster?
In the coming years, we will be moving towards more compact, faster teams. But that only works if people learn to think at a higher level of abstraction. Instead of “how do I write this code”, the question should be: “how do I design a process that provides this functionality — with the help of AI?”
Multiply AI power through structure
What we've learned is that AI only really comes into its own if you put the right structure around it. That means not determining everything centrally and leaving no room for creativity and innovation. But yes: guidelines on how we work with AI, what tools we use and (especially) how we ensure quality. As a management team, we set those standards. Of course, there is a say, but in the end, it just has to work in practice.
The trick is to provide structure without stifling the experiment. That's why we keep making space for exploration: we spend a lot of time on R&D. We have a leading group that experiments, we have weekly moments where lead developers discuss tooling and experiences and we are constantly adapting. And everyone can contribute. At Blis, AI adoption is not a tightly imposed program, but an invitation to grow.
This is part 4 in a five-part series about AI-first working in software development. In the white paper “The Foundation of an AI-First Company”, you can read about the framework we used to make Blis Digital AI-first and what we're currently using to make our customers AI-first.
Also read:
Blog 1: Why many software companies miss the AI boat
Blog 2: The 4-level framework; how to promote AI readiness in your team
Blog 3: Why AI requires more seniority
