...the same junior developers that management and the investor class have stopped hiring.

Most seniors I know like mentoring newer engineers and would happily have more juniors on the team, but we don't get to make hiring decisions. I don't like that we have a glut of unemployed/underemployed new college grads and I feel bad for them, but I do not remotely care that management may have to pay me more than they'd like in 5 years because they decided they didn't need a junior pipeline anymore. Play stupid games, win stupid prizes.

When can they come for the business side?

If agents are good enough to operate as “drones” and tools for senior devs, it seems like they could automate/clean up the dysfunction I see over deciding what software should be made, and the complications on that end.

For example, instead of long meetings on the minutia of features, maybe agents could communicate amongst themselves, with structured access to company documentation, and present distilled recommendations for humans to review?

…Or maybe I’m rambling.

I'm a senior software engineer (~20 years of experience) and job-hunting right now is killing me. Most want AI prompt experience of which I have zero. I don't use coding agents. I'm also in deep rural Japan and most jobs here are killing remote (which is why I need to find one). I have citizenship in Canada and the US and remote jobs there aren't interested for both time zone reasons and logistical ones (such as needing to use an EOR or similar which is cost, even though I go lower on my salary requirements). I've also mostly been doing golang for the last 6ish years which is not the most sought-after, and haven't touched any modern UI framework. I've even decided I'm OK with basically giving up on the life I built in Japan (where I planned to retire) and applied for jobs in EEA countries to no avail since no one wants to do visa support at least in my target country. Shit is awful right now.

Definitely has some opus smell in several places. Then again, people who use specific model families at work seem to get infected by their lexical patterns. Not a fan.

Good point. I think most of the pitch here is to stakeholders and hiring managers, since they frame it explicitly as "buying senior-engineer futures at today's price,” but I also think they’re wrong that “your seniors will hate it.” IMO that depends entirely on what kind of seniors you’ve brought onto the team.

If they’re motivated entirely by money or personal accomplishment, or they don’t play well with other developers, like the type we’ve all met who are eventually siloed on smaller projects, then yes I’d agree. They’ll hate it. But they never wanted to mentor juniors in the first place. I’d call those mid-level engineers.

None of the true seniors I’ve known could grind through repetitive agentic workflows daily without eventually hitting a brick wall of boredom. And I think most who gave it a little thought would realize this in advance. The emptiness and tedium of that work alone would be deal breaker. The only exception might be former seniors who are burned out and just want to retire ASAP, to do literally anything else.

But otherwise I don’t think most seniors want this scenario to play out. At all.

Yeah part of why I posted it here was to avoid causing juniors unnecessary anxiety. It’s ultimately seniors who will need to have a plan in place to prevent this. And to be clear no senior worth their stripes wants this, because yes it would be soul sucking.

What would be the point? We’re already solving solved problems and reproducing known design patterns for someone else’s product. Money problems are solved pretty early in a developer’s career, so for most that motivation has diminishing returns. Meaningful work is harder to come by where the air gets thin, and developing people is where many of the best developers rediscover it. They won’t just give that up and spend every workday managing bots for nesting yacht riches.

Also new tools are just tools. Anyone who thinks they can replace human judgement needs to read more. Stakeholders will prioritize short-term profits because they’re free to be greedy shortsighted fools, but engineers who are any good at their jobs don’t have that luxury. They look ahead. They have a bench. Because that’s the job.

So i wouldn’t worry about this too much. If you want a takeaway from articles like this, something to give you an edge, maybe check out the new tools. Learn how to run them on basic local machines, how to train them, and understand what they can and (more importantly) can’t do. Even if it’s just to prove to yourself why they could never replace you.

So their "solution" is for senior developers to keep giving work to junior developers... In order to prevent senior developer salaries from skyrocketing.

Newly graduated computer engineer here. I find this whole thing extremely depressing. Rant incoming.

Look at this passage from the article:

There’s a terrific writeup from the folks at FlintAI — their team is now 5 devs and 45 agents, all living in Slack. Nine agents per developer. The agents take roles — triage, deploy, review — the human steps in for the two decisions that actually matter (code review, release approval), and they report something like a 3x productivity bump.

I'm not sure what I imagined software engineers did before I graduated, but it wasn't this. It is so soul crushing that even if I could get hired and accumulate experience to be a senior, the role I would have is to clean after LLMs. I like software development. I want to do the thing I studied to do.

It makes me wonder how these 5 senior engineers came to found a company that works like that. Do they not like writing the code? Do they have dreams of being rich? Do they believe the product they will produce is so essential that the process doesn't matter?

Looking at their company (FlintAI), it makes a CRM with an integrated chatbot. The first result that came up when I searched FlintAI was another website named FlintK12 that makes an education oriented chatbot platform for teachers and students.

90% of software development jobs I see are for companies like these. Business gobbledygook software equivalent to the other 9999 business gobbledygook softwares. Job replacer 4000. Ai bot to do things that traditional software already do. Sell your knowledge to our ai bot. Help us steal information for our ai bot. Smart camera. Missile guidance system.

They all add 0 or negative value to the society, or that's what it looks like to my baby brain.

Then there's the obvious problem with the author's proposal: Senior engineers aren't something companies can sell. If they get rarer and more valuable, that value would be captured by the engineer. Which means the value of the experience that a Juinor earns from a job is also higher. So the value the Juinor provides to the company has decreased while the value they receive from the company increased. The only way I see this ending is Juinor wages plummeting and turning into unpaid internships or paid (the other way) 'educational programs'.

Developer of over 20 years. Yeah job offers haven't really changed last 5-6 years. Boom bust. They need us.

Just FYI. I'm thinking this article is completely ai written.

Perhaps the specifics of your example are different. Your quality of life still going to work everyday is better than your friends who retired comfortably 20 years early? If not these specifics, what were the ones you and your friends had in front of you?

I’ve kind of done this hypothetical in real life. My quality of life is better than my friends who took this offer.

Basically. Making employee retention a priority pays off. Getting new people spooled up is expensive. Team productivity dips while the newbie gets their bearings. Keeping the knowledge around.

Although, another problem would be people sticking around which would block Jrs from moving up.

Same as always: treat them well, pay them fairly, don’t be a dick. It’s quite easy actually.

How about a hypothetical:

Take your current paycheck amount, now multiply it by 10. That's the pay offer from the other probably dickish company. If you last even just 1 year at dickish employer, you can take the next nine years off and still be ahead financially. If you last 2 years, you may be financially set and done working for the rest of your life.

Would you stay at your current employer?

How do you keep people? Same as always: treat them well, pay them fairly, don't be a dick. It's quite easy actually. Of course, if you can only think short term, that sounds like a waste of money, but long-term, it'll pay off.

And when I say "you" I mean the generic you, not you specifically.

Full disclosure, I'm not a senior developer, but a senior elsewhere in IT facing this exact same situation.

Like the author, I've also identified our cannibalism of our juniors with the obvious future consequences to this if continued unabated. I've struggled with how to combat this, and I really give the author lots of credit for producing actual actionable plans on a path forward.

The main failure mode I see for the proposal is organizational self interest. Investing in juniors made sense in the past because the junior work (grunt work) was needed completion anyway so the exercise of training produced a useful result while also freeing up cycles for seniors to engage in higher level work. The result is that the training of the junior became partially subsidized by their output. Today that isn't really the case. A senior with an agentic workflow can likely produce the same result as the junior with only a rounding error of effort. This shifts the organizational incentive model significantly to the point were training the junior is purely a cost sink with only a negligible return to the organization.

The author points out properly that systemically across the industry cannibalizing juniors eventually means cannibalizing future seniors, but wrongly assumes that training juniors inside the organization means producing seniors long term in the organization. Unless the entire industry adopts the new system to train juniors there will be organizations that simply poach juniors that have been trained up. Money is fungible. If it takes money to train the junior an org could take those same dollars and offer relatively obscene salaries to trained juniors.

From my view, seems like it will always be more expensive to train than to hire those trained. What am I missing here? How can an org that trains up its juniors (using the author's good suggestions on how) guarantee they keep their trained juniors (or at least retain enough to make the whole exercise worth it)?

And that mistake is even more shortsighted than the systemic failure condition the author focuses on (retaining only seniors and replacing juniors with AI).

Firing your seniors instead also cripples the growth of juniors but, as a bonus, guarantees proliferation of technical debt that tends to scale exponentially with the project. And that’s all before the compounding factor of reliance on coding agents.

Sounds like your former employer insists on learning the hard way. While I’m glad you got out ahead of the shitstorm, I do feel bad for your juniors.

They don't want to pay for engineer premium so they get basic or plus levels of efforts.

Hopefully my salary skyrockets to match the current RAM bullshit pricing…

My employer: best we can do is 3% raise.

Me: best I can do is quiet quitting. Enjoy

A good article, and a great point. At the place I was recently laid off from, even the "juniors" were skipping the basics to go right to running with scissors. My team asked me daily how the things they were working on actually worked with the rest of the system, but apparently they'll be fine.

Articles about this looming problem aren’t new, but this one stood out to me for the author’s diligence in

1. projecting the scope of the problem at scale convincingly without resorting to hyperbole,
2. demonstrating the problem-solution framing engineering leads will inevitably need in order to convince clients and stakeholders (i.e., via market anticipation/contingencies/scalability rather than true yet unpersuasive appeals to the common good), and
3. actually proposing a grounded methodology, with concrete reporting and workflow examples, toward rebuilding and maintaining the endangered training and mentorship pipelines in the context of agentic development instead of just pressing a hardliner easybutton before acknowledging its impossibility and declaring the illness terminal.

I’m particularly interested to hear critique of the author’s apprenticeship model, where it might fail, how it might be improved, etc.

Wow, this is really interesting! Thanks for the insights, and the write up!

I'd be a bit careful with the assumption that a good enough overarching doc stops the create feature getting rewritten when bulk-edit turns up. In my experience it usually doesn't. Trying to design the whole thing up front so the later feature drops in cleanly is the old big-design-up-front problem, you end up guessing about the part you haven't built. souperk and doo are right that it's cheaper to expect the refactor and keep the steps small.

What the doc is genuinely useful for is the boundaries. Write down what the create part is allowed to depend on and hold it to that. If create only ever goes through a repo abstraction and never reaches into provisioning internals it doesn't need, then bulk-edit comes in as a new module against the same boundary instead of a rewrite. When you do find the second feature forcing changes deep in the first, that's nearly always the first one having coupled to something it never needed, and no amount of spec detail up front would have caught it. So I'd keep the design phase you're after, just spend it on those boundaries rather than trying to predict the features you haven't specced.

I wrote the boundaries idea up here if it's any use: https://prickles.org/tenet/bounded-contexts/A6

That's an interesting approach! I'll look into moth, thank you!

I've not used speckit and likely reinventing the bicycle, but here's my process.

Idea.md in the root with a pitch of the system Readme.md in the root with technical information

Then I'm using moth (https://github.com/tailoredshapes/moth) to file ideas and track tasks. Those files are definitely not full specs, just several lines of the core of the issue.

Then I have a command /moth that instructs to read current moth, brainstorm design with me and when agreed, implement. Also as the agent works it should keep an up to date spec under ./spec describing the scope (explicitly no code details) as it evolves, decisions taken and rejected (adr like). It underscores that the task is only done when I say so. Superpowers skill is essential here.

Then there's the back and forth on development and testing.

Eventually another command /moth-done that instructs to run the full test suite and mark moth as done.

So the essence is that I don't expect to know the full specification beforehand, but I keep track of decisions and expect to refactor often and aggressively. Conveniently writing tests is now easy and I have plenty of both unit and e2e.

Its very tightly coupled to AWS. I mention it merely because I'm not familiar with the tool you mentioned. Probably they all have similar functionality and techniques with different naming.