The cost of writing software has collapsed. Anyone can open up a ChatGPT chat and get it to code pretty much anything they want, even on the free plans.
So, software engineering is dead, right?
Not so fast. Coding might be a job for machines now, but not everyone wants to be designing and maintaining software. Not everyone knows how to get the most out of a technology product. In fact, most people just want an app that works for them and their needs. The truth is that software engineering was never about coding - coding is just a tool for solving problems with software (like Charity Majors told us last year).
This is hardly news to most people reading this. But we’re all seeing a new level of abstraction emerge - Meta’s Muse is giving everybody a simple, useful personal assistant on their phone. Users of Codex or OpenCode etc. are able to build things they never dreamed of before. The Claude Opus 5.5 model is one-shotting complex animations (and I used it to animate this week’s episode).
We’re operating at a new level of abstraction - and becoming product engineers.
Sponsored by G2i
Human data and RL environments for AI training
I’ve said before on the show that most teams still treat evals like unit tests: write them once, check a box, move on. That doesn’t hold up once an agent is making real decisions.
That’s the gap G2i is built to close. For over a decade, they vetted and placed engineers at other companies, from startups to FAANG. Two years ago, they turned that same judgment inward, building their own bench to review the RL environments, evals, and training data models are trained on. Those reviewers know the difference between code that runs and code that’s good, because they’ve shipped it themselves.
That bench now runs 200 full-time engineers
Plus 8,000 more matched to the task
All vetted against real coding benchmarks like SWE-Bench Pro and Terminal-Bench.
If your team needs data partners on evals, RL environments, or training data, schedule a call with G2i to bring them in.
Someone still has to talk to the baker
A bakery owner knows how to make the perfect croissant. They probably have no idea how to write bakery software, and as Laurie Voss put it to me:
“They are not interested in finding out. They just want something that does the things they want to do.”
Laurie co-founded npm and now runs developer relations at Arize. He laid out his argument in a recent essay, We are all Product Engineers now. Agents have rapidly taken over writing code - and they’re getting better at reviewing and maintaining it fast. Shipping and scaling will be work for agents soon too.
But product sense, elucidating and mapping out features? Talking to customers? Identifying the right context to provide our agents with?
“When a customer says ‘I need to keep track of my orders,’ there are ten thousand pieces of software that fit that sentence, and only one of them is right for a bakery.” - Laurie Voss
That’s work for us, for newly minted product engineers - and I’d argue anyone can be one if they’re willing to put in the work.
Yes, people with design sense, product management experience, and product development + engineering chops will be at an advantage, but technical blockers can be solved with a sufficiently advanced LLM. Turn Opus 5.5, GPT-6 Astra or DeepSeek-V4.1-Flash loose on solving whatever you need for code - all you need to do is talk to it in plain language about what you want, and iterate. Use a microphone if you want to get extra context - you can talk faster, and you’ll naturally provide it more surface to grasp onto.
The challenge will be, for the moment, in maintenance. If you want to maintain your new personal software, you’ll probably need to engage in context engineering. If you want to do it at enterprise scale? You might need help.
And if you want to sell your new software? Well guess what, sales is still hard. If you can figure out sales and marketing, you’re going to be just fine with your AI CTO co-founder.
Agents still have gaps
While some enterprising, independent agents are building their own freelance businesses, they haven’t yet overtaken every human job, and orchestrating their work is still complicated and often messy.
My own experience hiring an AI agent freelancer last week drove this home for me - I’ve gotten multiple pitches from AI agents in my inbox, but only one struck the right balance, and getting all the detail that I wanted from their input took a couple rounds of feedback, it was startlingly similar to working with a human freelancer on an article.
It’s much harder for agents to take over in-depth customer facing roles, even if they’ve helped automate parts of front-line customer service. It’s much harder for them to draw out the product requirements of a user (though the grill-me skill can help you get started for your individualized software).
An old job with a new name
The concept of product thinking and product engineering is not a new one.
“It used to be called a systems analyst in like the 60s. That was their job, was translating business requirements into software requirements without writing any software. And that job is coming back, and we’re going to call it a product engineer.”
- Laurie Voss
It’s been a differentiator for senior+ engineers for decades. And the forward deployed engineering trend has been leaning in this direction for the last couple of years, with more than 1,300 open job postings across 565 companies, according to one census. Laurie cites average total comp around $240,000 and thinks this type of role will become most of software engineering over the next decade.
I think Laurie is right about where this ends up, but too conservative about when. My bet: 2-5 years, not 10. Model improvement is accelerating, and models are becoming more powerfully multi-modal and picking up grill-me skills and product thinking fast. I expect agents to take on technical product manager work, and be accepted in it, sooner than most of us think. After all, we’ve already got independent AI agents working as freelancers.
Buckle up, it’s going to get even more sci-fi.
But as we noted, this kind of product thinking and ability to get to the bare metal with customers and users is the kind of skill that has differentiated senior engineers for years. If you’re a principal engineer reading this, you’re probably wealthier and busier than ever before, orchestrating agent fleets to 10x or 50x yourself once again while using your sharply honed skills and domain knowledge.
That’s all well and good for those with experience, but what about new hires?
How do we help the juniors?
I’m more worried here. Junior engineers used to build judgment by writing code a senior reviewed, and agents now handle both halves of that loop. More broadly, apprenticeship and training in the economy has been a constant concern for decades as we’ve seen the ladder upwards in various professions erode. With AI picking up execution grunt work that was given to new career professionals as learning opportunities, how are new hires going to grow skills?
How would you advise someone to get started in software today? I think Antirez nailed this in response to a question by Gergely Orosz:
I think this is the right approach. The internet has opened up unprecedented control over our careers and personal brands - we can build in public, we can write and create on the internet. It can provide unprecedented leverage. It’s a major reason I write this Substack and it’s been a guiding principle for my career the last 7+ years.
Today, I think it’s more necessary than ever. Build in public, share your learning journey, network and grow community based on that building. Always be creating.
You can't get by with entering the industry without having a track record of building, and if you can build relationships through and on top of that foundation, you're off to a good start.
Have a good idea for folks starting out in their careers? Help share your knowledge below.
More broadly, we need companies to reinvest in apprenticeships and in system design theory: and how to get requirements out of users and into the models, whether that user is a baker, a sales team, or yourself. Engineers who already do this well should get more valuable. Our challenge is that we don’t yet have a reliable way to train the next cohort to do it, and until someone builds that path, the people entering the field must fight to grow and be heard. It’s an overused phrase, but there’s a reason everyone is talking about being high agency.
Laurie still ends on an optimistic and yet cautionary note. In his framing it’s 1997 on the web: a bubble is coming, nobody knows the winners yet, and there’s plenty of time to retrain.
Watch the full episode 👇 or listen and read the transcript on the episode page
Coming up
Just like this week’s double release, I’ll have two more podcasts coming your way next week including a bunch more data on what’s happening to technology hiring today with DataCamp CEO Jonathan Cornelissen - and how to solve it. Make sure you’ve subscribed so you see it first!
Plus, I’ve got two more essays in the works - maybe I’ll manage to ship them both!
Cheers, and thanks for reading -
PS - thanks again to G2i for sponsoring this week’s newsletter! If your team needs data partners on evals, RL environments, or training data, schedule a call with G2i to bring them in.
Agree that the job shifts from writing code to knowing what to build and for whom. That's also why product sense is showing up in engineering interviews now. Full disclosure, I built allthingspm.app, and its free PM question bank is a decent way for engineers to practice that side.