Coding agents now execute tasks, edit files, run tests, and return pull requests, so engineers need to direct them like fast junior developers.
2
Careful context management improves agent quality because excessive or outdated context can increase cost and make results worse.
3
The research, plan, implement, feedback loop gives agents better instructions and lets humans spend their time on decisions that require judgment.
Summary
Brendan O'Leary argues that coding agents have changed software work from autocomplete toward collaboration. They can break down tasks, modify files, run tests, and prepare pull requests, but they do not understand business context or the reasons behind existing design choices. O'Leary compares them to extremely fast, well-read junior developers who need clear direction and review. He focuses on context engineering: keeping only relevant information in the context window, storing durable project knowledge in files, isolating tasks, and starting fresh sessions when work goes off course. His main workflow is research, plan, implement, and feedback. The agent first studies the codebase, then produces a plan with scope and verification steps, and only then writes code. Humans review the research and plan, inspect changes locally with Git, and decide what the agent can do independently. The approach trades instant demos for a workflow with more control and clearer points for human judgment.
Coding agents require a different working model from autocomplete
O'Leary opens by asking engineers to explain what they hand to AI, what they keep, and how they decide between the two. He says most engineers cannot describe that workflow, even though 90% already use or have used AI tools and about half use them regularly. Earlier systems completed lines and then suggested whole functions. The newer generation can take a task, identify files, make changes, run tests, and return a pull request. O'Leary uses Armand's framing that engineers are now working with machines. The agent is still a tool, but the relationship looks more like collaboration than pressing an autocomplete button.
Agents are fast junior developers without judgment
O'Leary describes an AI agent as an energetic, enthusiastic, extremely well-read junior developer. It is fast, does not tire, has no ego about its code, and can rewrite the same work repeatedly. It has broad exposure to languages, frameworks, and patterns. It does not know the business context or why a specific architectural choice was made. That means it can produce code that is technically correct but wrong for the surrounding system. O'Leary connects Armand's reported gain of more than 30% of his day to knowing what to delegate and what to retain, rather than accepting every suggestion.
Context engineering means filling the context window with the information needed for the next step. O'Leary explains that the conversation history is sent as input tokens each time, so additional context adds cost. More context can also make the model perform worse, with quality degrading when the window gets over about 50% full. MCP servers can quietly add tool descriptions and other information. Bad context causes a separate problem. Mixed tasks, outdated comments, and attempts to steer an agent away from a bad path can leave old mistakes in the conversation, where they may reappear in later output.
Context should be stored, selected, compressed, and isolated
O'Leary recommends persisting useful information outside the context window in scratch pads, memory files, and agents.md files. Each step should bring in only the relevant files and data, rather than everything that might help. Unneeded MCP servers should be disabled. Long debugging sessions should be summarized and compressed once the problem and solution are understood. Separate sessions or parallel agents keep unrelated work from accumulating in one conversation. If a session feels off track, he recommends asking the agent for a summary, checking that summary as a human, and starting a new session with only the corrected context.
Research and planning should happen before implementation
O'Leary's preferred workflow is a research, plan, implement loop. He warns that starting with 'help me implement this feature' encourages the model to produce code before it understands the system. In the research phase, the agent examines how the code works, finds the relevant files, follows data flow, identifies patterns to copy, and considers edge cases. The result is a research document that a human reads and approves. The planning phase then specifies files to change, verification steps, tests, and what is in or out of scope. O'Leary quotes Dex Horthy's warning that a bad line of research can become hundreds of lines of bad code.
A separate implementation session keeps execution focused
After reviewing the research and plan, O'Leary starts a new session for implementation and provides the plan execution rather than the entire exploratory conversation. This keeps the context small and makes each change easier to inspect. He recommends committing frequently and treating local Git work as a first pull request review before asking colleagues to review the actual pull request. The plan also allows a smaller, faster, or cheaper model to implement the work because the difficult decisions have already been made. Human time spent on research and planning is where O'Leary places the most value.
Modes, project rules, and skills shape agent behavior
O'Leary describes specialized modes such as ask for research, architect for planning, and code for implementation. A repository should also have written rules covering conventions, build and test commands, and checks required before committing. He distinguishes agents.md from skills. agents.md is an always-loaded project guide with the information every agent needs. Skills are on-demand playbooks for repeatable workflows, such as compiling a change log or creating motion graphics. Agent settings also control parallel work, work trees, tool access, and which actions require approval.
MCP integrations are useful only when their context is relevant
MCP servers let agents call tools and access external systems. The GitHub MCP can expose pull requests, comments, issues, and other GitHub data. Context7 can retrieve current framework documentation. O'Leary warns that every enabled MCP adds information to the system prompt, even when the current task does not use it. A Postgres MCP is wasted context during front-end work and might confuse the agent about whether it should touch the database. For internal platform APIs, he suggests using an existing OpenAPI or Swagger specification, converting documentation to Markdown, pulling a frequently changing reference URL, or building an MCP server for complex multi-system workflows.
"You kind of have to think about your AI agent as an energetic, enthusiastic, extremely well-read, often confidently wrong junior developer."03:03
Who should watch
You use a coding agent but cannot clearly explain what it should handle, what you should review, and how you make those decisions.
Your agent sessions become confused after long debugging or mixed-task conversations, and you need a practical way to reset and preserve useful context.
You want agents to work against real repositories while keeping scope, testing, approvals, and Git review under human control.
