Becoming an AI-Native Engineering Organization: What Changed at Boldare Since 2023
Weekly AI usage on design and engineering teams jumped from 54% to 91% in the past year. Turning that usage into something the whole organization runs on the same way is a separate problem. The gap sits between individual developers who’ve found a tool they like and an engineering function that operates differently because of it.
We hit that same gap in 2023, before “AI-native” was a phrase anyone used in engineering conversations. This article is about what we changed to close it, what didn’t work the first time, and what the model looks like now that it’s been run inside Boldare, tested in our own business unit, and delivered as a workshop for an external client.
Table of contents
What “AI-native” meant before the term existed
In 2023, we already had close to twenty years of software engineering experience behind us. That’s what shaped how we approached early AI tools: a handful of developers piloted code-generation tools on specific pieces of work, with the same review discipline we’d apply to any new practice, testing deliberately rather than rolling something out organization-wide before we understood its limits. What we didn’t have yet was a shared standard for how those individual pilots should turn into something every team could rely on the same way.
That’s a normal phase, not a failure. The problem isn’t that individuals experiment - it’s that experimentation without a shared structure produces inconsistent outcomes across teams doing the same kind of work. One team’s AI-assisted refactor looks nothing like another’s, and nobody can tell you why the two review processes diverged.
We had two options at that point, and they’re the same two options most VP Engineering roles are weighing right now. Let individual teams keep experimenting and accept the inconsistency, or treat AI adoption as a change to how the engineering organization operates - not a new tool bolted onto the old process.
Why we built an internal AI guild instead of leaving it to individual teams
We chose the second path, and the first concrete step was standing up an internal AI guild. It’s been operational since 2023, handling the questions that individual teams shouldn’t have to answer alone: which tools get adopted, what context rules apply across projects, where human review is mandatory rather than optional, and how a new practice moves from one team’s experiment to something the rest of the organization can rely on.
A guild only earns its keep if it prevents the fragmentation that comes from leaving these decisions to whoever tries a new tool first. Without it, you get inconsistent standards for reviewing AI-generated code, and no shared answer for what happens when a fragment of code that shouldn’t leave the building ends up in a prompt.
Top Gun: giving exploration a structure instead of shutting it down
Standardizing the AI guild’s rules didn’t mean freezing experimentation. It meant giving it a place to happen safely. That’s what our Top Gun program is for: a series of internal hackathons where our team pushes a model or tool’s capability to its actual limits, together, before that discovery happens for the first time inside a client’s production system.
The distinction matters more than it sounds. Unstructured experimentation finds a tool’s limits by accident, usually in front of a deadline. A dedicated exploration track finds the same limits deliberately, documents them, and feeds the findings back into the guild’s guardrails before the next project runs into the same edge case.
From internal practice to external delivery
The internal model became an external offer once we had enough repetitions to trust it outside our own teams. One of our clients was the first external delivery: a hands-on workshop covering spec-driven development, AI-assisted TDD, code review with AI, and prompt-driven development, run directly against the team’s own Claude Code workflow rather than a demo repository.
The developer group included a QA cohort of around five people, so the format was split accordingly. A dedicated track covered how AI-assisted practices change testing and review work specifically, rather than treating QA as an afterthought to a developer-focused session. The workshop itself ran as a hybrid of hands-on exercises and a structured, gamified challenge format.
The point of running it as a workshop rather than a slide deck is that an engineering team doesn’t adopt a practice because someone described it well. They adopt it because they’ve done it once, on their own code, with someone in the room who can tell them why an output that looks correct isn’t.
The clearest signal that it worked came afterward: the client’s own team came back with interest in extending the same approach across their full SDLC, from planning through development, deployment, and documentation, rather than treating the workshop as a one-off training day.
Scaling beyond one team: the Gulf BU rollout
The most recent internal test of the model came from within Boldare itself. Our Gulf business unit rolled out an AI-native SDLC framework across every active project - the same guild-and-guardrails structure we’d been running since 2023, applied at business-unit scale rather than team by team.
That’s the harder problem, and it’s the one most VP Engineering and Head of Delivery roles are actually facing. A pilot that works for one team doesn’t automatically work for twenty. The rollout needed the same three ingredients every time: a shared governance model, champions embedded in each team rather than a central group people had to go ask, and a review cadence that catches drift before it becomes an incident.
What this looks like as a repeatable engagement
Running the same transformation internally three times, and once for an external client, is what turned it into a structured offer instead of a one-off consulting engagement. It now runs in three stages, matched to where an engineering organization actually is:
| Phase | What happens | Output |
|---|---|---|
| Day 0 — Framing (half a day) | Scope, user story, prototype goal | Defined sprint scope |
| Days 1–4 — Build | Claude Code + Figma Make: real flows, states, design system alignment | Clickable prototype |
| Day 5 — Polish & handoff | Fallback states, visual consistency, demo prep | Prototype ready for pitch |
ASSESS — AI Adoption Workshop (2 days, fixed price)
The same format delivered: spec-driven development, AI-assisted TDD, code review with AI, and prompt-driven development, worked through on the team’s own code rather than a demo repository.
BUILD — AI Enablement Program (8 weeks)
The workshop plus a readiness assessment, tooling selection, guardrails definition, and six weeks of embedded support while the first real projects run under the new rules.
SCALE — AI Guild Setup (3 months)
The part that took us the longest to get right internally: AI champions placed in every team, a governance model that doesn’t bottleneck on one group, and a quarterly review built in from the start rather than added after something breaks.
Where this doesn’t help
A two-day workshop doesn’t fix an organization with no test coverage or no CI pipeline. Those are prerequisites, not something the workshop substitutes for. And the guild model we’re describing was built for engineering organizations in the 20–200 person range. A five-person startup doesn’t need a governance layer; a 2,000-person enterprise needs a heavier compliance structure than a guild alone provides.
It’s also not a one-off. The teams that got the least value from the ASSESS stage were the ones that treated it as a training day rather than the first step toward BUILD and SCALE. The workshop changes how a team works for a few weeks. The guild is what keeps that from decaying back into ad-hoc use once the workshop facilitator leaves the room.
If your team is stuck between AI pilots and an actual standard
The gap between individual AI experimentation and an AI-native SDLC isn’t closed by a better tool. It’s closed by deciding, deliberately, who owns the rules and how a practice moves from one team’s experiment to the whole organization’s default.
If that’s the decision you’re sitting on right now, our AI Adoption for Engineering Organizations workshop is usually the fastest way to see what it looks like on your own codebase before committing to more.
FAQ
What does “AI-native” mean if AI tools are already widely used on the team?
Wide tool usage isn’t the same as a shared standard. AI-native describes an organization where context rules, review expectations, and escalation paths for AI-assisted work are defined once and applied consistently — not left to whoever adopted a tool first.
How long does it take to go from scattered AI pilots to an AI-native SDLC?
Internally, the shift from ad-hoc experimentation to a guild-run model took roughly a year before it was stable enough to test at business-unit scale. A single team can move faster — the ASSESS and BUILD stages are designed to get one team operating under shared rules in about eight weeks.
Do we need a dedicated AI guild, or can existing tech leads own this?
Tech leads can carry it if AI adoption decisions are explicitly part of their role and they have a shared forum to align across teams. What doesn’t work is leaving it implicit — the guild’s value is that everyone knows where the decisions get made.
What’s the difference between the AI Adoption Workshop and the AI Enablement Program?
The workshop (ASSESS) is two days and covers the core practices hands-on. The Enablement Program (BUILD) adds a readiness assessment, tooling selection, and six weeks of support while the team applies those practices to live work.
Does this apply outside Java or backend-heavy teams?
The specific practices covered in the workshop — spec-driven development, AI-assisted TDD, code review with AI, prompt-driven development — apply across stacks. The guild and governance model is language-agnostic by design; it’s a process layer, not a tooling choice.
Share this article:
