# The Future of Coding: AI Agents & the Next Tech Revolution

Ricky Doar, Cursor | Coding Agents Conference 2026 | 26:45

Source: https://www.youtube.com/watch?v=Bc71ywLTg0I
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/the-future-of-coding-ai-agents-the-next-tech-revolution
Published: 2026-02-21
Tags: agents, coding-agents, context-engineering, evals, tool-use

## TL;DR
- AI coding power users break large problems into tasks that fit the model's abilities and keep the engineer responsible for architecture.
- A fresh chat with only relevant context usually works better than carrying an old, bloated context window into a new task.
- Enterprise teams need to understand and own AI-written code, while deterministic hooks can enforce requirements that language rules may miss.

## Summary
Ricky Doar describes the habits he sees among effective AI coding teams working with Cursor. The main skill is learning how to divide work into tasks that an AI model can handle, then managing the context given to it. Engineers still need to understand their codebase and make architectural decisions. Doar says Cursor's codebase indexing and semantic search have improved work on older systems because the model can find existing patterns to follow. He recommends starting a new chat for each task, using plan mode when a larger project needs decisions recorded, and opening a separate context when debugging a feature. Enterprise engineers should understand code before shipping it, even when the AI wrote it. Doar also explains the limits of natural-language rules. Strong and soft rules can be stated differently, but deterministic hooks are better for checks that must always happen. His example of improving a GPT-5 harness shows that the agent's surrounding workflow can affect results as much as the model itself.

## Key ideas
### AI coding requires learning how to divide work into the right-sized tasks
[01:43](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=103s)
Doar says working with AI is a new skill next to engineering. The strongest users break large problems into bite-sized tasks that the model is more likely to complete. Tasks that are too large can lead to hallucinations, while tasks that are too small may waste the model's ability. This requires understanding what a particular model can do, where it tends to go wrong, and how much context it needs. He compares the skill to engineering fundamentals, where thinking through a problem matters more than memorizing syntax. The practical question is what size of task a given model can solve reliably.

### Engineers must remain responsible for architecture and code ownership
[04:44](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=284s)
Doar warns that AI can make engineers lazy if they hand strategic decisions to it. Cursor's ask mode can answer questions about a codebase without writing code, which gives engineers a way to learn how a system works before changing it. He says the engineer still has to understand the codebase, choose the architecture, and drive the agent. In an enterprise setting, a team should not ship code it does not understand simply because the AI produced it. When a bug reaches production, blaming the AI is not an acceptable operating model. The person who ships the pull request remains responsible for the result.

### Codebase indexing makes AI more useful on older systems
[07:19](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=439s)
Doar challenges the idea that AI is mainly useful for greenfield work. Cursor indexes the whole codebase and creates a semantic search, so a request such as adding authentication can retrieve relevant areas across a large system. Existing code gives the model patterns to follow instead of leaving every design choice open. Engineers can point Cursor to a well-built API, a related file, or components from an existing design system. This reduces arbitrary choices by the model. Doar argues that brownfield work can benefit from this because the codebase contains examples of the decisions the new code should match.

### A clean context window is usually better than maximum context
[10:51](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=651s)
Doar says giving a model more context does not always improve the answer. He describes a drop-off in performance as large context windows become heavily filled, including more hallucinations at high usage levels. His advice is to include only information relevant to the current task and start a new chat when the task changes. An old chat can contain decisions that are no longer relevant and cause the model to make arbitrary choices. Plan mode can help with larger work by creating a markdown plan, recording decisions, and asking the engineer to choose between paths. That plan can then seed a new chat without carrying over the entire earlier conversation.

### Debugging should often happen outside the context that created the bug
[14:27](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=867s)
Doar describes AI debugging as frustrating when the engineer tries to fix a bug in the same chat that created the feature. The model has accumulated context that treats its earlier decisions as correct, so it may keep following the same path instead of questioning the source of the problem. A separate context removes some of that attachment and gives the debugging task a cleaner starting point. This follows his broader advice that context is a boundary around a task. Related work can be useful, but carrying every previous decision forward can make the model confused and less willing to reconsider its assumptions.

### Engineers can ask AI to compare its solution with their own
[16:05](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=965s)
When Cursor proposes a different implementation, Doar does not recommend accepting it blindly or rejecting it automatically. The engineer should understand the solution before using it, especially when the software will serve a large enterprise audience. One useful prompt is to explain the approach the engineer would have taken and ask for the advantages and disadvantages of both approaches. This lets AI provide analysis while keeping the engineer involved in the decision. Doar says teams should slow down at important choice points, learn why a solution works, and then choose a path they can support through the following changes.

### Natural-language rules cannot guarantee deterministic behavior
[19:09](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=1149s)
Doar explains that AI systems are non-deterministic, so even a rule described as the most important instruction may be broken sometimes. A soft preference can be written as something the model should generally try to do, while a hard rule can be stated as the highest-priority instruction. Models still differ in how easy they are to steer. For checks that must always happen, Doar recommends deterministic hooks instead of relying on a prompt rule. Cursor hooks can run before or after prompts and code generation. A company could use one to check generated code for a required property, such as copied code, rather than hoping the model remembers the instruction.

### The agent harness needs testing for the task it performs
[23:47](https://www.youtube.com/watch?v=Bc71ywLTg0I&t=1427s)
Doar separates a loose harness for a conversational agent from the more prescriptive harness needed by an agent that can act throughout a codebase. Cursor's agent works with tools for editing, searching, browsing the web, planning, and interacting with MCPs. The harness needs to define how those tools are used and should be tested against the outcomes the team wants. Doar gives an example where fixing a GPT-5 harness bug raised a benchmark result from 45% to 65%. He says benchmark scores are imperfect, but the example shows that the surrounding workflow can substantially change an agent's performance. Teams should test and compare harness versions rather than treating the model alone as the source of results.

## Notable quotes
- "The best people that we work with on a day-to-day basis are the ones that are really, really good at breaking down large problems into bite-sized tasks that the AI is far more likely to be able to accomplish." (02:21)
- "You have to stay in the driver's seat, you have to make the right decisions architecturally, you have to drive the agent in the right direction." (06:05)
- "The more pristine you can keep your context, actually the less the better." (12:26)
- "You can't blame the AI if a bug comes out." (17:03)
- "The honest answer is it's not a solved problem yet." (20:17)

## Tools & references mentioned
- Cursor
- Anthropic
- Claude
- Sonnet
- Opus
- Gemini
- GPT-5 Codex
- MCP

## Who should watch
- You are introducing Cursor or another coding agent to an engineering team and need practical guidance on task sizing, onboarding, and context management.
- Your team is shipping AI-written code and needs a clearer boundary between engineer judgment, model suggestions, and automated checks.
- You are building an agent harness and want to understand when prompts are enough and when deterministic hooks and tool workflows are needed.

## Related talks

- [Co-Engineering: The New Era of Human-AI Collaboration](https://mlopstalks.com/talks/co-engineering-the-new-era-of-human-ai-collaboration) (Kiriti Badam, OpenAI, 29:25)
- [How Agents Changed Vibe Coding Forever](https://mlopstalks.com/talks/how-agents-changed-vibe-coding-forever) (Beyang Liu, Sourcegraph, 49:49)
- [AI Coding Agents Change Software Development Forever](https://mlopstalks.com/talks/ai-coding-agents-change-software-development-forever) (Michele Catasta, Replit & Aparna Dhinakaran, Arize AI & Erik Schluntz, Anthropic, 20:32)
- [Building Artificial Engineering Intelligence for Engineering Teams](https://mlopstalks.com/talks/building-artificial-engineering-intelligence-for-engineering-teams) (Aishwarya Shankar, Intelligence AI, 10:10)
- [Coding with AI](https://mlopstalks.com/talks/coding-with-ai) (Chip Huyen, Tep Studio, 44:29)