2026-05-24
By Vadym · Generated with Boba, curated by me
What started as a "coding tool" rollout became something much bigger. This is the story of how that happened — from the inside.
I didn't set out to become the person who rolls out AI tools to an entire company. I was an engineer. I was at the frontier of using these tools early, and at some point the question shifted from "how do I use this?" to "how do we make everyone else use it?"
That's a completely different problem.
This post is the story of taking AI coding tools from a handful of curious engineers to 400 people — and eventually past 1,000. Not as a manager making a budget call, but as an engineer embedded in the process: evaluating tools, making the case to leadership, running pilots, sitting in procurement negotiations, writing assessments, and watching firsthand how people actually adopt — or resist — these tools.
I'm writing this now because the landscape is still in motion. Too many tools exist. Some will be gone in a year or two. People are mid-transition, or evaluating, or just trying to figure out which one to commit to. If you're in that situation — especially in a large org — I hope this saves you some time.
The first tool was GitHub Copilot. At that point, it was mostly chat and inline completion — not the agentic experience people talk about today. Getting engineers to even try it was a sell.
I started making short videos. Screencasts showing small, concrete wins. I'd bring examples to team meetings — not pitches, just demonstrations. "Here's five minutes I didn't spend writing boilerplate." That sparked some interest, but it was a slow burn. Most engineers were skeptical, and honestly, the tool itself was still early.
Before any of that, though, I had to get the tool into the company at all.
That alone was a journey. Security reviews for a cloud-connected AI tool touching source code are not fast. Everything was new — the threat models, the data handling questions, the approval process. I learned a lot about how enterprises actually evaluate software that year. We got through it, but it took longer than anyone expected.
After the license was in place, adoption crept up. Not a wave — more of a trickle. A year passed. More people were using it, but not enough to call it a real shift. And by then, the tools had moved on.
Getting leadership to buy a new tool isn't a technical argument — it's a trust argument. You're not selling features. You're asking someone to sign a budget line for something that most people in the room haven't used seriously.
The first tool taught me how that process works. By the time we were looking at a second tool, I knew what questions would come — security, cost, adoption risk, what happens if it doesn't work out.
The gap between "a few people love this" and "the org can use this" is enormous. Pilots are where you find out what the gaps actually are — not the ones vendors tell you about, the real ones.
Cursor was the second tool. I ran a one-month trial, and the interest level was completely different from the Copilot launch — about a hundred engineers joined the pilot. We ran trainings, collected feedback, shared usage patterns. The tool was genuinely better for a lot of workflows, and people noticed.
But the pilot is only half the story.
Windsurf came next — my proposal, after the Cursor situation fell through. I had learned from the previous round. I looped in procurement and legal much earlier. The Cursor process had dragged on too long; I didn't want to repeat that. Even so, the Windsurf negotiation took months. We started conversations in July. By the time a deal was signed, we'd landed on 50 licenses with an option to extend to 200+ at the same price. Not fast, but it worked.
Kiro — Amazon's tool — came with a different procurement dynamic entirely. We were already AWS subscribers, so the security review was largely a known process. The licensing came in around the same price point as Copilot, which made the business case much easier. And it brought something new to the conversation: spec-driven development. Rather than just autocomplete or chat, Kiro introduced the idea of writing a spec and letting the tool drive the implementation from it. A meaningful chunk of engineers jumped in specifically for that workflow.
ChatGPT Enterprise arrived through a different channel altogether — the business side of the company, not engineering, drove that purchase. Suddenly everyone had a subscription, not just developers. That shift mattered. It changed the internal conversation from "AI is a developer thing" to "AI is a company thing."
And bundled with that came something most engineers didn't notice at first: Codex. It was quietly available, no real limits at the time, and almost nobody knew what to do with it. That became my next promotion problem — not procurement, but awareness.
There's a version of this story that skips procurement. That version is fiction.
The Cursor deal is the clearest example. The pilot was strong. Engineer feedback was positive. A hundred people wanted to keep using it. And then Cursor came back with a number — a large upfront commitment, full engineering org, take-it-or-leave-it framing. The CTO's answer was no. Too much money, too much lock-in for a tool category that was still moving fast.
It was the right call, probably. But watching a successful pilot die in a procurement meeting is a specific kind of frustrating.
The Windsurf deal took a different shape. Smaller initial commitment, room to expand, better terms. It still took months. The lesson I took from Cursor — get legal and procurement in the room early, before you have momentum to lose — made the process more predictable, if not faster.
Kiro was the easiest. Existing AWS relationship meant the hardest parts of the security and procurement conversation were already done. That's not nothing. When you're the person pushing for these tools, already-approved infrastructure is a real advantage.
Somewhere in the Codex era, leadership made a call that changed the framing of everything.
The directive, roughly: stop writing code manually. Start using AI most of the time. The mental model they wanted engineers to shift into wasn't "AI helps me code" — it was "I review what AI produces." The job title stayed the same. The workflow was fundamentally different.
I was one of the people asked to demonstrate what that actually looks like.
I built a five-minute demo. A real bug fix. I didn't write the code — I supervised the agent in Codex, reviewed the output, checked the MR. The point wasn't to show off a trick. It was to make the new workflow concrete and legible for people who hadn't made the jump yet. Abstract encouragement doesn't move engineers. Watching someone actually do it does.
That demo went company-wide. We ran it across four or five sessions, covering different parts of the organization. It was the moment the conversation shifted from "AI is a tool some developers use" to "this is where the developer role is going."
There's a graveyard of internal AI training programs that nobody attended, watched, or remembered. The ones that worked looked different.
The Codex company-wide sessions worked because they were grounded in real workflow, not theory. A bug, a repo, a real MR — start to finish in five minutes. People could see themselves doing it. That's a different kind of training than a slide deck about AI capabilities.
Earlier with Copilot, the short video format helped. Not polished productions — quick screencasts of small wins, shared in channels where engineers already were. Low effort to watch, low barrier to try. The goal was to reduce the distance between seeing something and trying it yourself.
This story didn't start with me deciding to lead an AI tools program. It started with an Engineering Director who was already trying to move GitHub Copilot into the org and asked if I'd help. I jumped in. Eventually, as he needed to handle other AI initiatives across the company, he handed ownership to me and I kept going.
At some point, my role became something I didn't have a title for: being the voice of the engineers who were actually using these tools, surfacing what was working and what wasn't, translating that back to leadership, and making sure the tools the organization was paying for were the ones people actually wanted.
That's a different skill set than engineering. And nobody told me that's what the job would become.
The honest part: it was often too much. I was doing this alongside my primary engineering role — not instead of it. The work got done, but I was burning on both ends. My line manager expected full output from me as an engineer. The tools work had no formal allocation, no protected time, no headcount. The tension with my manager wasn't a conflict exactly, but it was real — he couldn't see the other job I was also doing, because officially that job didn't exist.
I raised it with the Engineering Director many times. He understood, but there wasn't much he could do. There was no budget line for "AI tools lead." No position code. We were both doing this on the side of our actual roles, because we saw a gap that nobody else was filling.
If not us, who? That's not a rhetorical question — it's the thing that kept it going.
And the resistance was real. At the beginning, pushing these tools felt like moving against the current. Security skepticism, engineer skepticism, leadership skepticism. The green lights started coming when other companies publicly committed to AI tools — when it became undeniable that this was going to change the industry. Then, suddenly, we had visibility and support that hadn't been there before.
What made that shift land well for us: we'd already been at it for a year. The pilots, the learnings, the trust we'd built with early adopters — all of that was in place when the organization finally turned around and said "yes, this matters." We were ready because we hadn't waited for permission to start.
Before the company-wide sessions about moving from coder to reviewer, I built a small website that explained what each stage actually meant. My framing was slightly different from management's — this was my own research, not a top-down message — but it was close enough to be useful. It gave people a map.
The stages I laid out: Editor (AI assists your writing), Reviewer (you review what AI produces), Director (you direct AI on what to do), Orchestrator (you coordinate multiple AI agents working in parallel). Management was pushing people toward the Reviewer stage. I was already thinking about Director. The Orchestrator stage was the horizon.
That framing helped. Abstract mandates from leadership don't move people. A concrete progression they can locate themselves on does.
The company-wide Codex sessions were part of that role. Being the person on screen demonstrating a new way of working — that's not a job description, it's something that accumulated over years of being the one who tried things early and could explain them to others.
There were two separate role situations worth naming.
The first: an AI Director role opened on the enterprise side. I applied, didn't get it — someone already closer to the decision-maker got it instead. That one stung but was straightforward.
The second was more interesting. An Engineering Director role opened — not explicitly AI-focused, but the person who'd held it had been deeply involved in driving AI adoption across engineering. I was a candidate.
The feedback I got, more or less: everything I'd been doing — managing licenses, running pilots, driving procurement, advocating for tools, enabling engineers — none of that made me a manager. The path from Staff Software Engineer to Director runs through Manager, then Senior Manager, then possibly Director. The panel thought about career ladders the traditional way. I hadn't climbed those rungs.
I can't say they were wrong. But here's the thing: the role was ultimately opened and closed without anyone being hired. The company couldn't agree on what an Engineering Director is supposed to do in the current era of AI. What does engineering leadership look like when AI is doing more of the execution? Nobody could answer that, so the position was retired.
I found that more clarifying than the rejection itself.
What I can say honestly is that throughout all of this — every pilot, every procurement cycle, every company-wide session — my title stayed the same: Staff Software Engineer. The work I was doing had a different shape. I had exposure to leadership conversations I wouldn't normally have been in. Some influence over which tools the company bought and how much was spent on them. Visibility across the organization.
None of that showed up in my compensation.
The return was reputational. Recognition from engineers who appreciated having someone advocate for better tools. Trust from managers who came to see me as a reliable read on what was happening in the space. That's worth something — I'm genuinely not sure how much, in material terms.
What I do know is that the experience is real and transferable. The ability to navigate procurement, run meaningful pilots, build internal cases for new technology, and help people cross the gap between knowing a tool exists and actually changing how they work — that's a specific skill set. One that's increasingly rare and increasingly valuable. Whether it compounds at the current company or somewhere else is still an open question.
There's an interesting symmetry in how this all unfolded.
ChatGPT Enterprise came in as a company-wide tool — everyone had access, not just developers. Over time, through Codex, it became a deep developer workflow tool. Broad to narrow.
The most recent tool in this sequence ran the opposite direction.
It started as an agentic coding platform — a developer tool, evaluated and trialed the same way as everything before it. I got involved as lead for the trial, the negotiations, the license acquisition. Prior conversations about it hadn't gone anywhere; this time we moved more deliberately.
What became clear quickly is that this one didn't stay in the engineering lane. The nature of the tool — more conversational, more capable across different kinds of work — meant other parts of the organization started paying attention. Security teams. Project managers. Product managers. Designers. The interest wasn't pushed; it surfaced on its own.
The pattern from ChatGPT Enterprise → Codex had run: company-wide tool becomes a developer tool. This one was running the reverse: developer tool becoming a company-wide tool.
Negotiations are still in progress as I write this. But the trajectory is visible. This is probably where things are going — not a specialist tool for engineers, but an AI layer that spans the whole organization, with depth in whatever domain each person brings to it.
People don't evolve on their own. This is the most consistent thing I observed across every tool, every rollout, every company-wide session. Engineers are good at learning — but they learn in response to evidence, not instructions. They need to see what's actually possible before they'll change how they work. Telling people that AI will make them more productive does almost nothing. Showing someone a five-minute demo of a bug fix they recognize does something.
Remove the fear of limits. One of the things management did right: giving people space to explore without worrying about hitting usage caps, getting in trouble, or doing it wrong. Trials with real access and no artificial pressure let engineers form their own opinions. That's where genuine adoption starts — not from a mandate, but from someone trying something and thinking "this is actually useful."
Structure matters more than enthusiasm. Documents, framing, a progression people can locate themselves on — these things lower the activation energy for change. The website I built explaining the Editor → Reviewer → Director → Orchestrator stages helped because it gave people a map. Abstract encouragement doesn't move engineers. A concrete picture of where they are and where they're headed does.
Someone has to be the voice. Every successful rollout I've seen has at least one person who is not just using the tools, but actively translating between what engineers are experiencing and what leadership needs to hear. That role doesn't come with a title. It accumulates. But it matters — probably more than the tool itself.
You can't do it alone — and you don't need budget to build a team. I tried to bring others along. I couldn't pay them. What I could offer was time, and information — sharing what I'd learned about what was happening with AI tools inside the company and in the broader world. It turned out that was genuinely valuable currency. People wanted to be closer to the frontier. Giving them access to what you're seeing, ahead of when it filters down through official channels, is enough to build a small network of people who'll help carry the work.
Don't just open a signup form — seed your pilots intentionally. The standard approach is to send an email and wait for volunteers. You'll get some, but not necessarily the right ones. I learned to reach out directly to people I knew would actually try the tool, give honest feedback, and talk about their experience. Those people fill seats, generate signal, and make the pilot useful. A hundred curious engineers on a mailing list is worth less than twenty engaged ones you personally recruited.
Measure what matters. The most valuable metric I tracked was daily active users — not registrations, not seats assigned, actual daily engagement. Lines of code accepted, tokens spent, active sessions: these numbers tell you who's genuinely changed their workflow and who just signed up. They also tell you where your organization sits on the maturity curve. When the daily active numbers start climbing without being pushed, adoption is real.
Cost discipline is part of the rollout. Tools will default to steering users toward the most capable — and most expensive — models. That's not always the right call. Part of my job became informing engineers about where the value actually was, and when a cheaper or faster option was good enough. Burning through budget fast is easy. Burning through it well takes active attention. If you're not tracking spend and communicating about it, the invoice at the end of the month will be the first signal you get — and it won't be a useful one.
People don't read emails. Use multiple channels and repeat yourself. I cannot count the number of times I sent what I thought was a clear, well-timed communication and got blank stares at the next session. Record every training. Announce the recording in at least two places. Send it again a week later. People who missed the live session, or skimmed the email, or meant to watch it later — they exist in every organization. Meeting them where they are, more than once, is not spam. It's how information actually reaches people.
We're at a strange inflection point. The number of tools has exploded. Several of them are solving the same problem in slightly different ways, and a meaningful portion will be gone or consolidated within two years. Organizations that made big bets on one platform are already feeling the whiplash as the category evolves.
Most teams right now are somewhere between Reviewer and Director. The ones pushing hard are trying to reach Director — meaning they direct AI to do the work and mostly review the output. Orchestrator is the next frontier: coordinating multiple agents running in parallel, each handling a piece of a larger problem.
What I know from being inside this for years: the tool matters less than the culture around it. The organizations that win are the ones that build the habit of adopting, not the ones that pick the right tool at the right moment.
I drafted this post by speaking into voice notes and having an AI agent transcribe, structure, and write it alongside me. I reviewed every section, added context, corrected the direction.
That's the Orchestrator stage. Not in theory — in practice, on a Sunday evening, talking through years of experience and watching it take shape.
I've tried to stay a step ahead of the curve throughout this story. Not so far ahead that I lost the thread of what teams actually needed, but far enough to see what was coming and help others get there faster.
The next challenge — for me and for every engineering organization I know — is making the Orchestrator stage as legible as the Reviewer stage was three years ago. That's the work now.
More on this to come. This is the first in a series on what enterprise AI adoption looks like from the inside.