Realtime multiplayer, automation, and you! — Idan Gazit, GitHub
Description
Idan Gazit's personal site runs on Astro, which ships often enough to keep him permanently on the upgrade treadmill, so he wrote an agentic workflow in about three lines of plain English, the kind of message you would send a teammate. Copilot expanded it into a full playbook: check for new releases, read the changelog and upgrade guide, apply the changes, open a pull request. It then carried him from Astro 5 to Astro 7, two major versions at once, found and fixed the code that broke, verified the build, and flagged the manual steps it could not take itself. The workflow is a Markdown document. The YAML actions file is a compiled artifact nobody reads, so changing how the automation behaves means editing the English. The guardrails are the part he wants remembered. Prompting an agent to behave is not a guardrail, because anyone who can prompt inject it can undo the instruction, and you have let the fox into the henhouse. Permissions, allowed tools, reachable network destinations and safe outputs get declared deterministically in front matter instead. His upgrade workflow may open exactly one pull request, and is explicitly allowed to do nothing at all, since an automation that cannot stay quiet turns into a denial of service against its own owner. Secrets stay outside the agent's jail entirely, because a secret an agent can see should be treated as already compromised. The second prototype, ACE, runs every session in a cloud microVM and deliberately resembles a chat app, on the theory that what belongs in the shared surface is everything not already in the code: the political constraints, the infrastructure deal that quietly picks your cloud provider, the plan two people edit together before telling the agent to go make the document true. He ends on a study of around a hundred developers over thousands of hours which found that hands on keyboard typing is about 5% of the work, and that is the only 5% the tools have helped with so far. Speaker info: - https://twitte
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: GitHub Next argues that AI's highest-value shift is not faster individual code generation but secure background automation and real-time, shared workspaces where humans and agents jointly turn evolving intent into software.
- Why it matters: The talk offers two directly relevant operating patterns for agent systems: policy-enforced autonomous workflows that can safely act on repositories, and a collaboration surface where agents consume team context, produce editable plans, and escalate only when human judgment is needed.
- Best use: Use it as a product-and-architecture reference for designing an agent control plane: Markdown as human-editable intent, deterministic permissions outside the model context, auditable writes, and shared state between teammates and agents.
Executive Summary
Idan Gazit, who leads GitHub Next, frames the current AI transition as a move beyond individual productivity. Copilot-style assistance helps people type and retrieve information, but the larger opportunity is to increase what teams can accomplish through two complementary changes: automating work that previously required basic judgment, and redesigning collaboration so team alignment happens continuously rather than only before planning and after review.
The first prototype, Agentic Workflows, is GitHub Next's proposal for repository automation. A user describes an outcome in natural language; Copilot expands it into a Markdown playbook that is compiled into an Actions workflow. The central design claim is that the agent's permissions must be deterministic and external to its prompt: allowed tools, network destinations, read/write scope, output types, and output limits are specified in YAML front matter rather than entrusted to the model.
The demo is a dependency-upgrade agent for an Astro website. It checks releases and documentation, plans code changes, applies upgrades, runs a build, creates a single pull request, and identifies remaining manual steps. GitHub Next positions this as a scalable category because useful agents operate in the background, while guardrails prevent prompt injection, secret leakage, uncontrolled output volume, and unauditable changes.
The second prototype, ACE, explores cloud-hosted multiplayer development. Each session is a repository branch running in a cloud micro-VM; teammates can converse, edit shared planning documents, inspect work, and instruct an agent to execute the settled direction using the conversation and shared artifacts as context. Gazit's broader prediction is that teams will increasingly maintain Markdown documents as the source of truth for intent, then ask agents to make the code conform to those documents.
Key Takeaways
- Claim: The durable AI opportunity is team-scale leverage, not merely multiplying an individual developer's output. | Evidence: Gazit contrasts the first wave of LLM completion and agent retrieval with the need to enable groups of people to do more; he argues that faster execution makes small team misalignments snowball into wasted time and token spend. | Implication: Ken should evaluate agent systems by whether they improve collective planning, context-sharing, review, and delegation—not only per-user coding throughput.
- Claim: Agentic workflows should be written as editable natural-language playbooks but executed under deterministic, machine-enforced policy. | Evidence: Agentic Workflows uses Markdown for tasks such as checking releases, reading upgrade guides, modifying code, and opening a PR; YAML front matter defines permissions, permitted tools, allowed network destinations, and safe outputs. | Implication: Separate intent from authority: let users edit goals and procedures conversationally, but enforce capability boundaries in a control plane the model cannot alter. | Caveat: Natural-language instructions alone are explicitly treated as inadequate security controls because prompt injection can redirect an agent.
- Claim: Output constraints are as important as access permissions because autonomous agents can create operational noise or denial-of-service conditions even without stealing data. | Evidence: In the upgrade workflow, the agent may create only a single pull request or do nothing; Gazit gives the example of an injected agent creating 500 PRs as a denial-of-service attack on the maintainer. | Implication: Agent policies should include rate limits, cardinality limits, approval thresholds, and an explicit no-op outcome rather than treating every run as requiring an action.
- Claim: Background repository agents can now automate judgment-heavy maintenance tasks that rule-based automation could not handle. | Evidence: The Astro demo moves from version 5 to 7, reads release notes, detects and updates broken code, validates the build, creates a tailored PR description, and flags manual follow-up. GitHub's Home Assistant example analyzes Python stack traces on incoming issues, determines whether a bug is first- or third-party, and closes issues outside the project's ownership. | Implication: The near-term sweet spot is bounded, repeatable operational work with clear evidence sources and verifiable outcomes: upgrades, triage, CI repair, issue follow-up, query detection, and status synthesis. | Caveat: The examples demonstrate prototypes and preview capabilities, not evidence of fully reliable autonomous handling across arbitrary repositories or high-risk production changes.
- Claim: Safe agent architecture requires layered controls, secret isolation, staged writes, and comprehensive logging. | Evidence: Gazit states four principles: defense in depth; never trust agents with secrets; stage and vet all writes; and log everything. In the described design, secrets remain outside the agent's 'jail'; the agent requests access from a separate enforcement layer when it needs to call a service. | Implication: For Ken's agent deployments, tool invocation should use brokered, narrowly scoped credentials rather than exposing raw secrets in model context or general-purpose runtime environments. | Caveat: Treat any secret visible to an agent as potentially compromised, since an injected agent may be induced to disclose it through another channel.
- Claim: The right collaboration interface for agentic development may be a shared, persistent context layer—not an isolated IDE chat or a conventional messaging app. | Evidence: ACE provides cloud micro-VM sessions, each backed by a checked-out repository branch. The agent can use the entire team chat backscroll to act on a resolved discussion, and teammates jointly edit a Markdown implementation plan before telling the agent to execute it. | Implication: Build agent workflows around shared artifacts and observable state so the team does not have to repeatedly restate decisions to each other or to the agent.
- Claim: AI should address the non-typing majority of software work: system discovery, current-state understanding, design deliberation, and clarification of underspecified requirements. | Evidence: Gazit cites a longitudinal study of 100 developers across thousands of hours in which hands-on-keyboard typing accounted for roughly 5% of the job. He describes agents increasingly identifying underspecified behavior, asking humans to clarify, and invoking humans only when they need judgment or manual intervention. | Implication: Prioritize agents that synthesize repository, conversation, and organizational context, then escalate focused questions—rather than optimizing solely for code-generation latency or token volume. | Caveat: The 5% statistic is cited but the study is not named or independently contextualized in the transcript.
Detailed Brief
Workflow authoring and distribution model
- Claims: A short user request can be expanded into a structured operational playbook because the agent can inspect repository context and infer relevant dependencies and steps.; Markdown is intended to be the source code for the workflow, while YAML is treated as a compiled artifact that users generally should not need to inspect.; GitHub Next expects users to customize a library of standard workflow patterns rather than author every automation from scratch.
- Evidence: The dependency-upgrade prompt resembles a message to a junior developer: check daily for releases, read the changelog and documentation, plan the upgrade, and create a PR.; Example templates include issue triage, RepoAssist for maintenance and low-hanging fixes, CI Doctor, N+1 query hunting, goals, daily team status, repo status, and internet research or synthesis tasks.; Gazit says GitHub has internally used the approach as a basis for issue triage and monolith query analysis.
- Caveats: The transcript does not describe the exact compilation model, execution isolation, approval workflow, or failure-recovery semantics behind the Markdown-to-Actions abstraction.
- Implications: A reusable workflow catalog can make automation available to product, operations, and program roles—not just engineers—if tasks are expressed in outcome-oriented language and constrained by policy.; Intent documents can provide a maintainable interface for evolving workflow behavior without requiring each operator to edit procedural code.
ACE's proposed operating model for human-agent teams
- Claims: ACE treats each concurrent task as a cloud workspace rather than a process bound to one developer's laptop.; Real-time co-editing is only part of collaboration; ambient awareness of teammates' current work is also necessary to avoid divergence.; Agents can act as listeners over team context and should interrupt humans selectively when clarification or hands-on action is required.
- Evidence: The prototype displays sessions, teammate activity, a terminal, application preview, and repository branches running in cloud micro-VMs.; The speaker describes using an activity view to see that teammates are working on VM tooling, a dashboard, or other parallel tasks.; A shared plan for adding selectable timeframes is edited by multiple people, including changes such as adding an 'all time' option and removing 'today,' before execution is delegated.
- Caveats: ACE was described as planned for technical preview later that month; the demo contains network-delay issues and does not establish production readiness.; The model's ability to infer a final decision from a long discussion is asserted through the demo rather than measured for accuracy, conflict resolution, or accountability.
- Implications: The strategic control point is likely the shared workspace that unifies branch state, plans, discussions, agent actions, previews, and human escalation—not merely a stronger coding model.; Persistent decision artifacts reduce context-reset costs and make it easier to audit why an agent changed a system.
Notable Concepts & Terms
- GitHub Next: GitHub's exploratory labs team, led here by Idan Gazit; its mandate is to build and test plausible near-future developer workflows rather than only ship finished products.
- Agentic Workflows: GitHub Next's public-preview prototype for describing repository automations in Markdown while enforcing permissions and output restrictions through workflow policy.
- YAML front matter: The policy layer at the top of an Agentic Workflow that specifies deterministic access, allowed tools and destinations, and safe output actions outside the agent's natural-language instructions.
- Safe outputs: Explicitly permitted agent outcomes, such as creating at most one pull request or doing nothing, intended to contain noisy or maliciously redirected automation.
- ACE: A planned GitHub Next technical-preview prototype for real-time multiplayer software development using cloud-hosted repository sessions, team conversation, shared plans, and agent execution.
- Micro-VM sessions: ACE's execution model: each collaborative session is a branch checked out in an isolated cloud environment rather than on a specific user's machine.
- Make the document true: The proposed future interaction model in which teams collaboratively edit a specification or plan, then direct AI to implement the software changes necessary to conform to it.
- Ambient awareness: Visibility into what teammates and eventually automations are doing, intended to preserve alignment beyond synchronous collaboration or message threads.
Operator Notes / Why Ken Should Care
- Adopt a mandatory agent-policy schema that independently specifies read scope, write scope, tool allowlists, egress allowlists, output cardinality, budget/rate limits, and no-op permissions.
- Audit existing agents for secret exposure; replace model-visible credentials with brokered, task-scoped service calls and retain invocation logs.
- Pilot one bounded background automation with strong verification, such as dependency upgrades, CI diagnosis, or issue routing, before delegating open-ended feature work.
- Store approved implementation plans and material decisions as versioned repository artifacts; connect agent execution to those artifacts rather than relying on ephemeral chat prompts.
- Design human escalation as a first-class workflow state: agents should ask precise clarification questions when requirements are underspecified and stage consequential writes for review.
- Monitor GitHub Agentic Workflows for practical policy semantics and ACE for its shared-context interaction model; both are relevant benchmarks for an OpenClaw-style agent control plane.
Source/Metadata
- Title: Realtime multiplayer, automation, and you! — Idan Gazit, GitHub
- Transcript words: 5045
- Duration seconds: 1300
- Timestamp note: No usable timestamps or chapter markers were present. The transcript includes substantial duplicated material near the end.
Transcript
. We're gonna start one minute early, which gives me one extra minute. And then anybody who came on time is gonna miss the super enthralling introduction. Hi, my name's Ida. Nice to meet you all. I lead GitHub Next, which is the labs team of GitHub. I like to call this the department of fool around and find out, but I usually don't say the word fool. We're the team that created Copilot and pioneered a ton of areas since then, right? Spec-based programming, natural language to app, lots more. Not everything that we do turns into a finished product. Our job is to explore the future and scout it out. But our job is to reach for the GitHub that's gonna be next year, maybe not tomorrow's GitHub, but the tools that we're all going to use to make software a year from now, two years from now. That's pretty hard, because my crystal ball barely works until next week. And we're really fortunate that we get to do most of our work in the open, so you can check out GitHubNext.com and our socials, which we occasionally remember to post stuff to. And what we do isn't really research, right? Because the only way to know what's gonna be good is to make stuff. So we make a lot of stuff. And the hard part about being an undirected research team is always the question of what's worth our time. Even if you're a token billionaire, even if you have 10 terminals running Fable night and day, then opportunity cost is still there. It's everything. So if, in a world where the marginal cost of a line of code is approaching zero, and AI can help us to think and to make, what do we make, right? How do we even choose what's important when the market is super noisy and the tech changes every week? And this isn't even really a Next problem anymore. This is an all of us problem now. We're all labs teams now. And the way that Next thinks about this stuff is to look for durable themes. Things that will be true no matter what the technology is tomorrow. And I think that the theme of this moment is very much an evergreen one, right? It's AI started with a surge of personal productivity, right? The LLMs completed what I type, and the agents go fetch me the thing that I need. And now I have many agents helping me to parallelize myself. But the greatest value doesn't come from multiplying me into more me. It comes from enabling groups of people to do more. That's always been true. And we're thinking about how to accomplish that through two lenses. Every industrial revolution came about through automation, right? It's funny to think about our giant software industry as being pre-industrial, but on some level it is. Because until now, the only automations that we had were heuristics like make sure there's a semicolon at the end of every line. But now AI can help us to automate things that require some amount of basic judgment and intelligence. And there's no magic trick to making great software, right? It costs time. And we can buy that time by automating away the things that we used to need to do manually. The more we automate, the more time we have to spend on craft or on our product or on making it really good or on features, right? Either you hire more people or you automate away part of what your people are currently doing in order to spend that time. And at the same time, how are we going to work together, right? How does collaboration look in the future? Whoops. Oh well, sorry about that. Yesterday Jeffrey Litt talked about understanding being the bottleneck, and that's very true at a me level. But my personal understanding was never sufficient for shipping code inside a team, right? Our understanding at an us level can't only happen at the end of the process when the process happens so much faster. So going faster means that a small misalignment can snowball into a ton of wasted work, and that work costs tokens, and tokens cost real money now, on top of the time that you're misspending. So today I'll give you a quick tour of two prototypes that we're working on at GitHub Next in each of these themes. Argentic Workflows is our take. Why is that not there? Oh, I had to click again. Argentic Workflows is our take on how automations should work in an Argentic world. And ACE is a prototype that explores what real-time multiplayer software development looks like. So I'll start by showing off Argentic Workflows. And it requires me doing this. Okay, cool. This is my personal website. Not that interesting. I'm showing it to you. This is Chekhov's gun. We're going to see it again later. And my personal website is built with this framework called Astro. Astro is a great web framework. The greatest part about it is that they release like 50 things a month, which means that I'm constantly on the upgrade treadmill. And there's a great GitHub product called Dependabot, which notifies me when my stuff is out of date. But the problem is that when I do these upgrades, I frequently need to make code changes. So what I really want is a super-dependabot that's always there, automatically looking in the background at my dependencies and figuring out how to upgrade me, including the code changes, the breaking changes. And because I'm lazy and I like not doing work, I used Copilot to create a Nogetic workflow. And there's this magic line up top where I supply effectively a skill, saying, hey, create a Nogetic workflow. Here's a document that tells you everything you need to know about that. And then what comes below that is something a lot like a Slack message that I'd send to a junior developer on my team. Every day I want you to check if there's a new release, look at the change log, look at the docs, come up with a plan for the upgrade, and then create a PR with the thing, and here's the links to the docs. Right? This is a message that I would send to somebody on my team: go write a playbook. And when I went and created this, it did go and create a playbook. In fact, that's what a Nogetic workflows kind of look like. They look like markdown documents. If GitHub Actions and Copilot had a baby together, and it ran on markdown, this is what it is. So what does this Nogetic workflow look like? Well, it's an upgrade checker, it's got my tasks: step one, check for new releases. Again, because it sees my code base, it was able to infer what it even needs to check, and it actually found these specific dependencies. Review the change log in the upgrade guide, apply the upgrade, and then create a pull request. Right? I didn't ask for any of this that explicitly, but it turns out that Copilot's pretty good at sussing out my little three-line message into a full playbook. And then at the top, I've got this special section. This is what we're calling YAML front matter. This is where we stick the guardrails, because if we're going to be not supervising agents doing things, then we're going to need much stronger guardrails around what they're allowed to do, what they're allowed to read, what they're allowed to write. And where are we going to specify that? And it's not enough to just prompt the agent and be like, listen, bro, I don't want you to buy Bitcoin for me ever. That's not enough. Because somebody else can prompt inject the agent and take it in a direction that you don't expect. So any of the guardrails, if you're prompting the guardrails at the agent, you're effectively letting the fox loose in the head house. It's not actually a guardrail. So here you can see that I'm specifying deterministically, like my permissions are read all, what tools am I allowed to use, what network request is it allowed to make. It's not allowed to just go to bitcoin.com or whatever. In fact, it's only allowed to go to some specified set of default websites, the NPM ecosystem, because it's got to check for what's new, GitHub, and of course the Astro docs, which I specified in my original prompt. And I've got this block called safe outputs, which is basically saying these are the only things that the agent is allowed to write. And so I'm saying, in this case, the agent is allowed to create pull requests. Pull request single, because I don't want the agent to get prompt injected to create 500 pull requests. That would be a denial of service. Or, and this is the other thing, I explicitly said you're allowed to do nothing, right? Which sounds silly, but it actually matters, because in a world where I have lots of automations, the last thing I want is noise. I don't want the agent denial-of-servicing me. So, okay, I've created this, and I've run it, and this is actually my actual automation on my actual personal website. I didn't ask for any of this, but it did a pretty good job of saying, which I specified in my original prompt. And I've got this block called safe outputs, which is saying these are the only things that the agent is allowed to write. And so I'm saying in this case, the agent is allowed to create pull requests. Pull request single, because I don't want the agent to get prompt injected to create 500 pull requests. That would be a denial of service. Or, and this is the other thing, I explicitly said you're allowed to do nothing, right? Which sounds silly, but it actually matters, because in a world where I have lots of automations, the last thing I want is noise. I don't want the agent denying service to me. So, okay, I've created this, and I've run it, and this is actually my actual automation on my actual personal website. I didn't ask for any of this, but it did a pretty good job of saying, hey, here's the highlights of what you get from going from this version that you're currently on to the version that is the target, right? It's read all of the release notes in the middle. This is normally what I would do as a human. And it's built me a tailored description. It's figured out there's no breaking changes. It's actually verified this by running and building it and building my project. And because I happen to have this deployed to Cloudflare or whatever, anything with preview deploys, I can click that open and see that nothing has changed in my website, which is exactly what I want, right? It's done the upgrade, and I see that it still works exactly as it did before. But this was a minor point release. That doesn't really count. Let's look at a major upgrading change. And actually I'm lucky that Astro just released Astro 7, because this is actually jumping two major revisions from five to seven. And so now it's saying, okay, Astro 7 has brought me all of these things, and Astro 6 would have brought me all of that stuff, but I neglected to do the upgrade so I could have a cool demo for you all. And it's found all of the code changes that were broken, and it updated them. It also verified that the build runs, and it also highlighted manual steps, things that I would need to do later. And again, if I go down here, and I click on this, I can see, hey, still works. So cool. Now, it's just markdown. It's easy to iterate on that markdown, right? If you don't like the way that the automation works, just edit the English. It gets recompiled into an actions workflow. The markdown is the source code. The YAML is a compiled artifact. You never look at it. But we've also given you a whole library of agentic workflows for you to use as a standard. It's a starting point to customize. So, an issue triage. Internally, GitHub has actually used this as the basis for spiking out our own internal issue triage, or for hunting down N plus one queries in our monolith, or all kinds of things. There's a ton of things that are super helpful that way. RepoAssist, this is actually a swarm of agentic workflows that work together to help you maintain your project by finding low-hanging fruit, fixing them, identifying tickets that need nudging, or feedback that you need from people who have filed issues, whatever. CI doctor, how many times have you responded to a busted CI run by just running it again? All of us. Anybody who hasn't raised their hand is lying. A million more. Goals, sure. Daily team status and repo status. If I want this to go do homework on the internet, I can. So this is not just for engineers. This is also for product managers whose job it is to look at information over here and summarize those tickets over there, right? We can start to get everybody involved in automation. That's how you actually get industrial scale. So that's agentic workflows. The security guardrails, we have four principles that we believe everybody should burn into their brains. Defense in depth. One layer is never enough. That was always true. Never trust agents with secrets. If an agent can know a secret, that secret, you need to treat it as if it's already been compromised. Because you have no idea whether or not somebody's injected the agent to reveal that secret somewhere else. So if an agent can see the secret, it's bad. In agentic workflows, the secrets are all kept outside of the agent's jail. And when the agent wants to use the secret to call something, it needs to ask the warden, hey, mother, may I? Please go talk to that service. Stage and vet all writes, just so that it's auditable. And log everything, just so that it's auditable. And when we give this to existing projects like the Home Assistant project, which is a huge open source project, the first agentic workflow they built was something that looks at every submitted issue, walks the Python stack trace to figure out if the bug is in first-party code or third-party code, closes the issue if it's not their issue. Right? That's something that was not possible before AI. Not possible with heuristics. But it is possible now. Agentic workflows is in public preview today. You can go and kick the tires. So go ahead. Go wild. We actually believe that this is going to be a bigger category than interactive AI because automations that run in the background while you sleep, that's the ball game. Okay. So let's talk about the collaboration piece. So this is how we've always built software, right? Because the cost of writing code was so high. But that's not true anymore. We would plan and review together, but the building part was done alone. Illuminated by the light of my monitor, I would build. But now none of it is alone, right? Planning isn't before and review isn't after. We iterate on the direction together and AI takes a step, and then we iterate more on the direction. So what's an interface that makes sense for that style of development? I'm only slightly trolling, right? Slack was designed to be better than email for the average office worker. It was never designed for making software or the needs of everyone involved in that. But what this is good for is surfacing all the facts that are not in code. Anything that's in code, any fact that's in code, the agents can figure out by reading the code. What's left are the things that are not in code, like political considerations. Like, hey, if we do it that way, that VP over there is going to vibe with that direction. Or, we should make it purple because that's their favorite color. Or, we get a really sweet deal on infrastructure from Azure, therefore we should be building on Azure, not on GCP or AWS. Whatever. But the biggest win is the same one that we've already seen over and over, right? I don't email Word documents around anymore. I create and collaborate in the same surface, in the same place. So let's do this. This is coming for code, a trillion percent, right? So let me show you what we have there. Oop. Here we go. I've got to find the tab. All right. This is Ace. Let's switch to the repository. So Ace looks an awful lot like Slack, right? And over here on the left I've got sessions and I can create new ones. And so far this kind of looks like every other conductor-like product out there. The difference is that every one of these is not on my machine. In fact, none of this is running on my machine. It's all micro VIMs in the cloud. So every session is just a branch of my repo checked out to a spot in the cloud. And I can create them and do stuff in them and talk with my teammates. So, hey, what's your favorite color? Right? And meanwhile I'm going to install my dependencies. And then when that's done I'm going to run the dev server. And here Russ and I are having a discussion like, are you sure? Maybe green is calmer. Oh, no, I sent that as a terminal command. Good job, me. I do not want that as a thing. Great. I'll do it like this. And I can open up my preview. Whoops. Give me a preview. I'd like a browser preview. Okay. So, so far not that different from developing with any sort of multiplayer tool. And here I've got this calm Hacker News thing. I've just had a whole discussion with my teammate. I don't want to turn around and now emit those instructions again. Instead I just want to be like, yo Ace, do it. And because it sees the entire backscroll of my conversation with my peers, with my team, it's able to act on that chat history. And if the wifi was nice then it would be doing it faster. But you're going to have to trust me on this because I don't have enough time to wait for this, that it's going to just respond to the fact that we had a discussion about colors. I do not want that as a thing. Great. I'll do it like this. And I can open up my preview. Whoops. Give me a preview. I'd like a browser preview. Okay. So, so far, not that different from developing with any sort of multiplayer tool. And here I've got this calm Hacker News thing. I've just had a whole discussion with my teammate. I don't want to turn around and now emit those instructions again. Instead, I just want to be, yo Ace, do it. And because it sees the entire backstroll of my conversation with my peers, with my team, it's able to act on that chat history. And if the wifi was nice, then it would be doing it faster. But you're going to have to trust me on this because I don't have enough time to wait for this. That it's going to just respond to the fact that we had a discussion about colors. And AI is also really good at fishing out that final state. Very frequently, what do engineering conversations sound like? They sound like, hey, we should try it this way. No, wait. I thought of an edge case. We should actually do it that way. Let's go back to the first idea. Right? But instead of me figuring, teasing out that final state from that long conversation, I can just let AI do it and it'll figure it out. So I don't need to work for the robots. And sometimes we have things that are a lot more complicated. Here, I wanted to add selectable time frames to my app. And so I asked it to make a plan. And that plan comes as a markdown document. But this markdown document is not just for me to look at and edit. It's for us to look at and edit together. So Russ is somewhere here in this document, and maybe he thinks that we should add an all time. And I'm going to get rid of the today. And here I can again do, we've updated the plan. Do it. And it'll just respond to the plan that we've edited together. And as we see now, we're moving to this future where more and more of the work that we're doing with AI results in documents. Markdown documents in a docs folder that capture the truth. And maybe more and more in the future, we're going to be editing those documents as the way that we do development. In order to change something about my application, I'm going to edit a document and I'm going to tell AI, hey, make the document true. So this shared document editing is not just, oh, nice to have. Maybe this is actually the interface that we like to work in. But there's also the social coding aspect, right? If I'm working with other people on my team. Remember when that was a thing, that was a tagline under the GitHub logo? So how can it help me stay up to date with what everybody else on my team is working on? It's not just enough to have real-time multiplayer. I also want to be ambiently aware of what everybody's going on about. So Krzysztof is working on VM tooling. This is actually work that we're doing on ACE. And Maggie wrote this dashboard and hard-coded her name. And so that's why we're looking at Maggie's name. And David worked on whatever. All this stuff to help me stay aligned with my team. And when I look to the future, I'm starting to think about how automations surface themselves in this. If I want to talk with my automation. There's lots of things that I want to do in this kind of interface. Like when an agent wants to tap me on the shoulder and ask me a question. That I think are very interesting. So that's a short ACE demo. We're going through this weird inversion of our relationship with the agents. The better that we get at articulating our goals to the agents, the less they need us. And as the models get better, they're also good at spotting underspecified behaviors and then asking us to clarify. And then whenever they need a pair of hands, they can ask us to be the pair of hands. But either way, the interfaces now have the ability to support the ability of agents to listen to everything and invoke us when they need it. Which is a little funny to think about. It's maybe like we're coming at it from this side and open clause coming at it from this side, but we're landing in a similar spot. And I'll close with this thought. For the past few years, AI has helped me to type. But if you look at the science of the matter, it's only about 5% of the job. This was a longitudinal study conducted on 100 developers over thousands of hours. Turns out that the hands-on-keyboard typing part is 5% of the time. Now AI has to help me with the other 95%. Where is the system that I want to touch? How does it work today? What do other people think about how we could mutate it or should mutate it? When AI can discover anything in my code base, how do we help scale up all those other things? Right? Not just the 5%, which is what all the tools have been helping us to do so far. So that's ACE and that's Agentec Workflows. Please come by and talk to us. We have a booth down in the Microsoft booth because we're a Microsoft company. And you can find us on the socials and getimx.com. So if any of this resonates and you're interested in it and you want to give it a shot, ACE is going to be in technical preview, hopefully later this month. And Agentec Workflows is already out there for you to kick the tires. And we'd love to hear from you and how you want to use this. Thank you so much. Right? But instead of me sort of like figuring, teasing out that final state from that long conversation, I can just let AI do it and it'll figure it out. So I don't need to work for the robots. And sometimes we have things that are a lot more complicated. Like here, I wanted to add selectable time frames to my app. And so I asked it to make a plan. And that plan comes as a markdown document. But this markdown document is not just for me to look at and edit. It's for us to look at and edit together. So Russ is somewhere here in this document. And like, you know, maybe he thinks that we should add an all time. And I'm going to get rid of the today. And here I can again do like, we've updated the plan. Do it. And it'll just respond to the plan that we've edited together. And as we see now, we're moving to this future where more and more of the work that we're doing with AI results in documents. Like markdown documents in a docs folder that capture sort of the truth. And maybe more and more in the future, we're going to be editing those documents as the way that we do development. Like in order to change something about my application, I'm going to edit a document and I'm going to tell AI, hey, make the document true. So this shared document editing is not just like, oh, nice to have. Maybe this is actually sort of the interface that we like to work in. But there's also the social coding aspect, right? Like if I'm working with other people on my team. Remember when that was a thing that was a tagline under the GitHub logo? So how can it help me stay up to date with what everybody else on my team is working on? Like it's not just enough to have like real-time multiplayer. I also want to be ambiently aware of what everybody's going on about. So Krzysztof is working on VM tooling. This is actually work that we're doing on ACE. And Maggie wrote this dashboard and hard-coded her name. And so that's why we're looking at Maggie's name. And David worked on whatever. All this stuff to help me stay aligned with my team. And when I look to the future, I'm starting to think about how do automations surface themselves in this? If I want to talk with my automation. There's lots of things that I want to do in this kind of interface. Like when an agent wants to tap me on the shoulder and ask me a question. That I think are very interesting. So that's a short ACE demo. We're going through this weird inversion of our relationship with the agents. Like the better that we get at articulating our goals to the agents, the less they need us. And as the models get better, they're also good at spotting like underspecified behaviors. And then asking us to clarify. And then whenever they need a pair of hands, they can ask us to be the pair of hands. But either way, the interfaces now have the ability to support the ability of agents to listen to everything. And invoke us when they need it. Which is a little funny to think about. It's maybe like sort of we're coming at it from this side. And like open clause coming at it from this side. But like we're landing in sort of a similar spot. And I'll close with this thought. For the past few years, AI has helped me to type. But if you look at the science of the matter, it's only about 5% of the job. Like this was a longitudinal study conducted on like 100 developers over thousands of hours. Turns out that the hands-on keyboard typing part is 5% of the time. Now AI has to help me with the other 95%. Where is the system that I want to touch? How does it work today? What do other people think about like how we could mutate it or should mutate it? When AI can discover anything in my code base, like how do we help scale up all those other things? Right? Like not just the 5%, which is what all the tools have been helping us to do so far. So that's ACE and that's Agentec Workflows. Please come by and talk to us. We have a booth down in the Microsoft booth because we're a Microsoft company. And you can find us on the socials and getimx.com. So if any of this resonates and you're interested in it and you want to give it a shot, ACE is going to be in technical preview hopefully later this month. And Agentec Workflows is already out there for you to kick the tires. And we'd love to hear from you and how you want to use this. Thank you so much.