Why Can AI That Coding suddenly “work”?

AI can write code. That’s old news.
AI can ship tasks. That’s when things get real.

Last week, at YC’s Lightcone roundtable, Calvin French-Owen — early Codex core developer and Segment co-founder — said something that stuck with me:

“You’re not typing code anymore. You’re orchestrating a team of agents.”

And the timing couldn’t be more relevant. This week, OpenAI droppedGPT-5.3-Codex, claiming it’s the most powerful agentic programming model yet. Hours later, Anthropic fired back with Claude Opus 4.6, leading in accuracy for complex programming tasks. Two companies, same day, both pushing the next generation of AI coding agents.

The race isn’t about who writes better code anymore. It’s about who can actually finish the job.

Calvin has built Codex and used Claude Code and Cursor extensively. In this discussion, he wasn’t comparing features. He was asking a deeper question:

When AI stops being a code-writing tool and becomes a task-completing collaborator, what does an engineer’s job actually look like?

Three Tools, Three Ways to Divide the Work

Right now, the three AI coding tools developers talk about most are Claude Code, Codex, and Cursor.

They all help you write code. But Calvin points out the real difference:

“They’re not competing on who writes perfect code. They’re competing on who feels more like that teammate who actually gets things done.”

1. Claude Code: It breaks down tasks

Calvin now uses Claude Code for most of his daily development work.

What does he value most? It knows how to break down tasks.

It automatically splits a big task into smaller subtasks, handles them separately, then integrates the results. This ability is incredibly useful when you need to quickly triage issues, refactor, or fill in missing documentation.

2. Codex CLI: It runs long tasks

Codex CLI takes a different approach. Its strength isn’t task decomposition — it’s endurance.

It can reliably execute tasks spanning 24 hours or even 48 hours. Perfect for deploying complex projects, running CI/CD pipelines, or maintaining production environments with automated fixes.

3. Cursor: The daily workhorse

Cursor is the daily driver for many developers.

It embeds AI directly into the editor you already know. No context switching. Especially good for scenarios where you’re constantly jumping between files, writing and debugging on the fly.

But for deep debugging, system refactoring, or complex task orchestration? Cursor still has gaps.

Three tools, three strengths. The real efficiency gains come from knowing how to combine them. The most effective approach? Let Claude Code handle complex tasks that need decomposition, Codex CLI run long-duration deployments, and Cursor handle high-frequency daily interactions.

Why Did AI Suddenly Start Doing Things? It’s Not Smarter — It’s Running a System

For the past few years, most people’s experience with AI for coding has been typing prompts into a chat box and getting back a few lines of code. It felt more like a code snippet generator than an engineering partner.

But Calvin argues:

“Today’s Claude Code and Codex are starting to have the ability to complete tasks.”

This isn’t just because the models got stronger. It’s because the way AI executes, structures tasks, and manages context has all been upgraded.

1. Claude Code actually delegates work

Calvin shared an example: when you ask Claude Code to understand a large project, it doesn’t just give you one answer. It spontaneously spins up multiple sub-agents that search the file system, categorize files, summarize logic, and then report back.

These sub-agents each own a piece: some search files, some extract logic, some write tests, some draft PRs.

Just like an engineer dividing work among a few people — everyone checks their section, then you integrate and execute.

Old AI was question-and-answer. Today’s Claude Code is you setting the goal, and it breaks down the process and orchestrates execution on its own.

2. Codex CLI compresses context

Codex CLI has a built-in compression mechanism. After each round of conversation, it automatically cleans up and updates the context window. This lets tasks run longer without interruption, forgetting, or drifting off track.

Like someone working all day, taking notes and clearing irrelevant info, Codex periodically reorganizes to avoid losing the thread.

This mechanism makes Codex better suited for continuous development tasks, like:

• Building large code frameworks over time
• Long debugging sessions
• Automated testing + CI/CD deployment flows

It’s not smarter. It’s a structural design breakthrough.

3. Why is CLI better than an IDE for this?

Calvin mentioned an experience shift: when you use CLI mode, you stop staring at code details. You focus on the task itself.

Compared to the traditional IDE approach — clicking, editing functions — CLI mode puts you farther from the code and closer to the task.

You stop caring what a function is called. Instead, you’re issuing commands like you’re running a dispatch center:

• Is this bug coming from the concurrency logic?
• Does this code reference that old API?
• Refactor this component to use hooks

Claude Code and Codex don’t dump a page of code on you. They divide, conquer, and report back in steps.

Behind this are three technical directions: sub-agent orchestration, context compression, and CLI interaction. These are becoming the shared evolution path for all AI coding tools.

Which also means: future engineers won’t be code writers. They’ll be task orchestrators.

The Best Users Manage Context, Break Down Tasks, and Pick the Right Stack

Calvin noticed something: experienced developers and beginners use the same tools, but the efficiency gap is huge. The experienced ones actually boost their productivity with AI. Beginners are still figuring it out.

What are the people who use these tools most effectively doing? He identified three common traits.

1. Managing context is the prerequisite for completing tasks

A lot of people using Claude Code or Codex CLI for the first time notice that it runs smoothly at first, but then the output gets weird. Eventually, chaotic.

Calvin’s explanation? “Context poisoning.”

The AI forgot the point but kept generating. Maybe it remembered too much, drifted off course, or got influenced by its own useless output.

To solve this, Calvin’s approach:

• Actively clear irrelevant conversation history
• Compress and summarize every so often to help the AI reorganize context
• Set checkpoints to test if the AI still remembers the core goal

He mentioned a trick called the canary test: early in the conversation, drop an irrelevant line like “I had tea this morning.” If 1,000 lines later the AI can still recall it, context is intact. If it forgot, time to clean history or switch windows.

The essence of this method is judging system capacity: you can’t expect AI to remember everything you said forever. But you can tell when it’s starting to drift.

2. Breaking down tasks matters more than writing details

Efficient users all share one habit: they describe tasks like a product manager, not like an engineer obsessing over function syntax.

For example:

• Instead of “rewrite this function for me,” say “this component has too much logic — help me identify which code can be extracted into subcomponents.”
• Instead of “generate tests,” say “help me find the cause of this API’s abnormal response, and write unit tests that cover the edge cases.”

Instead of fixating on whether it writes perfect code, think clearly about how to decompose the problem you want it to solve.

3. Simpler tech stacks make AI more effective

Calvin also mentioned that tech stack choice matters: not all code structures are suited for AI-assisted development.

He emphasized two tendencies:

• Avoid architectures with excessive abstraction and deeply nested encapsulation (makes it hard for AI to find the point)
• Prioritize modular, well-documented, microservice-oriented structures (AI can locate and modify code more easily)

His own practice is to use stacks like Vercel, Next.js, and Cloudflare Workers — clean, clearly structured technologies. The reason is direct:

• Models can quickly identify structure
• Don’t need to spend tons of tokens understanding the environment
• Debugging and rewriting become more efficient

In other words, you’re not just writing code for yourself anymore. You’re writing code that AI can read and work with.

His summary: you need to be the director of a technical team, not the operator.

The Tools Are Universal. But Not Everyone’s Ready.

When AI could write code, you could treat it as a tool.

When AI can complete tasks, you have to rethink how work gets done.

Calvin emphasized this multiple times: not everyone — not every company — is ready to let AI do work for them. It’s not a capability issue. It’s a mindset issue.

1. Developers: From code worker to task organizer

Calvin said people who’ve been tech leads before often pick this up faster than beginners. Not because they know better prompts. Because they know how to structure workflows.

In the old IDE model, code was organized by logic blocks. Everyone guarded their module. But in CLI mode, tasks unfold by process and objective.

This requires developers to:

• Not just write code, but arrange task rhythm
• Not just articulate ideas clearly, but articulate them step by step
• Not just write functions, but judge what to delegate to AI and what to own yourself

2. Startups: AI doing work directly cuts costs

Calvin mentioned that a lot of the prototype development he does now used to require 2 to 3 engineers. With AI tools, one person can do it.

In traditional development flows, building APIs, filling in docs, writing tests, fixing bugs, and PR workflows — these steps eat up the most labor.

Now, agents can automatically push these forward.

3. Big companies: Tools are spreading throughout the organizational hierarchy

In large enterprises, the best tools are the ones engineers can download and use directly, without waiting for CTO approval.

If traditional enterprise software deployment processes don’t keep pace, they become bottlenecks blocking AI adoption. Engineering orgs have to answer: Is your task structure built to allow external agents to take over part of the work?

This Logic Applies to All AI Coding Tools

Though this discussion centered on Claude Code, Codex, and Cursor, the capabilities — sub-agent orchestration, context management, task decomposition — are becoming common features across all AI coding tools. This pattern is emerging globally.

The value isn’t in which tool you use. It’s in whether you understand this new collaboration model:

From making AI autocomplete code → to making AI complete tasks. From optimizing tools → to restructuring division of labor.

Calvin wasn’t giving a product manual. He was describing a new working paradigm that’s forming right now.

So, are you writing code? Or are you orchestrating a team of AI agents?