A long post published on 14 September 2026 on seldo.com makes a ten-year bet on the job of software developer. Its author - the copy we have is not signed in the body of the text; he describes himself only as working in AI evaluation - states up front the two assumptions everything else rests on, and we will say the same thing: if you reject them, none of what follows holds.
Assumption 1: agents are going to eat the entire software development lifecycle. They already write code well and are mediocre at everything that comes after - reviewing, testing, finding and fixing bugs, deploying, monitoring, scaling. The author bets this is temporary, and that nothing structural prevents it. Assumption 2: there is no upper bound to how much software we need. Look at your dentist's website, your insurer's, your children's school: that software is not bad because nobody knows how to do better, it is bad because the people who need it cannot afford better at current prices.
Both are bets, and the article owns them as such. What follows, by contrast, is largely observable today.
The labour market has already started deciding
The figures the post gathers describe a market split in two. The Stanford team tracking youth employment in AI-exposed occupations measures a 19% gap for 22-to-25-year-olds against their less exposed peers - up from 15% a year earlier - and notes that the gap widens through reduced hiring, not layoffs. On the company side, SignalFire's 2026 talent report puts entry-level hiring down 65% since 2019 at the big technology companies and down 75% at early-stage startups - while engineering as a share of hiring rose, from 46% to 55%.
Translation: companies are hiring fewer people overall, but a larger share of those they do hire are engineers. Just not the kind whose primary job is typing code.
The most interesting detail is not the volume, it is where it lands. Still according to the Stanford authors, young workers lost ground in occupations built on knowledge that is written down somewhere, and experienced workers gained ground in occupations built on knowledge you get by doing the job. The researchers call this codified versus tacit knowledge; the author offers a blunter rewording: stuff that is in the training data, and stuff that isn't.
One caveat that matters: these figures are cited from this post, not read in the original reports. We have not verified them at source.
What is left when code costs nothing
The core exercise of the article is to break the cost of making software into pieces and ask, item by item, how much of it an agent can take. The result falls into four buckets: collapsed (writing the code); going soon (reviewing, maintaining); next on the chopping block (shipping to production, scaling up); and possibly safe - deciding what to build, defining what "good" means, making it pleasant to use.
That last bucket has a property the article puts well: it does not transfer. The definition of "good" for a calendar app and for a scheduling app, which solve roughly the same problem, have almost nothing in common. Two bakeries don't have exactly the same problem either. Every time you meet software with a thousand configuration options that still doesn't do what you need, you are feeling that absence of economies of scale.
At some point every piece of software is a formalization of a human desire.
Hence the argument that carries everything: the only person on earth who knows the customer runs a bakery and not a parts factory is the customer. It cannot be extracted mechanically, it cannot be trained into a model, because it is written down nowhere. Somebody has to go and get it, turn it into something exact enough to build, then check that what got built is what she meant - which it never is the first time.
This is exactly the shift we described in July under the spec as the new software asset. The post adds an economic consequence: as the cost of creation falls to zero, the bottleneck moves to the description of the problem, and that is where it stays.
The market has already priced the job
This is not a forecast: the role is being bought already, under a dozen names. Palantir coined forward deployed engineer - someone who sits with the customer, works out what they actually need, and builds it inside the customer's environment, with the customer watching. It was a Palantir oddity. In 2025, postings for the title grew by roughly 800% in nine months; at the time of writing, a census counted almost a thousand live postings across 462 companies, including OpenAI, Anthropic, Databricks, Stripe and Google Cloud, with Salesforce saying it wants a thousand of them on its own.
Average total compensation sits around $240,000, with senior profiles clearing $600,000. Which is to say it pays like a senior engineering job, because it is one. The same role is posted as solutions engineer, deployment engineer, applied AI engineer, implementation engineer - nobody has agreed on the name yet.
Read the job descriptions and you find, roughly, a senior product engineer: scope the problem with the customer, understand their business, write production code into systems you didn't build, iterate until it works. Writing code is in there, but it is the smallest part - and it is the part the agent does.
The job isn't new. Its training pipeline is what vanished
The article takes care to recall that this role was not invented in 2026. When computers were new and programmers scarce, companies employed a systems analyst: someone whose entire job was to sit between the business and the programmers and write the need down precisely enough to be built. A 1963 memo from Miami University already describes it as a brand new profession. Then software went consumer-facing, and that translator became a product manager - a role borrowed from Procter & Gamble's brand managers by way of Intuit and then Microsoft, where a programmer named Jabe Blumenthal invented the program manager in the late 1980s because Excel for the Mac needed somebody to own what it should do.
One and a half jobs thus became two separate professions for twenty-five years. The post's thesis is that they are collapsing back into one.
And this is where the reasoning meets its real problem, the one that gives this article its title. The industry is about to need, in unlimited quantities, people who can extract requirements from humans, define "good" and exercise taste - and we do not make those people.
The numbers are unkind. Google's associate product manager programme, started in 2002 and copied everywhere since, takes about fifty people a year out of something like twelve thousand applicants. Meta, Uber, LinkedIn, Salesforce and a few others run equivalents of similar size. All told: maybe a few hundred people a year trained, on purpose, for what is about to be the whole job - against a junior developer pipeline that used to be tens of thousands and is now going out.
Because the old pipeline was not a school, it was a side effect. You hired a junior to write code against a well-specified ticket, a senior reviewed it, and over a decade of that the junior absorbed enough judgment to become the senior. The bottom two rungs of that ladder - type the code, have it reviewed - are precisely the two things agents take. Universities teach data structures, bootcamps teach React; nobody teaches "go sit with a baker for a week and come back with a spec".
What an organisation can do without waiting ten years
The author expects the market to correct eventually: the price of the scarce thing rises until somebody finds it worth making more of it. He cites IBM, redesigning its entry-level role around customer contact and specification rather than typing. But he adds that it will happen too slowly, and that a cohort will be hurt in the meantime.
An organisation does not have to wait for the market, because passing on judgment does not depend on a degree. It depends on something far more mundane: that decisions are written down somewhere. Yesterday's junior learned by watching a senior arbitrate in a code review. If code reviews disappear and nothing else takes over as a record, there is nothing left to watch.
That is precisely what we build, and I am not going to pretend it is a coincidence: Survol records product decisions, the trade-offs made inside a session and the constraints applied, because a product developed by agents needs a functional source of truth. But the side effect is worth stating, because it answers the post's question: a trade-off that is written down, dated and attached to a feature is something you can learn from. A conversation with an agent that disappears when the tab closes is not.
Three moves follow, and none of them requires waiting for universities to reform:
- Write the decision, not just the outcome. "We picked B" teaches nothing. "We picked B because this customer bills per order, not per line" can be learned.
- Put beginners next to the need, not next to the ticket. If the bottom rung is no longer "write the code for a well-specified ticket", it has to become "sit in the conversation where the ticket gets made".
- Record what you turn down. An organisation that keeps track of the requests it declined, and why, produces in a year a body of judgment nobody teaches.
The bias the author admits, and worth keeping in mind
There is an honesty in this post you rarely see, and it deserves repeating here rather than burying. The author writes that "figure out what to build, not how to build it" is also the part of the job he always liked, and that there is a well-known failure mode: everyone with an opinion about AI concludes that every job will be automated except theirs, mysteriously impossible to automate. He asks to be read with that reservation. We keep it as is - including for ourselves, given that our product happens to sell the work of specification.
Nor does he hide what his forecast costs. Writing code as paid work is, he thinks, mostly over, and that is a real loss - not only for the people, but for the profession, because the craft is where much of the judgment he says will be scarce actually came from. His only consolation is an observation: for many of those who thought they loved the typing, what they actually loved was the moment before it - when a vague mess of a problem resolves into a precise shape. That moment is now the job.
Sources
- "We are all Product Engineers now", seldo.com, 14 September 2026. The copy we have is not signed in the body of the text. Every figure in this article comes from it: the Stanford data on 22-to-25-year-old employment, the SignalFire 2026 talent report, the census of forward deployed engineer postings and the intake of Google's associate product manager programme are all cited by the author, and we have not read them in their original reports.
