The Three Eras of Software: From Autocomplete to Agentic Development

The framing I keep coming back to is from Andrej Karpathy’s June 2025 talk at YC’s AI Startup School. He called it “Software 3.0” and said something the room paused on: LLMs are a new kind of computer, and you program them in English.

Eight years earlier, he had written “Software 2.0”, the essay that argued neural networks were not just another classifier but a new way of building software. The 2.0 piece was about training. The 3.0 talk was about driving.

If you take Karpathy’s framing seriously, the conversation about whether Artificial Intelligence helps or hurts developer productivity is the wrong conversation. It is asking what brushes a painter should use in 1860, while photography is being invented down the street. The interesting question is what changes about the role.

I have spent the last year watching this play out at Cheesecake Labs, with our own teams and with clients across fintech, mobility, and platform engineering. The patterns are clear enough now to write them down.

Era one: Code written by humans

The first era runs roughly through 2021. Code was written, line by line, by humans. The tools were text editors, debuggers, terminals, and search engines. The product of an engineer’s day was code that compiled.

This era is not gone. Plenty of code is still written this way, and that is fine for some contexts. But the trajectory left this era. The thing to notice is that almost every tool we built in this era assumed the engineer is the bottleneck. IDEs got faster. Frameworks got higher level. Languages got more expressive. The whole stack optimized for typing speed and cognitive load on a single human at a keyboard.

Era two: AI-assisted, the autocomplete years

The second era runs from late 2022 to mid 2024. ChatGPT shipped, GitHub Copilot crossed the chasm, Cursor v1 turned the IDE into a chat surface. The pattern in this era was the same regardless of the vendor: AI suggested, the human pasted.

This was useful. It was also limited in a specific way. The unit of work was still a line, a function, a snippet. The engineer was still the driver. The AI was a smart autocomplete and a side channel for questions that used to go to Stack Overflow.

The numbers from this era are real and worth citing. By April 2025, Sundar Pichai said on Alphabet’s earnings call that more than 30% of new code at Google was being generated by AI. The caveat matters: humans review and accept those suggestions. It is not unsupervised. But 30% is not a rounding error.

In the same period, Cursor reported that AI was writing 40 to 50% of the code produced inside its editor, a different surface, but the same trajectory. What stayed constant across both tools was the structure of the job itself: the engineer was still typing, still reviewing, still the single point of contact with the codebase. Productivity increased, but the shape of the role did not.

Read more: Most Companies Aren’t Ready for AI Here’s How to Find Out Where You Actually Stand.

Era three: Agentic

Era three started showing up in late 2024 and went mainstream through 2025. The change is structural. The agent does not autocomplete. It acts. It reads the codebase, plans a change, edits files, runs tests, opens a pull request. The human moves up a layer.

Concretely, this is what era three looks like in practice. An engineer steps out of a meeting, fires off two or three agents on different branches, comes back twenty minutes later, reviews three pull requests. Each pull request implemented a feature. The engineer never typed a function body. They wrote a spec, approved a plan, and reviewed a diff.

This is not a thought experiment. Boris Cherny, who created Claude Code at Anthropic, describes this routine in talks. He also says onboarding times at Anthropic dropped from a couple of weeks to a couple of days, because new hires now learn a codebase by asking the agent questions and reading the answers, instead of pairing for hours with a senior. That is era three working as designed.

The shift era three represents is not from “writing code without AI” to “writing code with AI” — that describes era two. The structural change is from assisting to driving: the engineer becomes the orchestrator, the agent does the typing, and the unit of work moves from a function to a feature. The artifact you review is a pull request, not a paragraph.

If you are still living in era two, this distinction probably sounds overstated. It is not. The difference between using Cursor’s tab complete and running a Claude Code session in plan mode is the difference between a faster typist and a different job description.

Era three produces a new role. Two names, actually.

When you push more of the typing to AI agents, two things happen to the human role. First, the typing portion of the job shrinks. Second, the parts that were always the hard parts get more exposed: deciding what to build, judging whether what was built is right, talking to the people who will use it.

That shift produces a role that goes by two names in 2026 — close cousins, but not the same job, and the distinction is worth getting right.

The Product Engineer is the in-house version: an engineer at a product company who owns end-to-end outcomes, talks directly to PMs, designers, and stakeholders, queries production data through MCPs, and ships features that reach all users at once. The role is already hiring at scale. Stripe has an open Staff Product Engineer role on the Checkout team. Linear is hiring a Senior/Staff Product Engineer for AI. Vercel is hiring a Product Engineer for v0.

The clearest articulation of the role comes from Guillermo Rauch on Lenny’s Newsletter: the Product Engineer makes design, product, and engineering decisions in the same head, rather than handing off between three separate functions.

The hiring signal is also a supply signal. A Product Engineer with only product sense is effectively a PM with a new title. With only engineering depth, a platform engineer. The role lives at the intersection of both, which is precisely why the supply is thin and why the job ads keep going unfilled.

The Forward Deployed Engineer is the close cousin, and the shape is different. Palantir originated the model in the early 2010s. The FDE works at the product company (Anthropic, OpenAI, Palantir, Google) and gets deployed into a specific customer’s environment to integrate the product there. One customer at a time. One-to-one.

The role exploded in 2025 and 2026 as enterprise AI integration became the bottleneck. Gergely Orosz at The Pragmatic Engineer tracked an 800-plus percent surge in FDE postings in 2025. a16z called it “the hottest job in tech.”

Anthropic, OpenAI, Scale AI, and most AI-native companies actively hire under this title. Anthropic’s current FDE listing asks for “production experience with LLMs including advanced prompt engineering, agent development, evaluation frameworks, and deployment at scale.”

PostHog drew the cleanest line between the two: “Product engineers aim to solve a problem that many people have so that they can create a reusable solution. FDEs are focused on one customer at a time.”

What both roles share is what makes them era three: an engineer who talks to users, owns outcomes, and ships fast, with an agent doing most of the typing. The difference is scope. If you build a SaaS product, you are likely hiring Product Engineers.

If you sell AI capability and need to integrate it deeply with enterprise customers, you are likely hiring Forward Deployed Engineers. If your company is a consultancy or services firm, neither title is technically right, but the muscle is the same: people who can ship in days what used to take a team a month.

The honest answer most leaders avoid: the existing job ladder does not produce many people who fit either shape. The supply is thin and the skill stack is broader than what most senior engineers were trained for.

Read more: Your AI Strategy Has a Data Problem

The gap. Where the rest of the industry is

Writer’s 2026 Enterprise AI Survey interviewed 1,200 C-suite executives and 1,200 non-technical employees. Two numbers from that report are worth holding in your head. 79% of organizations report significant challenges adopting AI, up from the prior year. Only 29% say they are seeing meaningful ROI, despite 97% deploying AI agents in the past twelve months.

So most companies have shipped AI somewhere. Most are not getting paid back. Why?

The bottleneck is everything around the model. The org chart still assumes a sequential handoff: PM writes a spec, tech lead breaks it down, engineer writes a ticket, engineer writes code, QA tests, ops deploys. AI inside that pipeline accelerates one step. The other steps stay the same length. The total cycle time barely moves, and the cost of the AI tokens shows up as a line item without an offsetting savings.

In Valley companies operating in era three, the pipeline looks different: the engineer talks to the PM, queries production data directly with an MCP-connected agent, ships, reviews, instruments, and learns — with the agent handling the typing. Cycle time collapses because the handoffs do too.

The choice in front of most engineering leaders is not “should we adopt AI.” Most have already done that. The choice is “are we going to redesign the role and the pipeline to actually use what we adopted.” That is the work that produces the result, and it is the work most companies have not started.

What I’d actually do with this

Four moves, in order, that I would put on the table this quarter.

First, stop treating AI as autocomplete. If anyone on your team is still using a coding agent the way they used Copilot in 2023, that is a training gap. Close it. The minimum bar is that engineers should know how to put an agent into a plan mode, review the plan, and ship a feature end to end without writing code by hand. If your team has not done that on a real feature this month, schedule it.

Second, name the Product Engineer role internally. You do not need to rename every engineer. You do need to acknowledge that the most effective people on your team are already operating closer to this role than to “full-stack developer.” Promote against the new shape. Hire against it for new headcount. The interview should test for taste, spec-driven development authoring, and judgment under ambiguity, not LeetCode.

Third, invest in the harness. This is the work that compounds. Skills, CLAUDE.md files at the project and user level, MCP servers that connect to your real data, code review automation, completion gates. None of it is glamorous. All of it is what separates “we use AI” from “we changed how we work.” Two of the three case studies we ran at Cheesecake Labs in the last quarter shipped because the harness was strong.

Fourth, measure the right thing. Stop counting tokens. Start counting features per engineer per week, and cost per feature shipped. If you cannot measure those, you cannot tell whether your AI investment is paying back. Most of the 79% in the Writer report cannot answer “what is our cost per feature today vs. a year ago.” That is the gap to close before the next budget cycle.

Closing thought

Karpathy’s three eras framing is useful because it forces a question most leaders are still ducking. We are not in the era we were in two years ago. The tools are different, the role is different, and the org chart most companies are running was designed for era two. The technology is ready. The role design is not.

The companies that look prescient three years from now will be the ones that named that gap and rebuilt around it. The companies still treating AI as a productivity feature for their existing pipeline will spend a lot of money on tokens and wonder why ROI never showed up.

This is the work we do at Cheesecake Labs every day. We partner with companies that have outgrown the prototype phase and need to ship AI into production with the rigor it requires. Specs, evals, harnesses, agent-native delivery, the boring infrastructure that separates demos from durable products. If your team is staring at that gap, get in touch.