Choosing Your AI Copilot: Maximizing Developer Productivity

Sepehr Khosravi's thesis is that the public argument about AI coding tools is polarized in a way that helps nobody. Executives claim AI will replace mid-level engineers; a loud counter-camp claims the tools are hype. His position is that the truth sits in the middle, that measured productivity gains are real but modest for experienced engineers on mature codebases, and that the size of the gain depends heavily on how well you drive the tool rather than which tool you bought.

Khosravi is a machine learning platform engineer at Coinbase, teaches generative AI and rapid product development at UC Berkeley, and founded AI Scouts, a free program teaching teenagers to build AI applications. He gave this 51-minute, 45-second talk at QCon AI New York 2025; InfoQ published the recording and transcript on June 3, 2026. He notes he gave an earlier version of the talk at QCon San Francisco, which gives him a rough before-and-after comparison of audience adoption.

These notes report what Khosravi presented. Where I add explanation that the talk did not state, it is labeled as supplementary context.

What You Will Learn

• How large-scale survey and research data frames AI-assisted developer productivity, and why the headline numbers are smaller than marketing claims.
• The three tiers of AI coding tooling and which audience each one serves.
• Concrete Cursor features — tab completion, agent mode, multi-agent comparison, plan mode, commands, rules, MCP servers, indexing, checkpoints, browser, and YOLO mode — and when each is worth using.
• How Claude Code's skills, subagents, commands, and plugins differ from Cursor's model, and why separate subagent context windows matter.
• A worked comparison showing where a terminal-based research agent beats an IDE agent, and where it over-engineers.
• Why context engineering matters more than prompt wording, and how context rot degrades results as you add tools and rules.
• Which task types AI helps most and least: greenfield versus brownfield, task complexity, and language popularity.
• Organizational lessons from Databricks about why measured productivity gains stall even when the technical gain is available.
• The failure modes: tech debt, skill erosion, hallucination, security and dependency risk.

Where the Industry Actually Stands

Khosravi opened with live audience polling and then contrasted it against broader data. In the New York room, roughly 50% self-identified as intermediate AI-assisted coders, 33% as advanced, 13% as beginners, and 5% said they use no AI at all. Over 30% said that 50% to 75% of their daily code is AI-generated or AI-assisted. Asked which tools they use most, the room named Cursor and Claude first, with Copilot third.

He had comparable numbers from the San Francisco version of the talk. There, about 24% reported 50% to 75% AI-generated code, and only 2% used no AI tools. The more striking difference was tool choice: the San Francisco audience was still mostly on Copilot, while the New York audience had moved to Cursor and Claude Code. Khosravi reads this as New York being somewhat further along in adoption, while acknowledging these are small self-selected conference samples rather than representative measurements.

For a wider view he used the Stack Overflow developer survey, which he describes as the largest developer survey he could find that year, covering roughly 50,000 developers. Two findings stood out to him. First, about one in three developers use AI once a month or less — lower than he expected, though he flags that a Stack Overflow audience may be biased toward lower AI usage. Second, sentiment moved the wrong way. Positive sentiment toward AI tooling had been above 70% in the previous two years but sat around 60% in 2025, despite usage and tool quality both being higher than ever.

His explanation for the sentiment drop is social rather than technical. Statements like Mark Zuckerberg's claim that AI would replace mid-level engineers by the end of 2025 provoke a natural backlash, and a visible anti-AI counter-movement forms to refute the overclaiming. The tools did not get worse; the discourse got more extreme in both directions.

The Stanford Productivity Research

The most useful number in the talk comes from a long-term Stanford study of developer productivity that Khosravi cites as covering over 100,000 developers. He does not walk through its methodology in detail but emphasizes that it went beyond counting commits or pull requests, using manual reviewers to inspect code and judge real productivity. Its reported findings:

The rework figure is the important one. Raw output volume overstates the benefit because a meaningful fraction of generated code is thrown away or rewritten, so the net gain lands far below the gross gain. Khosravi argues the net number can be higher for people who become genuinely expert with the tools and use them correctly, but treats 15% to 20% as a reasonable floor expectation. That is his opinion layered on the study, not a study finding.

The same research also breaks the gain down by task type, which he returns to near the end of the talk:

• Greenfield work, meaning a codebase started from scratch, shows the strongest effect at roughly 35% to 40% productivity gain.
• Mature codebases show a declining gain as the project accumulates history and constraints.
• High task complexity pushes the gain down further, to the point where there may be no productivity gain at all.
• Language popularity matters. Python and Java are well represented in training data and the models do noticeably better on them; very new languages or very old ones with little public material online produce worse results.

Khosravi draws a forward-looking consequence from the language point: when you are choosing a language for a new repository, the amount of AI assistance available for that language is now a legitimate selection criterion alongside the traditional ones.

Three Tiers of Tooling

Khosravi divides the tool landscape into three tiers with genuinely different audiences and different realistic gains.

The first tier is all-in-one tools for non-developers. This is where the 100x headlines come from, and he thinks they are basically accurate for that audience. In his Berkeley classes and the teams he teaches, people with no technical background who previously could not write software at all are now launching companies and generating revenue. Going from zero capability to some capability is an enormous multiple; it does not transfer to professionals.

The second tier is IDE layers built on top of foundation models — Cursor, GitHub Copilot, Windsurf, IntelliJ's AI features, Cline, and Google Antigravity. These wrap an existing editor experience around a model you can usually swap.

The third tier is terminal-based agentic tools built by the foundation model labs themselves — Claude Code from Anthropic, Codex from OpenAI, Gemini CLI from Google, and Kimi. These live in the terminal rather than an editor and are built by the same organization that trains the model.

He notes that despite all of this, the Stack Overflow survey still shows 75% of developers using Visual Studio Code as their primary development tool. Asked what they would want to adopt next, VS Code users named a top four that included Claude Code and Cursor — the two tools he goes on to cover in depth, though he is explicit that he chose them on his own judgment rather than because the survey ranked them.

Cursor in Depth

Khosravi gives fourteen Cursor tips, ordered roughly from beginner to expert.

Tab completion is his entry point for anyone skeptical of AI or starting from zero. Cursor suggests inline completions in grey text that you accept with tab. It runs on Cursor's own custom model and adapts to your recent changes, the edits you have accepted, and linting errors. He reports commonly generating 10 to 20 lines from a single tab press.

Agent mode is the main interface. You choose a model, type instructions, and it generates and edits code. What he thinks makes it strong is the tooling attached to it: it can search the entire codebase, search the web, call MCP servers, and access your terminal to run commands.

Multi-agent mode runs the same prompt against three different agents simultaneously. His main use is model evaluation. When a new model ships — he gives ChatGPT 5.2 as the example against his then-current Opus 4.5 — he runs the new model in shadow mode for about a week, compares outputs on real work, and then decides whether to switch. This is a lightweight personal benchmark rather than a formal eval suite.

He illustrates model differences with one concrete task: generate a simple HTML landing page for an upcoming M5 Mac.

His reading is that Claude is generally the strongest coding model, Gemini is currently the best at generating UI directly, and Composer — Cursor's own in-house model — wins on latency. He calls Composer one of his favorite Cursor features and later names it his main reason for preferring Cursor over alternatives like Cline. Note this is a single informal comparison of one task, not a benchmark.

Shift-Tab switches between three modes. Agent mode makes edits. Ask mode lets you interrogate the codebase without any edits being applied. Plan mode is for larger work: his recommended workflow is to write full project specifications in a Google Doc first, paste them into plan mode, let Cursor produce a Markdown plan file broken into subtasks, review that plan, and only then let it execute subtask by subtask.

Cursor Sound he calls underrated. Agentic coding involves waiting minutes for generation, during which you switch tabs and forget to come back. A completion chime closes that loop. He mentions, with obvious amusement, that the attention gap is a large enough problem that Y Combinator funded "brainrot IDE", which plays short-form videos and games while your code generates. He does not recommend it.

Cursor Commands package repeated terminal workflows behind a single invocation. His favorite is a create-pr command that replaces three separate git commands and also encodes the PR description format he wants. Individually small, but repeated daily.

Cursor Rules are stored prompts. Where commands are explicitly invoked, rules have four application modes:

• Always Apply — injected into every chat. Good for blanket instructions such as "do not generate comments".
• Apply Intelligently — the model decides per task whether the rule is relevant.
• Apply to specific files — scoped by path or file type, for example enforcing a UI convention only when editing UI files.
• Apply Manually — never triggered automatically; you invoke it when you want it.

Rules can be set per project, per user, or shared with a team. They can also be written in the AGENTS.md format, which many tools including Codex have adopted so that a single rules file works across vendors. Khosravi notes that at the time of the talk Claude Code had not adopted AGENTS.md, and he hopes it will. His authoring guidance mirrors general prompting practice — concrete examples, avoid vagueness — with one specific limit: keep a rule file under 500 lines and split longer ones into multiple files.

Three rule examples he uses himself: a refresh.md that tells Cursor to zoom out and re-analyze the whole codebase from scratch when a bug has resisted several attempts (he reports using it three or four times successfully after ordinary prompting failed); a no-comments.md to suppress excessive generated comments; and a prd.md encoding a company-specific document format, which shows that rules are useful for non-code artifacts too.

MCP servers are, in his framing, the step from beginner to expert. The Model Context Protocol is an open standard that lets an AI client discover and call external tools through a uniform interface, so one integration works across compatible clients. His recommended set, in priority order:

1. Document store — Confluence, Google Docs, or Notion. He calls this the single most important one, because the gaps that make AI fail are usually knowledge that lives in documentation rather than in the code.
2. Version control — GitHub or Bitbucket, giving the agent access to prior pull requests and commits so it can see what has been tried and what failed.
3. Project management — Linear, Asana, or Jira. It can read a ticket and start implementing directly, and it can help author tickets.
4. Database — Snowflake, Supabase, or Postgres, for testing and querying. His explicit warning: set these to read-only so you do not accidentally destroy data.
5. Observability — Datadog, Prometheus, or similar, so the agent can investigate when you are paged.

He then gives the counterweight. Cursor caps you at 85 tools, and he recommends staying well under that limit, because more tools produce more context rot and the model struggles to choose the right tool. His practical approach is to enable only the servers relevant to what you are working on and toggle the rest off.

Prompt engineering he deliberately downplays. He is not a fan of memorizing prompt formulas; what matters far more is context engineering, meaning telling the model everything it needs to know about your project. He shares two supporting data points. First, Anthropic-published prompts that tell the model to ignore its remaining context budget: models sometimes truncate answers when they sense the context window is nearly exhausted, so at around 90% context usage, explicitly instructing it not to worry about context and to give the best answer helps materially. Second, a large prompt published by Google that improved Gemini's benchmark scores by roughly 5%. His interpretation of that 5% is nuanced: for your personal coding productivity it barely matters, because you can simply follow up with another prompt; but when the prompt is baked into a system that your users invoke, a 5% quality shift becomes significant because there is no human to re-ask.

Checkpoints address a specific failure mode. A chat is going well, the model clearly understands the problem, then one follow-up message derails it and the accumulated context is poisoned. Cursor lets you restore to an earlier checkpoint within the chat rather than starting over. This is separate from your version control system.

Indexing runs automatically. Cursor indexes at least 80% of files on load, skipping some very large ones, and updates the index on every add, modify, or delete. This is what makes its semantic search over the codebase work.

Slack integration covers small fixes. If a reviewer spots a trivial problem in your PR, they can tag Cursor in Slack and describe the fix, and it will raise a PR — cheaper than either the reviewer or the author context-switching back into the editor.

Cursor Browser renders the application in a tab inside Cursor and, more importantly, gives the agent access to console logs and network traffic. He recommends it particularly for frontend work, since it closes the loop between generated code and observed runtime behavior.

YOLO mode removes the approval step for edits and terminal commands. He does not broadly recommend it. The one use case he considers genuinely good is a self-contained test loop: write tests, write code, run the tests, generate additional tests it judges useful, and fix whatever fails — a task where the feedback signal is automatic and the blast radius is contained.

Claude Code and Where It Wins

Khosravi's argument for keeping both tools rests on a real task from work. He gave the same feature to Cursor and to Claude Code using the same underlying model. Cursor picked a solution and implemented it, and the solution was non-optimal. Claude Code instead searched the web, found three different open-source repositories as candidate approaches, and produced what he describes as a high-quality analysis that saved him many hours. His conclusion is that Claude Code does substantially more thinking before acting.

That extra deliberation is also its weakness. Claude Code burns considerably more tokens, and it tends to over-engineer. On work that closely resembles something already in the codebase, he says using Claude Code can actively hurt, because the over-engineering can carry it fully off course. His division of labor:

He frames this as a mixed toolkit rather than a winner. Claude Code is terminal-only.

The Four Claude Code Primitives

Skills are the closest analogue to Cursor rules, but auto-invoked. Rather than choosing an application mode, you write the skill and the model decides on its own when to pick it up. His example is a blog-to-HTML converter that rewrites content into a company-specific format.

Subagents are the real differentiator in his view, for one structural reason: each subagent gets its own context window, and each can be given its own set of MCP tools. That isolation means a specialized agent is not competing for context with your main session. His examples:

• A PagerDuty investigation subagent with Datadog and Slack access that reads an alert, digs into metrics, and proposes a root cause or fix.
• A documentation subagent that detects when a PR requires a documentation update and writes it in the company format.
• A "Karen" subagent that checks whether everyone finished their tasks that week and notifies those who did not — offered as a joke, but a legitimate illustration of scheduled, scoped, tool-using automation.

Commands work the same way as in Cursor; a create-PR command is again his example.

Plugins are the distribution mechanism. You bundle skills, agents, commands, and MCP server configuration into one package and share it with your team or publicly. This is the answer to the obvious problem that all of the above is per-developer configuration that would otherwise never propagate.

In the Q&A he was asked directly how to decide between a skill and a command. His rule is about invocation: a command is for something you explicitly tell the AI to do, such as "make a PR"; a skill is for knowledge you want the AI to discover and apply by itself without being told, such as a UI convention that should activate only when relevant files are being edited.

Architecture And Data Flow

The following diagram summarizes how the pieces Khosravi describes fit together. It is a synthesis of his material, not a slide from the talk.

flowchart TD
    Dev[Developer] --> Choice{Task type?}
    Choice -->|Quick fix, model switching, visual work| Cursor[Cursor IDE agent]
    Choice -->|Complex feature needing research| CC[Claude Code CLI agent]
    Cursor --> CtxA[Context assembly]
    CC --> CtxB[Context assembly]
    Rules[Cursor Rules / AGENTS.md] --> CtxA
    Skills[Claude Skills] --> CtxB
    Index[Codebase index] --> CtxA
    Sub[Subagents with isolated context] --> CtxB
    CtxA --> MCP[MCP servers]
    CtxB --> MCP
    MCP --> Docs[Document store]
    MCP --> VCS[Version control]
    MCP --> PM[Project management]
    MCP --> DB[Database - read only]
    MCP --> Obs[Observability]
    CtxA --> Model[Foundation model]
    CtxB --> Model
    Model --> Out[Generated code and analysis]
    Out --> Review[Human PR review and AI code review]
    Review --> Metrics[Tracked metrics: PRs merged, time to merge, revert rate]

The load-bearing idea in this picture is that the model is interchangeable and the context pipeline is where your engineering effort goes. Rules, skills, indexing, and MCP servers all exist to get the right information into a finite context window, and every one of them can degrade results if you overfill that window.

Context Engineering and Context Rot

Context rot came up repeatedly, and the Q&A sharpened it. An attendee asked whether adding too many rules or skills degrades performance the same way adding too many MCP tools does. Khosravi's answer was that it does, that finding the balance is "an art" specific to your codebase, and that the practical method is to add rules incrementally and subtract when you notice quality falling off.

Pressed on whether rules are automatically loaded into context or fetched by the agent, he gave a more actionable breakdown. Always-Apply rules enter every single context window, so you should keep very few of them — reserve them for absolute requirements. Apply-Intelligently rules can be added more liberally, with the same watch-and-subtract discipline. File-scoped rules behave similarly. Apply-Manually rules are effectively free, because they only consume context when you deliberately invoke them.

He also volunteered what he considers the most common cause of people failing with these tools: doing everything in one long chat window until the context is rotten. His instruction was blunt — start a new agent for every new task rather than continuing to type into the same session.

This connects back to the MCP tool limit. Cursor's cap is 85 tools, but the practical ceiling is much lower, because tool selection quality falls before you hit the hard limit. Selective enabling of servers per work session is the mitigation he recommends.

Beyond Code Generation

Khosravi devotes a section to adjacent tooling, on the argument that the largest gains may not be in code generation at all.

DeepWiki, from Devin, generates full documentation for any GitHub repository from its URL and includes an embedded AI you can question about the generated docs. He describes using it on an open-source project with a single page of real documentation and says it saved substantial reading time. He is clear it is not perfect, but recommends it especially for undocumented repos.

AI code reviewers he recommends generically without picking a winner, noting he has heard CodeRabbit is strong. Their value is catching small bugs, syntax problems, and style issues and giving a fast first pass on PRs.

Low-code workflow tools he frames as an engineer's responsibility toward non-technical colleagues who do not know these tools exist. His top pick is n8n, a node-based workflow builder with connections to thousands of services, where you drag and drop nodes, can embed real code in custom nodes, and can place AI agents inside a workflow — for example, a node that reads incoming email and writes extracted results to a spreadsheet. He says he has seen people rebuild workflows in this way and save thousands of hours on non-technical teams. Lovable is another option, and Cursor itself for the more technically inclined.

CLAUDish is an open-source terminal client that looks like Claude Code but lets you reach Gemini, Grok, DeepSeek, and Claude. He suggests it for people who prefer a terminal to an IDE but want model choice, while cautioning it will not be identical to Claude Code itself.

Measuring Whether Any of This Works

Khosravi is explicit that no perfect metric exists, and equally explicit that you should still track something. The measures he lists include pull requests merged, support tickets created, time to merge a pull request, and number of revert PRs. Asked in the Q&A about tracking a remote agentic workflow that pulls from Figma and Jira through MCP servers and opens PRs, he added tickets created, tickets completed, and elapsed time from ticket open to ticket complete, plus the AI-authorship percentage that enterprise tiers of tools like Cursor can report.

His reasoning for tracking broadly is worth restating precisely, because it is unusually honest: you will usually form a qualitative story about whether the tools are working, and the recorded metrics let you support that story when you need to tell it. He does not claim you should stare at merged-PR counts continuously; he claims you need the history available at the moment you must justify a decision.

He deliberately skipped tool cost analysis, on the assumption that most of the audience spends company money. If you are paying personally, he says, the cost-benefit trade-off deserves real evaluation.

Organizational Lessons from Databricks

The most memorable section is second-hand: a story from Databricks CEO Ali Ghodsi, shared at a Berkeley executive education session Khosravi hosted a few weeks before the talk.

Databricks builds data connectors, and the historical delivery time for one connector was four quarters. Ghodsi personally tried a newly released AI tool and got roughly 90% of a connector built in a single day. He handed the tool to the team with the goal of compressing four quarters into one day. The team evaluated it, agreed the tool was great, and came back proposing to reduce four quarters to three quarters. Ghodsi pushed back, but the team defended their process constraints and he eventually let it go. Then one German engineer joined and reworked the whole approach, taking output from one connector per four quarters to 21 connectors in a single quarter.

Ghodsi's takeaways, as relayed by Khosravi:

• People are people. Humans resist change, including excellent engineers. Bringing in outside eyes helps, both because they see the problem freshly and because someone outside the team is more willing to break the team's existing process.
• Yaysayers versus naysayers. People who say something cannot be done produce sound reasons and turn out to be right; people who say it can be done also produce sound reasons and also turn out to be right. The lesson is to put the yaysayers in positions of power when the goal is innovation. Khosravi adds a self-interested corollary for skeptics: if executives are promoting the optimists, career incentives point toward engaging with the tools rather than dismissing them.
• Software is just software. Investigating the connector process revealed that only about 20% of the work was actually coding; the other 80% was customer interviews, design documents, and similar. Their response was to remove much of that surrounding process and accept a higher risk of building the wrong thing, on the reasoning that rebuilding software is now cheap enough to make that trade worthwhile.
• Reassess previously made assumptions. Many process rules exist because they were once correct. AI invalidates some of them, and they will not re-examine themselves.
• Ghodsi's closing remark was that every company is desperate to hire "that German guy" — the person who will actually rebuild workflows around the new capability.

Two cautions are worth stating explicitly, as supplementary context. This is a single anecdote relayed at two removes, with no independent verification of the 21-connector figure or of what quality bar those connectors met. And deleting customer interviews and design documents to move faster is a defensible bet in some markets and a serious mistake in others; the talk presents it as a bet Databricks chose to take, not as general advice.

Trade-offs And Limitations

Khosravi is direct about the downsides and dedicates a section to them.

Unintended changes and suboptimal designs. Agents modify things you did not ask about, and they select workable but inferior approaches — exactly what he observed in his own Cursor-versus-Claude-Code comparison.

Confident hallucination. The tools are frequently wrong in a fluent, highly confident register, which is harder to catch than obvious failure.

Skill erosion. As reliance grows, engineers get worse at things they used to do themselves.

Security threats and dependency risk. He raises the scenario of a codebase built entirely with AI by someone who does not understand how it works; when something breaks, nobody can help. His illustration of tools acting beyond their remit is a reported incident where Google Antigravity deleted a user's hard drive data it should not have had access to, and then apologized profusely. This is why he recommends read-only database MCP servers and why he does not broadly endorse YOLO mode.

Accumulating tech debt. An attendee raised the concern that teammates ship code that technically works but is less simple and less elegant than a human solution, and that a team doing this for a year or two would accumulate serious debt. Khosravi agreed it is a real problem, not a transient one that better models will erase. His mitigation is context-dependent: at a startup the speed may be worth the debt, while a larger company should actively fight it through disciplined PR review and an explicit team norm of not shipping "AI slop". He argues code review now needs more human attention than before, not less.

When not to use these tools at all. Asked directly when hand-writing code is still the better choice, he named three cases: complex brownfield work, uncommon programming languages, and anything critical enough that you must fully understand every part of it. Where the cost of failure is high, he would not use AI.

Tooling gaps for lightweight or mobile workflows. An attendee described trying to run a full development loop from a phone-like environment across Claude, ChatGPT, Workspaces, and Cursor, and hitting failures on basic tasks such as creating a repository and setting up CI/CD, with connectors failing to reach GitHub or other resources. Khosravi did not have a solution. He suggested the usual causes — too little context, too much context, too many MCP tools enabled so the model cannot choose correctly — and noted that others report success on tasks of that kind, but the exchange stands as an unresolved gap rather than a fix.

Evaluation is subjective. Asked what he actually looks for when comparing models in multi-agent mode, he said the SWE benchmark is what models are tested against at release, that it is the best available benchmark, and that he does not think it is a good one. His honest answer is that he judges by eye: the quality of the response, how well it explained what it did, and how fast it was. He observed that preferences differ substantially across individuals and told the audience to make the trade-offs themselves.

Fragmentation across tools. An attendee compared the current situation to the old IDE wars, where some companies mandate one editor and others let developers choose, and asked what is missing to let teams mix agents freely. Khosravi pointed to AGENTS.md as the best available answer to configuration fragmentation and hoped for universal adoption. On IDE choice he had no clean answer: paying for many IDEs rarely makes sense, so most companies will standardize on one, even though free choice would be preferable in principle.

Watch Google Antigravity. As a competitive observation, he flags Antigravity as significant because it is the first case of a foundation-model company shipping both an IDE and a CLI. Owning the model, the editor, and the terminal agent together may prove decisive long term — his speculation, not a prediction backed by data, and notably the same product involved in the data deletion incident he cites.

Practical Takeaways

• Calibrate expectations to roughly 15% to 20% net gain for experienced engineers, not 10x. Expect 35% to 40% on greenfield work and close to zero on complex brownfield tasks in unpopular languages.
• Use both an IDE agent and a CLI agent. Route quick fixes and pattern-matching work to Cursor; route genuinely novel features that need research to Claude Code, accepting the higher token cost.
• Invest in context, not prompt wording. Prompt tuning is worth about 5% by Google's own measurement. Getting your documentation, tickets, PR history, and schema reachable through MCP is worth far more.
• Start with a document-store MCP server if you add only one. Documentation gaps are the most common cause of AI failure on real codebases.
• Set every database MCP server to read-only. Do the same for any tool with destructive capability.
• Keep total enabled tools well under the 85 limit and toggle servers per task. Fewer, more relevant tools beat comprehensive coverage.
• Keep Always-Apply rules minimal. Prefer intelligently-applied, file-scoped, or manual rules so they only consume context when relevant. Keep each rule file under 500 lines.
• Start a fresh agent session for every task. Long-running chats accumulate context rot; use checkpoints to recover when a session derails.
• Write specs before large tasks and use plan mode. Review the generated plan before any code is written.
• Build and share a rules library. Package it with Claude Code plugins or a shared AGENTS.md so improvements propagate beyond one developer.
• Shadow-test new models for about a week on real work using multi-agent mode before switching your daily driver.
• Increase, do not decrease, code review rigor. Add an AI code reviewer for the mechanical pass and keep human review for design quality.
• Track PRs merged, time to merge, revert rate, ticket cycle time, and AI-authorship percentage now, so you have history when you need to justify a decision later.
• Look outside code generation. Documentation, PRDs, and design documents may be where the larger gain sits, and low-code tools like n8n can unlock large savings for non-technical colleagues.
• Re-examine process assumptions that predate these tools. The Databricks story is a story about process inertia, not about a model.

Key Terms

• Greenfield / brownfield — A greenfield project starts from scratch with no existing constraints; brownfield work modifies an existing, mature codebase with accumulated history and dependencies.
• Context window — The finite amount of text a model can consider at once. Everything — code, rules, tool definitions, conversation history — competes for the same budget.
• Context rot — Degradation of output quality as a context window fills with too much or poorly targeted information, causing the model to lose track of what matters or to choose the wrong tool.
• Context engineering — The practice of deliberately curating what enters the context window, as opposed to tuning the phrasing of a prompt.
• MCP (Model Context Protocol) — An open standard for exposing external tools and data sources to AI clients through a uniform interface, so one integration works across compatible tools.
• Agent mode / agentic workflow — A loop in which the model chooses tool calls, the client executes them, and results are fed back until the model produces a final answer, rather than the application deciding what context to retrieve.
• Subagent — In Claude Code, a scoped agent with its own isolated context window and its own set of tools, used to keep specialized work from consuming the main session's context.
• Skill — In Claude Code, a stored instruction set the model invokes automatically when it judges the skill relevant.
• Cursor Rule — A stored prompt in Cursor with a configurable application mode: always, intelligently, file-scoped, or manual.
• AGENTS.md — An emerging cross-vendor convention for a single repository-level instructions file readable by multiple AI coding tools.
• Indexing — Cursor's automatic parsing of repository files into a searchable representation that powers semantic codebase search.
• YOLO mode — Cursor setting that auto-approves file edits and terminal commands without per-action confirmation.
• SWE benchmark — The standard suite of software engineering tasks used to evaluate coding models at release. Khosravi considers it the best available benchmark while explicitly doubting it is a good one.
• Composer — Cursor's in-house model, optimized for generation speed rather than maximum capability.

Khosravi's closing asks were modest and concrete: try at least one AI-powered IDE and one AI-powered CLI, especially if your impression was formed by a disappointing trial a year ago, because the tools have moved substantially; start building a shared library of rules and skills even if it begins with something as small as a PR command; and revisit the assumptions your team has stopped questioning. His argument throughout is that the difference between a 15% gain and a much larger one is not which vendor you pay, but how deliberately you engineer the context you hand the model — and how willing your organization is to change the process around the code.

Reference: Sepehr Khosravi, Choosing Your AI Copilot: Maximizing Developer Productivity, QCon AI New York 2025, published by InfoQ on June 3, 2026.