Coding with AI // Chip Huyen

Chip Huyen provides a deep dive into the evolving landscape of AI-powered coding. The talk covers the different interfaces for AI coding tools, introduces new metrics like "interruption rate" to measure productivity, and outlines a framework for the levels of coding automation. Huyen argues that the engineer's role is shifting from writing code to architecting systems and reviewing AI-generated output, emphasizing the rise of spec-driven development and the critical importance of system thinking.

5 min read
Coding with AI // Chip Huyen
source: https://www.youtube.com/watch?v=xY1FcjIbErQ

The adoption of AI coding tools has become so widespread that for many hiring managers, a software engineering candidate who hasn’t experimented with them is considered a “red flag.” It signals a potential unwillingness to adopt new, productivity-enhancing technologies.

Interfaces and Evolving Workflows

There are several interfaces for AI coding tools, each suited for different tasks and user preferences:

  • IDE-based: The most common starting point, with features like autocompletion integrated directly into editors like VS Code.
  • CLI-based: A more advanced interface where developers interact with agents through the terminal to perform tasks.
  • GitHub-based: An emerging interface where an agent can be invited into a repository to address an issue by submitting a pull request or to review an existing PR.
  • Web-based: Useful for front-end development, where a user can provide a mockup image and have the AI generate the corresponding application interface.

User preference for these tools often evolves. While many start with IDE-based tools, there’s a trend towards more automated, CLI-based workflows over time. This follows the “principle of least effort,” where users gravitate towards solutions that require the least manual intervention. As trust in AI agents grows, developers spend less time directly viewing or writing code in an editor.

Rethinking Productivity in the Age of AI

Traditional software engineering metrics are becoming obsolete in the context of AI-driven development.

  • Engineering Time vs. Mental Energy: A task that takes a full day to run is no longer a bottleneck if it requires minimal human oversight. An engineer can initiate a task, context-switch to other work, and return later to see the result. This low mental energy cost allows for massive parallelization, where a developer can spin up dozens of tasks simultaneously.
  • Lines of Code: This metric is now largely irrelevant. AI is incredibly proficient at generating vast amounts of code. Consequently, the attachment to existing code has diminished. It is often more efficient to discard a problematic codebase and have an AI regenerate it from a clear specification rather than attempting to debug and refactor it manually.

Levels of Coding Automation

Borrowing a framework from the self-driving car industry, we can categorize AI coding tools into different levels of autonomy:

  • Level 1: Autocompletion: Simple code suggestions that the user can accept or reject. This has been a mature technology for several years.
  • Level 2: Partial Automation: The AI can handle very specific, isolated tasks, such as writing documentation for a function.
  • Level 3: Conditional Automation: The AI can automate a wider array of tasks from scratch, like building a new feature or a simple application based on a prompt.
  • Level 4: High Automation: The AI can handle nearly all tasks, with human intervention required only for highly specialized or complex areas, such as optimizing low-level CUDA code or working with obscure legacy systems.
  • Level 5: Full Automation: Complete end-to-end automation of all coding tasks.

Currently, the industry operates primarily between Levels 1 and 3.

The “Interruption Rate”: A New Metric for Autonomy

A more effective way to measure an agent’s capability is the interruption rate: how often a human needs to intervene to correct the agent’s course.

A low interruption rate signifies high confidence in the agent. If you have to check on the agent every 10 minutes, you can’t mentally disengage. But if it can run for hours or days without intervention, you can trust it with more complex, parallel tasks.

Reducing the interruption rate is crucial because it:

  1. Frees Up Mental Energy: Allows developers to manage multiple tasks in parallel without being overwhelmed.
  2. Enables Sub-Agents: An agent will only spin off a sub-task (which a user cannot interrupt) if it has high confidence the task can be completed autonomously.
  3. Reduces Context Load: Fewer interruptions mean the agent can use its memory and context more efficiently.

Factors Influencing Interruption Rate

The interruption rate is influenced by several factors:

  • User Background: Senior engineers tend to have a lower interruption rate than junior engineers. This is because their experience allows them to write more precise, comprehensive specifications and prompts, leaving less room for the AI to make mistakes. Junior engineers often learn as they go, leading to a more iterative and interrupt-driven process.
  • Task Type: AI agents perform significantly better on greenfield projects (writing new code from scratch) than when working with complex, existing codebases. This has given rise to a new discipline focused on refactoring legacy systems to be more modular and “AI-friendly.”
  • Tech Stack: The agent’s performance varies by programming language. For instance, models often perform better in Python than in JavaScript. This is attributed to the training data; the average quality of Python code available on the internet is generally higher than that of JavaScript, leading to better model outputs.

The Shift to Spec-Driven Development

The developer workflow is transforming into a three-step process: Plan -> Execute -> Verify.

  • Plan: The human’s primary role is to create a detailed plan and specification. The idea that “prompt engineering is going away” is misguided; communicating requirements clearly to an AI is a crucial skill, akin to communicating with human colleagues.
  • Execute: The AI writes the code. The developer’s time in an IDE plummets, replaced by time in the terminal initiating tasks and on GitHub reviewing pull requests.
  • Verify: The human reviews the output to ensure it meets the initial specification.

This paradigm pushes engineers to become architects and reviewers rather than hands-on coders. Senior engineers will increasingly focus on high-level architectural design and reviewing AI-generated code, guiding the agent’s work. The most important skill in this new era is system thinking: the ability to understand, design, and specify complex systems for an AI to build.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

Why humans are AI's biggest bottleneck (and what's coming in 2026) | Alexander Embiricos (OpenAI)

Why humans are AI's biggest bottleneck (and what's coming in 2026) | Alexander Embiricos (OpenAI)

Alexander Embiricos, product lead for OpenAI's Codex, shares the vision of AI as a software engineering teammate, not just a tool. He explains how a strategic shift to a local, interactive experience unlocked 20x growth, details how the Sora Android app was built in 28 days, and argues that the real bottleneck to AGI-level productivity is now human review speed, not model capability.

Why humans are AI's biggest bottleneck (and what's coming in 2026) | Alexander Embiricos (OpenAI)

Why humans are AI's biggest bottleneck (and what's coming in 2026) | Alexander Embiricos (OpenAI)

Alexander Embiricos, product lead for OpenAI's Codex, discusses the vision of AI as a proactive software engineering teammate, the product decisions that led to its explosive 20x growth, and why the real bottleneck to AGI-level productivity is shifting from model capability to human review speed.