Agentic Engineering: Working With AI, Not Just Using It — Brendan O'Leary

April 7, 202627:0397,642 views

Summary

Brendan O'Leary, Developer Relations Engineer at Kilo Code, delivers a practitioner-focused talk on what he calls "agentic engineering" — the discipline of working with AI coding agents as collaborators rather than simply using them as tools. He opens by noting that while 90% of engineers have used AI tools and roughly half use them regularly, most cannot articulate their actual workflow: what they hand off, what they keep, and how they decide. This gap, he argues, represents the core challenge of the current moment.

O'Leary traces a compressed history of AI in software development: line-completion tools in the early 2020s, function-level suggestions and GitHub Copilot's breakthrough in 2022, and the 2025 inflection where models began executing full tasks — breaking down requirements, touching files, running tests, and returning pull requests. He quotes Flask creator Armin Ronacher: "We are no longer just using machines. We are now working with them." His proposed mental model: treat your AI agent as an "energetic, enthusiastic, extremely well-read, often confidently wrong junior developer" — fast, tireless, ego-free, with enormous breadth but no business context or architectural judgment. He references Ronacher's claim of reclaiming more than 30% of his working day, attributable specifically to knowing what to delegate versus what to retain.

The central technical concept is context engineering, citing Andrej Karpathy's framing of it as "the delicate art and science of filling the context window with just what needs to happen for the agent to have the right context for the right iteration." O'Leary identifies two compounding failure modes: (1) context bloat — model quality can degrade noticeably above approximately 50% context window utilization, and every enabled MCP server loads additional tokens on every request; (2) context poisoning — mixing unrelated tasks, stale comments, or a failed exploratory path can cause bad patterns to re-emerge because the model lacks genuine reasoning about its own history. His prescriptions: persist working memory in files like agents.md outside the context window; pull in only what is relevant to the current step; compress and summarize long debugging sessions before pivoting to implementation; isolate work across parallel agents or separate sessions. He notes that the rise of parallel agents over the past six to eight months is a direct response to this problem.

For workflow, O'Leary advocates the research-plan-implement loop. In the research phase, use a read-only "ask mode" (Kilo Code's term for a mode that cannot write files) to understand the codebase, identify relevant files, and surface edge cases. The output is a research document the engineer reviews and approves. The planning phase produces an explicit step-by-step plan file — specifying files to change, test commands to verify correctness, and explicit scope boundaries — detailed enough that a smaller, faster, or cheaper model can execute it. He quotes Dax Raad: "A bad line of research can potentially be hundreds of lines of bad code." Implementation then starts in a fresh session with only the plan as context, enabling small commits and careful review — O'Leary likens local Git diffs to a personal pre-review before a formal pull request. He also references a resource he maintains at path.kilo.ai compiling agent workflow patterns.

On agent configuration, he distinguishes three layers: mode-based role configuration (ask/architect/code), workspace-level rules in agents.md (conventions, build and test commands, pre-commit requirements), and on-demand skill files for reusable playbooks. For MCP servers, he recommends disabling any server not actively in use — a Postgres MCP loaded during pure front-end work wastes tokens and can confuse agent scope. For internal platform APIs, he suggests four strategies: use existing OpenAPI/Swagger specs, convert to markdown for repo storage, maintain a reference URL for frequently changing specs, or build a custom MCP for complex multi-system workflows. He closes by encouraging engineers to pick a tool, accumulate reps, and try the research-plan-implement loop, noting that senior engineers report rediscovering enjoyment in programming as agents absorb tedious work.

Key Takeaways

•Treat AI coding agents as a junior developer with broad knowledge but no business context — provide explicit architectural decisions and scope boundaries rather than expecting them to infer them.
•Context window quality degrades noticeably around 50% utilization; monitor your context meter and start a new session before the window gets too full.
•MCP servers each add tokens to every request; disable any server not actively needed for the current task to avoid wasted tokens and scope confusion.
•Context poisoning from a failed exploratory path persists; start a new session and have the agent summarize its understanding rather than trying to steer an off-rails conversation back on track.
•Follow the research-plan-implement loop: use a read-only mode to produce a research document, review and approve it, then produce an explicit plan file before writing any code.
•A detailed plan file with step-by-step changes, test commands, and explicit scope boundaries allows a smaller, cheaper model to handle implementation — invest human time in research and planning, not execution.
•Persist project context (conventions, test commands, pre-commit requirements) in an agents.md file so every session starts with the right always-on rules without bloating the working context.
•Use separate skills files for reusable on-demand workflows (changelogs, motion graphics, recurring tasks) rather than loading everything into agents.md.
•Use parallel agents or separate sessions to isolate distinct tasks and prevent context accumulation across unrelated work.
•Commit frequently during implementation and use local Git diffs as a first-pass review of agent changes before creating a pull request for colleagues.

Transcript

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. Ma...