Talk by Brendan O'Leary (Developer Relations Engineer, Kilo Code) on making AI coding agents reliable collaborators in real-world software development. Topics include where coding agents succeed and fail, designing workflows that balance speed with control, agent autonomy, context management, human-in-the-loop design, and moving from "vibe coding" to production-grade, agent-driven development that preserves code quality, security, and trust. # Channel Identity Observations — "Agentic Engineering: Working With AI, Not Just Using It" ## Intended Audience - **Practicing software engineers and engineering leads.** The talk repeatedly addresses engineers directly: - > "If you're an engineer, how do we really get good at this?" - > "Most engineers can't [explain their AI workflow] and that's a little wild to me." - > "The question isn't whether your team is using AI, they are." - **Engineers new to or skeptical of agentic coding tools.** The speaker addresses people who may be "anti-AI or think that AI is not a useful tool because they've jumped right in and gotten... garbage in and garbage out." - **Developers across skill levels**, framed via the "junior developer" mental model and the comparison to onboarding/managing junior engineers. ## Claimed Scope - The talk claims to cover a **workflow paradigm for AI-assisted software engineering** ("agentic engineering"): - > "That gap between using AI and being able to articulate how you work with it, that's what this talk is all about." - > "Let's get tactical. If you're an engineer, how do we really get good at this?" - Concrete topical scope demonstrated: **context engineering** (cost, context-window limits, MCP server token overhead, isolating/summarizing context), the **research-plan-implement loop**, **agent configuration** (modes, agents.md, skills.md, auto-approve settings), **MCP and internal API integration**, and **Git-based review practices**. ## Creator Self-Description (Explicit Claims) - **Speaker identity:** Brendan O'Leary (per title). He self-describes his background: - > "I spent a lot of time as an engineering manager and product manager before I went into the dark arts of developer relations." - > "I used to work at a company called GitLab for many, many years." - **Current employer:** Kilo Code / Kilocode: - > "When I joined Kilo Code over a year ago..." - > "I work at Kilocode, and so I've got some power user tips there." - The talk functions partly as a **product presentation for Kilo Code**, ending with an explicit plug: - > "If you haven't taken a look at Kilo... visit kilo.ai, and we'd love to get your feedback on what we're building." ## Observable Presentation Patterns - **Educational talk format** with a clear thesis, mental models, historical framing (autocomplete era → Copilot 2022 → agents 2025/2026), personal anecdotes (the iPad/Balsamiq intern story), and tactical recommendations. - **Heavy use of third-party citations** to lend authority — Armin Ronacher (Flask creator, "no longer just using machines... working with them"), Andrej Karpathy (context engineering quote), and Dex Horthy ("AI can't replace thinking"). The speaker recommends Horthy's YouTube videos. - **Cross-promotion of related resources:** - > "I've even compiled a lot of them at path.kilo.ai." - Mentions kilo.ai and upcoming features (OpenClaw/KiloClaw safety, expanded surfaces: CLI, mobile, cloud agents, Slack). - **Bridal-conference style closing** with actionable next steps: "pick a tool and get lots of reps," try the research-plan-implement feedback loop. ## Distinguishing Claims from Demonstrations - **Claims:** The speaker explicitly claims the talk covers a paradigm shift and tactical guidance; claims his own background (EM, PM, GitLab, Kilo Code). - **Demonstrated:** Deep familiarity with agentic tooling specifics (context windows, MCP token costs, agents.md conventions, work trees, VS Code integration), consistent with a developer-relations role at a coding-agent company. The presentation style itself demonstrates the "devrel talk" pattern he references. - **Not inferable:** No evidence about channel size, upload cadence, or broader content strategy beyond this single video. # Delivery Observation: "Agentic Engineering: Working With AI, Not Just Using It" ## Overall Tone - **Conversational, talk-style delivery**: The transcript reads like a conference talk or video presentation, opening informally: > "Let's talk a little bit about what I mean by agentic engineering. And let's maybe start with a question." - **Direct audience address**: Frequent use of "you" and rhetorical questions aimed at listeners: > "If I were to ask you right now, how are you using AI in your work? Could you actually really explain it?" ## Recurring Rhetorical Patterns ### 1. Opening with provocative questions - Opens the talk with a challenge to the audience: > "Could you actually really explain it? Not just, you know, it helps me code faster." - Repeats this pattern when reframing the core question: > "So, the question isn't whether your team is using AI, they are. The question is whether you're getting the most out of it." ### 2. "You know" as a verbal filler - Extremely frequent throughout the transcript (appears dozens of times), e.g.: > "And you know, the history of AI and software engineering is moving uh very fast." - This is a stable, consistent habit across the entire talk. ### 3. Self-corrections and restarts mid-sentence - Regular stumbles and repairs, suggesting a live, unscripted delivery: > "I I do think they're still tools" > "the facts that fact that MCP servers became so popular" > "it's a a faster horse" > "human research at the planning or sorry, human time at the planning and research phases" ### 4. Short punchy summary sentences - After longer explanations, he frequently lands on a compact takeaway: > "And that's the difference between using AI and working with AI." > "So, the real critical thing for engineers is to manage the context." ## Teaching Habits ### 1. Attribution to named sources - Repeatedly grounds claims in quotes from named figures: **Armin Ronacher** ("We're no longer just using machines. We're now working with them."), **Karpathy** ("context engineering is a delicate art and science"), and **Dex Horthy** ("a bad line of research can potentially be hundreds of lines of bad code"; "AI can't replace thinking"). ### 2. Signature metaphor: the junior developer - His central teaching device is an extended analogy: > "You kind of have to think about your AI agent as an energetic, enthusiastic, extremely well-read, often confidently wrong junior developer." - He returns to this analogy later: > "just like I would review a junior engineer's code." ### 3. Personal anecdotes as teaching tools - A detailed story about interns and a Balsamiq wireframe (Comic Sans placeholders shipped in a prototype) illustrates the importance of context — with self-deprecating framing ("before I went into the dark arts of developer relations"). ### 4. Structured, enumerated advice - Tactical sections are broken into numbered lists ("one, I think it means persisting..."; "there's kind of four different ways of doing that"). - Practical habit summaries: > "you just need to think about doing one task per session, keep an eye on your context meter, and if you're in doubt... start a new session." ### 5. Memorable coinage and vivid framings - Repeated catchy formulations: > "auto complete on steroids" · "a faster horse" · "confidently write code that is technically correct and contextually wrong" · "put garbage in and gotten garbage out" · "dumb zone around 50% context" - Pop-culture reference used for relatability: "the Will Smith eating spaghetti when it comes to AI videos." ## Vocabulary and Framing - **Business/management vocabulary applied to AI**: "hand off," "delegate" implied via "directing the work," "in and out of scope," "pull request review." - **Bridging old and new**: repeatedly maps AI-agent behavior onto familiar engineering practices (Git, pull requests, engineering management). - **Hedged confidence**: qualifiers like "I think," "kind of," "maybe," and "a little bit" appear constantly: > "It's a little bit of art and a little bit of science." ## Communication Pattern: Sales-lite close - The talk ends with a soft product pitch for his employer: > "I work at Kilocode... it's just a little plug at the end here, visit kilo.ai" - This is an isolated structural moment (beginning-middle are educational in tone), not a recurring pattern. ## Stability Notes - **Stable, repeated patterns**: filler words ("you know," "uh"), rhetorical questions, punchy summarizing sentences, the junior-developer analogy, enumerated tactical advice. - **Isolated moments**: the Balsamiq anecdote, the GitLab self-disclosure ("maybe I'm a little biased"), and the product plug appear once each. - **Uncertainty note**: tone inferences (e.g., humor) rest only on textual cues; vocal delivery (pace, intonation) is not observable from the transcript alone. # Observation Document: Agentic Engineering — Brendan O'Leary ## Speaker - **Brendan O'Leary** (Kilo Code / previously GitLab, per his own statements) — sole speaker in this talk. ## Core Thesis - The gap between *using* AI and *articulating how you work with it* is the central problem. Most engineers can't explain their AI workflow. - Claims **90% of engineers** have used AI tools; **maybe half** use them regularly — a number he says is growing (his stated figures, not independently sourced). - Framing shift: "We're no longer just using machines. We're now working with them" — attributed to **Armin** (whom O'Leary identifies as the creator of Flask; note transcript inconsistency: spelled "Armin" once, "Armand" later). ## Mental Model - AI agents are "still tools, but we have to think about them differently." - Key metaphor: an **"energetic, enthusiastic, extremely well-read, often confidently wrong junior developer."** - Strengths: fast, tireless, no ego, broad knowledge of languages/frameworks/patterns. - Weakness: **no judgment**, no business context, no memory of past architectural decisions; will write code that is "technically correct and contextually wrong." - Cites Armin's claim of **30% time gained**, attributing it to knowing what to hand off vs. keep — "that's the difference between using AI and working with AI." ## Historical Timeline (as presented) - **Early 2020s:** line-completion tools ("autocomplete on steroids"). - **2022:** whole-function suggestions; GitHub Copilot's breakthrough. - **2025:** models execute — break down tasks, touch files, run tests, return pull requests. "Not just a faster horse. It's a collaborator." (Talk framed as delivered in 2026.) ## Context Engineering Quotes **Karpathy**: context engineering is the "delicate art and science" of filling the context window with just what's needed. Two problems identified: - **Cost:** full chat history resent as input tokens each turn. - **Quality degradation:** more context can make the model "actually dumber"; quality degrades around **>50% full** context. MCP servers, popular and often always-enabled, contribute to this "dumb zone." - **Bad context poisons output**: mixing unrelated tasks, outdated comments, or trying to steer an agent back after wrong turns — the agent "is not doing real reasoning like you and I as a human" and negative patterns creep back. Practices recommended: - **Persist** information outside the window (scratch pads, memory files, agents.md). - **Select** only relevant context per step (@-mentions, disable unnecessary MCP servers, human-curated data). - **Summarize/trim/compress** after deep dives. - **Isolate context** — one task per session; parallel agents/worktrees as a rising pattern. Habits: one task per session, watch the context meter, restart sessions when things feel off; let an agent summarize the session — "AI is really great at writing prompts for AI." ### Junior Engineer Analogy (personal story) - Early-career engineering manager at a healthcare software company; designed an iPad patient-history form wireframe in **Balsamiq** (Comic Sans, smiley placeholders); interns shipped a prototype with Comic Sans and emoji placeholders. - His conclusion: "It was my fault as an engineering manager not giving the right context" — the same failure mode as agent misuse. ## Research → Plan → Implement Workflow - Most people jump straight to "help me implement this feature," which causes wrong assumptions, wasted time, frustration, and anti-AI sentiment ("garbage in, garbage out"). - References the "Will Smith eating spaghetti" video as evidence of how far AI video has come in a few years. - Quotes **Dex Horthy**: "a bad line of research can potentially be hundreds of lines of bad code" and "AI can't replace thinking. It can only amplify the thinking you've done or the lack of thinking." - **Research** (Kilo's "ask mode" — chat-only, cannot write files): understand the system, find relevant files, data flow, edge cases; output a research document the human reviews. - **Plan:** explicit steps, files to change, tests, in/out of scope; produces a plan file clear enough that "maybe a smaller, faster, or cheaper model" can implement it. - **Implement:** new session with just the plan; low context; review and commit frequently. He treats local Git "like my own first pull request review" — noting he's "maybe a little biased" from years at GitLab. - Claims human time in research/planning is "the highest leverage use of your time." ## Agent Configuration - **Modes** (ask/code/architect) — role-based behaviors. - **Workspace rules** (repo-level or global), which must be written down to be in context. - **Behavior tuning:** parallel agents, worktrees, auto-approve settings, tool permissions (file reads, tests), adjustable "as you learn." Three buckets: - **Modes** — role-based configuration. - **agents.md** — de facto standard, always-loaded readme: conventions, build/test commands, commit requirements; keep minimal. - **skills.md** — on-demand reusable playbooks for specific workflows (e.g., motion graphics, changelog compiling). ## Power User Tips (Kilo-specific, some general) - @-mentioning files, commits, terminal output. - Slash commands (new task, condense context). - VS Code right-click "add to Kilocode" for selected code. - Autocomplete in code *and* while prompting. - Cross-surface use: CLI, mobile, cloud agents, Slack — "more like a collaborator that's everywhere." ## MCP and Internal APIs - MCP explained as extending tool-calling (e.g., GitHub MCP for PRs/issues; "context seven" for up-to-date framework docs given LLM knowledge cutoffs). - Caution: every enabled MCP adds tokens to every system prompt; e.g., a Postgres MCP left on during frontend work is "wasted tokens" and may "confuse the agent." - Four approaches for internal platform APIs: 1. Use existing OpenAPI/Swagger spec. 2. Convert to markdown, store in agents.md/repo. 3. Reference URL the agent fetches fresh. 4. Build a custom MCP server (for complex multi-system workflows). - Closing rule: **isolate your work from the agent's work; review agent output as a pull request**, "just like I would review a junior engineer's code." ## Product Plug - Kilo Code: new features, expanded surfaces, focus on "Openclaw and Kilocaw" as a "very safe way" to use Openclaw agents; visit kilo.ai. Workflow patterns compiled at **path.kilo.ai**. (Self-acknowledged plug; he works at Kilo Code.) ## Closing Advice - Pick a tool and "get lots of reps" — it's "part art and part science." - Try the research-plan-implement loop. - Quotes unnamed senior engineers: "I'm having more fun programming now than I've had in years," with agents handling tedious work while humans tackle harder problems. ## Preserved Qualifications & Tensions - O'Leary repeatedly hedges: agents are "kind of somewhere in between" tools and collaborators; his Git advice carries admitted bias; Kilo tips are marked as partly product-specific. - Name inconsistency in transcript for the Flask creator ("Armin" / "Armand") — recorded as transcribed, not corrected. - Statistics (90%, ~50%, 30% time saved, >50% context degradation) are the speaker's assertions, some secondhand (Armin's 30%). # Speaker Attribution & Provenance Record **Video:** Agentic Engineering: Working With AI, Not Just Using It — Brendan O'Leary ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Brendan O'Leary** | Sole speaker; presenter/creator of the talk; employee of Kilo Code (states "I work at Kilocode," "when I joined Kilo Code over a year ago") | Entire transcript | No guests, narrators, or other voices appear; the transcript is a single continuous talk. ## Third-Party Claims & Attributions (per speaker's account) - **Armin Ronacher** ("creator of Flask") — quoted as saying "We're no longer just using machines. We're now working with them," and as reporting a **30% time gain** from AI use. *(Note: speaker says "Armin" and later "Armand" — transcript inconsistency.)* - **Karpathy** — cited on context engineering: "the delicate art and science of filling the context window with just what needs to happen." - **Dex Horthy** — cited twice: "a bad line of research can potentially be hundreds of lines of bad code," and "AI can't replace thinking. It can only amplify the thinking you've done or the lack of thinking." Speaker recommends his YouTube videos. - **Unnamed senior engineers** — quoted paraphrase: "I'm having more fun programming now than I've had in years." ## Referenced Sources & Products - **path.kilo.ai** — speaker-compiled collection of workflow patterns. - **kilo.ai** — promotional endpoint. - Products/technologies mentioned: GitHub Copilot, GitLab (speaker's former employer), Kilo Code (ask/architect/code modes), MCP servers (GitHub MCP, Postgres MCP, Context7), agents.md, skills.md, VS Code, Balsamiq, Openclaw/Kiloclaw. - Anecdotes from speaker's own career (healthcare software engineering manager; iPad patient-history prototype with interns). ## Promotional Segments — FLAGGED - **Closing promotion:** "that's really the presentation that I have on Kilo. We've got some exciting new features coming up… if you haven't taken a look at Kilo, I've just a little plug at the end here, visit kilo.ai" — explicit plug by an employee of the promoted company. - **Embedded product promotion:** "Power user tips" for Kilo Code (at-mentioning, slash commands, right-click "add to Kilocode," autocomplete in VS Code) — presented as tips but product-specific; speaker discloses employer affiliation. ## Availability & Evidence Gaps - No curated metadata supplied; no comment availability, dates, view counts, or verified speaker identity beyond the title and transcript self-identification. - Quotes of Armin, Karpathy, and Horthy are the speaker's recollections, not direct external citations. - Transcript contains minor speaker self-corrections and a name inconsistency (Armin/Armand), recorded as-is. Let's talk a little bit about what I mean by agentic engineering. And let's maybe start with a question. If I were to ask you right now, how are you using AI in your work? Could you actually really explain it? Not just, you know, it helps me code faster. It can write code really fast, but like the real workflow. What you hand off, what you keep, how you decide in between. Most engineers can't and that's a little wild to me because 90% of engineers are already using AI tools or have used them. Maybe only half of them are using them on a regular basis, but that's a number that's definitely growing all the time. And that's the current state. So, the question isn't whether your team is using AI, they are. The question is whether you're getting the most out of it or you're just kind of auto completing your way through the day. That gap between using AI and being able to articulate how you work with it, that's what this talk is all about. And really, I think it represents a paradigm shift of how we think about AI. And you know, the history of AI and software engineering is moving uh very fast. It's also very surprisingly short, right? In the 20 early 2020s, we got tools that could finish the lines for you. You type, you know, half of a function signature and the model would guess the rest of it. You know, kind of like auto complete on steroids. It's a neat trick. And then in 2022, models started to be able to suggest entire functions, right? You could describe what you wanted and chat with a model and maybe get a working implementation back. And this is where GitHub Co-pilot first came on the scene and broke through and millions of developers started using it. And for the first time it was starting to seem like maybe AI wasn't a novelty, maybe it was generally useful. But then in 2025, something really broke. It's, you know, what we're living in now in 2026. The the models don't just suggest, they can execute. They can take a task and break it down and figure out which files need to be touched and make the changes and run the tests themselves and then come back with an actual pull request. And so, that's not just fancy auto complete. It's not just a a faster horse. It's a collaborator. It's a different way of working. And Armin, the creator of Flask for those Python folks here, put it, I think, perfectly. We're no longer just using machines. We're now working with them. And that framing, I think, captures this real shift. Right? Tools are things that you pick up and put down. You use a hammer. You don't work with a hammer. But the AI coding agents we have today, they're kind of somewhere more in between and they're maybe a little bit more like working with another engineer. Now, it just happens to be an engineer who's read every Stack Overflow answer ever written. And I think that needs a a mental model shift. And this is the mental model I want you to carry through the rest of this video and honestly through the rest of your, you know, next couple years of your career in working with these tools. I I do think they're still tools, but we have to think about them differently. You kind of have to think about your AI agent as an energetic, enthusiastic, extremely well-read, often confidently wrong junior developer. That junior developer is incredibly fast. They don't easily get tired. They don't have any ego about their code. They'll happily rewrite something six times if you ask them to. And they have an astonishing breadth of knowledge. They've seen lots of languages. They've seen lots of frameworks. They've seen lots of patterns. But, and this is critical, what they don't have is judgment. They don't know your business context. They don't understand the reasons why you made that very specific architectural decision 3 months ago. And they'll confidently write code that is technically correct and contextually wrong. Armand also said that he's gained more than 30% of time in his day because the machine is doing a lot of the work. That's a real gain. But he's getting that 30% because he knows what he can hand off and what he has to keep for himself. He's not just blindly accepting every suggestion. He's directing the work. And that's the difference between using AI and working with AI. And that's what agentic engineering actually means. And so, let's get tactical. If you're an engineer, how do we really get good at this? I think the number one thing to think about is context engineering. And here Karpathy says, you know, context engineering is a delicate art and science of, you know, filling the context window with just what needs to happen for the agent to have the right context for the right iteration for the next step. I think that's really critical for a couple of reasons. First, context is expensive, right? Every token you add into the context is going to add cost because all of those things, that whole chat history, is sent back in as a input tokens every time that you send it. And that, you know, can can add up pretty quickly. And the other key is that more context doesn't always mean better results. And in fact, um it can make the model actually dumber. Right? It's not just about the money. The quality can degrade as you get over about 50% full. And there's lots of things that can trap you here. And not the least of which are, you know, the facts that fact that MCP servers became so popular that we have a lot of these enabled all the time now. Well, each one of those loads more and more context. Uh you know, more and more input code tokens in the context. And and that can be a real problem if you start getting into this dumb zone around 50% context. And that also isn't the only problem because not only can more context be a problem, but bad context can be a problem and can poison everything. Right? So, this happens when you're maybe mis- mixing two different tasks that didn't really overlap. Or you've kind of got some outdated comments either in the code or that you've made to the agent. Or even worse, what I've seen a lot of people do is they start walking down the road with an agent and then realize, "Hey, we're down the wrong path. We've made a lot of wrong decisions." And they try to steer the agent back. But the problem is again, the agent is not doing real reasoning like you and I as a human. Right? It's taking all that context every time. And it may get lost in the middle or even see some of those negative things that you had before as still part of the context. And you see those negative patterns creeping back in if you're not careful. That's why it's better, you know, to not let these things kind of compound. But also, you know, always start a new session once you realize things are kind of off the rails. Right? Because not only is context expensive, the more we have doesn't always mean better quality. In fact, at a certain point there's a tipping point where it means worse quality. And bad context can corrupt the output. So, the real critical thing for engineers is to manage the context. And what does that mean? Well, one, I think it means persisting a lot of information outside of the context window so that we can bring it in, right? So, this is things like scratch pads for things we're working on, memory files, the agents.md, those kinds of files that help the agents have context to what you're working on. We also need to be very selective when we're selecting that context. So, that means only pull in what's relevant for this step of the problem, right? Don't just pull in everything that might be useful. And so, that could mean, you know, things like bringing in the right at mentions for files that we're referencing. That could mean making sure we don't have unnecessary MCP servers enabled. Uh and it means, you know, making sure that the agent has the right data and that we as a human have curated that data for the agent. And then, as it's getting bigger and that that window gets bigger, we want to summarize and trim and compress that context, right? If we've gone through a whole big deep dive and debugging session with the agent and now we think we have the problem and the solution, well, that's great. It might be time to compress that context and just focus the agent back in on, "Okay, now we understand this problem. We're going to go fix it." Uh and then the other most important thing is to isolate context. And I think this is why we've seen this huge rise in the past six or eight months of parallel agents because splitting work across several agents or several sessions can help things not accumulate. And really drive this kind of task separation. And again, if you think about it, aren't these all of the same things that I would tell a brand new engineering manager about about managing a junior engineer? Like the story I tell here is a when I was early in my career, I spent a lot of time as an engineering manager and product manager before I went into the dark arts of developer relations. And in my first job ever as an engineer manager, I was at a healthcare software company. And there was this new thing coming out called an iPad. And that dates me a little bit. Um but it was it was released in the market and we thought this could be a great place to collect patient history, you know, that form you have to fill out every year at the doctor. It's very critical to assessing a lot of your, you know, risk of disease. Um but having to fill it out from scratch every time is is not fun. And so, I designed in this other archaic tool that some people may have heard of called Balsamiq, basically a wireframing tool, a wireframe of what this would look like. Now, that wireframing tool used things like Comic Sans and like silly smiley face icons as placeholders. And a lot of other stuff like that that you'd expect from just a wireframe. And I handed that to a set of interns that we had working for us that summer thinking this is a great green field project for them to take some time on. And you know, a few weeks later I got back a working prototype and the font was Comic Sans and there were silly emoji placeholders. And that's because that's what the spec had in it. And so so whose fault was that? Obviously it was not the intern's fault. It was my fault as an engineering manager not giving the right context to those junior engineers as to what's important, what's not, and what we really need to focus on and what problem we're solving. And so I think the habits that can tie all of that together are you don't need to think about all four of those things for every task, you just need to think about doing one task per session, keep an eye on your context meter, and if you're in doubt and it feels like things are off the route rails, you're probably right. So start a new session, ask it to summarize the session for a new agent. Turns out that AI is really great at writing prompts for AI. So if you've worked on something with an agent for a while, have that agent summarize where you're at, you can now read it, make sure it matches with your understanding and then start a new uh session with just that right context. Again, it's a little bit of art and a little bit of science. So how do we put this into practice? Well, I think there's a lot of workflows, there's lots of things written out there that you can read. I've even compiled a lot of them at path.kilo.ai. It's a where you can find like all of these kinds of trends and ideas and workflow patterns that have been talked about. But what I think I keep coming back to is is maybe one of the simpler ones and that's the research plan implement loop. Right? And I think this really helps us solve for a lot of like classic mistakes that people do when they pick up agentic engineering for the first time or pick up AI to help try to do some engineering. Um and what most people do is say, "Hey, help me implement this feature. I want it to do X and Y." And you know, these large language models are very good at outputting lots of code. In fact, when I joined Kilo Code over a year ago, I made a pronouncement that we would never have our website be just prompt and a whole lot of code flying by. Makes for a great demo and you've seen lots and lots of coding agents that maybe that's how they show it off. But I think the reality is jumping straight into code like that can cause a lot of wrong assumptions, it can waste even more time rather than saving time, and just create a lot of frustration. And it really creates that kind of paradigm that we've seen where people are kind of anti-AI or think that AI is not a useful tool because they've jumped right in and gotten, you know, put garbage in and gotten garbage out. Uh or maybe it's been a while since they've used it, right? I mean, if you think of the the Will Smith eating spaghetti when it comes to AI videos, that's come a long way in just the past two, three, four years. You know, the same is true of the AI coding models, but you have to do what works to give them the best chance at getting a great result. And what that is is first understanding the problem really well and making sure you and the AI agent can understand the problem really well. Then laying out explicit steps for implementing that uh that those changes or fixing that problem. And only then do we jump to the implementation phase where we're writing code. And Dex Horthy has a great uh phrase that he says here, which is a bad line of research can potentially be hundreds of lines of bad code. And so we're really going to focus in on how do we get the research and the plan in place in order to make give ourselves the best chance of having great code come out. So in that first phase, we're going to use a tool that is only going to be focused in on research. And so for Kilo, we call that ask mode. And the reason we call it that is because the ask mode can't actually do anything. It can only chat. It can't write files. It can maybe read files if you let it, but it can't, you know, start trying to code a solution. And so instead of trying to to code a solution from the beginning, we're going to first try to understand the system. You know, how does it actually work today? Where are the right files that are going to be involved? What are the right paradigms that we want to mirror or how does this differ from something that we have already? And you know, just kind of learn where in the code base this this is going to go and you know, how the data is going to flow through the system and how it's going to change with our change as well as like any edge cases we can need to consider, right? AI is really great at brainstorming and so it can help you kind of brainstorm those things and make sure you've really covered all of your bases. And then once you're done that research, what's going to come out of that is an actual output document that shows the the details of that research that you can then read and basically agree with and understand, "Hey, this this matches my understanding of the problem. I think we're ready to move on to the plan." And so then once we've reviewed that as a human, now we can say, "Okay, let's outline the next steps. What kind of you know, files are we going to create or or change? Maybe there's some code snippets, but not always is it a good idea to have a code snippet in the plan. We are definitely going to include like how is how are we going to verify and know this change is correct? What are the test either changes or additions that we're going to make to know that? And we're also going to be really explicit at the plan planning phase about what is in and out of scope, what is going to change, what isn't going to change. And again, the output of that is going to be a very clear plan file, right? You'll see a lot of repositories nowadays have a folder called plans. Right? And we want to have that plan file be step-by-step instructions with specific changes that we're going to make that have test commands to verify it, that has a strategy for understanding how it's going to change the system. And it's going to be very clear so that we can even use maybe a smaller, faster, or cheaper model to implement it because we've spent the time in the research and plan phase to really understand what we're going to be doing once we get to implementing the change. And when we come to implementing the change, we now can start over a new session and give it just the plan execution. It allows us to keep the context in that session very low. It allows us to carefully review each change and I think commit very frequently. Now, I used to work at a company called GitLab for many, many years. Uh so maybe I'm a little biased towards Git, but I think Git can be a huge helper here when it comes to helping you slowly iterate and understand the changes that the agents are making. I treat Git on my local machine kind of like my own first pull request review with my agents before I maybe put up an actual pull request for my uh you know, for my colleagues to look at. But I think again, it's critical to understand here that human research at the planning or sorry, human time at the planning and research phases is really the highest highest leverage use of your time. By the time you're implementing, you want to have all that hard thinking done. Uh and that's really critical cuz again, going back to Dex Horthy who's who's spoken a lot on the subject and uh I I highly recommend you check out his you you know, videos of him on YouTube talking about this. He says very aptly that AI can't replace thinking. It can only amplify the thinking you've done or the lack of thinking you haven't done or you know, the fact that you haven't thought it through. And so let's talk about how we can figure our agents kind of like one more step down from this this uh paradigm of research plan implement to really make sure we do this. So first we talked about modes and customizations. We already talked about these modes, ask, code, architect. These modes that are specialized and focused on the thing that we're trying to get done. Right? Architect is maybe for planning. Ask mode is for research. Code mode is for actually implementing. Uh then we also want to have, you know, a set of rules that make sense for our workspace, right? For the the repository we're in. Uh or maybe globally on our machine so that we understand, you know, that we have a certain set of rules that we always want to adhere to. Uh and agents are pretty good at loading in and understanding those rules. Uh but we have to have them written down for them to have those in their context, right? And so I think a lot of the agent behavior then is are things that we want to tweak as we're learning, right? How many Do we want to do multiple agents at a time? Do we want those agents to use work trees so that we can then again, merge them back in to our local uh repository locally before committing them to to a pull request? Uh how much do we want to auto-approve, right? So most agents have the ability to tune, you know, what are the things that it can do independently? What are the tools it can use independently? Can it read files? Can it read files inside or outside of the workspace? Uh can it run tests? You know, what can the agent do autonomously without your intervention versus what do you need to approve? Yeah, I think this is something that you have to set up to be comfortable with in the beginning and then also you need to be comfortable changing as you learn how to use these tools. And then I think a good mental model um for this agent configuration is maybe kind of three distinct buckets, right? We talked about modes, right? This is that that role-based configuration, you know, a behavior of an agent that we want. Uh but there's two other really key things and that is the agents.md and then skills.md that you'll hear about. Uh and so what are those what's the difference between the two? Well, the agents.md is now quickly becoming the de facto standard for where all agents go kind of for their readme, for the like always-on rules and details about the project. Uh so I think it's critical that your project has an agents.md with a minimal amount of information that an agent needs to know about, you know, what are the conventions that we're using, what are the commands that we're using to get it built or tested, and like what are the requirements around testing, uh or requirements that we need to be sure check off before committing. And then skills are kind of more of a specific workflow, right? So there's reusable kind of playbooks for agents. So if there's something that you're doing a lot, you're making motion graphics with their motion often, or you're um you know, doing some sort of like uh daily or weekly or monthly change log compiling, those kinds of things are great to put in as skills that an agent can then pick up when it needs it to do those specific kinds of workflows. And so typically those are on demand and you say, "Hey, let's use this skill for this task." Versus the agents is almost always loaded into the context for the agent, so it knows what's going on. And then of course, I I work at Kilocode, and so I've got some power user tips there, um but I think some of these many of these apply, you know, regardless of which agent you're using, but I think they're critical as you kind of get comfortable with those first kinds of paradigms. How do I now customize this and make it work for me? And one is at-mentioning for context. So mentioning files or commits or, you know, things from the terminal that output. Those kinds of things and bringing them into the context quickly are really helpful. Uh using slash commands to do things like starting a new task when we need to, or condensing the context when it's getting too full. Uh those kind of quick commands can help us move a lot faster. Uh we also can, if we're working in in VS Code uh with Kilocode, we can select uh a section of of code and right-click and say add to Kilocode, and then that context is brought right in there, and I can then talk or ask or uh questions about the that code, or ask the agent to change a certain part about that code. Uh and then of course, we have autocomplete built in as well, which I think is still useful, especially because we also have it not just in code, but as you're prompting. And then kind of beyond the IDE, I think we're seeing, you know, also this shift this year in, you know, where else do I want to be able to use this? In the CLI, from my mobile phone, in a cloud agent, directly in Slack. Right? The ability to kind of use these agents wherever you are is something that's becoming more expected uh of of everyone and everyone's agents. And I think that's a good thing. I think that means that we're starting to learn how we can use this these agents again more like a collaborator that's everywhere that we need to be. And then one other thing that I want to talk about um are is getting other context things in. First of all, model context protocol, right? Context is right in the name. Um the idea of this is, you know, fundamentally these models originally can only like it receive input tokens and create output tokens, right? Uh and slowly but surely we've been enabling them to use tools where they can, you know, make tool calls out uh and affect things in the environment, like running tests. Uh the MCP, the concept of MCP basically expands this to say, "Hey, I want to give other tools." Right? For instance, the GitHub MCP gives the agent a lot of tools to interact with the GitHub API, look up pull requests, um look up comments, look up issues, and understand a lot more about your your GitHub environment, right? Um or context seven helps it look for up-to-date framework documentation, because of course, as you know, the LLMs kind of have a cutoff date where their knowledge cuts off, and then then anything that's improved since then they don't know about. Um so these MCP servers can be very helpful, and there's there's thousands of them out there. Uh but the concern is that every one of them is going to add at least some information, right? Details about those tools that it has to the system prompt that gets sent every time uh you're having an interaction with an agent. And so you want to make sure, if you're not actually using that, to disable it, right? Let's say I have a Postgres MCP that connects to my database, and I'm doing a whole bunch of front-end work that doesn't involve the database at all. Well, that Postgres MCP is just going to be wasted tokens, and maybe even worse, tokens that help, you know, kind of confuse the agent and and not understand that it's not supposed to touch the database right now. Uh so we want to be really careful to not like overuse MCPs. And then another thing we hear from um enterprises a lot is how do we work with internal platform APIs? Uh and I think that, you know, there's kind of four different ways of doing that. One, if there's already an OpenAI open API spec for it, or Swagger spec, use that. If there's not, then convert it to markdown so that you can save that markdown, you know, in the agents.md or somewhere else in the repository to reference it. Uh and if it's something that changes a little bit more frequently, maybe you do need to have like a reference URL that you can pull in uh and have the agent go pull every time to see the latest and greatest. Uh and then we've seen some customers who, you know, have complex multi-step, multi-system workflows, where building their own MCP server might be the right choice. But, you know, one way or another, I think the the key is to, when working alongside Kilo or any of these agents, you know, isolate your work from the agent's work, and then review that agent's work as a pull request, right? That helps you understand, you know, how can I um best review the code just like I would review a junior engineer's code. And so that's really the presentation that I have on Kilo. We've got some exciting new features coming up. We've got, you know, expanded across all these surfaces. Uh we also have a big focus on Openclaw and Kiloclaw and making a very safe way to use um Openclaw agents. Uh and so if you haven't taken a look at Kilo, I've just a little plug at the end here, visit kilo.ai, uh and we'd love to get your feedback on what we're building. And you know, just kind of to give you, you know, where do we go from here? Again, I think you've kind of got to pick a tool and get lots of reps, right? We said earlier on that, you know, it's part art and part science, and I think that just means you need a lot of reps, right? To kind of get the feel for what can I trust the models to do, and what can't I trust the models to do. Uh and then try this research, plan, implement, feedback loop. See how that works for you. Um and I think maybe you'll end up like some of these other senior engineers who have said, "Hey, look, I'm having more fun programming now than I've had in in years and years." Uh as we, you know, farm out some of this tedious work to AI agents and let our brains work on the harder engineering problems. Thanks.