Agentic engineering: from individual productivity to shared quality

Colleagues of the AI team
Coding with LLMs often starts with speed: can we write or debug faster, get a first version of a test or script without starting from a blank page? However, after the first wave of adoption, you should ask yourself: how can we make our work reliable across teams using AI? 

Agentic engineering answers that question: it gives people with different roles and repositories a common way to use AI, instead of leaving everyone to ad hoc prompting. 

 

The gap is uneven usage

AI adoption rarely happens evenly. Some people use GitHub Copilot every day, others only occasionally. Some work in mature repositories, others in notebooks or locally. Some want to learn how to use ready-made prompts, agents, instructions or skills, others want to customise their configuration or even build the foundations themselves. 

All of these profiles are valid, but they need different support, which is why we describe adoption through three groups:

  • Takers need practical assets they can use right away. 
  • Makers need enough understanding to adapt those assets to their own project or team. 
  • Builders need the space and technical depth to create new agents, skills and scaffolding that others can reuse.

Give everyone the same training or the same demo, and one person gets excellent output, another gets something generic, and a third doesn't trust the tool enough to let it touch anything important. 

Why we built the Agentic Engineering Library 

The Agentic Engineering Library is our way to close that gap. It captures the assets that make AI-assisted work easier to repeat: repository instructions, custom prompts, custom agents, reusable skills and workflows... some broad enough to reuse across projects, others tailored to a specific stack or team. Reusable assets avoid every team starting from zero, project-specific configuration stop GitHub Copilot working with generic context. 

The library also makes improvement visible: a useful prompt gets shared beyond one person's chat history, and once an instruction file improves GitHub Copilot's output for a repository, we maintain it like any other engineering asset. Personal tips and tricks become shared practice.

Templates make the practice easily applicable

The library gives you the building blocks, template repositories turn them into delivery. That's why you get key repositories like a web development and workflow template, which define how to start a new project, what context is already available, and what "good" looks like before anyone starts prompting. 

In the web development template, agentic engineering gets embedded directly into the setup: component conventions, testing expectations, back-end access and scoped agents or prompting  for recurring tasks, so GitHub Copilot doesn't need to rediscover the basics of the project when someone asks for a new feature.  

A workflow template carries different context like process logic, validation rules, integration points and auditability requirements, often exactly the details that make generic AI output weak. Once that context is captured in the template, every new project starts from a stronger baseline. 

Quality improves when the workflow is explicit

AI-generated work is hardest to trust when the path to the result is unclear. A broad request can produce an impressive-looking change, but the reviewer still has to understand the assumptions, the files touched and the risks introduced. That's where "vibe coding" turns into a problem: the work is difficult to inspect. 

Agentic engineering changes that: the goal is defined before implementation, the task stays bounded, the right context is provided, and a plan can be reviewed before changes are made. Tests, validation and human review are part of the workflow, not an afterthought. It also lets Takers, Makers and Builders grow at their own pace, so the organisation gets progression instead of fragmentation. 

Governance should live close to the work 

A policy document can explain acceptable use, but it doesn't help someone choose a model, write a better prompt or decide when agent mode is appropriate. Agentic engineering builds that governance into the working environment: security expectations written into repository instructions, review habits embedded in prompts, agents scoped to bounded responsibilities. 

A web team, a data team and a functional team will use GitHub Copilot differently, and that's fine, as long as they share the same principles: clear context, bounded tasks, reusable assets and visible review. 

From experimentation to capability 

Experimentation is still how your teams discover better ways of working, but it only turns into organisational value once the useful parts are captured, improved and reused. The Agentic Engineering Library and our template repositories build exactly that: a common recipe for better AI-assisted delivery.

We covered the cost-management side of the move to token-based pricing in our previous article. That argument still holds, but the same practices that reduce waste also improve quality: better context, clearer scope, stronger review and more repeatable outcomes. For organisations already using AI coding tools, the next step is better usage, adapted to the different profiles in your teams and built into the environments where work happens. 

If you want Takers, Makers and Builders to grow in the same direction, BDO can help with a practical activation trajectory

  • assess current usage, 
  • identify the right profiles, 
  • work on real repositories or workflows, 
  • and build the scaffolding needed to move from experimentation to shared capability. 

Curious what this could look like in your organisation? 
BDO can help you find the right starting point.