The Agent-Era Career

AI gets good at anything with an answer key. Your career is everything that doesn’t have one.

If the AI layer gets good at anything, it will be anything that has an answer key. School used to be answer keys all the way down. School is the ultimate anchoring of success, because it’s all about getting the right answer. The thing that makes work durable and ungradeable in the age of AI is not getting any better at solving problems. It’s not being able to build systems, or understanding people, or making cool new things. It’s choosing what to build and judge if it’s good. The rest will all be done better and faster by AI.

I started in engineering at 16, building a browser in rural Ireland. I was at Google for over 14 years, where I led engineering teams working on Chrome, Gemini and Cloud AI, and written a number of O’Reilly books. I’ve turned down offers from frontier labs and FAANG companies when the fit wasn’t right. Good people are always needed, so we each have an obligation to try our hardest and make the best thing we can.

Most career advice still holds up. Get on the rocket ship, don’t over-optimize your seat. The specifics have changed a little because of agentic coding, but here’s what I wish I’d known for ambitious engineers out there now.

Optimize for scarce resources. Almost nothing I’m known for came from chasing the highest pay. The years I spent in open source had almost zero direct payoff. But they led to reputation and relationships that very efficiently compounded into opportunities later. I would have spent the comp I got from any single job. My reputation kept paying.

Many resources are abundant. Capital is abundant. Time is abundant. Real relationships, and especially track record of doing good work, are still scarce. I can raise money in a couple weeks, but I can’t raise a reputation. So here’s the plan: do good work, and make sure the people who like good work see it. In a world where vibe-coding makes earning a quick buck trivial, I think that quick buck is worth very little. When shipping stuff is so easy, the scarce move is choosing something worth shipping.

Learn to find problems, not just solve them. The first time I ever felt the burden of selection rather than solution, LeetCode seemed a measure of skill. But as agents absorbed all that work, solving problems went cheap while selecting them became scarce. My origin story: I noticed dial-up was slow, created chunked multi-connection fetching, realized I’d never solve that problem in my life, and quickly moved on to whatever absorbingly complex one I could find next. Finding problems predated solving them.

I’ve watched students who were wildly good fall flat on their face when an agent ran through their problem set (like watching the wrong microwave number on the clock). The same agent. The same problem set. Wildly different token and time budgets. Why? Because at the end of the day, the strong ones bring judgment and intuition to the work; the rest bring a prompt.

I used to build that judgment by grinding out boilerplate and fixing bugs. I got to see and deeply feel the worst abstractions humans could devise. I approached each commit with the awe of someone who’d just seen the fever dream of previous authors. Each commit brought hindsight and judgment. The agents automate those reps. Taste is pattern-matching, but all that pattern-matching has to be earned by doing the work.

The real risk isn’t agents writing bad code. We’ve been there before. It’s losing the ability to tell. Judgment will atrophy. Output will look a lot like working code.

Good practitioners don’t put agents in front of everything. They engage in deliberate practice. Pick a few problems that really matter. Do them the hard way, without the agent, building deep mental models of how systems and languages work. Read a thousand times more code than you ever write. Treat every diff from an agent like a human review you need to carefully justify. Go deep on at least one system end to end, from intake to output. On a daily basis, keep a private log of every time you see an agent suggest something that looks wrong and confidently flag it. That’s where taste accumulates.

The real thriving engineers won’t be the fastest at getting suggestions. They’ll be the ones who know instantly when to say no.

Shift from doing to directing. Just like you’d delegate to a person, you need to learn to delegate to an agent. Scope the task, define done, calibrate trust, and verify the result.

Autonomy is a setting, not a rank; it’s a per-task switch. Turn it up to the maximum on something small and reversible and cheap to check. Turn it down on anything where mistakes will be hard to undo.

Specification and verification are two distinct, complementary skills. The agent isn’t as good as the intent you hand it. The best engineers are those who know how to write precise specs; clear thinking made legible.

It’s verification, not evidence. Not evidence in the form of an agent grading its own homework. There’s nothing more demoralizing than delegation without verification at scale.

Own what you ship. If the agent wrote it and it breaks in production, “the AI did it” is not a defense. Your name is on the change. Adopt the posture of an accountable human who understands what went out the door and how to fix it.

Most ambitious version of the problem. Rich Sutton’s bitter lesson: in almost every field general methods that scale with additional compute beat out hand-tuned equivalents. As a career lesson, there’s no point in solving an easy version of the problem, it’s worth almost nothing. The value ends up concentrated in the hard version.

Sprint the last mile. No turnkey agent writes a whole system from end to end. As a rule, you’ll get 70% of a feature quickly from an agent, and the last 30%—debugging the gnarly edge cases, figuring out the right architecture, cultivating the right taste—will be the whole game. The median output today is whatever the agent produces from some lazy prompt. The only personal value you can bring to the table is getting as far as you possibly can past that median. When first drafts come free, finish is the product. To sprint the last mile, here’s my tactic: every few months I completely rebuild from scratch using the latest, sharp-end-of-the-sword model. It’s less exhausting than nursing half-hearted old code to health.

My job as a software engineer has been to finish strong. The difference between finish strong and finish okay is the polish: spending an extra hour, which shows instantly to everyone who matters.

Increase both your xG and your finishing

If soccer had a stock ticker, it would be xG. xG measures the number of chances your play should produce. Finishing measures whether you convert them. You can’t plan the number of chances you get, but you can hope your play produces enough, and over your career you can get better at finishing them.

The same is true of careers: your reputation gets you in front of goal, and you convert them with good judgment. Chances arrive whether you’re ready for them or not; how many you get, and which ones you finish, is up to you. I’ve only ever had big opportunities as a result of work I’ve done in public, never from a job I’ve applied for. You can’t script which chances arrive, only whether you’re standing where they land. You have to create the opening as much as you can, and then be ready to take it.

One easy mistake is anchoring on whatever product your company has right now. It’s true that your work has to exist somewhere, but a good team quickly mutates their current offering into something unrecognizable. So bet on the team and the market opportunity, not the demo. It’s just a snapshot. The team is the trajectory. On superintelligence: it’s possible (I believe) that future models will eventually come to replace much of what we do as knowledge workers. It won’t erase it overnight, it won’t replace all of it, and won’t be able to do many of the tasks we do. New kinds of jobs will be created. Verification will always be a bottleneck. Someone has to make the call on which problems are worth solving and allocate the correct amount of judgment to each, and that someone can be you.

But importantly, you can do frontier work right now, from where you are. The gate to AI research is smaller than it looks, and you don’t need a lab to build intuition. Just use models hard, and turn what you notice into evaluations. Evals and benchmarks are where understanding lives.

To summarize: the world isn’t short on opportunity; it’s short on people who can find the right problem, tell whether the machine solved it, and finish past where the machine stopped.

We sometimes talk about the “last mile” as the biggest piece of the puzzle. But in the world of agents, the last few feet are infinite (agents scale output infinitely; you don’t). Your attention is your most precious asset, and it doesn’t refill. You can’t afford not to protect it. Anything which is gradeable by someone else is getting automated. The career is the ungradeable part: choosing what matters, judging honestly when you’ve got it, and answering for it. Do that. In public. Near the hard problems. The rest tends to follow.

This piece grew out of Phil Chen’s original, which is well worth reading in full.