How to be an engineer in the AI era
I gave this as a semi-informal workshop to my engineering team, recorded it, and figured the argument was worth writing down. Short version: the thing we were paid for — being smart and writing code — is getting cheap fast, and the engineers who do well from here are the ones who see that early and move.
Here's the deck if you'd rather skim:
Exponentials don't feel like exponentials
The whole talk hinges on one thing humans are bad at: feeling exponential growth. The classic version — would you rather have a million dollars, or a penny that doubles every day for a month? The penny wins by day 30, and it isn't close. Your gut says "a penny, come on," because the first two weeks look like nothing. AI is in that part of the curve where the next doubling is bigger than everything before it combined, and most people are still anchored to how it looked last year.
Concretely, the share of code written by AI: roughly 15–20% a year ago, ~50% six months ago, ~80% now. I don't think 100% is a crazy target. If your own code output hasn't moved over the last twelve months while you've been in the same role, that's the signal to pay attention to — the bar moved and you didn't.
Intelligence got commoditized
White-collar work, software included, paid a premium for raw intelligence. That premium is evaporating because intelligence is now instant, cheap, and available to anyone with an API key. When something becomes a commodity, the value moves somewhere else. The question is where.
The value stack flipped
The old stack — what made you a "good engineer":
- Ability to produce code
- Engineering expertise (senior > junior)
- Domain knowledge (databases, distributed systems, whatever)
Product sense, taste, soft skills, customer empathy? Nice to have. Bonus points.
The new stack inverts it. The things that are hardest for a model to commoditize float to the top:
- Product intuition
- UX taste
- Customer empathy
Engineering expertise and domain knowledge still matter, but I think they're the first technical skills to get commoditized, not the last. The model already knows more about Postgres internals than most of us. It does not know what your users actually want, or what "good" feels like.
You're now competing with PMs
Here's the uncomfortable part. As code production gets handed to the model, you stop competing only with other engineers. You compete with product managers who just got handed the same code-writing tools you have. I set up a few non-technical colleagues with a coding agent in a 45-minute session and they were shipping real things.
So if your whole pitch is "I can write the code," that pitch is getting weaker every month. The engineers who win build genuine intuition for what makes a product great and add value past the ticket they were assigned.
There's an exec version of this too. If you run a big technical org with a fixed budget, you've got three bets: (A) hire more engineers, (B) spend more on AI for the engineers you have, (C) train your non-technical people to use the technical tools. Most orgs are in B right now. I think they shift to C, because the ROI on giving non-technical people self-service tools is just very high.
The role is changing, not ending
I don't think "software engineer" disappears. But the entry-level, ticket-closing tier — call it the L3/L4 grind — is getting compressed hard. The honest framing is the printing press operator who needs to learn the typewriter. The craft you mastered isn't the craft that pays next.
One detail that surprised people: when I surveyed sentiment, engineers split roughly 15% bearish / 35% hardcore adopters / 50% lukewarm. The executives? Basically one bucket — "this is huge, apply it as aggressively as possible." That gap between the floor and the top is the thing to internalize. The people deciding your comp are not lukewarm.
The new job: product shepherd
So what is the job? You shepherd the product. You judge what the AI writes, you steer it, you accelerate it — you are not the bottleneck typing every line. Your attention moves to decisions and to the PM-flavored skills, because the PMs are coming the other way to meet you.
Betting that you can write better code than the model, long-term, is a bad bet. Bet on the things the model is bad at instead.
How to actually get good at this
The single biggest lever is aggressive practice. Not courses, not reading — reps. Want a cheap benchmark for whether you're adopting fast enough? Look at your AI compute spend. If you're burning through your budget, you're probably in the top percentile of users. If you've got budget left over, you're not practicing enough. Use it on personal stuff too — go vibe-code something dumb on a weekend.
And study the things that aren't intuitive to you: UX, taste, product strategy, go-to-market. People assume creative skill is innate. I went to art school — plenty of people there came from non-art backgrounds and got genuinely good. You can learn taste. A starting heuristic that travels well: less is more. Simplify, cut clutter. Become a force multiplier — the person who speeds up the whole team, which is the thing that actually shows up in promo packets.
The summary I keep coming back to: intelligence is a commodity. Value now lives in taste, speed, and intuition.
You're an orchestrator of agents now
Practically, accept that you manage a team of subordinates who happen to be AI agents. I run a minimum of five at a time, average around twelve on a normal day, and 12–20 when I'm vibe-coding individual sites. They ping me with a sound when they finish — customizable — and the real skill that's developed is context switching: knowing how to isolate tasks so agents don't step on each other or burn tokens fighting over the same files.
A few things from my setup:
- Run the agent from the whole monorepo folder, not a single package. More context means it can change multiple areas coherently.
- Playwright that drives your real browser, not a headless throwaway — essential for authenticated crypto stuff where you need the actual session.
- Loop to auto-resolve PR comments.
- Simplify, scheduled to run off-peak (overnight), to consolidate the codebase and keep it DRY while I sleep.
- Skills worth having: front-end design, web animation, GEO, and a Humanizer for copy that doesn't read like a robot wrote it.
The planning-first workflow
The workflow that makes big builds possible without babysitting every step: start with a fat planning prompt — an essay, 500–600 words — that makes the agent produce a PRD first. Not code. A product requirements doc you can actually read and correct.
Only after the PRD looks right does it generate the architectural plan and a phased task list. Then it executes the phases — sometimes 11, sometimes 30 — and my intervention drops way down because the thinking happened up front where it's cheap to fix.
The pipeline in practice: drop a general starter file into a new folder → PRD → ask for the build plan → tell it to work through the phases. I've used this to vibe-code a custom customer-service desk, a Hookdeck replacement, and a Mintify replacement I'd otherwise have paid $300/month for. Wire in payments and you're collecting money the same day. The point of the examples isn't the apps — it's that the output is good enough to replace paid services, and that non-technical people can hit that bar too.
"Do you review the code?"
Best question from the room. For the vibe-coded sites, I don't manually read the code — I run other agents to audit it. Get to production for something real and yes, a human reviews it. But an auditing agent gets you most of the way; the output is probably 95% of the way there.
My actual take: agents should do the first PR review pass. Neither humans nor agents write great code on the first try, so defer the human review until after an agent has already cleaned it up. The human looks at higher-quality code, and their time goes further.
That's the talk. The meta-point: none of this is about whether AI is "good" or "bad" at code. It's that the curve is steep, the value moved, and the move is yours to make. If you build something with any of this, show me — that's the whole reason I recorded it.