Talk by Angie Jones (Agentic AI Foundation) on transforming a traditional enterprise engineering organization into an autonomous, agentic one. Covers why acquiring frontier models and tools is insufficient, the shift required across the software delivery lifecycle (design, development, deployment), transitioning software engineers into agentic engineers, the supporting systems and processes, and the new challenges agentic engineering poses for large enterprises. # Observable Presentation Evidence — "Building an Autonomous Engineering Org" (Angie Jones, Agentic AI Foundation) ## Intended Audience - **Engineering leaders and practitioners at technology companies facing AI adoption.** The speaker frames the problem as industry-wide: *"this is a challenge that most tech companies are actively trying to solve or will be in the very near future."* - **Conference audience of peers.** She directly addresses the room as fellow practitioners: *"I know because I went looking at your blogs hoping that you all had it all figured out."* - **Decision-makers responsible for AI enablement strategy** — she discusses CEO/CTO dynamics, maturity models, and organizational rollout strategy rather than basic tooling tutorials. ## Claimed Scope - **First-person account of an enterprise-scale transformation**: *"I've spent the last couple of years transforming Block's 3,500-person engineering org into an autonomous one."* - **Cross-functional enablement experience**: *"I spent the first half of 2025 leading AI enablement for our entire company. So, 12,000 employees across every function."* - **Deliverables presented as original frameworks from this work:** - A three-phase model: *"experimentation, adoption, and impact."* - A five-stage maturity model for engineer–agent relationships (credited in part to Steve Yegge's Gastown article: *"helped me reorganize it into a better model"*). - An "AI champions" program structure and repo-readiness component standards. - **Named tools and partners**: Goose (Block's internal coding agent, *"reference implementation for the MCP client"*), Claude Code, Codex, Jira/Linear, Slack, and a partnership with Anthropic on MCP. ## Explicit Self-Description Evidence - **Role claim**: Speaker identifies as the leader of this initiative — *"I spent the first half of 2025 leading AI enablement for our entire company"* and *"our CTO tasked me with building an agentic engineering org."* - **Presentation purpose claim**: *"today I'll share our path to getting there"* — positions the talk as a case-study/roadmap sharing, not a pitch or tutorial. - **No explicit channel-level self-description** appears in the transcript (no statements about the channel itself, its mission, or subscription/branding). ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Case-study narrative format**: chronological retelling (early Goose work → 90% adoption → champions program → stage four/five → layoffs), with concrete metrics: *"AI-authored code was up by 69%, reported time savings increased 37%, and automated PRs increased 21 times."* - **Candid, reflective tone**: openly admits failures and doubt — *"the AI code reviewers sucked so badly, and we were just pissing the engineers off"*; the closing layoff reflection: *"Was this my fault?"* - **Practitioner-level technical specificity**: repo context files (agents.md, claude.md), auto-fix review loops, cloud workspaces for parallel agents, a company-wide world model over *"25,000 repos."* - **Critical/ethical framing at the close**: ends with open questions rather than a sales pitch — *"What are we doing? Where are we heading? You sure that it's where we want to end up?"* ## Notes on Source Limitations - **No curated metadata was supplied**; all observations derive from the title and transcript alone. - The title attributes the talk to Angie Jones and the Agentic AI Foundation; the transcript itself does not restate the speaker's name or venue. # Delivery Observations: "Building an Autonomous Engineering Org" — Angie Jones ## Tone and Register - **Conversational, first-person narrative**: delivered as a personal retrospective, framed with "So, I've spent the last couple of years transforming Block's 3,500-person engineering org." - **Shifts dramatically in register near the end**: the closing moves from upbeat war-story mode to a somber, reflective tone — "This felt like a dream. / Until it became a nightmare." - **Casual, colloquial phrasing** throughout: "Okay, sure," "all right?", "Very cool party trick, by the way," "the engineers are cooking." ## Recurring Verbal Habits - **Sentence-initial "So"** as a discourse connector, appearing constantly: > "So, today I'll share our path to getting there." > "So, I began to dig into this a bit." > "So, to make their repos AI friendly, they added assets like contacts and rules files." - **Rhetorical tag "right?"** appended to statements to invite agreement, repeated many times: > "As far as he was concerned, because we weren't shipping any faster... he was right." > "This was not a call for volunteers, all right?" > "engineers' laptops were running out of memory. CPU was choking, you know?" - **"you know"** as a recurring filler/connective, e.g., "they still were kind of using it inside of their IDE, you know, asking questions." ## Storytelling and Structural Habits - **Narrative framing with explicit stakes and numbers**: heavy use of concrete metrics — "3,500-person engineering org," "90% of our engineers," "50 engineers," "69%," "37%," "21 times," "25,000 repo code base." - **Numbered/structured mental models**: "I think of AI enablements in three phases: experimentation, adoption, and impact," followed by a staged maturity model (stage zero through stage five). - **Story-within-a-talk**: a dramatized Slack bug-fix anecdote with mock dialogue — "Engineer three @goose right there in Slack and says, 'Hey goose, have you seen this bug before?'" - **Sequential problem/solution arc**: each stage of the maturity model introduces a challenge then its fix (code review bottleneck → Codex auto-fix loop; laptop overload → cloud workspaces). ## Vocabulary and Phrase Choices - **Insider/gaming-flavored language**: "stage five is that final boss," "the engineers are cooking," "stop the bleeding." - **Repetition of "playbook" as a motif** for the absence of established practice: > "There's no playbook for any of this stuff, right?" > "There's no playbook, again, for any of this." - **Blunt, unpolished honesty about failures**: "Mostly because the AI code reviewers sucked so badly, and we were just pissing the engineers off." - **Crediting and name-dropping external tools/people**: Anthropic, MCP, Steve Yegge's "Gastown" article, Codex, Goose, Claude Code. ## Communication Patterns - **Rhetorical questions** used to pivot or dramatize: "But, what does that actually mean?" and "Was this my fault?" - **Self-aware humor and asides**: "I went looking at your blogs hoping that you all had it all figured out. But, I only saw a bunch of posts saying how you all were making it up as you went along. So, I did the same, right?" - **Rule-of-three listing** habit: "Decomposing problems, delegating work, reviewing and verifying what was done"; "One, this is all highly experimental... two, things were moving so fast... And then three, people were already feeling turned off." ## Ending Pattern - **Abrupt tonal reversal**: pivots from a success narrative to open-ended ethical questioning, ending on unresolved rhetorical questions: > "What are we doing? Where are we heading? You know, we sure that it's where we want to end up?" - Notable that the talk **does not close with a summary or call to action**, breaking the established structural rhythm — this appears deliberate, though intent cannot be verified from delivery alone. ## Uncertainty Notes - Timestamps are coarse (transcript chunk indices only); precise pacing, pauses, and vocal delivery cannot be observed. - Delivery features like gesture, audience reaction, or slide usage are not observable in this transcript. - The "So, ..." and "right?" patterns are strongly evidenced by repetition; tonal shifts are inferred from word choice only, not vocal qualities. # Observation Record: "Building an Autonomous Engineering Org" — Angie Jones, Agentic AI Foundation ## Speaker - **Angie Jones**, describing her role leading AI enablement at Block (per transcript self-identification). ## Background & Context - Spent "the last couple of years transforming Block's 3,500-person engineering org into an autonomous one"; describes this as a challenge most tech companies face or will face. - Block built **Goose**, an internal coding agent, **before LLMs supported tool calling**; worked with **Anthropic as design partners** for the initial **MCP** release; Goose became the reference implementation for the MCP client. - Spent the first half of **2025** leading AI enablement for the whole company (~12,000 employees across marketing, design, finance, legal); the CTO then tasked her with building an agentic engineering org. ## Key Claims & Reasoning ### The Adoption–Impact Gap - Within months, ~**90% of engineers** used tools like Goose and Claude Code regularly — "on paper, it looked like we were all in on AI." - **Contradiction observed:** The CEO believed engineering wasn't using AI because shipping speed hadn't improved. Jones states the CEO "was right" that features weren't reaching customers faster, despite metrics and token bills proving AI usage. - **Her framework:** three phases of AI enablement — **experimentation, adoption, impact**. Block had passed experimentation but usage stayed inside the IDE (questions, boilerplate); impact required integrating AI into build-and-ship workflows. ### Definition of Agentic Engineering Org - "Engineers leverage AI agents as their primary means of producing engineering outcomes" — agents as core workflow members: decomposing problems, delegating, reviewing/verifying, directing work by default. - Notes **no playbook exists**; she checked industry blogs and found only "making it up as we went along" posts. ### Maturity Model (six stages; reorganized with help from Steve Yegge's "Gastown" article) - **Stage 0:** No AI tools. - **Stage 1:** Autocomplete only; never agent mode. - **Stage 2:** Chatting with agents, no agent-produced PRs. - **Stage 3:** Delegating tasks, reviewing output. - **Stage 4:** Running multiple agents in parallel. - **Stage 5:** Delegating complete tasks; agents produce shippable results without human guidance. - Mid-2025 status: bulk of engineers between **stages 1 and 2**; goal was stage 5. ### Stated Challenges to Scaling 1. Highly experimental; no playbook. 2. Best practices could be outdated within a week — leading to **AI fatigue**. 3. Top-down "AI or die" pressure turning people off. ### 1-9-90 Strategy - Applied the **1990 rule** (1% create, 9% interact, 90% consume) to AI adoption; concluded a strategy depending on every individual leveling up would never produce broad impact. - Instead formed an **AI champions program**: ~50 handpicked (not volunteer) engineers from critical teams, required to dedicate **≥30% of their time**, resilient to AI's non-determinism. - Selected via tech leads/managers to cover Square, Cash App, Afterpay, Tidal; frontend, backend, mobile, data, infra; repos of all shapes including legacy monorepos. ### Making Repos AI-Ready (target: stage 3, ~June 2025) - **Her theory:** embedding AI directly in repos improves agent performance and benefits whole teams, since repos are a central reference point. - Champions added: context/rules files, repeatable workflows (slash commands, later agent skills), AI code reviewers with instructions, AI attribution on PRs. - **Findings preserved as stated:** - Monorepos: shared contexts/rules at root, layered specific ones at service levels (leveraging JVM devs' inheritance-pattern experience). - Web patterns didn't necessarily transfer to mobile; Android and iOS sometimes needed different approaches. - No one-size-fits-all mandate; teams converged naturally on tools/patterns — engineers "loved this." ### Delegation from Existing Workflows - Three requirement sources — issue trackers (Jira/Linear), GitHub issues, Slack — all three implemented by champions. - **Slack bug anecdote (as told):** engineer reports bug → goose diagnoses, offers three fix options → engineers pick option one → goose implements and returns PR link; full cycle "like 5 minutes." - Agents assigned Jira/Linear tickets and GitHub issues end-to-end; "agents have become a part of the sprint." First time, a team pulled in more tickets twice. - Key insight: other engineers didn't need new skills — champions' foundation made delegation "native to how people already work." ### Results at 3 Months - AI-authored code up **69%**; reported time savings up **37%**; automated PRs up **21×**. ### Stage 4: Parallel Agents — New Problems - **Code review bottleneck:** PR volume tripled/quadrupled, stuck in review. "Not a totally solved problem" — mitigation: enabled **Codex** on all repos plus an **auto-fix loop** (another agent fixes identified issues and commits). Earlier AI reviewers "sucked so badly" and angered engineers; repo-readiness work plus better models improved results. - **Resource exhaustion:** laptops ran out of memory; solved with dedicated **cloud workspaces** — isolated environments per agent, runnable in parallel from anywhere. ### Stage 5: Builder Bot Orchestrator - Small group (including champions) built **Builder Bot** to coordinate agents. - Built a **company world model** of the entire **25,000-repo** codebase — machine-readable view of every service and its connections — letting orchestrators and agents pull context on demand and merge parallel explorations into cross-codebase plans (useful for multi-product offerings). - Result claimed: stage five reached; non-engineers could invoke Builder Bot in Slack to fix bugs or implement features without needing GitHub. ## Unresolved Tension & Qualifications (preserved) - **The ending pivot:** "This felt like a dream. Until it became a nightmare." Jones describes a layoff at Block and her questions — "Was this my fault? Did enabling employees to do the most incredible work of their careers ultimately result in their dismissal?" She states no answer, closing with open questions: "What are we doing? Where are we heading?... Are we sure that it's where we want to end up?" - Code review bottleneck explicitly **not fully solved**. - Tone markers of tentativeness retained: "very cool party trick," "I'll be honest," "to what end?" # Speaker & Provenance Observation Record ## Video Identification - **Title:** Building an Autonomous Engineering Org - Angie Jones, Agentic AI Foundation - **Video ID:** `01a15ca8-e0e2-7b3f-8f79-c3f617417ae5` ## Speaker Inventory | Speaker | Role | Evidence | |---|---|---| | **Angie Jones** | **Sole speaker / presenter** | Title attribution; first-person account of leading AI enablement at Block | - **Format:** Single-speaker talk; no guests, narrator, panelists, or Q&A voices appear in the transcript. - **Speakers referenced within the narrative (not direct speakers):** - **Block CEO** — claimed engineering "wasn't using AI" because shipping hadn't sped up (reported secondhand). - **Block CTO** — tasked the speaker with building an agentic engineering org. - **AI champions** (~50 handpicked engineers) — described as implementers; quoted only in the speaker's anecdote about unnamed "engineer one/two/three" in Slack. ## Referenced Sources & Third-Party Claims - **Steve Yegge's "Gastown" article** — cited as influencing the speaker's maturity model reorganization. - **Anthropic** — Block worked with them as design partners on the initial MCP release. - **Tools/products named:** Goose (internal), Claude Code, Codex, MCP, Jira, Linear, GitHub issues/PRs, Slack, Builder Bot (internal orchestrator), agents.md / claude.md files. - **Concepts cited:** the **1990 rule** (1% create / 9% interact / 90% consume in digital communities). - **Internal metrics claimed (unverifiable from transcript):** 90% engineer AI usage; AI-authored code up 69%; reported time savings up 37%; automated PRs up 21x; 3,500-person engineering org; 12,000 total employees; ~25,000 repos. ## Promotional Segments - **None detected.** No sponsor, product placement, or call-to-action segments present. ## Provenance Notes & Uncertainty - All figures and anecdotes are **first-person claims by the speaker** with no external verification available in the source material. - The layoffs mentioned at the end are described without attribution, dates, or specifics — context remains **uncertain**. - No curated metadata supplied beyond title; **comment availability unknown**. So, I've 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 actively trying to solve or will be in the very near future. So, today I'll share our path to getting there. Our agentic coding journey started very early. We were building Goose, our internal coding agent, even before the LLM supported tool calling. We worked with Anthropic as design partners for the initial release of MCP, and Goose became the reference implementation for the MCP client. So, internally, our most curious engineers were some of the very first in the industry to use these types of coding agents. After a couple of months, about 90% of our engineers were now using tools like Goose and Claude Code regularly to generate code. So, on paper, it looked like we were all in on AI. But our CEO was convinced that engineering wasn't using AI at all. Like, they couldn't be, right? As far as he was concerned, because we weren't shipping any faster. Well, I had the numbers, both the metrics and the token bills. So, I knew that engineering was, in fact, using AI, but he was right. Features certainly weren't making it to our customers any faster. So, I began to dig into this a bit. I think of AI enablements in three phases: experimentation, adoption, and impact. I'd say that we surpassed the experimentation phase as 90% of our engineering org was using AI, but they still were kind of using it inside of their IDE, you know, asking questions or writing boilerplate code. And I knew that if we really wanted to see impactful outcomes, then we needed a way to integrate AI into how we built and ship. I spent the first half of 2025 leading AI enablement for our entire company. So, 12,000 employees across every function, marketing, design, finance, legal. Now, our CTO tasked me with building an agentic engineering org. Okay, sure. But, what does that actually mean? There's no playbook for any of this stuff, right? And I know because I went looking at your blogs hoping that you all had it all figured out. But, I only saw a bunch of posts saying how you all were making it up as you went along. So, I did the same, right? In the simplest of terms, I defined an agentic engineering org as one where engineers leverage AI agents as their primary means of producing engineering outcomes. So, that meant that our engineers needed to treat agents as core members of their engineering workflow. Not just using AI to help them write code here and there, but actually working with agents. Decomposing problems, delegating work, reviewing and verifying what was done. And we wanted them directing the work as their default way of operating. But, of course, the vast majority of our engineers were not here. So, to see where we needed to go, I came up with the maturity model. This model measures the engineer's relationship with AI agents. So, how they think and delegate and orchestrate. And while I had some form of this model in Q3 of last year, Steve Yegge's Gastown article helped me reorganize it into a better model. So, stage zero is where the engineer doesn't use AI tools in their workflow at all. Stage one, they use AI to auto complete, but they've never used it in agent mode, maybe. Uh stage two is where engineers are chatting with agents, but not using it to produce any PRs. Stage three, engineers are delegating tasks to agents and reviewing the output. Those at stage four are running multiple agents in parallel. And then stage five is that final boss where engineers are delegating complete tasks to agents and the agent is able to produce shippable results without the human necessarily needing to guide it. So, I'd say by the end of the first half, the bulk of our engineers were between stages one and 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, right? There's no playbook, again, for any of this. Um two, things were moving so fast that what might be a best practice this week could be outdated when a new tool or a new model drops next week. And honestly, this was leading to AI fatigue. And then three, people were already feeling turned off by the top-down pressure from leadership to essentially AI or die. So, I thought about the 1990 rule where in digital communities about 1% create, 9% interact, and 90% passively consume. And this maps almost perfectly to how engineers adopt AI. So, you'll have a small percentage that'll deep dive and start creating agentic patterns and discovering useful techniques for working with agents. You'll have some that might tweak the agent's MD file here or there. But most people aren't going to spend the extra cycles to figure this stuff out. So, I realized that if my AI strategy depends on every individual leveling themselves up, I'm never going to see that broad impact. So, I leaned into this model. And I used it to my advantage. Instead of focusing on all 3,500 engineers, I decided to focus on forming the 1%, the power users, from our most critical teams. So, I started an AI champions program where I handpicked about 50 engineers across the company who could pioneer what a genetic engineering looks like for their team. Now, this was not a call for volunteers, all right? I needed to be strategic about the selection. I needed engineers who were willing to dedicate at least 30% of their time to investing in AI enablement. I needed those who wouldn't be discouraged by the non-deterministic nature of AI and give up on it all when it didn't work out of the box, which it often did not, right? So, I spent the week talking to tech leads and managers to find the 50 engineers who could represent our most critical repositories. Now, remember at this point, most of our engineers were between stages one and two where they're chatting with AI but not really using it to produce PRs. So, I wanted to get the AI champions to stage three. This was about June 2025. So, the models were decent enough to write a feature for you, right? But chances were pretty high that the code wouldn't conform to your team's conventions and standards. So, developers didn't trust the agents enough to delegate work to it yet. So, the first area that we focused on was making our repos AI ready. My theory here 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 would benefit, not just the 1%. And the repos are a central point of reference for every engineer that's contributing code. So, to make their repos AI friendly, they added assets like contacts and rules files so that agents could reliably understand and navigate the code base as well as contribute to it. Now, when building the AI champions, I made sure that we have folks from every corner of Block engineering: Square, Cash App, Afterpay, Tidal, across front end, back end, mobile, data, infra, right? Um we covered repos of all shapes and sizes, the nasty big legacy massive mono repos, the smaller services, mobile apps, right? And that mix let us pressure test patterns across very different engineering realities so that we could quickly see what actually scales. As expected, mono repos came with their own challenges. But my JVM devs were already strong in inheritance patterns, so we set shared contexts and rules at the root, then layered more specific ones at the service levels. We also learned fast that what worked for web didn't necessarily work for mobile. So Android and iOS even needed different approaches at times. So instead of forcing a one-size-fits-all solution, each champion figured out what worked for their repo, and then teams with similar shapes and sizes naturally converged on the same tools and patterns. And honestly, engineers loved this, right? We let them choose what made sense for their repo instead of pushing a top-down mandate on them. So we ended up with a standard set of components that would make a repo AI friendly, but again, customized for each team's needs. Some context files like agents.md or claude.md to provide the agent with repo guidance, rules files to provide the agent with some guardrails, repeatable workflows like slash commands and later agent skills, um an enabled AI code reviewer, preferably with some instructions on what matters and what it should review. And then AI attribution on PRs. So at this point, we've done a lot of great work and technically, we do have the agents writing PRs, but I had a couple of concerns, right? Not many outside of the AI champions had gotten to this level where they were delegating work to agents. And the idea is to have the work of the 1% lift everyone up. So, we weren't there yet. And then even with the champions, they were delegating, but they were still kind of babysitting the process. 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 so as well. So, there's three common places where engineers receive requirements for work. Issue trackers like Jira or Linear, GitHub issues, and informally in Slack. I wanted to be able to delegate work to the agents from any of these places. And the champions implemented all three. So, true story. We were in Slack one day, an engineer saw a bug with the product and wrote, you know, like, "Hey, I saw this bug. Anybody else seen it?" So, engineer two responds to that and goes, "Mhm, no, I hadn't seen that one." Engineer three @goose right there in Slack and says, "Hey goose, have you seen this bug before? Like, can you can you go and check if this is a bug?" So, goose goes to the repo, it like pulls the files down, and says, "Yeah, this is a bug. Here it is right here. But, here's also three options of how you might implement a solution, right?" Right there in Slack, code snippets. And so, engineer one goes, "I like option one." Engineer two goes, "Yeah, yeah, me too." So, engineer three says, "Hey goose, go implement option one." Goose does so, returns with a link to the PR, right? So, the entire cycle from discussion, diagnosis, issue creation, alignment, and the fix took like 5 minutes all right there in Slack. Very cool party trick, by the way. Um engineers were also able to assign linear and Jira tickets, as well as GitHub issues to an agent, and have the agent implement the work end to end. So, now the agents have become a part of the sprint. This blew everyone's minds. The first time we did this, the team ran out of work and had to pull in more tickets like twice, right? So, of course, engineering managers, product teams, they love this flow. And the beauty about these flows is that all engineers didn't necessarily have to learn a new skill. The champions had already laid the foundation so that agents were able to work well within these repos, and they worked well all of this worked well because it made delegation feel native to how people already work. So, now I felt comfortable claiming that we were truly delegating work to the agents. At this point, it had been 3 months since launching the champions program, and we were seeing great results. AI-authored code was up by 69% reported time savings increased 37%, and automated PRs increased 21 times. We were ready to pursue stage four, multi-agent parallelism. And with our setup, honestly, moving to stage four was almost free. We were pretty good at delegating work to the agents now. But, this stage introduced several new challenges that we needed to solve. Engineers are now tripling, quadrupling the number of PRs that they're producing, but the PRs are stuck waiting for code reviews, right? So, people struggled to stay on top of code reviews even before we added AI to the mix, so you know that it's bad now. And I'll be honest, this isn't a totally solved problem, but I'll share how we did stop the bleeding a bit. We absolutely had to get the bots to help us review PRs. So, earlier in the process, this was optional. Mostly because the AI code reviewers sucked so badly, and we were just pissing the engineers off by having them use them. But now, with the repo readiness work that the champions had done, coupled with better models and tools, shout out to Codex, uh we were getting much better results here. So, we enabled Codex on all the repos, and we also created an auto-fix loop where if Codex identified issues, another agent will automatically fix those issues and commit them to the PR. So, now, at least people would no longer complain about not wanting to review sloppy PRs from bots, right? By time they got to them, they were in pretty good shape. Another issue, specifically when running multiple agents in parallel, was that the agents were bumping into each other as they were trying to work. And more importantly, our machines couldn't handle the load anymore. Like, engineers' laptops were running out of memory. CPU was choking, you know? So, we invested in dedicated cloud workspaces where each agent ran in its own isolated environment. And this allowed us to easily run them in parallel and from anywhere. So, at this point, the engineers are cooking. They got four or five agents running at any given time, and that number is growing. So, a small group of engineers, including many of the AI champions, started building our own orchestrator to coordinate all of these agents, Builder Bot. And we needed Builder Bot to get us to an autonomous engineering org. We realized that if we're trying to build anything close to an autonomous engineering org, the agents need to understand where everything lives and what depends on what. So, we built a company world modeled based on the entirety of our 25,000 repo code base, right? And this was a machine-readable view of every single service and how they all connect. And this allowed orchestrators and the agents that they delegated to to pull context in as needed and understand the landscape as they implement. And this enabled multiple agents to explore different parts of the system in parallel, each building their own understanding and then come back together and have the orchestrator put all of this together, right? Put in a plan that spans across multiple code bases, which was especially useful for us as we were building offerings that spanned multiple products. Now, with this, we had successfully reached stage five, where engineers are delegating complete tasks to agents. The agents are able to produce shippable results without human hand-holding. In fact, this wasn't even limited to engineers anymore. Anyone at the company could act Build-A-Bot in Slack and have it fix a bug or implement a new feature. They didn't even need GitHub. This felt like a dream. Until it became a nightmare. You know, of course, all layoffs are tough, but this one felt different. I had so many questions. Was this my fault? Did enabling employees to do the most incredible work of their careers ultimately result in their dismissal? Just the day before I had felt so proud. I was in awe of the way we were working, feeling quite accomplished that I successfully built an autonomous engineering But to what end? I guess I'll leave you all with a few questions. What are we doing? Where are we heading? You know, we sure that it's where we want to end up?