Junior software engineers not being hired is not the same as not needing them. Now I have to fight senior employees that do worse things than junior employees (and produce worse software than two years ago), because they delegate their work to the AI without checking or reviewing anything at all, or questioning the AI architecture "decisions", and we have more incidents than ever...

this is so accurate it hurts. the amount of my coworkers who just outright have handed any and all thinking over to the computer is staggering. its not just senior either, plenty of devs at the lead and staff level are producing complete garbage that has to be rolled back within an hour of deploy because it is extremely broken, no one verified, and it passed automated checks.

there are several features over the last few months that were obviously made and deployed and no one even launched the dev server and tried a single thing to verify if it was right. just "pull my ticket, do my ticket, push my ticket. i am a developer."

Managers can be even worse. I’ve seen an entire roadmap mostly AI generated. Director+ across the company approving based on it having the right keywords, without nuance or detail.

I’ve seen monthly and quarterly executing results AI generated with plainly wrong factual information.

same here, i call it aids (ai delusion sickness) and some companies i've seen have it bad

> just "pull my ticket, do my ticket, push my ticket. i am a developer."

IME a lot of people are now subject to output-rate expectations that preclude doing much else, honestly.

In general, it's bizarre that people look at problems this systemic and conclude that they are primarily a failing happening at the level of individual contributors. This organizational rot didn't even start with LLMs, though it's certainly been accelerated by them

myopic systems are one thing. developers and product leaders outright refusing to even click on pages and test features before they go to production is worse than their orgs simply being bad. many developers i work with can barely even reason with decisions anymore without consulting the agent. it is worse than simply saying the orgs are bad.

It's a feedback loop. I've fallen into something close to it (Thought not on the level of just not testing things before I ship them) myself once or twice under pressure. If there are deadlines that get tighter and tighter and execs and managers make credible threats about them and every checkpoint takes days, and every time you look for feedback people are doing PR reviews with AI and saying "IDK ask claude" and giving you LLM output in response to your questions then you're going against the grain by having standards in a way that could threaten your job security. If you happen to have the kind of power that lets you push back successfully in your organization, or the kind of organization that will actually take pushback seriously and not just label you a problem for it, I encourage you to be the change you want to see in the world. I think a lot of people don't meaningfully have that option. I have already found that out the hard way once. This tech is not unique in having modes of usage that are lazy, addictive, or sloppy. The difference here is that the culture from the top down in a staggering number of organizations is creating active pressure to use it that way

Yeah, it's not actually really about coding, it's about thinking. Anyone with any software experience knows the job is 90% thinking and 10% typing. At first I thought AI agents were just a faster keyboard, but no, they think for you too. For many people it's going to be very difficult to force themselves to think when they have a magic thinking machine that makes it look they thought it through.

several people on my team cannot even reason with decisions their code made, why architecture is a certain way, etc. without consulting their agent. its the thinking that is falling off, i dont care about the code nearly as much as the critical thinking part.

That and the shear volume. Since you're not writing it yourself you have to figure out what it's doing if you want to be able to review it, internalize and follow how it's changing the model that the software defines. This is doable but it takes time.

Time unfortunately that you are simply not given because the whole point is to work faster so expectations of velocity have of course increased.

So you end up having to get a fuzzy idea of a given changeset, look at it a bit and evaluate quickly if it's a good change or a bad one and click it through, and on to the next thing.

At the size of PRs being whole features and doing this 5x faster than before, all you've got left as a senior is your Spidey sense. As a junior.. no idea how they cope.

We'd all love to still spend that 90% thinking time, but it used to be justified by necessity of getting the job done. Now, it's just not a luxury that is afforded.

What can ya do.. I'm slowly learning to be the best bot herder I can be, but it certainly feels like a change in skillsets. I definitely only feel like I'm able to do a good job due to enough experience and building and growing software projects over time to have an idea of what kind of decisions might bite us down the road, as well as to know what maybe can't be known but is just worth a risk. Without that kind of intuition I think I'd feel like I was really shooting blind.

It's really depressing watching brilliant software developers and engineers producing the worst, unmaintainable code imaginable, and being okay with shipping it because it's passing the test suite. Assuming the test suite is any good anyway (because holy crap, the nonsensical tests AI writes...)

Your code used to be a masterpiece, so well crafted it's easy for AI to tweak and modify because you've got everything so logically organised and scoped... and now this is what you're producing? Hard to debug monstrosities that only an LLM can realistically bolt new features or tweaks onto, because it can do the kinds of refactoring necessary each time.

We use to talk about the fact that code should be readable because you spend more time reading it than writing it, but I think that misses the key part that readable code is also typically easier to debug. If you can read and understand the code, you can follow the logic when things are wrong in production, and you can more easily reason about the emergent properties of interactions between the complex systems that are involved.

I always like to say that LLM-produced test suites aren't for testing software correctness or validity, they're for testing to make sure that stuff that was previously in place stays unchanged. This, of course, is six-in-one-hand-half-a-dozen-in-the-other since the agent will often just update tests to match the updates it just made, but I do find value in providing some kind of continuity to a codebase that's being modified at breakneck pace. YMMV

Yep. The only reason for automated testing is to enable future refactoring, which might be needed for future development. If we only wrote software once, we wouldn't need automated tests. You'd just write the software, test manually as you go, then ship it when you're happy. Ideally not all future development would even need any refactors. A good software architecture would allow one to add features simply by adding more modules of code. But, of course, we don't know what the perfect software architecture is from the start, so we need to assume someone will one day need to refactor.

Nice point. But I still have way too many vibe coded tests that passes and break in production despite they should have failed but Claude fixed the test by mocking the test to pass. I am not kidding.

Your code used to be a masterpiece? Ours was more… Amazon basics wall art.

I jest, while in agreement with this whole comment. We used to care about fostering informed developers and maintaining high standards and good quality software.

I literally compared it to being an expert woodworker. Beautiful ornate decoration. Rich, sturdy mahogany, one of a kind, beveled edges and a fantastic stained hardwood.

Now it’s the 30$ Ikea cardboard stuff.

My biggest question is how many tables does the world need, and how many woodworkers will be required to build + maintain those table factories.

Certainly mostly what I did wasn't great but throughout 20+ years I think at some point I found a balance between "doing this shit because someone f'cking overpromised" and "I am doing this because I want a brain teezer". But it is not like I always do the same. I understood that there are times to do things in one way and times to do in another way.

I think with AI, most people are getting lazy to do it properly.

The other day, I deleted 65K LOC that were dead code or stupid explanations over very obvious code from a vibe coded repository which had 95K LOC (but should have 10k imo)

It's getting off topic, but I think a major reason for $30 cardboard tables is the strange modern idea that furniture isn't part of the house.

If you buy a house or rent an apartment in most of the US, any furniture will be stripped out, even if the only thing you plan to do with it afterwards is throw it away. Then the new tenant provides their own furniture, which they either moved from elsewhere at great expense or had to purchase on the spot. No part of this makes any sense. We don't strip countertops when selling a house even if they're unfashionable, we don't replace white goods, but somehow it's expected for the furniture.

If you buy a house in Hawaii, it's understood that you're buying the furniture that's already in the house. I assume the reason is that it's more difficult to obtain new furniture in Hawaii.

If you rent an apartment in China, it will come with furniture, because how else are you supposed to live in it? And if you're not happy with the furniture it's shown with, you negotiate with the landlord for the furniture you need.

If Americans sold their furniture when they moved instead of throwing it away, you'd see everyone using much higher-quality furniture. It would have come with their house. And providing it to houses that didn't have it yet would be an investment, just like the countertops.

  > If you rent an apartment in China, it will come with furniture, because how else are you supposed to live in it?

+1 this. not in china, but same for me when i was a student; it was a godsend

> Your code used to be a masterpiece

Do you even see anything underneath that rose tint ?

There's this amazing rhetorical technique called hyperbole. Compared to what I'm getting from co-workers, and in code bases I'm subjected to these days, what I used to have to deal with was a masterpiece.

I've waded through unfamiliar code at 3am trying to figure out just why the hell things broke this time more times than I can care to remember, particularly trying to tease apart the ways that code has organically grown compared to the original intent. If I'm subjected to one more piece of "spooky at a distance" injected behaviour code I'll probably scream loud enough to be heard half way across the country.

It's still just leaps and bounds more readable than what people are slopping together (I do have some co-workers that have been extremely tightly focused on avoiding "slop" with their AI and doing a lot of tuning, and it's certainly preferable to the ones that haven't)

TBH I'm seeing the opposite, I have a legacy codebase where the people originally writing it were incompetent and inexperienced, but the project took off. It's scaling up but the foundation is shit and has to be gradually rebuilt. Every AI slop commit is still better than the underlying crap.

And this is the pattern I've seen on most (semi)successful projects I've worked on in the past - I'd say correlation between financial success and code quality is 0 (up to a point where the whole thing doesn't fall apart). Once scale (both in load and in code size/features) starts mattering you're stuck building on a foundation of shit. LLMs are very good at identifying and cleaning up said shit layers, as long as you're steering them towards a desireable outcome.

I’ve seen people say this kind of code was written, but I’ve never seen this kind of code anywhere I have ever worked.

Not saying it doesn’t exist, just saying this sounds dangerously close to a boomer talking about the 1950s

> I’ve seen people say this kind of code was written, but I’ve never seen this kind of code anywhere I have ever worked.

Luckier than me. I've worked at a few places where the code was simultaneously brilliantly written[0] and also unmaintainable nonsense that caused endless problems. One place had its own object model and ORM that absolutely no-one currently at the place understood and literally every bug filed (whilst I was there) could be traced back to that code.

(Probably just a coincidence that most of those places where Perl shops but I've seen it with Go too...)

[0] In terms of "cleverness", not in terms of "maintainability" or "readability".

I don't know which companies you work for. Where is the code a masterpiece? In all my work, I have yet to see this elegant code. Before AI, we had to deal with human slop. Byzantine, spaghetti messes. I haven't been lucky. I once worked with code that made me want to pull my hair out. I look at LLM-generated code, and it's mostly better than any code I have worked on. But maybe it's just me.

>> I once worked with code that made me want to pull my hair out.

Only once?

Oh god, we're gonna do the four Yorkshiremen, aren't we?

so you're saying that junior software engineers write better code now? I find that hard to believe.

No, I say that senior software engineers write worse code than a year ago (when they started forcing us to use AI at work)

TECH! PRIESTS!

https://warhammer40k.fandom.com/wiki/Tech-Priest

> This is not a problem unique to the mathematical community.

Ahh that's OK then. Everyone's in this same boat simultaneously in multiple industries! Cool!

> What is the solution? I don't think the solution is to say AI progress in software, mathematics etc. should be halted.

I think the solution from the maths world is to not grant these AI papers (or their human sponsors) the normal courtesies of "regular order", just as you would not with an AI lawyer or someone who was just pressing enter at a law firm.

But in the software world, nobody gives a shit, apparently. We are collectively morally bankrupt and should not be granted the regular order to help other people to decide what to do with us.

There is nothing preventing Junior Developers to develop their own systems and understand it.

In fact, the world is always filled with curious people who like to go one level below.

This hysteria about losing "Junior Software Engineers" -- most of them in it for money, promotion rather than craftmanship, is over-rated.

People who love solving puzzles will always find ways to sharpen their mind.

People who love understanding things, will always find ways (AI will help them tremendously).

People who love taking shortcuts will always find ways for it (AI or not)

Aren't you forgetting that they need to eat? Pay rent?

We are not in the 1930s.

If you have made it to the point of being a Junior Developer, I can assure you food and shelter is not a problem for them. You just have to adjust to a standard of living like the other 7 Billion people on this world.

Also, if a Junior Developer can show me(or anyone) they have built an entire system on their own and explain key concepts, there is no dearth of jobs for them

This feels like a truism that's easier said than done. In fact, I know someone in that position. They've built things from scratch, they understand things at a deep conceptual level... Oh and they're a math prodigy. How do I refer them to you?

LinkedIn. Our recruiter will contact them /s

Nope, they won't. Recruiters look for keywords and companies on your resume. If someone has built something as a personal project that doesn't count for squat.

If he is really as good as you say, you can literally ask Claude as to how to go about getting visibility.

It's just a search problem now.

> There is nothing preventing Junior Developers to develop their own systems and understand it.

Eh? Apart from it not being what they are paid to do on their 9/9/6 jobs, when will they have the time to make it happen?

What is going to happen is that the remnants of the open source community will do the job of educating juniors for free, when the university degree system collapses. Just like it currently keeps a bunch of systems going with inadequate compensation.

The corporate world gets the problem off its balance sheet. Again.

The argument you respond to here is "it is impossible for anyone to be Junior Software Engineer because AI". That is a straw-man.

The actual argument is "there will be no jobs for Junior Engineers, so there will be far fewer, and as a result there will be a huge shortage of Senior Software Engineers".

You are responding to the problem as if it some kind of extinction event, like a rare bird, where if we can find a breeding population we save the day. A few curious people, self training for the love of the game, and as a result we still have a few Software Engineers so everything is fine. It is not like that, and I haven't heard anyone suggest that is the issue. The potential problem is a massive shortage of workers with skills that are currently essential to the functioning of a large fraction of the economy, whom we might still need in the future.

The continued existence of talented enthusiasts does not establish an adequate workforce pipeline. If paid entry level experience contracts, what replaces it, and why should we expect that replacement to operate at sufficient scale?

If there is a market demand, skills will find a way, especially in non-regulated industries like Software Engineering with $0 barriers to entry and no government certification

The market very often fails to solve problems until after some kind of huge collapse or failure. Will this problem be around in 200 years? No. Does that mean we should follow your advice and just shut up and not talk about it or try to avoid some kind of major market inefficiency due to short sighted macroeconomic planning? No.

Or the broader reproducibility problem that’s been silently plaguing most of academia for decades with little to no mention. Many, many, many papers and theses and assumptions we build on may be bunk.

[delayed]

AI development should be harnessed in such a way that AI augments humans without replacing them. Tools that replace human intelligence altogether are not true progress for humanity.

This ship kinda sailed when OpenAI came out of the barn by claiming it could replace people. The narrative of the AI bubble has always been this cynical management driven replace your human capital/labor with stupid bots.

Trying to actually get the framing to be more reasonable is just hard because so many people have oversold it and large swaths of the public are sick of hearing about it.

  AI progress in software

Oh, yes... the progress... You measure it by LOC, right?

We know how this goes, at least in broad strokes. We've been through it before, just not with "knowledge" work. If there is demand for something then supply will show up to provide it.

Some jobs will stick around in vastly diminished numbers with tasks that are completely different than what they used to be to produce the same output (e.g. farmer). Other jobs will be eliminated entirely (e.g. switchboard operator). I'm guessing things like software engineering will go the way of the farmer, with the main unknown being just how much demand for software there is.

Why do people think that people displaced by AI in one industry will get a job in another industry?

The entire valuation of the AI industry is predicated on people not just losing individual jobs, but being taken out of the workforce entirely on an economic level.

They are talking about the workforce of the entire economy shrinking. People will lose their livelihoods for good.

This has the potential to be even worse than the second agricultural revolution to industrial revolution phase, which made ordinary workers lives absolutely miserable for maybe a hundred and fifty years.

This time, there will be no jobs. If you are displaced from one industry by AI, you will end up in another industry also being decimated by AI; if you get a job at all, you will do so by working lower pay than other workers, who will in turn be pushed down the ladder.

And that is if you are lucky: if you have only IT skills, why should you be the first to get a fruit picking or plumbing job?

> And that is if you are lucky: if you have only IT skills, why should you be the first to get a fruit picking or plumbing job?

Easy. Because you have the skills to increase productivity by automating it. Oh wait...

That valuation is from the same people that valued dot.com's so high, and didn't bet against mortgage backed securities. So call me a bit skeptical on their far seeing wisdom. I mean maybe this time is different. Sure. And they don't need the whole economy to collapse or the bubble to not collapse; they just need to have invested in 1 or 2 entities that become large long lived companies.

I would argue that how it goes ends up with the main downstream effect of shifting knowledge growth and therefore expertise and therefore economic power away from the people who outsource it and to the people who do that outsourced work.

In this case with AI that power will shift to the companies that run the AIs

I'm not old enough to have gone through the revolution that was programming languages that got increasingly more abstract and decoupled from the metal, but surely there's a lesson that can be learned from that era?

Those abstractions are deterministic. LLMs are not.

Garbage collection and what the JIT decides to do often isn't.

I think the more salient point is that going from writing assembler to C still required you to understand a lot about your machine, algorithms, how to debug issues, and in general it demanded problem solving skills.

LLMs eat away at all of these requirements.

Making things work demands problem solving skills. LLM or not. Perhaps one returns from the thoughtful debugging walk around the block knowing what question to pose to the LLM rather than what function to add logging to, but whatever. Everything is flux, this too shall end.

Perhaps, but as far as I've seen they don't make the requirement go away. They do make many types of development far more accessible, as an extension of how SQL or Excel make development far more accessible. Sure, people make messes with the tools available, and sometimes the tools can handle it and still give you something useful, many times it takes someone actually knowing what they're doing to clean it up though.

Human’s aren’t deterministic either.

We don't keep snapshots of humans in source control.

One time this codebase I worked on had an ASCII art image of one of the devs in it buried in a comment at the bottom of some random file. YMMV.

more importantly those abstractions were designed to try to make it easier to reason about what was going on for the author, build additional internal abstractions and to allow a reader to follow along and gain an understand of the structure. unless we believe that we can completely punt on having agency over the codebase, then llm code is only as valuable as it is readable.

The dream is that we keep agency, but also give up on reading code, by doing away with code as our level of abstraction and instead having humans edit human-readable spec files (including, say, depicting UIs directly with visual mocks). Like "no code" platforms, but for everything.

If by "human readable" you mean written in natural language, then those spec files will have ambiguities and imprecisions. If you make the spec precise and unambiguous enough, then it essentially just becomes a program written in code.

>The dream is that we keep agency, but also give up on reading code, by doing away with code as our level of abstraction and instead having humans edit human-readable spec files (including, say, depicting UIs directly with visual mocks). Like "no code" platforms, but for everything.

Human language is famously terrible at being unambiguous.

That's ok if you and the AI are on the same page. And it is possible to write more rigorous natural language, e.g. laws are written in human languages, and yet judges and lawyers agree on how to interpret most of them and there's a defined arbitration process to resolve any new ambiguities.

> if you and the AI are on the same page

But that's the thing, you and the AI might be "on the same page" for one prompt, and then you aren't for the next.

> and yet judges and lawyers agree on how to interpret most of them

Um, no? Lawyers and judges frequently disagree on how laws should be interpreted. And it is often not written in a way that a layperson can easily understand.

> defined arbitration process to resolve any new ambiguities.

That is famously slow and expensive, and can resul in something very different from what the lawmakers originally intended.

Yes. As machhine power and memory increased, and as as programming abstractions advanced, software grew larger and more bloated, therefore what used to run on a single core in KB of RAM now takes multiple cores and GB of ram.

The developers who knew how to write efficient low-level code found that there were no jobs for that anynmore, so today the developers who can work at that level are very few.

The same will happen with AI being the new abstraction. In another decade or two, very few people will be able to write code by hand. We'll need a rack of compute in a data center and multiple KW of power to do what we used to do on a desktop PC drawing a couple of hundred Watts.

The funny thing is it appears we may see a return to the software output from AI being efficient low level code. So while the compute to actually write the software rockets upwards the software itself might broadly become dramatically more efficient again.

I suppose that is possible, but I have not seen it yet. When I ask an LLM to write code for me, "dramatically efficient" are not the adjectives that come to mind to describe the results. Usually "well, it works" is about as good as I can hope for, and I often don't even get that at least on the first iteration.

on the contrary, AI seems to do better at high level code generation

I think we will see the same trend as other industries. “Good enough” but produced cheap is better business than “really good” but expensive. I assume most software will go that way, or has gone that way already. AI will probably cover most of it and only a few senior engineers will be needed. Basically like any other industry where it went from everybody being a craftsman to a few people building the machines that then can be used by relatively untrained people.

I hope we discover a solution before innovation totally stalls, but I do not think any solution has been found yet. And I agree that halting AI is unlikely to be the solution because even if we halt the big companies China for example can still do AI.

Some people hope AI will get good enough in a few years that it can innovate without human experts. Maybe? But that remains to be seen.

It does remain to be seen.

By the progress of AI from ChatGPT to now is horrifyingly fast.

Trendlines and basic reasoning point to a most probable future where the AI is superior. We can’t just say “that remains to be seen” because the alternative is the least probable future.

Anticipate the change and act prior.

AI models and tooling has advanced significantly in the last 6 months. Give it a couple of years and the companies will not need senior software engineers. They will need someone to steer the AI, maybe. Why would anyone need senior software engineers?

> Give it a couple of years and the companies will not need senior software engineers. They will need someone to steer the AI, maybe. Why would anyone need senior software engineers?

Right, companies won't need software engineers. They'll just need someone who can use tools to produce source code and maintain the generated artifacts, plus make domain-specific technical decisions like "what should the system do when two users update the same record as the same time" or "how should the system behave when a message in the queue cannot be processed".

We really oughta come up with a job title for these people.

> We really oughta come up with a job title for these people.

agent herder!

If that comes to pass, I will have to re-evaluate my career options

What makes you think the LLM won’t just handle that on its own, or ask the person doing the “development”?

Because there's no one correct answer and every decision involves engineering tradeoffs.

Who do you think the will be choosing whether the database uses a pessimistic or optimistic concurrency strategy? The CEO?

I honestly don't think that these people will need to think in this level. `message in the queue` is an implementation detail..

I do not know or care what my if statement turned into in x86 assembly unless it becomes a performance problem and even then, I'm not profiling or debugging in machine language. Neither do most developers these days. A message in a queue becomes something akin to that in this era.

I see that I got downvoted there. This is not something I advocate or look forward to but I feel this is where it is going.

It may not be necessary to think in those terms exactly, but if you are not even able to think in those terms, you probably will be no good at prompting the LLM either. It's quite plausible that someone can be a productive dev with claude if they don't know exactly how the message queue is processed. But if they don't know there is a message queue at all, that is much less likely.

Likewise, you don't care exactly how an if statement gets converted into machine code, but you do know precisely what an if statement is and how it should behave, and could identify if it was buggy, and that that part of the codebase contains a bug. If you can't do that, then there is an impossible-to-estimate probability that at some point you get stuck and no progress will ever be possible. I don't see that as a winning strategy, in the long run (but it may work very well in the short term).

> I honestly don't think that these people will need to think in this level. `message in the queue` is an implementation detail..

No it isn't lol. Have you worked on any real systems with customers? Good luck telling your boss at AWS that a poison pill message stopped the payment queue from processing so they lost $100 million in sales but hey, it's an implementation detail, no big deal.

> No it isn't lol. Have you worked on any real systems with customers?

I have. Those systems already fail in spectacular ways and people tell their bosses that some worker process stopped working because its transaction IDs overflowed.

I bet that sounds like `the flux capacitor stopped reticulating splines` which is already an implementation detail for the boss anyway. Nothing changes.

Right, so who's going to ask Claude to investigate the worker processes and fix the transaction ID overflow? The CEO? Someone in marketing? The sales team?

Or maaaaaybe.... an engineer?

if your boss is prompting the AI, that's what the claude output is going to sound like, if not worse.

Exactly these people will be experts at typing this:

“ Claude! what should the system do when two users update the same record as the same time, explain to me with full clarity”

or "Claude! how should the system behave when a message in the queue cannot be processed? Give me all the possible ways ranked from best to worst, also explain to me all these concepts so I can understand as I don’t have a cs degree".

If you think that there is no future where software engineers don’t matter then you are delusional. While the future is not set in stone the pace and trendline of AI point to this future as a MORE realistic future then the alternative.

Your example btw is ALREADY a solved problem. AI can answer it and design around it. Agents at my company already handle our infra.

> “ Claude! what should the system do when two users update the same record as the same time, explain to me with full clarity”

This isn't even the right question to ask, I think you've basically proved my point. You are in charge of deciding what the system should do when two users update a record at the same time. It's extremely dependent on what you're trying to do.

> Your example btw is ALREADY a solved problem. AI can answer it and design around it.

What's the one-size-fit-all solution for concurrency management that works for every single domain and application? I'm curious.

> Claude! how should the system behave when a message in the queue cannot be processed? Give me all the possible ways ranked from best to worst, also explain to me all these concepts so I can understand as I don’t have a cs degree".

Who's going to make this decision? The CEO?

> This isn't even the right question to ask.

It’s your example. I simply took your example and asked Claude. If it’s not the right question then don’t give it out as an example.

> What's the one-size-fit-all solution for concurrency management that works for every single domain and application? I'm curious.

I’m curious how your brain concocted I said that. Examine the context of our conversation. What I mean there is that AI can solve those questions for every possible domain application.

> Who's going to make this decision? The CEO?

Armed with Claude any non technical person can make this decision.

> If it’s not the right question then don’t give it out as an example.

Knowing the right question to ask is what makes a person an engineer.

> What I mean there is that AI can solve those questions for every possible domain application.

Yes, if you know what to ask. You're doing an excellent job of demonstrating my point!

> Armed with Claude any non technical person can make this decision.

You just disproved that by asking the wrong question. Much like you, the CEO won't even know what to ask an AI.

>Knowing the right question to ask is what makes a person an engineer.

Yes, but this is orthogonal to the point and that is: AI can do it too.

>Yes, if you know what to ask. You're doing an excellent job of demonstrating my point!

No it's your comprehension that needs work. You are missing MY point while being repeatedly getting enamored with your own point. My point is that AI KNOWS the questions.

>You just disproved that by asking the wrong question. Much like you, the CEO won't even know what to ask an AI.

I didn't ask a single question bro. I only regurgitated your examples. Much like AI, half your statements are based off of hallucinations.

Because the models do what you ask them. "Claude, do this thing, be thorough, no mistakes" is not a good prompt.

Maybe for some value of "what you ask them."

I have a data pipeline with 6 steps, A -> B -> C -> D -> E -> F. I asked Codex to make some specific optimizations to step B and benchmark them. It did what I asked. Then it decided to also benchmark the entire pipeline, and after noticing that step E was slow it decided to make some optimizations that I had not asked for on step E. It was at this point that I wondered why it was taking so long, saw what it was doing, and stopped it.

This is GPT-6.1 Sol High.

What do you think "steering the AI" means? It is not like we need someone to sit at a desk and type "yes, implement it". Of course if you are a sane person you mean someone who will determine if the AI is doing "the right thing" and change its direction if it is wrong. That person is almost by definition a senior engineer.

Someone making sure that the business requirements are implemented properly and correctly. Basically a project manager. Maybe also someone testing the output and providing feedback. Not someone that says `we might have a race condition here, lets implement a distributed lock`.

I think that person does not need to know about locks anymore.

The evidence from skilled vs unskilled users vibe coding is not on your side, I think.

At the moment yes, you are absolutely right. The argument was about a couple years into the future. Nobody can predict this though. I feel this will slowly steer that way. We’ll live and see.

I think this will be a self-correcting problem once the damage is done, and the only cure is more cowbell, I mean - TIME.

In the age of extraction capitalism where building sustainable, profitable companies is not the goal, no one will care.

Hopefully, there are some sustainable, profitable companies that keep a low profile now and will take over after the "self correction" happens, and whoever invested in them will become very rich.

Tons of corporations rely on the fact that human interaction within software production will be as minimal as possible, and no one actually cares who trains the seniors of the future.

> Without junior engineers how will there be senior software engineers in the future?

My take is: the bar to what counts to HR as "senior" will go down as businesses everywhere try to adapt and hire more seniors - "senior" now just a name, as it becomes the new "junior". Then everyone will pat each other on the back till it all goes down in the flames of bankruptcy.

You see in this thread. Even seniors are shipping slop because at the end of the day its the companies shitheap of a codebase, not theirs, they will ship with slop code all the same.

In other words, they are increasingly devauing their own senior position and discarding their hard earned skills that make them seniors in the first place.

There will be no more seniors. Tech companies will hire junior llm agent wranglers who took a class in undergrad doing this. That is probably the nearterm.

It would be exceptionally fascinating, if AI, due to the limitations of how it models information, and the way that it warped incentives, if AI ended up being a net inhibitor of progress than accelerator.

Going fast, and sustained speed, are very different things. I've often felt, in many different areas of life, that a shortcut will pay off in the short term, but if you take nothing but shortcuts then you will do terribly long term.

You have to do the hard thing eventually, or you never get anywhere.

AI slop is basically the grey goo scenario but happening on the level of information and thought.

"Without junior engineers how will there be senior software engineers in the future?" If I were an AI fan, my answer would be this: By that time, AI will have improved enough that it can replace senior software engineers as well.

Disclaimer: I am not a fan of AI, and I am currently writing software without any help from AI, as I prefer.

Right, that's a possibility. When that happens we won't need senior software engineers. We won't need a "thriving mathematical community" either.

Would we need doctors, accountants or analysts? Probably not. At some point farming will be fully automated too, and so will grocery distribution and food preparation. At that point we will have arrived in the post-scarcity world. This is the promise of AI.

The problem is that the post-scarcity world will arrive gradually, not suddenly. Some jobs will be automated sooner than others. The ones that are not yet automated will expect payment for services. People who just lost jobs to automation won't have income to pay for those not-yet-automated services. But that's only until all jobs are automated.

There will be tremendous social upheaval and unrest during the transition to post-scarcity world.

For the record, I agree entirely with you.

I'll add that as a retired person myself, I have found things to do with my time that seem (reasonably) useful. At the moment that includes writing a computer program, substitute teaching at the high school level, and occasionally writing a sci-fi novel. How much of that the average person could or would do if they had no employment in the post-scarcity world, I don't know---and for that matter, most (maybe all) of these would be replaced by AI. The point: what are people going to do to make their lives seem worthwhile? Which will add to the social upheaval and unrest you rightly predict.

My company hired a junior dev that was helping a senior one, then after layoffs and financial issues senior was fired, and junior left to pick mission critical code with a stick and codex.

So how was the result?

Yet to see, as a few big sweeps he did (with various problems), are still sitting unmerged after 2-3 months, with a dev from another project reviewing them and a hardware lead reviewing the idea.

AI progress is so massively out pacing any rate of loss of senior developers though.

Just for a thought experiment lets say junior hiring actually goes to 0% starting today and there is no other route into software dev for example maybe it is illegal for anyone under 22 today going forward to work in dev. Maybe something like ~2-2.5% of the workforce retires each year? And lets just define senior as 10+ YOE so 75% of the current batch of ~40 year working timeline. For simplicity lets just say the other 25% don't ever become senior devs and in 10 years the total number of senior devs has reduced 33% due to retirements. ChatGPT public launch was less then 4 years ago! Look at the ludicrous progress in the timespan. Even if progress suddenly massively slows or hits a wall it is currently hard to fathom it not improving at a rate of 3% a year.

More realistically I think we just have no ability to predict wtf things will look like 10+ years out at this point which is the point in this artificially constrained timeline where a reduction of senior devs just due to time would even start to be noticeable I think.