Host Intro (Gene Kim)

So here's a confession. For over a year, I've been trying to find someone at Block to learn more about their AI journey. And then Angie Jones, who led their AI enablement across the entire company, reached out to me, and I'm so grateful she did, because she has absolutely blown my mind every time I get to interact with her.

So three years ago, she led Block's developer relations group, and the founder, Jack Dorsey, asked her to lead AI enablement across the entire company. And she assembled 50 of the most switched-on developers across every major monorepo, every business unit, to scale AI adoption across the company, across the entire engineering organization. She then became Block's VP of Engineering, AI Tools and Enablement, and she and her team were able to achieve so many things.

Angie is now bringing this expertise to the Linux Foundation's new Agentic AI Foundation, created by Block, OpenAI, and Anthropic, helping the entire open source ecosystem level up. And I'm so grateful that she's willing to share her journey with us here.

Here's Angie.

---

Angie Jones

All right, here we go.

So I have spent the last couple of years transforming Block's 3,500-person engineering org into an autonomous one, and this is a challenge that most tech companies are trying to solve right now — or you will be very soon. So today I just wanted to share our path for getting there.

Our agentic coding journey actually started very early. We were building Goose, which is our internal coding agent, even before the LLMs supported tool calling. And we worked with Anthropic as design partners on the initial release of MCP, and Goose became the reference implementation for the protocol. So internally, our most curious engineers were some of the first in the industry to work with these types of coding agents.

Now, after a couple of months, about 90% of our engineers were using tools like Goose, like Claude Code, to regularly generate code. So on paper, this looked like we were all in on AI, yes?

But our CEO was convinced that engineering wasn't using AI at all — just couldn't be — because he's not seeing anything ship to the customer any faster. But I had the numbers, the stats, the bills from the frontier providers. I had all of this. So I knew that we were in fact using AI, but he was right: features certainly weren't shipping any faster.

So I began to dig into this a little bit more.

I think of AI enablement in three phases. We have the experimentation phase, the adoption phase, and then the impact phase. I'd say we had comfortably surpassed the experimentation phase — we got 90% of engineering using AI — but they're still just inside the IDE, using Copilot, that sort of thing, asking questions, writing some boilerplate code. And if we really wanted to see the impactful outcomes from this work, I knew that we needed a way to integrate AI into not just coding, but how we build, how we ship.

So I had spent the first half of 2025 leading AI enablement across the entire company — all functions: marketing, design, finance, legal. This was 12,000 employees. So now our CTO was saying, "Hey, I need you to go really deep on engineering and build us an agentic engineering org."

Okay, sure. But what does that actually mean? There's no playbook for any of this stuff, and I know because I went to a lot of your blogs. I was looking for the answer, and you all said, "I don't know. We are just making it up as we go." So I did the same thing.

In the simplest of terms, I define the agentic engineering org as one where engineers leverage AI as their primary means of producing engineering outcomes. That meant we had to treat the agents as core members of the engineering workflow — not just using them to help us write code here and there, but actually working with the agents, decomposing problems, delegating work to them, reviewing and verifying the outcomes. And if we wanted engineers to direct that work as their default way of operating, we knew we had to get them in a position to do so, because they are not there yet.

So I came up with a maturity model. This model measures the engineer's relationship with AI agents — how they think, how they delegate, how they orchestrate. I had some form of this model around Q3 last year, but Yegge's "Ghostown" article — banger, by the way — helped me reorganize it into a better model.

Stage zero is where the engineer just isn't using AI tools in the workplace at all. Stage one: they use AI to auto-complete, never went into agent mode with any of these things. Stage two: chatting with the agents but not producing PRs with it. Stage three: they're delegating work to the agents and reviewing that output. Stage four: now we're running multiple agents in parallel. And then stage five, that final boss — where the engineers are delegating complete tasks to agents, letting the agents produce shippable results without too much hand-holding.

I'd say that by the end of the first half of 2025, the bulk of our engineers were between stage one and stage two, and I needed to get them to stage five.

Now, I wasn't quite sure how to get 3,500 engineers to that level, especially when: one, this is all highly experimental — again, there is no playbook, we're all just making it up; and two, things are moving so fast. If it were static, maybe we could figure this out a little quicker. But something that might be a best practice today could very well be outdated tomorrow when the next release of a model or agent comes out. And this was leading to a lot of AI fatigue — folks were sick of hearing about the constant change. And three, people were already turned off by the top-down mandates, the pressure from leadership to "AI or die."

So I thought about the 1-9-90 rule. In digital communities, 1% are going to create; 9% will interact; and the rest, the 90%, they're just going to passively consume. This maps almost exactly to how engineers adopt AI. You're going to have that small percentage — they're going to dive deep. They're going to create the agentic patterns. They're discovering the useful techniques on how to work with agents. They're creating the skills library and everything that we need. The 9% might tweak an `agents.md` file here or there, but they're not doing too much. And then the rest of the folks — they're not going to spend those extra cycles trying to figure this stuff out.

So I realized that if my AI strategy relied on everyone individually leveling themselves up, this was never going to work. So I leaned into this model and used it to my advantage. Instead of focusing on all 3,500 engineers, I decided to focus on forming that 1% — the power users — from our most critical teams.

I started an AI Champions program, and this was not a call for volunteers. I handpicked 50 engineers from across the company who could pioneer agentic engineering within their teams. And I needed to be really strategic about this selection, because I'm asking them for 30% of their time to devote to AI enablement on their teams — not just for themselves, but for their entire teams. And I needed people who are not going to be discouraged by, "Hey, it doesn't work. It's not deterministic." No time for that. Put your engineering hat on — we've got to figure this out.

So I spent a week talking to tech leads and engineering managers to find my 50 people, and I needed the ones that would represent our most critical repositories.

Now, remember, at this point most of our engineers were between stages one and two — chatting with AI, not really using it for PRs. So I wanted to see if we could get the AI champions to stage three. This was about June 2025. The models are decent at this point — we can write a feature — but we can't guarantee that feature is going to conform to your standards and your code base. So generally, the developers didn't quite trust the output of the agents enough to delegate work to them.

So the first area we focused on was: how do we make our repos AI-friendly so that we change that? My theory was, if I can get engineers to embed AI directly into their repos, then not only would the agents perform better, but the entire team should benefit from this — not just the 1% — because the repos are the central point of reference for every engineer contributing code. So to make their repos AI-ready, they added assets like context files and rules files so that the agents could reliably understand, navigate, and contribute to the code base.

Now, when building the AI Champions program, I had to make sure we had folks from every corner of Block engineering: Square, Cash App, Afterpay, Tidal — across front-end, back-end, mobile, data, infra. We covered repos of all shapes and sizes: the big nasty monorepos with thousands of services, the really small focused service projects, mobile apps, all of that. And this mix let us pressure-test these patterns across different engineering realities so we could quickly see what actually scales.

Now, as expected, those monorepos definitely came with their own challenges. But — shout out, do I have any JVM folks in the room? All right. Shout out to the JVM folks and their brilliant skills in object-oriented programming, because they were able to clearly see, "Oh, this is an inheritance problem," and so they did a lot of work at the root of the monorepo — things that would trickle down to the services — and then layered specific ones at the service level. We also learned that what works for web doesn't necessarily work for mobile, and even your Android and your iOS teams might have different approaches to this.

So instead of forcing a one-size-fits-all onto everyone, each champion figured out what works for their repo. And teams of different shapes and sizes naturally converged on the same patterns. Honestly, the engineers loved this approach — it was no longer a top-down "you must do it this way" or "you must use this tool." They were able to get creative and do what worked best for them. And these are trusted people on their teams. This is not Angie telling a team they have to do X, Y, and Z — this is Rob, who you've worked with for five years, who you trust, who knows the code base as well as you do, if not more. And so that resonated more with the teams.

Now, we did end up with a standard set of components that would make a repo AI-friendly, again customized for each team's needs. Some context files — like `agents.md`, `claude.md`, and similar — provide the agent with some repo guidance. Rules files provide the agent with guardrails: what should you not do in this repo versus what do we need you to do. Repeatable workflows — recipes and commands. Later, agent skills. An enabled AI code reviewer, preferably with instructions around what matters to your team. And AI attribution on the PRs. We added scoring for each of these so contributors could assess where their repo stands at any given time, and we later turned this into a skill where your agent could even help you get some of this stuff done.

---

So at this point, we've done a lot of great work. Technically, we do have the agents writing PRs now. But I had a couple of concerns before I called victory. Not many outside of the Champions program had gotten to the point where they realized they could delegate work to agents. And the whole idea of this 1% is to uplift everyone, not just have 50 great AI engineers in the company. And even those champions themselves — they're delegating, but they're babysitting: "Hey, do this part of it, let me look. All right. Now do this part." So I wanted to explore if we could delegate work to the agents in a more hands-off approach, and make it easier for others outside of the Champions program to do that as well.

There are three common places where engineers receive requirements for their work. You've got your issue trackers that the whole team uses — things like Jira, Linear. You've got your engineering issue tracker — GitLab, GitHub. And then informally, your conversation tool — Slack, in our case. So I wanted to be able to delegate work to the agents from any of these interfaces. And so the champions implemented all three of these.

True story: we're in Slack. Developer One says, "I think there's a bug in this product." Developer Two says, "Huh, I hadn't seen anything like that." Developer Three — the switched-on person — comes into the conversation and says, "Hey, @Goose," which is the internal agent, "go and look and see if this is a problem." So Goose has the context of the conversation, goes and looks in that repo, brings the code snippet back, and says, "Yep, there is a bug. It's right here on line X, Y, and Z. Here are three possible solutions to solving it," complete with code snippets. So right there in Slack, Dev One says, "I like option one." Dev Two says, "Yeah, me too." Dev Three says, "Good. Goose, go and implement option one." And we get a PR back.

This entire thing — identifying the bug, discussing it amongst the team, triaging it, converging on a solution, and getting to a result — happened in five minutes. This is where we wanted folks to be. Cool party trick, by the way.

Engineers were also now able to assign agents Linear tickets, Jira tickets, GitHub issues, and have them do that work end to end. People really loved this flow. In fact, the first time we did it, the team had their normal amount of work for their three sprints. By week one, they were done — had to pull in more work, agent knocking it out. Week two, done again. They had to pull in more work a second time during that sprint. I think they ended up out of work for that project and moved on to something else. This all blew everyone's minds.

So now I felt comfortable claiming that we're truly delegating work. At this point, it had been about three months since I launched the Champions program, and we had AI-authored code up by 69%. Engineers were reporting a 37% increase in time savings, and automated PRs had increased by 21 times. So now we were ready to pursue multi-agent parallelism.

---

With our setup, moving to stage four was almost free, honestly. We had gotten pretty good at delegating the work. But this stage introduced several new challenges we needed to solve.

Our engineers are now tripling, quadrupling the number of PRs they're producing, but they're stuck in code reviews. How many of you are there? Yes. People struggled to stay on top of code reviews before we introduced AI into the mix, so you know it's bad now. And I'll be honest — this is not a solved problem. I hope you're not waiting on the answer to this. I do not have it for you today, but I'm working on it. I'll share how we did stop the bleeding just a bit.

We had to get the bots to help us with the PRs. Earlier in the process, this was optional — you could turn on the AI code reviewers if you wanted to for your team. But because they were doing such a poor job, it was frustrating engineers and everyone was turning it off. But now, with that repo readiness work the champions had done, the agents were able to do a much better job at this. And the models got better — Codex is what we use, really good at this sort of thing. We also created an auto-fix loop: if Codex identifies issues, another agent automatically fixes those issues and commits them back to the PR. So by the time engineers got the PRs, they were actually in pretty good shape — people weren't complaining about reviewing sloppy PRs from the bots anymore.

Another issue, specifically when running multiple agents in parallel, was that the agents were bumping into each other as they tried to do work. And more importantly, our machines could no longer handle the load — battery, memory, CPU, everything just depleted. So we invested in cloud workstations where agents run in their own isolated environment. This also allowed us to do parallel work much more easily.

Now, at this point, engineers are cooking. They've got four or five agents running at any given time, and this number just kept growing. So a small group of engineers, including many from the AI Champions program, started building our own orchestrator to coordinate all the agents. We needed this to get to that autonomous engineering org.

And we realized that if we were trying to build anything close to an autonomous engineering org, the agents need to understand where everything is, how they relate to each other, and not stop and ask questions. So we built a company world model based on the entirety of our 25,000 repositories — a machine-readable view of every single service within the company and how they all connect. This was really important because we have multiple products that had been siloed for a very long time, and a lot of our advantage as a company is being able to integrate some of those. So this world model allowed the orchestrators, and the agents they delegated to, to pull context as needed, understand the landscape as they implement, explore different parts of the system, form opinions, bring those plans back, and let the orchestrator put it all together into a master plan that spans multiple code bases, maybe multiple products.

So with this, we had successfully reached stage five, where our engineers are delegating complete tasks to the agents and the agents are able to produce great, shippable results. In fact, this was no longer limited to engineers. With our Slack setup, anyone in the company could add a bot and say, "Hey, fix this bug I noticed," or "Hey, implement this new feature." They didn't even need to have a GitHub account.

So this felt like the dream.

Until it became a nightmare.

---

Of course, layoffs are tough. But y'all, this one hit different.

I had so many questions.

Did I do this?

Did enabling our employees to do some of the most incredible work of their careers ultimately lead to their dismissal?

Just the day before, I had felt so proud. I remember thinking back, just in awe of the way we were working, feeling so accomplished. I had successfully built this autonomous engineering org.

But to what end?

So I'm going to leave you all with a couple of questions. Namely: what are we doing? Where are we headed? And are we sure that this is where we want to end up?

Thank you.