Why scaling AI across your engineering team requires more than giving everyone a licence
Imagine a team of ten engineers. All of them are using AI tools and AI skills every day. All of them are writing their own prompts, developing their own habits, and getting their own results.
Now ask yourself: are those results consistent?
In most teams, the honest answer is no. One engineer has spent weeks refining how to ask for a code review. Another is getting output that barely meets the standard. A third is prompting in a way that works for their current project but would not transfer to the next one. The knowledge of how to get good results from AI is distributed unevenly across the team, and it is not being shared.
This is not a tools problem. It is a team problem. And it is one that grows more expensive the larger the team becomes.
What Does Prompt Inconsistency Actually Cost Engineering Teams
When every developer prompts differently, the output varies. When output varies, quality varies. When quality varies, the burden of maintaining standards falls back on human reviewers – code reviews, QA, pull request approvals – who are now compensating for inconsistency that should have been prevented earlier in the process.
There is also a knowledge retention problem.
When the skill of prompting effectively lives in individual developers heads rather than in shared, version-controlled artefacts, it walks out the door when those developers leave. Teams that have invested months in learning how to work with AI effectively find themselves starting over when their team composition changes.
At Hack9 2026, Gabriela Hanganu, Lead Software Engineer at Levi9, framed this as a fundamental architectural challenge: the industry is moving from AI helps me write code to AI participates in the entire development workflow.
Making that transition successfully at a team level, not just an individual level, requires a different approach to how AI knowledge is organised and shared.
Why Good Prompts Don't Scale
A common reaction to this problem is simple: teach everyone to write better prompts.
The challenge is that prompting expertise does not scale particularly well.
In most engineering teams, the people getting the best results from AI are often the ones who have spent the most time experimenting. They have discovered which instructions work, which context matters, how to structure requests, and how to guide the model towards useful output. Over time, they build personal workflows that make them significantly more productive.
The problem is that these workflows rarely become team assets.
A great prompt saved in a personal notes application helps one engineer. A great skill stored in a repository helps every engineer.
This distinction becomes increasingly important as teams grow. The larger the team, the more variability appears in how AI is used. Some developers generate high-quality documentation automatically. Others spend time rewriting AI output. Some perform AI assisted reviews consistently while others avoid them entirely because their previous experiences were unreliable.
Over time, the organisation ends up with dozens of individual approaches to solving the same problem.
Engineering teams solved this challenge years ago in other domains. We do not ask every developer to invent their own testing framework, coding standards, or deployment process. We standardise the parts that benefit from consistency.
AI should be treated no differently.
The goal is not to create better prompts. The goal is to make effective AI practices repeatable, shareable, and maintainable across the entire team.
What Are AI Skills in Software Development
An AI skill is a structured instruction file stored in your project repository that teaches an AI tool how to perform a specific, repeatable task according to your team’s standards. Unlike a one-off prompt, a skill is reusable, version-controlled, and automatically discoverable by the AI whenever the task is relevant. Teach it once, apply it everywhere.
The practical difference between a skill and an agent: skills handle single, well-defined tasks; agents coordinate multiple steps with autonomous decision-making. If a task is predictable and repeatable, make it a skill.
Where skills pay off most is consistency and continuity. When your PR format, code review checklist, or documentation standard is encoded in a shared file, every developer gets the same AI output regardless of how they prompt. And when new team members join, they inherit not just the codebase but the accumulated knowledge of how to work with it – reducing onboarding time and protecting against knowledge loss when people leave.
How Do AI Skills Scale Across an Engineering Organisation
Shifting from individual prompting habits to shared, codified skills has implications that go well beyond individual productivity.
When skills live inside a project repository, they are version-controlled. They can be reviewed, improved, and updated as the team learns. They are automatically available to every team member working on that project, including people who join the team next month. Onboarding a new engineer to a project with well-defined skills is fundamentally different from onboarding them to one without – in the latter case, they are inheriting not just the codebase but the accumulated knowledge of how to work with it effectively.
At the organisational level, the implications extend further.
Enterprise-level skills can enforce standards across every team and every project – security requirements, coding conventions, documentation practices – applied consistently by AI regardless of which individual developer is doing the work. This is a governance capability that did not exist two years ago.
When Should an AI Skill Become an Agent
Skills handle what is repeatable. Agents handle what requires reasoning across multiple steps.
An AI agent is a system that perceives a context, decides what to do next, executes actions, observes the results, and loops until the task is complete. Where a skill gives instructions for a single well-defined task, an agent coordinates a sequence of tasks, potentially in parallel, potentially using multiple skills, to achieve a more complex goal.
The practical guidance from Gabriela’s workshop is worth repeating for any team starting this journey: begin with skills, not agents. If a task is repetitive and well-defined, it is a skill. Only promote it to an agent when you genuinely need autonomy, when the task requires dynamic decision-making, multi-step execution, or parallel workstreams that a single instruction set cannot cover.
Complexity introduced prematurely creates the opposite of what teams are trying to achieve: unpredictable output, difficult-to-debug failures, and agents that loop rather than deliver.
The teams that are getting the most value from this architecture, including several that presented at Hack9 2026, are the ones that started with clear, well-tested skills and built agent layers only where the complexity was genuinely justified by the problem.
How Do You Measure Success
One of the challenges with AI adoption is that many organisations focus on activity rather than outcomes.
It is relatively easy to measure how many licences have been purchased or how frequently AI tools are being used. It is much harder to determine whether those tools are actually improving the way teams work.
Skills provide an opportunity to move beyond anecdotal success stories and start measuring consistency.
For example, teams often report fewer review cycles when pull request descriptions follow a common structure. Documentation becomes more complete because the same standards are applied every time. New engineers become productive faster because they inherit not only the codebase but also the accumulated knowledge encoded in project skills.
Perhaps more importantly, teams spend less time repeatedly enforcing standards and more time discussing the actual engineering decisions behind a change.
The objective is not to maximise AI usage.
The objective is to reduce variability, improve quality, and make good engineering practices easier to follow by default.
When skills are successful, the effect is often subtle. Reviews become smoother. Onboarding becomes faster. Standards become easier to maintain.
What AI Skills and Agents Mean for CTOs and Technology Leaders
For CTOs and Engineering Leaders, the strategic question is not whether your team is using AI. Most are. The question is whether your team’s AI usage is producing consistent, scalable, governable results, or whether it is producing a distribution of individual experiments that happen to share a licence agreement.
The gap between those two states is significant. It shows up in code review volume, in onboarding time, in the reliability of AI-assisted output, and ultimately in delivery speed and quality.
Closing that gap requires treating AI knowledge the way you treat any other engineering practice: defining standards, encoding them, making them version-controlled and shareable, and ensuring they improve over time.
Skills and agents are the mechanism for doing that. The teams that build this infrastructure now are the ones that will scale their AI practices effectively as the tools, and the expectations, continue to evolve.
This is the third article in a series on AI-first software development at Levi9, based on the workshops and hackathon sessions from Hack9 2026. Read them all:
– AI-First Software Development Is No Longer Experimental;
– From Requirements to Production: What an AI-First Software Development Lifecycle Looks Like in Practice
