Rendered at 15:38:37 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Syntaf 1 days ago [-]
> bad engineers were always a liability
This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.
I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu
overgard 22 hours ago [-]
I kind of think the whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry. Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job. The problem is our industry mostly doesn't have any sort of reasonable mentorship or apprenticeship culture, so we've always left it to the engineers to teach themselves. Sink or swim. The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation, and we don't have a good culture of getting them up to speed. So now we have seniors that can barely write a function, much less reason about a complex system.
I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.
hn_throwaway_99 21 hours ago [-]
The whole "learn to code" and software bootcamp craze always baffled me. Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training." Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.
And more directly, I believe good software engineering is really hard. I think it takes a certain mindset to begin with that many people just do not and will never possess, and it takes years of experience to get a good sense of what works and what doesn't, especially with respect to the entire relationship between code, business, people and teams. Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit), often times by our own practitioners of the craft.
jselysianeagle 20 hours ago [-]
> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."
For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did. We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.
Additionally, it wasn't software engineers doing this, but people looking to cash in on students looking to get a 6-figure job. They were business people, not software engineers.
ElProlactin 17 hours ago [-]
> For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did.
"Professionalize" is an interesting way to frame this. As Milton Friedman argued, occupational licensure is almost always pursued by the practitioners rather than consumers. The licensing boards are mostly run by practicing lawyers and CPAs, so you have practicing lawyers and CPAs determining who can compete with them. So what you get are cartel-like bodies.
Most people don't know the histories of how these professions came to be what they are today in the US. If you take 15 minutes to read up on it, it leaves little doubt what the intentions are and how much consumers have been screwed.
> We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.
Except that basically everyone in the industry knows that leetcode doesn't test real-world proficiency. It's equally dubious to believe that some sort of body (ostensibly run by practicing software developers) would be able to come up with a means to certify proficiency.
Incidentally, many of the outfits "looking to cash in on students looking to get a 6-figure job" placed a heavy emphasis on teaching their students how to interview, not how to be proficient.
joshdavham 12 hours ago [-]
> It's equally dubious to believe that some sort of body (ostensibly run by practicing software developers) would be able to come up with a means to certify proficiency.
I very much mostly agree with you, but I did take the Google Cloud Associate exam a year and a half ago and honestly it felt like a pretty rigorous exam. I definitely could not have passed that exam if I was incompetent in my knowledge of cloud and IT. Exams like these, I think, might become more mainstream in certifying developers in my opinion. (Though whether this is desirable is another question.)
ElProlactin 11 hours ago [-]
The question is whether you then want there to be a legal licensing requirement that requires an individual to hold certification to work as a software developer.
dijit 4 hours ago [-]
Maybe treat it like other professions and have a specific title be protected?
blu3pr1n7 3 hours ago [-]
Is it really possible to do that? I think if we were to go down this avenue we would need to consider titles other than software engineer.
dijit 2 hours ago [-]
yes, it's possible. That's why there's no Software "Engineers" without degrees in Quebec.
sgarland 14 hours ago [-]
I, for one, am extremely happy that electricians and plumbers have to be licensed.
hattmall 12 hours ago [-]
Sure, but are you happy about the requirements of that licensing? Requirements that have continually expanded to require more "experience" over the years. I know in my state it was originally 1 year of experience or completion of a tech diploma and then you had to take the licensing exam. Now it is 5 years of experience and a diploma can count for one of those years. Which of course has pushed prices to insane levels.
Are you happy that the license is much less a license to do the work and much more of a license to hire unlicensed people to do all the work.
And lastly are you happy that private equity can "hire" the licensed professional to hire 100s more unlicensed people to run a huge company with a catchy slogan?
Eddy_Viscosity2 4 hours ago [-]
These are valid things to be unhappy about and should be corrected. But if the implication is 'licensing has issues so we'd be better off without' then I'm not on board. It reads like one of those 'if we can't have a 100% perfect solution, then we should do nothing' arguments. Licensing does have merits and I think currently they outweigh the drawbacks. If we can make licensing better by fixing some issues, then absolutely let's do that.
breezybottom 13 hours ago [-]
Milton Friedman was a libertarian crank. I'm a consumer and I'm quite happy that doctors and lawyers are licensed.
ElProlactin 11 hours ago [-]
You can have a regime that regulates who can practice medicine and law without having it run through private organizations that function like a cartel.
Terr_ 9 hours ago [-]
It's a little more-complicated in that one of the major bottlenecks comes not from the private organizations per se, but from Congress--though I wouldn't want to underestimate the effect of lobbying.
> In the Balanced Budget Act of 1997, Congress capped the number of residency positions that Medicare would fund at each teaching hospital at 1996 levels.
You can also buy from companies that hire licensed software engineers if you want to? The main thing that would stop people patronising licensed individuals is if there was no obvious skill gap between a licensed and unlicensed practitioner that justifies the price gap.
People don't need a government body to tell them to check for credentials. If people care they can ask (I had to give a copy of my degree certificate thingo to my employer a job or two ago, they cared that I was qualified). The whole and only point of mandating licensing is to raise prices for consumers.
EDIT
Just while I'm thinking about it, the law is expected to be easy enough for everyone to follow while simultaneously there is is an absurd legal fiction that only a licensed professional can talk sensibly about the law. It is internally inconsistent that lawyers would require a license.
jjmarr 17 minutes ago [-]
I'm getting work experience to become a licensed software engineer, which is possible in my jurisdiction (Ontario).
Rarely does anybody care. I heard it's useful for safety-critical stuff but have never met anyone who has made use of the designation.
breezybottom 2 hours ago [-]
That's the absurd libertarian logic. I'm supposed to be able to assess the credibility of whatever credentials I'm shown? Despite having no expertise in the field?
win311fwg 13 hours ago [-]
What advantage do you, the consumer, see to licensing over certification?
fauchletenerum 12 hours ago [-]
Liability for the professional that knows if they botch a job in horrendous fashion that they could lose the ability to continue practicing their profession.
win311fwg 12 hours ago [-]
What's the practical difference between that and certificate revocation? Maybe you can still technically do the job, but who is going to work with you when you are not certified?
But it's not certain you would even be able to continue to do the job if you botched things in a horrendous fashion. There is precedent for individuals being barred from working in certain industries if it is considered necessary to protect the public, even when those industries are unlicensed. Granted, it is rare and a lot more complicated than where licenses are found, but if you've botched things in a horrendous fashion anything is possible.
nullsanity 12 hours ago [-]
[dead]
wyclif 12 hours ago [-]
Au contraire, mon frere. Milton Friedman looks prophetic in 2026, especially his book "Free to Choose."
analog31 17 hours ago [-]
This is a "better watch what you ask for" situation.
Accountants and lawyers effectively controlled their customers. You can't use accounting or legal work for business purposes without those things coming from licensed practitioners. And they have no other use than to work with regulatory agencies (loosely speaking such as courts, IRS, etc).
If you lock down software development too hard, people will write their own. It's easier to hack something together that solves a specific problem than to write general purpose software that can be sold. And eventually the licensed programmers will break their own rules, for instance by using un-approved computers, languages, and development tools, in order to compete with software smuggled in from overseas.
Animats 13 hours ago [-]
> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."
I’m pretty sure that the IEEE tried that, and it never took off.
Regulatory bodies generally need a raison d’etre to exist (like people will die, or go to jail, if we screw up). They also need to provide clear benefits (to the licensees), like medical practice, or CPA licenses.
I don’t think that ever worked, for software. Companies have been hiring anyone that can spell “algorithm,” for a couple of decades, and making money, hand over fist.
In my case, I’m sort of grateful. I have no “on paper” qualifications (high school dropout, with a GED), yet managed to have a long career, working with some pretty heavy-duty pros.
nixon_why69 12 hours ago [-]
Ok, but consider if we had professionalized in, say, the late 90s.
Would we be insisting everyone writes bad 90s style OO code because that's the professional standard? How do you have standards when the field is still figuring itself out?
elmer2 1 hours ago [-]
It also changes every year or two. Plumbing, for instance, hasn't changed much in decades.
nixon_why69 39 minutes ago [-]
Have we solidified a little, though? I don't want to overindex on my particular biases given my particular age, but I feel like we ironed out the problems with object-oriented programming and reached a rough consensus about a functional/object-oriented hybrid where nobody likes too much inheritance.
Are we at a stable spot now or am I just overindexing on my personal understanding?
gizajob 9 hours ago [-]
“The good thing about standards is that there’s so many to choose from”.
WalterBright 19 hours ago [-]
> We never had any real body that could certify proficiency
Good!
> having to resort to leetcode and other such styles of interviewing
Such test filter out the obvious frauds.
tombert 15 hours ago [-]
> Such test filter out the obvious frauds.
I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have worked with plenty of incompetent people who managed to get past the leetcode challenge but are wholly unable to do anything useful involving software.
I feel like what leetcode primarily tests is "does this person know how to use a hashmap in a way that you shouldn't actually use it because you lose cache locality", and that's literally all they test.
WalterBright 12 hours ago [-]
You might be surprised at how incompetent some engineers are. They get filtered out with the leetcode test. Of course, it doesn't filter them all out, and that's why there's a followup interview round.
tombert 11 hours ago [-]
I have given dozens of interviews at big companies and small companies and medium companies so I am not speaking out of my ass. These leetcode tests are not good filters, nothing is “surprising” me.
Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for.
I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.
marcus_holmes 2 hours ago [-]
Agree 100%. The problem is that leetcode problems are nothing like the actual practice of writing commercial code. Writing good commercial code is about keeping things as simple as possible, as clean as possible, as readable as possible. Use libraries for the complex stuff, don't invent complex solutions. And, as you say, use standard data structures whenever possible. Don't optimise early. Don't fix performance bottlenecks unless you actually know they're causing a problem in production. And even then, throwing more hardware at the problem is often better than making the codebase more complex. None of this is anywhere near what leetcode tests.
The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
bdangubic 18 hours ago [-]
> Such test filter out the obvious frauds.
if you need garbage like leetcode to filter out "obvious frauds" you got a whole lot of problems in your company/team/...
WalterBright 18 hours ago [-]
A colleague of mine came to me for advice. He wanted one of those high dollar jobs at a well-known MegaCorp. He knew a leetcode test was used by them. I suggested that his top priority was to study the leetcode books for the next 3 weeks. I told him those three weeks would be the best ROI he'd ever make.
He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!
P.S. I'm curious what your test is for obvious frauds?
marcus_holmes 2 hours ago [-]
Let's assume that instead of leetcode, the company had decided that the qualifying test for programmers would be sketching a vase of flowers (about as relevant as leetcode for commercial programming).
Your friend would have spent three weeks practicing their sketching, right? And they would have made a decent drawing at the interview. And that would have the exact same ROI as spending those weeks on practicing leetcode.
The point is not that studying leetcode is good ROI. The point is that large orgs are testing for something that isn't relevant to commercial coding.
zzrrt 15 hours ago [-]
Doesn't this imply that, had your friend not taken your advice, he would have failed and thus been an "obvious fraud", but a mere 3 weeks transformed him from fraud to competent programmer?
WalterBright 12 hours ago [-]
The leetcode test is just a screening device. Passing it means you then go through the real interviews.
Also, if someone is unwilling to do the work to pass the leetcode test, they likely don't have the ambition to get the high pressure jobs.
zzrrt 11 hours ago [-]
If a good candidate can do it in 3 weeks, then a middling one can do it in 10 weeks, and a bad one in 6 months of memorizing. They all pass the screen, but two are lower-quality, and the bad candidate is about as much of a waste of the "real" interview as a total fraud would be.
If the bar is that low, just use an accredited degree, certification, references, or a proctored quiz with questions like "define a linked list in < 3 sentences," and it would be just as effective at filtering the very lowest, while more pleasant for everyone involved and maybe cheaper. Crammable puzzles that don't represent real software engineering don't provide much more value than those filters would.
sscaryterry 4 hours ago [-]
> they likely don't have the ambition to get the high pressure jobs.
What absolute drivel. I've done plenty of leetcodes. I don't care about writing a qsort algorithm, I know the trade-offs, unless you're working for a FAANG or FAANG-adjacent company, the need to write your own sorting algorithm implementation is probably zero or near zero.
watwut 6 hours ago [-]
As if these were high pressure jobs ... or had any rational reason to be high pressure jobs.
inigyou 15 hours ago [-]
No it means he fooled the interviewers
wyclif 12 hours ago [-]
I don't think he "fooled the interviewers." The point of the story is that he focussed down on what the company's culture decided was important.
zzrrt 12 hours ago [-]
That's the point we all see, but from context, the story teller apparently thought it shows that leetcode is an effective way to filter frauds.
WalterBright 12 hours ago [-]
And it is an effective way.
SoftTalker 12 hours ago [-]
It's like cramming for an exam. Yes you can get enough information in your short term memory to pass, even do well. But a year later (or a month) it's all gone. You never really knew it.
WalterBright 12 hours ago [-]
True, but it shows a willingness and ability to do the work.
rightbyte 9 hours ago [-]
Such recruiting selects for KPI hunters. It is probably bad for an org to select for people that game it rather than doing "what is right".
A dice throw and some chitchat would be better recruiting.
selcuka 14 hours ago [-]
I'm confused. Your example contradicts your point. How is it a good filter for fraud if it can be aced by only studying for 3 weeks?
WalterBright 12 hours ago [-]
The frauds and incompetents don't want to do the work.
tombert 11 hours ago [-]
All this proves is that BigCo puts a lot of value in these idiotic leetcode tests. It doesn’t imply at all that it gets rid of “obvious frauds”, and in fact seems to suggest the opposite given that someone was able to “ace” the test just by buying a book and studying it for three weeks.
timr 17 hours ago [-]
> He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!
...and everybody clapped?
I have news for you: passing an online leetcode is now so easy that an AI can do it. If you think you're catching the cheaters, you're just wrong.
Leetcode was always a stupid test of competence, but it was cheap and it had a high true-negative rate, which filtered the riff-raff. That isn't true anymore.
WalterBright 17 hours ago [-]
He went in for a monitored taking of the test.
timr 17 hours ago [-]
Sure, sure. So now we have the worst of all possible worlds: an expensive interview process where the candidate has to be onsite, and a stupid evaluation mechanism that doesn't at all reflect real-world job requirements. And in exchange for the inconvenience of an in-person interview, the candidate gets treated like a number and is met with a stupid memorization gauntlet that tests a skill that quite literally will never be used again now that we have AI. Sounds great.
Man, there are times when I really hate this industry.
bandrami 6 hours ago [-]
The only job application process I've ever walked out on in the middle of was 25 years ago, when I was taking a proctored computer skills test and it dinged me for pressing the Windows key rather than moving the cursor to the Start button and clicking it.
So this is a new presentation of an old problem, I guess is the takeaway there.
nocman 14 hours ago [-]
> an expensive interview process where the candidate has to be onsite
I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire (I mean, unless it is a remote job, and the person is nowhere near the employer, obvious exceptions would apply).
In-person interviewing can be extremely valuable. Will it filter out every bad candidate? No, some people excel at faking it. However it can be a big help in finding a good candidate.
timr 13 hours ago [-]
> I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire
Nobody said anything about not coming on site. That's how we used to do it, in the ancient pre-history of 2019. What I said was that if you bring someone on site only to leetcode them, you deserve not to hire anyone.
The downside, of course, is that you don't have the cheap, dumb pre-filter of a memorization test anymore, so you'll have to figure out a better way to winnow down the applicant pool whom you're willing to pay to bring on site.
Maybe finally software engineering will achieve a level of interview maturity seen in other professional fields...but I doubt it.
WalterBright 12 hours ago [-]
If you're willing to travel to be on site, you should be willing to study for the leetcode test.
eloisius 11 hours ago [-]
So if it’s just a shit-test to see if the applicant has enough grit to grind through an arbitrary filter, and not to measure their aptitude, why not use Minecraft or something? Come into our office and show us how long it takes you to kill the End Dragon.
DonHopkins 9 hours ago [-]
Factorio is a much better test of your design and programming and refectoring ability than Minecraft.
bdangubic 16 hours ago [-]
> Man, there are times when I really hate this industry.
Or as I'd like to call it - Wednesday :)
watwut 6 hours ago [-]
Your friend does not sound like an obvious fraud. He sounds like someone talented and capable of learning.
sscaryterry 5 hours ago [-]
Honestly this is purely because time is money. Its a blunt instrument that is surprisingly effective. Unfortunately, it also removes a fair amount of competent people too, that simply don't think/operate in a leetcode mindset.
leptons 18 hours ago [-]
I took an online technical interview recently where there was a check-box they made you click before every section, promising you would not use AI to solve the test for you.
After they rejected me I had to point out that their test is selecting for the cheaters.
WalterBright 18 hours ago [-]
I would view skeptically any testee who turned in a perfect score.
When you check in at the airport, the machine asks you to certify you are not carrying banned items. Of course, one wanting to break the law and carry banned items would certify it. The purpose is that if you get caught with the banned items, and you certified you did not, it's an extra charge they can paste you with.
inigyou 15 hours ago [-]
Once we carried dangerous (not banned) items and selected yes and the first action by the attendant was to come over and say we selected yes by mistake and she selected no for us
arcboii92 18 hours ago [-]
I've said "code was always the easy part" recently so I should probably explain where I'm coming from. I think the practice of software engineering includes that "understanding of the relationship between code, business, people and teams" you mention, which essentially boils down to the ability to skillfully design a system - regardless of whether it's a big cloud-based web application or a tiny cli tool for use within a team.
To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. Once all that is covered I generally have a good high-level mental map of a system's structure, and actually writing the code to bring those ideas to life truly is the easier part.
That being said, I still believe writing good code is a skill that is only learned through experience/the practice of actually writing code. And that experience is necessary for reviewing code - regardless of whether the code you're reviewing was written by humans or AI.
Kind of like baking. Putting it in the oven was always the easy part. But combining the right ingredients in the right ratios is necessary, and much more difficult than the putting-it-in-the-oven part. And even then, it takes experience to know when something needs to be pulled early or left in longer. Because ovens are non-deterministic.
timr 17 hours ago [-]
> To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance.
This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs...
Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available.
There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA.
[1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...
Terr_ 9 hours ago [-]
"Product Manager, your job is to find the mix of features which is fast and cheap and good, and then browbeat the Engineers into implementing them. Don't just parrot me their excuses, fix it!"
hn_throwaway_99 16 hours ago [-]
Sure, I'm not saying design is easy either, but even if you have detailed user requirements, a fully spec'ed out UI, and some general technical requirements, translating that to (working) code is still really, really difficult.
I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code.
Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.
mrheosuper 13 hours ago [-]
"Talk is cheap, show me the code" - Linus
skydhash 14 hours ago [-]
> Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part
Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two.
People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.
sgarland 14 hours ago [-]
Your analogy to baking makes no sense. At best, compiling would be like putting a cake in the oven. Making the cake is coding.
> ovens are non-deterministic
Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.
sky2224 9 hours ago [-]
> Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit)
Whenever I've used this phrase or seen other people use this phrase it's never been in the context of software engineering. It's always been in the context of literally just spitting out code that a compiler will accept. Believe it or not, a lot of students in CS cohorts have significant struggles fighting the compiler because they just don't understand the language they're programming in and are slow to become proficient (if they ever do). Thus, a lot of people have this idea that writing code, and I mean literally just spitting out something that compiles and runs is hard.
Doing that is indeed quite easy today. That's what we mean by "coding was always the easy part".
Writing code that actually scales into something bigger and is constructed in a way that meets requirements and is flexible? That's a whole different ball game. That's software engineering.
sirsinsalot 18 hours ago [-]
Four MONTHS?!
Most of the dolts I interviewed in the UK had a 6 week bootcamp behind them and called themselves "JavaScript Experts". No joke.
scorpioxy 14 hours ago [-]
I was once commissioned to teach such a "bootcamp". It was a 4-months duration but 1 day a week. So something like 2-4 weeks total duration. I found out that the students were promised that this was enough to get them a job doing software development and were disappointed when I told them it wasn't. So towards the end, I took some time to explain what was missing and why it will take MUCH longer to even just learn the basics. The organizers were not happy at all that I did that.
To be fair, there were a bunch of students that did listen and worked hard on their assignments and projects and went on to integrate what they learned into their chosen profession and progressed in their jobs. I was very proud of that bunch.
Surprisingly, I wasn't asked by the organizers to teach again. It also didn't help that midway I was asked to switch from teaching web development to machine learning and they didn't really like it when I said "but those are two very different things".
eru 12 hours ago [-]
> Practically every other job I can think of at a similar salary level has entrance requirements (e.g. grad school admissions exams), extensive and expensive training, a lengthy apprenticeship period and follow on licensure exams.
It's the great strength of software engineering as a profession that formal barriers to entry are so low.
You are right that good engineering is hard, and many people who went to these bootcamps didn't make it. But that doesn't mean we need more bureaucracy and paperwork to keep people out.
ChrisMarshallNY 14 hours ago [-]
My experience:
You can learn a new language, in a couple of weeks, if you’re experienced.
But you’re gonna have a heavy accent.
Learning the language without an accent, takes years, no matter how good you are.
There’s always stories of apocryphal John Henry types, but I’ve never actually met one, and I’ve worked with some pretty sharp characters.
wiseowise 12 hours ago [-]
> Like what other profession markets themselves as "Hey, our job is so easy that any schmuck off the street can enter the career with 4 months of training."
Any profession with scammers, con artists, and snake-oil sellers?
vrighter 9 hours ago [-]
I use a variation of it. "Typing the code in was never the hard part. The work is in figuring out what you want to describe"
cm11 11 hours ago [-]
It might generalize to tech rather just engineering. The same pitch was made for marketing and SEO roles, designers, product managers to varying degrees.
everfrustrated 18 hours ago [-]
A large amount of programmers are hired just building crud apps. Display data from a database and write it back with a validation. Etc.
There is very little innovation going on. And most companies do everything they can to stick to standard patterns, technologies etc where all the risk is removed and known in advance.
Often "good" programmers are worse - they over complicate the architecture, go off on tangents, try to solve problems the business didn't ask for either etc.
So bootcamps filled a need.
sscaryterry 5 hours ago [-]
> they over complicate the architecture, go off on tangents, try to solve problems the business didn't ask for either etc.
because they've been bitten plenty times before by business telling them that certain requirements are not needed, just to be told 2 weeks later that they are...
beardbandit 14 hours ago [-]
Out of every single reason given for why the bootcamp era was justified the only one I believe is that there was so much focus on it because bigger players wanted to flood the market with cheap supply and drive salaries downward.
This is not any different with offshoring before, and AI now.
eru 12 hours ago [-]
You say it like it's a bad thing.
operatingthetan 11 hours ago [-]
True, and the explanations about "solving big problems" are each engineer's personal brand and justification for having a job. I'm sure some of those people exist, but they probably aren't the ones doing it rote on forums.
tayo42 20 hours ago [-]
Good code apparent doesn't matter. Most software doesn't have real repurcussions for being bad. You just get a shittier oncall which doesn't seem to matter to some people
imtringued 19 hours ago [-]
The people who have to fix the mess and the people who created it are two different groups of people.
TeMPOraL 18 hours ago [-]
And both are well compensated for their work.
hattmall 12 hours ago [-]
A shit load of jobs could be taught to a useful level with a 4 month bootcamp. It's just that it's very easy to set up, scale, and monitor results for coding. It's the same with AI, AI isn't particularly good at coding compared to how good it could be at other tasks. It's just that by nature coding is easy to iterate, test, and verify. I've certainly seen AI produce impressive code that works but the actual quality of the code is abysmal.
win311fwg 13 hours ago [-]
> The whole "learn to code" and software bootcamp craze always baffled me.
Why? While the rest of your comment explains why the plan failed, it seems like it should be pretty obvious why business would try to attract an increased supply. Hint: It puts downward pressure on price. Same reason they are trying again with AI.
> every other job I can think of at a similar salary level has entrance requirements'
Yes, the artificial restrictions on supply is how those careers have similar salaries. Other occupations moved to have restrictions so that they could have high salaries. Software never felt the need to do the same because the natural market propped up salaries just the same, but we'll see how long that lasts now before software practitioners panic and clammer for restrictions to prop salaries back up like the others. AI does actually seem to be making inroads where "learn to code" failed.
Granted, like as suggested at the top of this, the upper class of software engineers who have the necessary reputation and prestige to drive software towards being a licensed profession are not feeling the same pinch that the middle class is feeling, so that is going to make it hard to see restrictions come to fruition even now. When the upper class of software engineers start becoming afraid of shrinking incomes, that's when software engineering will start needing a license.
eru 12 hours ago [-]
> Hint: It puts downward pressure on price. Same reason they are trying again with AI.
You say it like it's a bad thing.
About occupational licensing for software: it's also a uniquely global market, so I'm not sure how any one economy moving ahead with occupational licensing would work, unless they also restricted what software you can import or use in the cloud.
disgruntledphd2 5 hours ago [-]
> About occupational licensing for software: it's also a uniquely global market, so I'm not sure how any one economy moving ahead with occupational licensing would work, unless they also restricted what software you can import or use in the cloud.
Relatively easily, tbh. Just create a regulation that requires either the country's standards or equivalent ones to be used in the creation of any software sold to people/businesses in the country/region.
win311fwg 2 hours ago [-]
> You say it like it's a bad thing.
What to you suggests it is said as a bad thing? It reads neutrally to me.
jorblumesea 17 hours ago [-]
the people with the hiring and budget aren't technical people, usually are not engineers or have that background, and are incentivized to cut costs. It's not that complex, good engineering is expensive and somewhat of a cost center.
It's the same behavior around consulting firms, code boot camps, and now AI.
mrguyorama 20 hours ago [-]
I mean, the obvious thing is that the "learn to code quick, code bootcamps!" drive was driven by connected people who were, as they are now, attempting to drive down the cost of software development.
Management types really really really loathe software developers for making good money, and have spent decades now jumping at any advertisement that suggests it can undercut the salary of your current crop of engineers.
Devaluing software developers has always been the point. Whether you take the cynical view of "They resent us for being expensive" or the apathetic view of "Capitalism simply wants to eliminate any and every cost by definition"
bornfreddy 19 hours ago [-]
Exactly this. And now it is AI - I can't wait to see what they will be paying in a few years to those who will be able to clean up the LLM mess.
WalterBright 19 hours ago [-]
> Management types really really really loathe software developers for making good money
Of course. I bet you loathe having to spend $70,000 to buy a nice car, too!
> Capitalism simply wants to eliminate any and every cost by definition
You could look up what life was like under Soviet communism. Me, I prefer capitalism.
rayiner 17 hours ago [-]
The irony is that Soviets are famous for falling behind in computing because their 5 year plans failed to appreciate the importance.
leonidasrup 2 hours ago [-]
And yet the Chinese with their 5 year plans are not falling behind in computing.
Advances in computing can not be pinned just to planned economy/capitalist economy. For example the West Germany computer industry, French computer industry, UK computer industry (with exception of ARM), Japanese computer industry have fallen behind.
eudamoniac 19 hours ago [-]
It's called suicidal empathy. It manifests in many domains.
e2le 20 hours ago [-]
> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.
Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a licence that can be revoked at any time. Additionally, legislation could be written to require such licensed individuals in safety critical roles.
I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a licence.
If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.
The problem with making programming a regulated profession is who gets to define the regulations. You are probably imagining that it would be expert developers with a track record of success. I would bet on it being the people who write lots of blog posts and books about programming and give lots of conference keynotes - whether or not those people have any evidence base to support their advocated policies or any personal track record of delivering good software.
inigyou 15 hours ago [-]
Once I was talking about a video game and mentioned a global variable holding a reference to the player character and got the eyes wide open horrified look.
Those people would be writing the regulations.
lilbigdoot 7 hours ago [-]
I am a FP nerd and I approve this message
e2le 20 hours ago [-]
> You are probably imagining that it would be expert developers with a track record of success.
I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.
> who write lots of blog posts and books about programming and give lots of conference keynotes
I do not think people who write blog posts and give conference keynotes should be awarded with roles that regulate the profession because they write blog posts and give keynotes. I would hope that any regulation is evidence driven.
rayiner 17 hours ago [-]
> I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.
Licensing organizations disproportionately attract people who enjoy "administrating" over "doing."
9cb14c1ec0 15 hours ago [-]
Other those who prioritize profits over providing good customer service.
rayiner 15 hours ago [-]
People who enjoy administrating rarely think you’re the “customer” lol.
amoss 8 hours ago [-]
What you have to remember is that the people who decide who to appoint into these roles are another step removed from the problem domain. They will have no programming experience, or the ability to evaluate programming experience. They will try and rely on metrics or some "data-driven" approach to deciding who to appoint.
What kind of data will they look towards? Here, we have a precedent from frantically points to absolutely everywhere around us. So the people with "engagement" and "reputation", i.e. they gushed on their blog and farmed engagement, will be exactly who gets appointed to make the decisions.
NateEag 19 hours ago [-]
> I would hope that any regulation is evidence driven.
Have you found existing regulation in any field that's evidence-driven?
My impression is that regulation is not made in a way that has much to do with evidence, but I would be delighted to be shown evidence I'm wrong.
decimalenough 19 hours ago [-]
Aviation comes to mind. Most aviation regulations exist because people died.
It's hardly a perfect system, but the problem is mostly that it's too conservative and risk aware, making it difficult to impossible to innovate and ignoring the risk this creates. (The world's most popular light aircraft is the 1950s-vintage Cessna 172, mostly because it's impossibly slow and costly to get a reasonably priced modern competitor certified.)
NateEag 16 hours ago [-]
Thank you for the data point. I guess I had overlooked that.
unknownfuture 13 hours ago [-]
Have you never heard the adage that regulations are written in blood?
Plenty of regulations in many many fields are evidence based.
Sure, many are not.
But to make such a blanket statement is absurd.
akiselev 19 hours ago [-]
The important part of the professional certification like PE or MD is the liability that comes with it, which means that the professional has a lot more agency. A construction firm or hospital can't really force their professionals to do anything because the consequence is criminal prosecution (and a lot of legal liability for the employer).
Bring a software engineer into a courtroom as an expert witness, and the jury's eyes will glaze over. Bring in the PE who told their firm not to cut that corner, and the hammer comes down hard.
Even if the certification for software engineers starts as barebones as knowing what WASP is, it still provides an avenue for the feedback mechanism to work (the rules "written in blood"), so that the entire industry can study and learn from what happened, instead of this mess we have now, the peak of which is postmortem blog posts. Even now we have plenty of examples of regulatory frameworks where the regulations adapt to the field like the FDA where you've got a huge spectrum ranging from diagnostics to medical devices of which where are many classes, and drugs where every clinical trial can be tailored to the exact nature of the disease.
Silhouette 18 hours ago [-]
I have been a professional software developer for decades and worked in several roles where quality and security were at a premium but I have no idea what you mean by WASP. And yet you described it as "barebones" - an interesting illustration of the problem here. Real engineers have many years seeing the hard way what actually works. In software we don't have that kind of consistency and shared understanding of how to reliably get good results yet.
coderenegade 17 hours ago [-]
In my experience, good software engineers are often better "engineers" than those working in more physical disciplines, because they get a lot more practice. But traditional engineers have a far better culture when it comes to testing and validation. Since the cycle time is longer, and the cost of mistakes is higher, analysis and testing are generally baked in from the beginning. In software, it's easier to skip that stuff. But software engineers who do get indoctrinated into that culture learn most of the same lessons that traditional engineers do (i.e. how can a component be tested and maintained? what makes for a good design?) and the speed of development means they get more exposure to those types of challenges in general.
Silhouette 17 hours ago [-]
In my experience this works both ways too. Good engineers working on physical projects have picked up on some of the useful practices that good software developers have adopted for maintaining progress in the face of ambiguous requirements until they can be clarified and allowing as much flexibility as possible without necessarily compromising quality in the meantime. I believe these relationships can be summarised as something like "Good people keep open minds and learn from what has worked well for others".
The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?
In physical engineering disciplines there are often clearly evident problems if something was built without being adequately specified by the responsible engineers. In a disastrous case a bridge might literally fall down but you're also going to see that a bridge wasn't designed properly if it's distorting in ways it shouldn't under loads that it should be able to support. There are lots of experienced engineers who have proven records specifying buildings or planes or ships that need to not break using established and peer reviewed techniques.
In software we can all agree catastrophic failures that result in loss of life or half the Internet going down are obviously bad. For something controlling a life-saving medical device or the launch authorisation system for the nuclear missiles we can probably all agree that the answer to what quality level we want in the software is "the best quality we can achieve". But those systems have unusually serious consequences if anything ever goes wrong and probably also very high development budgets that can justify such an extreme position on quality. In general we don't have clearly defined levels of software where different trade-offs between cost and risks and other factors might be considered reasonable and acceptable. Nor do we have well tested and universally accepted standards for how to reliably achieve a specified quality level.
akiselev 17 hours ago [-]
> The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?
There is zero useful evidence because there is no one to collect it.
The Institution of Civil Engineers was founded in 1818, after decades of random civil engineering societies in Britain doing the exact same thing we are now (running around like chickens with their heads cut off). It wasn't until after the ICE's Royal Charter a decade later that civil engineering began to get really systematized into the "real engineering" we know today and that charter effectively established them as a regulatory body that allowed that to happen.
Silhouette 17 hours ago [-]
There is zero useful evidence because there is no one to collect it.
I'm not sure that is entirely true. There have certainly been a few people who have attempted to study what did or didn't work in industrial settings - either pure academics or people working in industrial research labs. But I agree that currently we have nowhere near enough data to form robust conclusions about almost anything in this field and I think this is the strongest argument that the industry is not ready for any kind of licensing and regulation regime.
nick__m 14 hours ago [-]
Wasp the defunct PL group from washington.edu or wasp as in owasp or something else entirely?
WalterBright 18 hours ago [-]
> software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers.
My experience with civil engineers and lawyers is many of them aren't worth spit. Licensing is not a magical cert that proves competence.
BTW, if you hire a lawyer in WA state, be sure to ask if they passed the bar. The state has been licensing lawyers who don't pass it.
cucumber3732842 17 hours ago [-]
Competence is tangential. They're happy to allow the idiots, so long as they aren't so stupid it makes the organization or the government look bad.
The way licensing fundamentally works is industry basically strikes a bargain with government to it's benefit. Government lets the licensing organization run a supply cartel and collect protection money (dues, test fees, whatever) so long as they promise to enforce (low) minimum standards along the way. Government gives licensees favorable treatment in court (statutory limits to liability, licensed professionals opinions are more equal than average peasants, etc, etc), etc. And all this stands so long as they do whatever the government's rules say (to the detriment of the customers). And of course the professionals make money hand over fist (or at least more than they're worth) in the process because the licensing organization constrains supply.
Society gets just enough scraps to provide the political will to get it done and keep it rolling (the low minimum standards).
coderenegade 18 hours ago [-]
It's probably worth distinguishing software engineering from the ability to program. Programming is a skill that is similar to reading and writing in that it's a type of literacy, and it shares a common theme with literacy in that even though most of us can read and write, not everyone is good at it. Professions that leverage that unit of literacy build on top of it, and take literacy as a given.
For instance, a lawyer spends most of their time reading and writing, but no one would ever say "you can read and write? Have a crack on our legal team". It's a particular type of writing, and the writing is really a means to an end. This is a distinction that is lost in software development. Every engineering discipline now learns programming, but the ability to write code shouldn't be a license to write software in the same way that knowing how to read and write doesn't just grant you the ability to join a legal team and start writing contracts.
groundzeros2015 20 hours ago [-]
Credentialing lowers the skill floor and increase every other kind of friction.
Civil engineering or medicine is hardly a desirable career model to follow.
Btw doctors make mistakes that kill people all the time. It’s a top 3 cause of death in the US AND they often keep their jobs.
toss1 18 hours ago [-]
>>doctors make mistakes that kill people all the time
Yes, but they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.
The standard is not perfection; the standard is as good as practical and better than if nothing were done. Medical licensing definitely meets both of those criteria. Unless you are arguing that anyone who takes a ten-week "Medical Bootcamp" is ready to be a surgeon you would trust to operate on you or your children?
Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
You have it exactly backwards — Credentialing RAISES the skill floor. It does not raise it to perfection, and "Certificates" in the computing industry are a joke, but real medical or engineering credentials certainly raise the floor higher than the software floor
groundzeros2015 18 hours ago [-]
> they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.
I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.
Milton Friedman wrote a PhD dissertation on the topic of medicine that I invite you to take a look at.
> than if nothing were done.
The alternative is not to invite people who have no experience to build bridges or perform surgeries.
There are no credentials to work at Google. But you’ll find very skilled and capable people running large projects.
Investors want capable people. Those people are vetted through their reputation in their professional circles.
> Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
No. But I would like to drive over bridges from people with 30 years of bridge building experience over a 4-7 year degree.
If you live in Europe you drive over bridges built without credentials all the time.
> Credentialing RAISES the skill floor.
Correct. That’s my mistake.
The point is if cut off the bottom 20th percentile the field doesn’t get much better. Those people aren’t trusted leaders anyway.
You do however lose a significant amount of upside. Including countless top performers from non traditional backgrounds, which is characteristic of computer hackers.
You can maybe argue that the general public, unlike a corporation is not capable of vetting their own doctor, so the government classified those options for them. And that’s reasonable. But that does not apply at all to software engineers who don’t solicit public work.
I have all the traditional credentials and this is not a projection of my own career.
cbsmith 10 hours ago [-]
> I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.
The medical boards are well aware of this, which is why the standards are far more than just about having more schooling.
I am familiar with Friendman's dissertation, and while the economic claims it makes are solid, it isn't a take down about the medical impact of the boards. It really doesn't say one thing or another about them. Let's put it this way: if you are going to inflate the cost of a service, it's hard if the quality of the service is terrible and easily replicated by someone else.
Silhouette 18 hours ago [-]
I appreciate your positivity. However it is difficult to reconcile your argument with the reality that executives at tech companies frequently behave in ways that satisfy the investors but clearly do not produce good results for the people using their technology. Indeed in numerous cases today the technology is openly hostile to its own users' interests. The regulations are there to protect the users (or customers or clients or patients). If anything they are there to prevent protecting the profit margins of the businesses - because hiring people to pump up the profits is often in conflict with the other objective.
groundzeros2015 17 hours ago [-]
What would credentialing software engineers do to curtail leadership incentive problems?
Hardware technology jobs have some of these credentials and are part of that system.
Silhouette 17 hours ago [-]
What would credentialing software engineers do to curtail leadership incentive problems?
The same as in other regulated professions. It would give the people on the front line who can see the consequences of the corner cutting an effective right to say "No, we're not doing this user hostile thing". This would be a significant barrier because it wouldn't be legal to ship software without the required professional approval and the professionals would be heavily incentivised not to sign off any corner cutting because they would be personally and professionally responsible for any adverse consequences if they did.
groundzeros2015 16 hours ago [-]
That’s not how these systems work in reality. I’m actually an extreme pessimist.
What actually happens is that you as an engineer become paid to frame the desired leadership goals in compliant terms.
It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.
This skill among engineers is highly sought after in large companies with political organizations and greater encouraging it changes the composition of the workforce.
Top civil engineers don’t design buildings.
disgruntledphd2 5 hours ago [-]
> It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.
This is true, and basically what tends to happen is that if the Head of some compliance function (e.g. internal audit) is causing problems for the business, then they are replaced with someone who won't cause such problems.
It's still better than nothing. Like, software basically runs our society now, so either software professionals get together on this, or regulations will be imposed on us, and they will be much worse than what we'd get in the first option.
Silhouette 14 hours ago [-]
In the physical engineering teams I've worked with the culture you just described is not what happens at all. There are always some people who seemingly live to circumvent the intention of rules lurking around the edges of regulated industries. But my own experience has been that real engineers very much value real engineering - it's often why they got into the field in the first place - and will push back hard against and if necessary refuse to sign off anything they consider inappropriate for the job. They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.
disgruntledphd2 5 hours ago [-]
> They won't be impressed at all by someone's big title and even bigger budget while they're exercising that professional judgement either. Some of these people have had pretty stellar careers so I think it's safe to say their professional conduct hasn't damaged them with their employers or clients.
It really depends on the status of the profession in society and the company. I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.
toss1 16 hours ago [-]
More credentialing and requirements would do plenty to curtail leadership incentive problems. First, as the sibling points out, it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order — "I'm not going to lose my license for that stupid idea", and a serious incentive to do so, as well as solid job prospects if he does get canned for it (because there's a limited pool of credentialed engineers).
You glibly say "More schooling does not mean more trustworthy or careful doctors.". Yet the schooling and credentialing clearly cuts off huge numbers of would-be doctors who never pass the exams, never graduate med school, or never even get into med school, or decide it is too difficult in the first place. In the software realm, those people just go to some boot camp and they're off to the races...
Another huge aspect of credentialing is required ongoing education, which REQUIRES physicians and engineers to take updated continuing education just to maintain their license. This again continuously improves the talent pool.
And, if your main concern is that they be "more trustworthy or careful", credentialing also helps that by finding the worst, least trustworthy and careful and cancelling their license, so they are NOT doctors anymore. The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere, probably taking one from the actual good engineer because their talent is not engineering, but bullshitting.
groundzeros2015 16 hours ago [-]
> it gives the licensed engineer a solid ground to stand on when refusing a stupid leadership order
I disagree to the extent to which this is real leverage. It changes the language and approach, but not the outcome, Ask a civil engineer the degree to which they can fight their leadership on these grounds.
> clearly cuts off huge numbers of would-be doctors who never pass the exams
Yes the fallacy is that more exclusive is better. You don’t understand the traits you select for.
> those people just go to some boot camp and they're off to the races
I don’t see any kids who just got off a boot camp running large software projects. Does this happen at your workplace? Why not?
> This again continuously improves the talent pool.
I just disagree to the extent to which the talent actually increases.
The people who excel already learn and study all time.
This slightly raises the floor by forcing the least curious person to be exposed to some PowerPoints and videos.
> The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere
They can only ruin the extent of responsibility and scope given to a new hire with no reputation.
> least trustworthy and careful and cancelling their license
Once again you assume the system works as stated. I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
The image that comes to mind is someone who made a mistake, cares a ton about medicine, and hates the organizational administration.
toss1 12 hours ago [-]
Wow you have a relentlessly unrealistic view of things.
>>Ask a civil engineer the degree to which they can fight their leadership on these grounds.
Both civil engineers and doctors both can and absolutely do refuse to sign off on unsafe situations.
That does not mean they detect them 100% of the time, or never cave to pressure, but they absolutely do. We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action — precisely because nothing newsworthy happened. We DO hear about the ones that did happen, Therac-25, Mars Climate Orbiter loss, Cloudflare outage, it is endless
>>I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
You might think that, but clearly you have never read even the summaries of cases where doctors lost their licenses. Hint: it was not some mistake that could have been covered up by better schmoozing. If anything, the system is too lenient.
The rest isn't even worth the bytes to respond; just handwaving an attitude. There are very good arguments to not have licensing on software engineering but you are not making them
dolni 18 hours ago [-]
> The alternative is not to invite people who have no experience to build bridges or perform surgeries.
You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.
Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.
Sometimes they slip through the cracks for a variety of reasons.
groundzeros2015 18 hours ago [-]
Cold call job interviews are primarily for people early in their career to get established in the field. You don’t hire someone that way to lead the Golden Gate Bridge.
How do you think companies hire for key roles like CEOs?
stronglikedan 20 hours ago [-]
> software engineering aught to be a licensed profession
Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.
wing-_-nuts 20 hours ago [-]
It's not licensed per se, but in certain areas of the defense industry, one is restricted to using the 'DOD approved' subset of C++. Coders that know how to be productive within those constraints (and can pass clearance) are much more rare than your average code monkey
f6v 20 hours ago [-]
Some pieces of software are classified as a "medical device" and require certain processes to be in place.
mcmcmc 17 hours ago [-]
I think a more effective way of enforcing the licensing would be adding a cyber insurance requirement to sell software or internet services commercially to some threshold of users. Insurers could give a prime rate to licensed developers and offer a service to have their own engineers certify software from firms without credentials for a higher rate.
Direct licensing requirements from the state are prone to abuse via regulatory capture. Big or entrenched players can give to politicians who’ll change the rules in their favor, setting who needs a license and who can get one.
The profit maximizing incentive for insurance is a double edged sword, but if there’s a government backed insurer that just does the prime rate for licensed developers, the commercial market can build off that and fill in the gaps.
If you need a special license and insurance to drive a commercial truck on public roadways, why not the same for commercial traffic on the public internet? A good way to drive adoption from nontechnical folks could be something like the lock icon in the browser for TLS. Issue a domain cert for certified software, you can go to their website and confirm they are compliant right away. People are free to publish and use non-certified apps, they just won’t unless they have a reason to trust them.
CM30 6 hours ago [-]
Eh, I've never been a fan of licensing simply because software engineering is a vast field with huge differences in the impact your work might have.
Like sure, if you're writing software for medical professionals, or lawyers, or aviation companies then I can see that being something you'd want people licensed for. A major bug in a pacemaker or plane's autopilot system is a huge deal that could injure or kill a lot of people.
At the same time though, a lot of software engineering/programming work is extremely low stakes, and I think expecting that to be licensed would be kinda ridiculous. Having someone need to be licensed to create a small business WordPress site, or local desktop software to solve a personal need, or most video games in general feels kind of absurd. Do people need to be licensed to make say, Minecraft mods or hack a game from the 80s?
The difference with the legal and medical industry is that if someone is incompetent or screws up in those fields, there are almost certainly going to be negative, if not dire consequences for those involved. If someone screws up in tech, then there may be dire consequences in some industries/sub-fields, or no/positive consequences in others.
nocman 14 hours ago [-]
Licensing is not a substitute for hiring competent people that actually care about the quality of their work, and then giving them the time, resources, and support they actually need to do it.
Government involvement almost always just makes the problem worse, not better. There is a place for control in some areas (medical, military applications, etc), but I think broad-sweeping regulation would do far more damage than good.
singpolyma3 19 hours ago [-]
This sounds like a terrible idea. Do people need license to draw a picture or write a song? Why would we restrict other creative work in this way?
andrewflnr 18 hours ago [-]
People doing "mechanical engineering" in their garage don't need licenses either. I don't love the licensing idea either, but that's not a good argument.
Barrin92 19 hours ago [-]
>Why would we restrict other creative work in this way?
Because it isn't creative work. Software underpins payment processors, medical services, emergency alerts, infrastructure. In the UK not long ago a ransomware attack took the healthcare system offline and surgeries had to be postponed. in 2021 the Colonial Pipeline attack took 50% of the US East Coast's oil supply offline. The entire German train system died a few weeks ago for half a day because of a software bug.
People's entire communication is in digital services, all of their private data, the economy grinds to a halt or national security is impacted monthly now by either deliberate attacks or just bugs.
singpolyma3 16 hours ago [-]
Then license healthcare systems, payment processors, etc. Not humans
Barrin92 16 hours ago [-]
you license both. When you go in for surgery your hospital is accredited and the surgeon who operates on you is licensed. I don't even understand what you're trying to argue, you're okay with being operated on by a guy they found on craigslist as long as the hospital has a license? We should bridges let bridges be built by engineers who took a few courses on Khan Academy?
Of course professionals themselves need to be licensed, how else is any company supposed to have any confidence in who they employ or any legal security?
singpolyma3 14 hours ago [-]
We weren't talking about doctors, but about coders writing utility apps being a different thing than payment processors
18 hours ago [-]
noduerme 9 hours ago [-]
One thing is for certain... the "learn to code" movement was a smug, pompous, and deeply unsympathetic response by privileged knowledge workers toward blue collar workers who experienced mass unemployment a couple times in the last decade, beginning in 2008, and it really pissed off a lot of the people it was directed at. I know a lot of people who did move out of trade and service jobs and learn to code, but very very few who made it far enough to keep those jobs. The guys in the trades are having the last laugh now, and there's no sympathy for coders whose jobs are being taken by AI... largely as a result of the attutide that came with that prescription.
ofjcihen 9 hours ago [-]
I have yet to know anyone who’s lost their job to AI. On the contrary, because juniors are being hired less, the ladder on a well-paying job in knowledge work is essentially being pulled up (by the Csuite mind you).
So unfortunately, for those like me who spent a decade in the trades, saw that it could destroy your body by your 40s and decided I’d like to not have that happen to me the number of exits into knowledge work is shrinking.
noduerme 8 hours ago [-]
Not to sound bleak, but you're describing what things looked like to me 18 months ago. The C-suite's gonna keep pulling that ladder up until the loss of layers of knowledge come back to bite them in the ass in six years. If it ever does.
I'm not the best person to talk to, because I'm not a salaried programmer for some corporation, and I'm not looking for a job from a startup or something. I'm in a unique position where I wrote a suite of proprietary software that clients pay for that they would have a hard time replicating or migrating away from, even if AI helped them. Lucky me, I happened to get into a specialized industry and start writing code for it 20 years ago, and I kept all the data and code logic in my own silos and never shared anything with anyone. So I am somewhat protected because it would cost 3x more to replace what I wrote than to just pay me for the rest of my life to maintain what I built.
By the way, I started this software in my 20s when my body was already being destroyed by physical jobs. I started it while I was driving a taxi and waiting tables at the same time. I learned by reading books in my cab. I don't think that's an option for people anymore.
My best friend worked for a massive multinational similar to Salesforce and he ran a team of 60 people under him until last year. He was not AI-proof. They laid off everyone on his team except for him and 3 helpers, and told him to use AI to do everything else. After awhile, they laid him off too. After interviewing for a couple months, he found a new job, and his job is to manage two people running AIs. It was a 30% pay cut and he feels lucky to have it.
Under any external hierarchy, where I didn't have this lifetime of private code and clients in my pocket, his job would have been way, way above mine. I would have been one of the 60 people laid off.
Okay, so I'm going to say something about this "knowledge work" thing because I've known a lot of people who took courses and transitioned to it from the trades. Almost all of them did not get decent jobs. One of them was a bartender who just somehow got it. This was around 2018. Her husband works in construction. She just sat down and it clicked, she learned to write javascript in 3 months. I'd sit at her bar and tell her what to improve and she'd write it down and memorize it. In six months she was writing like a native, and she got a job at [huge multinational retail company] working on their website. And somehow she survived round after round of layoffs to keep going and become the only person left on her team. I'm immensely proud of her. And she will still probably lose her job in the next six months.
But my ex-girlfriend tried to learn to code at exactly the same time, and it went nowhere. Just didn't make sense to her.
So that's why I wouldn't recommend it. Honestly, if I didn't have the little pile of code I was sitting on that pays my bills, I would go to school to be a plumber or air conditioning specialist, or to repair helicopters or be a car mechanic. That's basically what I do anyway, I just do it in code instead of parts. At one time, what I did was equivalent to building custom cars and engines, only in code. At this point, fixing a car would be more satisfying. No one's paying to build their hot rod in code anymore, that's all being thrown at AI. And the rest of the jobs suck.
abustamam 18 hours ago [-]
I'm a bootcamp graduate, 10 years of experience. My mentor is a bootcamp graduate. I've worked with him for most of my career and he is a very experienced systems engineer, often mentoring and coaching folks with masters degrees in CS. Together, with a lot of other team members of course, with him being the principal engineer, we've exited multiple companies. We were both fortunate to have mentors earlier in our careers.
I've interviewed many bootcamp graduates. You're right. Many of them can't do the job. We don't hire those guys. But that begs the question - what companies are hiring incompetent people?
monksy 12 hours ago [-]
> whole "Learn to Code" push of the 2010s was one of the worst things that happened to our industry
I would also throw in the toxic positivity and gas lighting sorrounding that. We got a lot of churn on "we have to be nice to everyone" and fears that people weren't "being included." I'm not saying you have to go all Linus on everyone, but it really catered to those who didn't want to learn a lot of the details or were resistent to testing their own code.
mancerayder 12 hours ago [-]
I've uncovered some -2x engineers recently - who cause long-term problems with their changes that more than one person has to unravel. It's usually comes as a surprise, some going back to look at who approved MRs, and loud ranting and cursing as you find a murder trail of laziness or incompetence. It's breathtaking. I'd trust some people with AI as much as I'd trust myself operating a machete - a tool best left to someone else.
oraphalous 18 hours ago [-]
Learn to code wasn't just about careers though. It was also about individual empowerment. Everything goes through computers, and having the power to understand that domain increases agency.
For a lot of people, they have no need to ship production grade software that scales to babel. But a custom script that solves an immediate business need is a common thing.
I think that aim is more important than the harm learn to code might have caused our profession. And for similar reasons, I feel the agency AI brings to individuals is something that shouldn't be discounted either. No idea what the total calculus on cost benefits turns out to be, but I would hope this benefit is not missed.
analog31 13 hours ago [-]
"Programming is too important to be left to the programmers." -- apologies to Clemenceau
analog31 18 hours ago [-]
There was a time before "learn to code" when it was even more wide open. My mom taught programming at a community college in the early 80s, after learning it herself a year prior. Many of her students were working manufacturing or clerical jobs. They were able to get programming jobs at Ford's or GM after a year of my mom's class. (At first, they taught PL/1 because it was what they used at Ford's, then switched to Pascal in line with the colleges in the area). My mom did try to teach good practices, but there's only so much you can do in a year.
At my workplace, the earliest programmers were a combination of self-taught and people with real CS degrees. The CS people wrote the OS and languages for an in house minicomputer. The apps were written by people with app experience, mostly scientists. And there were a few odd characters like the secretary who learned programming because it was quicker to fix bugs herself than get clarification from the engineers.
BatteryMountain 6 hours ago [-]
I've seen a lot of Wordpress theme jockies in my country call themselves engineers and demand very high fees.. yet half of them do not know how the db works, when/how/when not to use queues, do not care about security ("the client will pay us to upgrade the site to be more secure"), do not know anything about real compilers, type safety etc. In my mind they were a scourge because we are not at the same level at all yet some of them earned more money/status than my peers. Some cases they have caused harm but nothing ever happened to them. So yeah, good the frog is being boiled now. Same with consultancies. They've been milking the system for 20 years, selling "dev hours". They are all getting eaten alive and I'm here for it.
storyinmemo 21 hours ago [-]
"One bad programmer can easily create two new jobs a year."
-John Cook
wseqyrku 21 hours ago [-]
In my previous job the entire DevOps team were terminators from the gym. I don't know when or how they were attracted to software, and why. There's so many other jobs they could spend time on and be successful rather than writing yamls.
ChrisRR 5 hours ago [-]
The issue was that it was "learn to code" and not "learn to program", as if the only thing you needed was a month of training and then you were just as good as someone with 20 years of experience.
It's similar to why there's hundreds of books about learning the basics of a language, but comparatively few books about good software architecture/design
dijit 6 hours ago [-]
“learn to code- everyone should code-“ pushes always seemed like a way of trying to suppress wages for tech workers.
I’m not in it for the money, and that I can make a good (better than most) living from it is just pure luck and I am genuinely thankful.
But there are lots of people in it only for the money, and they will be very disappointed when it dries up, because the #1 thing these bosses want is for us to have less leverage.. They want it even more than they want revenue.
nkrisc 20 hours ago [-]
But how many of those bootcamp people actually went on to get software jobs? One of the big criticisms of that whole phenomenon that I recall is that people were graduating them and then were unable or unprepared to actually get a job in the industry?
So how many people "learned to code" and then ended up back on non-software related careers?
backwardsponcho 19 hours ago [-]
I think that changed around the time COVID hit and offer was highly surpassed by demand. Lots of overhiring during those days.
phil21 21 hours ago [-]
Or it’s just the largely self-taught intrinsically curious autodidact developers and engineers have always been 10x and the “average” person in it for the paycheck is really what a 1xer has always actually been.
I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job.
Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries.
Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.
wwweston 21 hours ago [-]
I also have a suspicion that people’s microdistributions of talents is underappreciated. Some people are good architects and average at algorithms. Some people are unusually good at debugging or QA. Some can spin out whole systems at an impressive speed that may not be a great long term fit for the larger system.
And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.
kian 20 hours ago [-]
I think this is one of the beauties of AI -- filling in the gaps to help people make their microtalents shine.
NateEag 19 hours ago [-]
nah, as someone who's driving Claude daily by corporate mandate, AI just shits acceptable mediocrity over everything, and my microtalents don't fit into the org anywhere anymore.
They've been replaced by Markdown files asking Claude to burn tokens on doing something deterministic tools already do faster and better, like checking variable names for typoes (I wish I was making this up).
andrewflnr 18 hours ago [-]
I'm very much a curious autodidact and there are still people who easily 10x me or more. Someone like Fabrice Bellard is an obvious, extreme example.
sleight42 17 hours ago [-]
I agree completely and have said similar. Yet this is what happens when supply tries to catch up to demand. There were not enough software chefs to keep up with the patrons appetites. We started minting more cooks. Instead of Culinary Institute of America candidates and autodidacts, we got what the customers wanted: people who would just churn out more.
Blame the patrons for demanding more with little care to the quality.
I mostly gave up on software development roles in business when the vast majority of developers and, particularly management and executives, made clear that they couldn't give a fuck about craftsmanship. It was just about shipping, good, bad or otherwise.
AI in software development predates on that appetite for MORE at any cost. When the business doesn't really care about quality, because, let's be honest, most don't, this is what you get. You get massive volumes of garbage.
tiew9Vii 12 hours ago [-]
Previously it felt like there was a lot more nerds who were in it for the interest instead of today for the career path and fast track higher salaries.
2010’s was when more traditional CS courses also started moving from traditional languages and content to JS etc…following industry demand.
A lot of tech conferences were pure tech. Now a lot of them are agile, soft skills based, introverted nerds pushed out.
It’s certainly a different place from the 2010’s.
myth2018 17 hours ago [-]
This.
For a certain class of professionals, slowness is a kind of superpower able to restrain their damage. LLMs have turned off those guardrails.
On one hand, I'm not fully surprised -- LLMs are powerful tools, but of course they can be misused. On the other hand, I'm impressed by how fast things are deteriorating in some shops. At my job they got encouraged, over-confident even, to finally do some long-awaited major overhaul in the code base. I'm genuinely concerned about our ability to continue maintaining this mess in the mid and long-term.
Planktonne 18 hours ago [-]
> we ended up with a lot of people that just can't do the job
I don't think this is attributable to the 'learn to code' push; I know many fine engineers who came through boot camps, and many, many poor ones who came in the 'official' way.
The problem is that we trained too many people, many of them without the aptitude, not how we trained them.
fierycatnet 19 hours ago [-]
I tried to get a job back then but never could. Its wild to read to me that it was 'sink or swim' back then. Nobody wanted to hire a junior. So I never became a SWE and it was my passion since 14. Now I just don't care and too much time has passed.
lief79 18 hours ago [-]
When? The specific years and locations matter greatly, there's always been a boom and bust aspect to it.
zabriel_goss 18 hours ago [-]
I understand your point and ultimately agree with the systemic problems here.
And, as a "Learn to Code" guy who's had a successful and interesting career filled with self-study and continual improvement, I'll call you a gatekeeper.
hdndjsbbs 18 hours ago [-]
If compensation for software devs was in line with other profession there wouldn't be bootcamps. The problem is it's an easy job that gets paid a ton of money
scrapedface 19 hours ago [-]
Just because you CAN code doesn’t mean you SHOULD code.
BrenBarn 16 hours ago [-]
> The problem is that worked when the industry was mostly composed of people that were implicitly interested in this stuff, but the people that just got in it for a paycheck don't have that motivation
That is a problem whenever people do things for money. It suggests that a big problem with our society is people are encouraged (in some cases effectively forced) to want money too much.
dismalaf 17 hours ago [-]
Is the problem the self taught programmers or the people who would have gone the finance or law route in university doing CS and then not caring?
leptons 18 hours ago [-]
Maybe you weren't around in the 2000 dot com bubble burst era, but the same thing happened then. Companies hired anyone they could because talent was scarce. A friend of mine who was a substitute teacher got a job as a sysadmin, and he was texting me constantly because he had no clue how to do his job, asking me all kinds of questions. That pretty much ended our friendship when I told him I wasn't going to do his job for him.
voidhorse 16 hours ago [-]
Eh, not all software engineering is made equal.
To work on engineering real time communications systems, banking systems, or transit systems and low level infrastructure, you definitely need some chops. To design and build out core network infra at the web giants, chops also certainly required.
To build out a basic crud app, pwa, or the next feature in the massive products that major companies ship? Yes you need some understanding but it really isn't that difficult or onerous. TBH if you ask me the profession always had a problem where the term "engineer" was a tad over applied. The boot camps are mostly churning out people who can write basic apps, not (hopefully) anyone being placed into a a senior IC and systems design role.
sgarland 14 hours ago [-]
As someone who works in fintech, I assumed the same; alas, I was wrong.
n0rand0 14 hours ago [-]
[dead]
RSHEPP 1 days ago [-]
This 100%. I just requested a hackathon for performance improvement (might be wasted effort).
We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.
Our biggest consumer of CPU right now is HTTP connection churn because engineers are creating new clients every request we handle. If the engineers would just think for a second, push back on Claude, even Claude would tell them this is bad. But they don't... Platform engineering is now 10x harder with terrible engineers and unlimited code machines.
Don't even get me started on ffmpeg usage, engineers act like the resources are unlimited.
notakio 23 hours ago [-]
When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.
He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.
dcrazy 22 hours ago [-]
What did the software engineers hope to learn from this tour?
jackyinger 22 hours ago [-]
The scale of a cloud datacenter is pretty awesome to witness. I had the opportunity to visit a large cloud company’s data center years ago, it was immense in scale and (mostly) very well thought out.
I’m personally of the opinion that everyone who works in software should have to rack a server and bootstrap it. Physically mount it, cable it, and get the *nix distribution of your choice running on it, serving Hello, World.
Everywhere I’ve worked, there is a marked difference in the quality of engineers who had played with hardware - even those who merely had expressed interest in it, and maybe had an RPi - and those who had not. There is something about physically touching the thing that runs your code that makes you better at it. Maybe it’s a correlation between “wants to play with something unnecessary but adjacent” and “curious enough to ask why more frequently,” but I swear, it exists.
orphereus 22 hours ago [-]
What was he doing? Showing them that bad code will make them feel hotter?
yardstick 22 hours ago [-]
Busy servers generate more heat. Inefficient code makes servers busier. There’s a real physical outcome for bad performance code at scale.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
18 hours ago [-]
bmurphy1976 22 hours ago [-]
He was showing how complex and expensive a data center is and giving them real-world visceral experience that inefficient code has real-world implications.
Chance-Device 22 hours ago [-]
Maybe he got PTSD from being a former tour guide and this was his time for vengeance.
ryandrake 1 days ago [-]
Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
palmotea 24 hours ago [-]
> Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!
The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
florianherrengt 23 hours ago [-]
The supposed “10x engineer” may simply be someone stealing productivity from everyone around them.
You measure the output of one person while ignoring the cost they impose on their team.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I haven’t become 10x more productive. I’ve just moved the work onto other people.
Worse, I’m consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
That’s why PR count, lines changed or features “completed” are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
palmotea 22 hours ago [-]
FYI, your comment showed up as [dead] like you were banned until I vouched for it, but I don't see any reason for that. Just thought I'd let you know in case you want to follow up.
florianherrengt 20 hours ago [-]
Thanks for letting me know. I had no idea. I’ll follow up with the moderators.
cdud3 22 hours ago [-]
> You can make your own numbers look incredible while reducing the throughput of the entire team.
Taken how some companies award promotions and bonus this is actually a double win. You not only improve your own numbers but also make this of your competition worse! /s
SauciestGNU 18 hours ago [-]
I just left a backstabby stack ranked company and so many people were sabotaging colleagues or teams they were in competition with. AI psychosis has been enabling terrible management practices as well as terrible engineering practices.
budsniffer952 23 hours ago [-]
If your company has bad engineers cranking out 10,000 line PRs your engineering culture and product was already bad, I guarantee it.
RSHEPP 23 hours ago [-]
It's not the whole culture and product, it's specific teams that do it. And trying to push back on teams that are "producing" is not a simple task.
Silhouette 22 hours ago [-]
Sadly AI also amplifies both the good and the bad managers and tech leads. If you have managers who fail to set a clear direction or tech leads who fail to define a good framework for developers to operate within then AI just means the poorly directed developer effort goes further in the wrong direction faster. Meanwhile teams with well-specified goals and better structure and processes can exploit the benefits of AI tools much more effectively.
oriolid 21 hours ago [-]
In the before times, a small dedicated team could hold back against bad engineering culture and intentional enshittification. Now the balance has changed.
watwut 5 hours ago [-]
> or most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran
Really? I have never seen that. The expectation was that you could create the code that compiled on day one.
cube00 1 days ago [-]
> We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.
Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.
Just look at how they're merging ~300 commits a week into bun.
That really sounds like the kind of people who will complain in university about being forced to study calculus.
Natural consequence: Then they never grasped the concept of computational complexity.
O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!
dr_dshiv 23 hours ago [-]
As a side note; There is plenty of useful math that many people need (or would benefit from) in the real world. Much math curricula is arguably poorly aligned to needs, as it emerged from various historical flukes of design-by-committee. Popular math curricula is not perfect by any means. I recommend looking at high school or college textbooks and considering whether it is well prioritized.
Shorel 23 hours ago [-]
In principle I agree with you.
The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.
monocasa 19 hours ago [-]
That was one of the biggest changes that happened with common core. Common core itself didn't really mandate this, but it took a reset of the curriculum to insert the new ideas like an emphasis on intuition rather than rote arithmetic.
annzabelle 15 hours ago [-]
The problem with common core is that it replaced building arithmetic fluency with less rigorous ways of building intuition, leading to a generation of kids who never gained the basic math skills that are foundational to actually understanding the intuition.
You can't just skip arithmetic drills in favor of intuition and still come out with students who are prepared for further study in math. There's a reason Kumon etc are so popular - parents are replacing the lack of mathematics drills in schools with after school options, leaving behind all of the kids whose parents can't afford it.
monocasa 15 hours ago [-]
After school stuff like Kumon was popular before the switch to common core.
And there still are arithmetic drills, it's just not the only focus in early math education.
sgarland 13 hours ago [-]
Montessori. My kids’ school has kindergarteners solving trinomials [0]. My kids learned multiplication and division by 3rd grade. They’ve also memorized powers of 2 up to 2^20, but that was more me telling them about exponents one day, and then giving those as examples. However, they did learn binary trees (and binary) from their school.
Kids can absolutely learn complex concepts early, they just may not be able to formally write them out until a few years later. But they’re kids, so who cares? By the time they need to be able to write out math equations, they’ll understand the underlying concepts on such a deep level that it doesn’t matter how long you make it, they’ll plow through it.
I was a skeptic, and am aware that I sound like a cultist, but damn if Montessori isn’t something special. I highly recommend it.
computational complexity was never part of calculus. Calculus is the math of continuous change.
moregrist 22 hours ago [-]
You don’t learn Big-O in Calculus because it requires CS algorithmic concepts.
But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.
BigTTYGothGF 20 hours ago [-]
> You don’t learn Big-O in Calculus because it requires CS algorithmic concepts
Big O notation was invented in 1894.
WorldMaker 20 hours ago [-]
Big O notation predates Computational Complexity. It was originally used to guesstimate asymptotic behavior (limits as they approach infinity). The related Little o notation (even more specifically limits of already large values as they approach infinity) is directly related to early attempts at defining differentiation and differentiability and still sometimes show up in Calculus next to derivatives to explain how derivatives work.
The visual interpretation/intuition of Big O notation can be a useful way to build a visual intuition of what a function's derivative and integral "shapes" may look like, so some Calculus books teach Big O notation, too.
Shorel 23 hours ago [-]
I should add that text to the rant at my last paragraph!
20 hours ago [-]
mirmor23 24 hours ago [-]
If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
palmotea 24 hours ago [-]
> If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.
AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.
Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."
satisfice 23 hours ago [-]
More like developers are now testers and nobody is doing QA.
chasd00 23 hours ago [-]
> a emergency leader with an eye towards promotion
i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.
butlike 23 hours ago [-]
Also you don't get the money. Why pay for a job already done
pydry 24 hours ago [-]
The bigger issue (I find) is that the pipeline for finding those engineers is completely fucked.
Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.
This is leading to stuff like incompetent junior-level engineers being hired as principals.
lubujackson 22 hours ago [-]
My company's hiring process is basically: Can you code a product quickly with AI? Can you understand the generated code?
That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.
johnnyanmac 23 hours ago [-]
>be a emergency leader with an eye towards promotion..
You assume those people haven't already left, been kicked out, or were hired to begin with. We're not in a rational job market right now.
ponector 20 hours ago [-]
The actual issue is not the "bad" engineers but the bad organization. While people are allowed to push and merge whatever crap is generated there is no point to do otherwise. Even if you do care about performance, "good" code your teammates don't and close more tickets and are better by many metrics.
If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.
florianherrengt 19 hours ago [-]
It means the company is measuring the wrong thing.
I would much rather have someone on my team who ships less but whose work I can trust than someone much faster whose changes leave me wondering what problems we’re going to discover later.
And when production breaks (and it will), I need the person who made the change to actually understand it well enough to help fix it, instead of showing up with no idea what is going on.
You can obviously be an asshole about how you do it but I don’t think pushing back makes someone toxic.
You need to be flexible and compromise when the business trade-off makes sense. But you also need a backbone. If you think something is going to cause real problems, bringing it up is part of the job.
ponector 17 hours ago [-]
>>I would much rather have someone on my team who ships less but whose work I can trust
Me too, but it is not what happening across the industry. Instead they are pushing for more LLM usage as well as more features. And faster, faster!
bmurphy1976 22 hours ago [-]
Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?
You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.
Trace the increase back to specific deployments, call out those teams, and make them fix their shit.
RSHEPP 22 hours ago [-]
Yes to all, but it's just me responsible for monitoring performance/cost. I either push back or fix it myself, but I am behind. So this is an attempt to give/push more ownership to the teams.
butlike 23 hours ago [-]
A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job." I don't foresee this going well for the company. Best case scenario: you wildfire churn all the chaff engineers which limits the company's throughput until they're rehired... with no expectation the new hires will be any better. You also lose A LOT of domain experience and are self-inflicting brain drain.
I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).
ivanmontillam 22 hours ago [-]
> A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job."
Not necessarily, great engineers do also ship temporary code they didn't have the time to trim.
Our process is of 1) make it work, 2) make it right and 3) make it fast; not necessarily that engineer had time for the 3rd step.
scj 18 hours ago [-]
The older I get, the more I feel that #3 should be "make it work well". Where the definition of "well" can be situationally interpreted.
wonnage 22 hours ago [-]
they meant application performance
whilenot-dev 24 hours ago [-]
The handling of backpressure is such a good example to distinguish bad from good engineering. A good implementation even presents all the typical "clean" code indicators: DRY, KISS etc.
pengaru 23 hours ago [-]
Mind sharing where you're at?
noncoml 23 hours ago [-]
Sounds like bad management to me
jurgenburgen 23 hours ago [-]
My company got rid of line management. I now report to a director with over 20 reports and barely any time for career development. Our performance reviews are AI generated and we’re losing engineers. The industry has gone completely insane.
soperj 23 hours ago [-]
This has less to do with bad engineers than bad policies and procedures. You don't performance test before shipping to prod? you get what you get.
cpgxiii 18 hours ago [-]
To a first approximation, basically no one in the industry does. Users regularly report performance regressions in basically every major piece of software, most of which would have been caught by performance testing.
rhdunn 9 hours ago [-]
It can sometimes be difficult to predict what will cause performance regressions when developing an application or web server with test data. So you do your best with what you know at the time of release, and then deal with performance issues when you know what is causing regressions (e.g. saved searches) and can then make measurements and profiling to see what exactly is causing the issue.
Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).
There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).
There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.
JavaScript evaluation for example is complex. Before Chrome the approach was to use a slow interpreter. IIRC, Chrome was the first browser to introduce JIT (Just-in-Time) compilation, leading to faster JavaScript and eventually more complex applications running in that language. Modern browser JavaScript pipelines are complex in order to achieve and maintain performance:
1. start interpreting the code on the AST so it is run immediately (or only rely on (2));
2. generate a machine code equivalent of that interpreted code (for faster baseline performance);
3. run more aggressive optimizations on known types based on profiling/analysis for even faster performance, including special handling of things like asm.js.
Startups have limited resources, we prioritize the best we can. As a staff engineer it's my responsibility to bring this to my company, but it's not an overnight process.
soperj 21 hours ago [-]
why wouldn't you use those limited resources to test things before they go to production, instead of creating more crappy things that go to production?
rhdunn 9 hours ago [-]
What do you test? How much time/effort do you spend testing each of those things? How do you know those will be performance issues?
There's only so much you can do -- making reasonable assumptions, choosing suitable data structures, database indices, testing various workloads, etc. -- in a limited test environment.
You may spend a week optimizing a feature that only 10 people use or that never gets to the point where it becomes an issue. Or you may have something that can't easily be tested at scale, such as various counts or other dynamic data that are determined by complex queries that you may (likely) find you need to cache but don't necessarily know which values will become issues until you start using the system.
fn-mote 21 hours ago [-]
From this argument, it sounds like your company is making a rational choice to go with what you’re seeing. Even if you don’t like it.
UncleOxidant 21 hours ago [-]
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
It's even worse than that. We've got a CEO who has suddenly learned how to vibe code and the stuff he's coming up with is... kind of horrendous. He's coming up with new "products" and proclaiming them the next big thing for us to work on and we're kind of over here scratching our heads asking who would want this? Who would pay for it? I mean, he was able to put together a kind of a cool web app (with 0 web app knowledge) that's supposedly going to let users design thingys with AI, but it just seems like he re-invented a harness/IDE. I suggested that maybe what he wants is a VS Code plugin like Cline or KiloCode... but he hadn't used VS Code.
lawn 19 hours ago [-]
It would be funny but sadly our CEO is also vibe coding all days (with AI I have so much free time!), forcing everyone in the company to use his vibe coded product.
Oh and he's altering course from the previous "AI only where it makes sense" to "everyone should code, even the sellers" and "AI is not optional, we're an AI first company".
Talk about drinking the Kool-Aid...
swatcoder 23 hours ago [-]
> > bad engineers were always a liability
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
Yup, and that's going to be the comeuppance for a decade of aggresive overhiring.
There are so many "bad engineers" filling the ranks now that in many teams and divisions there's not even anyone left around who can recognize them as such.
This was already manifesting as a rapid decline in software quality and worsening practices, and the amplification effect of AI is mostly going to make everything worse for a while as we wait for all these declining projects to buckle under their weight.
If you are a good engineer, it's a good time to work on small teams with other good engineers and rigorous practices. You can be using AI to amplify what you do (and probably should), but you need to be rigorously considering your processes and guarding yourself from seduction by blind-leading-blind hype you see on social media or in iconference talks.
ponector 20 hours ago [-]
It's all about the process and the organization. No one is pushing for quality, everyone needs more features.
>>a rapid decline in software quality
It's hard to expect anything else if budget for QA teams is reallocated to cover llm bills.
swat535 22 hours ago [-]
> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.
I wouldn't be so quick to judge the long tenured engineers. They probably realized that moving business forward is more important than writing artisan code.
You always have some young hotshot who comes in and wants to rewrite your old boring Java monolith into a micro services disaster for "better architecture".
The greybeards learned the life lessons the hard way.
The other aspect to consider is this: stay in this industry long enough and it will beat the soul out of you.
cactusplant7374 21 hours ago [-]
I agree. Why is everyone so hard on everyone else? Look at the outages Anthropic and OpenAI have had. They aren't hiring stupid people but they can't seem to go a week without major platform instability. And you can't even argue that it's because of high load because all of these engineers have worked at Facebook, Meta, etc. They are seasoned veterans that should be able to build resilient systems.
NateEag 19 hours ago [-]
> They aren't hiring stupid people but they can't seem to go a week without major platform instability.
All those smart people are probably using genAI to generate their codebases.
So far, that does not seem to have resulted in a robust, stable system.
Certainly no better than the results the hyperscalers got doing things by hand, and arguably worse.
cpgxiii 17 hours ago [-]
Either they believe their own hype and their reliability is a reflection of the real weaknesses of AI coding, or they're complete liars and doing far more traditional SWE than they claim. I think the former case is far more likely and that while they may have hired plenty of senior people from big companies, there's definitely a self-selection for "true believers" in AI coding baked into that hiring process.
butlike 23 hours ago [-]
Tell me how to paradigm shift careers and I'll get out of your hair and stop shipping uninspired features.
But, right now I'm paralyzed with fear in how to make a successful career switch without starting from literally "new grad level." I have wisdom, so it doesn't feel like I should have to start at the bottom rung again. Egotistically, I don't even mind, it's just the salary hit that would be the main issue.
Maybe it's not even a paradigm shift (though, I've always wanted to work on film productions). I've sort of lost the passion for being an IC, but how can I make a transition to management without any management experience? Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
burningChrome 22 hours ago [-]
>> Egotistically, I don't even mind, it's just the salary hit that would be the main issue.
This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.
>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.
butlike 21 hours ago [-]
Interesting. Thanks for that last anecdote. I feel you on the weird state of purgatory. I'm confident we'll find a path forward, though. Gotta keep your head up
SauciestGNU 18 hours ago [-]
I've decided to take that salary hit. I want to stay an IC and work somewhere that doesn't effectively require a 996 schedule to keep up with openclaw slop for PR count stack ranking purposes. It really depends on your financial situations, but I've seen the human cost of very high compensation jobs on myself and some things are worth more than money.
vips7L 18 hours ago [-]
Same man. I hate everything about this career path right now, but even real (civil, structural) engineers get paid massively less. I think I’ve just come to a realization that software engineering salaries are just massively inflated, especially for those of us that just do the programming part and not the actual engineering part.
It just seems like there’s a reckoning coming for our field. I’m going to keep doing it, I don’t see any other choice right now.
throwaway613746 22 hours ago [-]
[dead]
cautiouscat 1 days ago [-]
I think this point gets lost on people. A frequent argument I see in favor of vibecoding is: “well there’s also bad engineers”. In other words, bad code is already being written, so who cares if the LLM is wrong sometimes?
The issue is that with no reins, the LLM is a fire hose of bad code compared to the garden hose of bad code orgs had before. A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.
cdud3 21 hours ago [-]
The easiest way is to actually review the prompt input, put it through a LLM to catch the typical missing steps and automatically forward the result as review comment to the MR.
Let the LLM wars start!
SchemaLoad 17 hours ago [-]
A single bad dev with AI can overwhelm multiple good devs trying to hold back the tidal wave of slop.
skydhash 23 hours ago [-]
> A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.
A good engineer, without LLM assistance, will still produce great stuff.
crystal_revenge 17 hours ago [-]
> A good engineer, without LLM assistance, will still produce great stuff.
Not fast enough to keep their job these days.
Time was always the limiting factor to code quality, good engineers satisfied the classic "good", "fast" but not "cheap" selection of those three classic options.
I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now. Not to mention that frontier models do ship pretty consistently good code. By far the biggest source of issues I see is not "poorly coded" but "problem poorly specified". We still need good engineers, because they can understand how to do decompose problems well, but I don't know anyone who writes code by and anymore (other than for fun).
skydhash 14 hours ago [-]
> I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now.
What's the current delivery rates? From my past experience, any feature can take several weeks from idea to be in a somewhat usable shape for production. While the actual coding is often less than a few days. A lot of time is spent on gathering requirements and resolving conflicts between them.
I believe most current improvement in speed is just moving from idea to demo in a few days, then spend several months fighting bugs. While the customer can't really use said feature.
crystal_revenge 13 hours ago [-]
> I believe most current improvement in speed is just moving from idea to demo in a few days
This is an outdated view.
Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say the timeline for a similarly shaped feature at another startup was around ~3 months (and the team at the time agreed that was an aggressive timeline). Bug rates are not noticeably different than other teams I've been on in the past 20 years.
Nobody I know working in startups is still building demos with AI like they were a year or more ago (for work), that's seen as largely a waste of time since you can just ship the feature and be experimenting with customers much faster.
On top of that everyone working in startup land knows that SaaS's days are numbered, so you need to be shipping working software fast enough you can get ahead of the curve to navigate where things are going next.
skydhash 12 hours ago [-]
> Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say the timeline for a similarly shaped feature at another startup was around ~3 months (and the team at the time agreed that was an aggressive timeline). Bug rates are not noticeably different than other teams I've been on in the past 20 years.
My issue with these kind of numbers is that they never contrasted them with a NO_LLM practice while keeping everything the same. It's always perfectly fine to YOLO generated code straight into prod, but if you handwrite it, you need to fill several forms in triplicate to even make it to the review phase. Then someone claims they are 10X-ing their productivity with AI.
> you can just ship the feature and be experimenting with customers much faster.
That's basically what I said. Instead of shipping something that have some value to the customer/user from the get go, which may takes one or two months, you spend one or two weeks on it, ship it, then frustrate your customers/users when things aren't working or keep shifting around.
For all of AI being touted as the best thing since sliced bread, there's been little to no value for humanity as a whole.
cindyllm 17 hours ago [-]
[dead]
zinodaur 23 hours ago [-]
Yes, but much more slowly. And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
vips7L 18 hours ago [-]
Speed doesn’t matter.
crystal_revenge 17 hours ago [-]
I take it you're not working at a startup?
vips7L 15 hours ago [-]
I’ve worked at plenty of startups. It still does not matter, it never has.
zinodaur 17 hours ago [-]
For beings with finite lifespans, time is precious
bdangubic 18 hours ago [-]
it does if you are writing the checks, it doesn’t if you cashing the checks
vips7L 17 hours ago [-]
I genuinely doubt it. Amdahl’s law will always reign supreme.
skydhash 22 hours ago [-]
> And if they realize halfway through implementation that there is a better way to do it, but they are under pressure to deliver, they wont have time to rewrite it and will live with the consequences of that decision forever
I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.
There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.
sillyfluke 21 hours ago [-]
"Slow is smooth, smooth is fast."
...as Mickey Mouse was fond of telling me as I waiting for the ride at Disney World. Or it was my drill instructor. can't remember which.
dzonga 22 hours ago [-]
pretty good presentation.
my take is everyone in the industry should read grog-brained developer, & no silver bullet before working as a professional.
the other is a mindset change - the best working code is code that's never written as it doesn't have bugs or suffer technical debt. Agentic coding doesn't solve that. Human taste does, which means our job is to reduce the amount of lines we write. agents etc are useful for the filler or bullshit part of our jobs e.g generating tests.
but ultimately I think the whole spec-driven development & agents spitting 100000s of lines era will be looked upon as mass psychosis.
last thing to give an analogy - you don't carve a David statue by gluing together pieces of marble - but you carve it by cutting pieces of a huge block of marble.
perrygeo 24 hours ago [-]
Rather than good or bad engineers, I'd focus on the quality of the idea. Every software engineer has good and bad ideas. Historically, bad ideas were kept in check by the effort it would take to code the implementation. With that barrier nearly gone, there's no friction - a bad idea in the morning gets deployed to prod in the afternoon. No thinking required!
So yes, garbage in -> garbage out, but framed in a way that makes it clear what is garbage. The ideas, not the engineer themselves :-)
This suggests we need to be doing more designing and planning; introducing that friction intentionally to make sure bad ideas get culled, viable ideas get refined. Critical thinking becomes the bottleneck; the quality of the idea becomes the deciding factor in success.
WorldMaker 20 hours ago [-]
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases.
We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.
ehnto 3 hours ago [-]
> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft...
Which is an incentive problem, they have likely reached an equilibrium with their company. Genuinely few companies provide any incentive and critically, the space, to ship good code.
Because frankly it doesn't matter in the middle grounds. Which is where 90% of developers are.
I wish we all had fulfilling edge of our seat projects to work on, that challenged us just right, mattered to our community etc. AI is absolutely poised to disrupt the middle 80% of development because the middle 80% of dev is not that important or hard.
It's just a shame for all of us who loved the craft, and didn't mind being in the middle making a living. That's a totally noble place to be, and it could get taken away from many of us.
__turbobrew__ 24 hours ago [-]
The analogy I have heard is that LLMs are a force multiplier, so if you were a 2x engineer before you are now a 10x engineer, and if you were a -2x engineer you are now a -10x engineer.
23 hours ago [-]
hn_throwaway_99 1 days ago [-]
This is me to a tee. I think I'm a fairly good software engineer, and I loved building software and mentoring more junior engineers who I thought had both ability and a good attitude. I also think I was a pretty pragmatic engineer (I was not an "architecture astronaut"), but I did enjoy the craft of getting into the nitty gritty details of software.
The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age. I thought software as a business had "lost its way" from building great products with attention to detail to "how do we addict as many people as possible as quickly as possible". Think about the degradation in Apple software from say the "it just works" era to now.
With respect to AI, I'm not really against it, and I find it extremely valuable in my personal projects. I just feel in a large group/enterprise context that it's replaced a lot of tasks I actually enjoy doing with becoming an editor for what feels like a slightly inebriated junior developer. Or maybe it's better to say a junior developer on a mild amount of meth, because as you say this developer can churn out semi-but-not-fully-working code at an astonishing rate, and then I feel like it's often my job to mop the slop off the floor. Pass, not interested.
I feel lucky to have had my career during what I consider the golden age of software engineering, but I'd note I don't think that golden age lasted even a full career of one person.
SoftTalker 24 hours ago [-]
In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it:
Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.
Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.
Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.
Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.
Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.
The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.
hn_throwaway_99 17 hours ago [-]
In thinking about it more, I think you're totally correct.
For the vast part of my career I worked for good companies that I thought were comparatively very well managed, and I was especially fortunate that overall I think I had excellent bosses. But the reality of the Internet age and CICD in particular is that speed is much more important than quality. I don't even really disagree with the business imperative of "ship, ship, ship", but for people who really value their craft, it can be discouraging shipping stuff you know is always kinda half baked. I was definitely not a "gold plater" either, and time pressure was certainly a thing pre-Internet, but as you say mistakes were a lot more expensive then so there was more business rationale to ensure quality before a release.
butlike 22 hours ago [-]
Going to CompUSA and looking at the back of the box for not only video games, but spreadsheet and translation software, too; was awesome. As a kid I always wondered about the adults who needed such software as the back of the Deus Ex or Shogun Total War boxes captured my imagination.
Since it sounds like you built software during that era, thanks. Thanks for the memories.
saulpw 23 hours ago [-]
You're right about those things, but you're forgetting that we had no source control, and almost all software was closed source. You took what you were given and you liked it, and you developed strong attachments to particular versions of software which you clung to well beyond its use-by date (like Python 2.7). MS-DOS 3.3 forever!
MyHonestOpinon 22 hours ago [-]
I started using SCCS in the late 80s, then RCS, then CSV, then subversion, and finally git.
skydhash 23 hours ago [-]
We had version control in the 70s with SCSS and then RCS. They were primitive, but a lot of software were only a few files.
saulpw 23 hours ago [-]
In the 80s, source control was like networking. Yes some orgs had it (mostly academia) but the rest of us just had a precious floppy that we copied the known-good source onto.
cdud3 21 hours ago [-]
We had an own good-releases directory in our svn repository! That's when you realize old habits are hard to change.
22 hours ago [-]
MyHonestOpinon 23 hours ago [-]
I also consider myself a fairly good pragmatic software engineer. I have led small (3 engineers), medium (15), and large (100+) teams.
To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.
closeparen 22 hours ago [-]
I definitely hear about segments of the industry being like that, but FAANG and adjacent generally isn't. Engineers are expected to display ownership of a problem space (scope depending on seniority), navigate ambiguity, and manage their own time.
bossyTeacher 18 hours ago [-]
> The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age.
What year did you leave? And what are you doing now?
vogelke 23 hours ago [-]
This is right on the money. It's not that we have way more bad engineers than before; it's that the damage they do is out of all proportion to their numbers.
joshdavham 12 hours ago [-]
> people lack the right skills today to wrangle agents into writing good code.
It's actually this that leaves me feeling optimistic. We're definitely bad at this today, but will we always be bad at this into the foreseeable future? I'd like to think not. I'd like to think that we'll get better at working with agents in the future and eventually develop better practices around this new weird technology once it's better understood.
jnpnj 1 days ago [-]
I've seen a subtler variant of that. Since 2025 winter model improvements, low quality developers can now commit somehow decent stuff more regularly, but as before, they still don't own the solution space independently. LLM output is now larger than what they can envision and cracks will simply happen further away, only to be discovered by someone else later. It's strange everything changes so nothing changes phenomenon.
SchemaLoad 17 hours ago [-]
Most vibeslop these days is superficially good in that it has unit tests, compiles, passes the style guide, but it's bad on a macro level in that it makes the system more complicated, ignores the wider design of the app, implements what the prompter asked for and not what the app actually needed, etc.
I'm seeing a bad pattern of vibeslop being used to solve the immediate complaint of the user without stepping back and reconsidering things from a product perspective. Just add another conditional statement to make this very specific scenario the user complained about work the way they want.
andersmurphy 11 hours ago [-]
This is why my theory is LLMs are self defeating in large orgs. Or worse terminal for the organisation.
For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.
ChrisMarshallNY 14 hours ago [-]
> not enough interest to make what they ship _good_.
I know this happens, but don’t really understand it.
In my experience, quality hits usually resulted from external pressure (bad managers, trade show-driven schedules, etc.). I always wanted to do better.
Now that I’m retired, I take the time to really get Quality right. LLMs have helped (but they need close watching).
consp 22 hours ago [-]
> but not enough interest to make what they ship _good_
I'm having the impression business decisions always win, time is always reduced and requirements always changed half-way during a project, having a much greater impact than any bored old engineer.
matchagaucho 23 hours ago [-]
"Okay. I'll create a loop and goal so it doesn't stop until it's checked that everything works."
This is where the quality magnification seems to be occurring.
Goal-driven loops can make good code great, or bad code worse.
davidguetta 8 hours ago [-]
Not all industries require good software engineering tho.
one good swe out of ten with high authority may be enough in most organisation
dfee 19 hours ago [-]
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
and
> I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
those people who lack the right skills today – are they the bad engineers you'd mentioned previously?
la6479 24 hours ago [-]
But sooner or later for AI to reach its true potential we need to have HOTL ie Human Out of the Loop. Meta prompting or using AI to develop the prompt by coaxing it to ask relevant questions , creating specs and going through multiple loops with LLMs - things like this can be a good start towards the final goal. Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.
bobthepanda 24 hours ago [-]
Alternatively, cutting out labor just results in mass poverty except for the moneyed few, and a new era of technofeudalism.
It seems pretty clear that the current crop of executives strongly prefer the latter scenario.
goatlover 20 hours ago [-]
Pretty big assumptions that we will get a UBI that everyone can live comfortably on, that there will be optional jobs for anyone who wants to work, and even given the first two, that there won't be massive wealth and power accumulation at the top, even more than today.
bothers 19 hours ago [-]
> Final means the over abundance of goods and services like the men of the millenium are suggesting us mere mortals will reach one day,. .. and work will be optional.
Yeah, that sure sounds like paperclip maximizing hypercapitalists. Real big on sharing, not so big on minding the cost, but they just can't show their love for us all while employee labor still has some value to them. Once that's out of the way and they've taken or mulched everything of value from others, that's... that's when they'll start giving it all back, yeah.
I know the sarcasm isn't helpful. But goddamn I can't understand this take, I don't know why people believe people-shaped entities like [your favorite wealthy sociopath's name here] will become society's mommy if given the power, and it's incredibly fscking frustrating. Like people who think once their home and everything is burned to the ground, the fire will rebuild everything, but better.
torginus 23 hours ago [-]
I think the parallels with AI art are uncanny - nowadays people with zero artistic skill, vision or effort invested are capable of creating stuff that would've previously taken a master artist a solid week of work - doesn't mean any of that is good, but it does mean that the logic of 'if it works and looks good, it's good' is completely broken now.
CuriouslyC 1 days ago [-]
Ironically, AI mitigates bad developers quite a bit. The architecture/design is coming from above bad devs (in a functional org), and AI tends to write less sloppy code than bad devs, and test/validate it more rigorously.
mjr00 1 days ago [-]
I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.
If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
whateveracct 1 days ago [-]
AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.
stackskipton 1 days ago [-]
Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.
to11mtm 16 hours ago [-]
It can but you need to be careful.
At my org we use Github Copilot as our AI tool for devs, both internally and for vendors (Including a WITCH =/).
Where it gets ugly, is that we have a -lot- of WITCH provided code already in our systems, and as a result GHCP winds up often preferring the existing (terrible) patterns.
I've done some things to help mitigate at least; Adding instruction/skill/agent files, tossing in some LLM-built .NET analyzers to catch the worst anti-patterns to warn on build and error on CI, and making sure to call out when the vendor people are obviously not even reviewing what the LLM generated for them [0]
[0] - Simplest case being, EF Core mappings where the datatypes do not even exist in the target DB...
kube-system 23 hours ago [-]
A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.
johnsmith1840 21 hours ago [-]
If those bad engineers are in a very well defined box. Give bad engineers greenfield and watch it implode
jayd16 24 hours ago [-]
Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.
marssaxman 22 hours ago [-]
Just like compiler-generated machine code, then.
jayd16 11 hours ago [-]
no, not like that at all.
mohamedkoubaa 1 days ago [-]
Jury is still out here
re-thc 1 days ago [-]
> AI tends to write less sloppy code than bad devs, and test/validate it more rigorously
I've often had it test and benchmark against the wrong things = no test.
It also writes over-engineered code. So yes sort, maybe.
dominotw 23 hours ago [-]
> The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.
i think i fall into this bucket. our "leaders" and executives have told us they dont care about 'shipping good' . we are simply responding to incentives.
florianherrengt 22 hours ago [-]
They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.
This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.
a34729t 19 hours ago [-]
My coworkers and I give it 12-24 months before we have a total collapse due to unmaintainable slop and good people leaving. Generally there's a feeling that this will sink a lot of bigger companies.
roncesvalles 19 hours ago [-]
Bad engineers simply don't care about good engineering. They aren't even trying. LLMs have made these engineers super "productive".
ThePhysicist 1 days ago [-]
Maybe those engineers that don't care about making their solution _good_ are actually the good engineers, have you ever thought about that??? There are exceptions where quality really matters but most software shops build CRUD web apps where it's not really a good characteristic to obsess over the cleanest and most elegant details, instead you need to get the stuff the customer wants done!
I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference.
Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!
Syntaf 1 days ago [-]
Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.
There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.
michaelrpeskin 22 hours ago [-]
Thanks for the wording on your first sentence there. I've been trying to figure out a way to get that thought expressed succinctly.
I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?
We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?
I don't know, but it's just something I've been thinking about lately.
kian 20 hours ago [-]
Using context always means there's less for something else, whether you're a human or a machine. Abstractions that localize reasoning and help load the context into a human brain are ideal for machines and humans alike.
jonnycoder 1 days ago [-]
This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.
Kinrany 24 hours ago [-]
If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem
florianherrengt 21 hours ago [-]
I tend to find that this perspective comes from people working on relatively small or isolated projects.
On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.
Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?
If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.
If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.
blub 23 hours ago [-]
In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.
Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management.
This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D
fennecfoxy 1 days ago [-]
I have found this to some degree (even though I work with amazing people day to day).
It's much easier for people to pump out absolute garbage, you know the kind of "just get it done fast" slop that management types cry out for. And then they wonder why everything end ups broken, not being maintained etc.
And I think the contrast between good and bad code output is much more impactful. Someone can pump out 10x the bad code they used to before, never test it never read through it just push push push baby. And then for good code, sure it's increased my output for slop tasks like repetitive unit tests, but a lot of TLC and review is required for good code and I'd say I've had maybe a 2-3x speed up on a lot of things. But not 10x; you only get that when you don't give a fuck.
cindyllm 1 days ago [-]
[dead]
Animats 14 hours ago [-]
Why is there no transcript for that video?
indoordin0saur 22 hours ago [-]
Great talk
pbronez 12 hours ago [-]
Good talk, thanks for sharing! I’m trying something similar for personal project I’m hacking on.
Specifically, I’m spending a lot of time on the first few instances of a pattern that I hope to have the AI scale out for me. My thought is that I can provide an opinionated project structure, feel it out myself, then point the AI to those working examples in the future. Until then, I’m mostly just using ai as fancy autocomplete + domain research.
viccis 15 hours ago [-]
>With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
I would expand this even further and say that the worst problem for people in the trenches isn't even just that this is happening, it's the it creates a situation where managers are held to some expectations (their team shipping product features) that incentivize not looking too carefully at what their team members are putting out. It makes it really hard to tell a boss "we need to stop and spend a few days reviewing and rewriting because one of my teammates likes to one-shot everything with poorly thought out Claude prompts making multithousand line PRs" when their own bosses are breathing down their neck.
It's the same struggle we face to get refactor work prioritized, just at a much more frequent cadence. "It's working so why do we need to spend another sprint on it?"
_fat_santa 1 days ago [-]
My team is currently developing our 3rd product this year where 99% of the code is written by an agent. One thing I've definitely noticed is our problem solving hasn't stopped, it just moved up the stack to the "agent layer".
A big part of this is ensuring that a "bad" engineers can still write solid code and also investing in systems that make it easier for us to review code.
When it comes to writing code, we have this entire library of coding standards that we've moved from one project to another. It describes, sometimes in excruciating detail, exactly how we want our code structured, antipatterns, best practices, etc.
On the review side we have invested equally into skills that split up code into readable chunks, take screenshots of any UI changes for quick validation, and a whole battery of tests to ensure that we're not generating slop.
If you were to look at just our development process, you would conclude that we're very lazy engineers. We seldom write code by hand, we seldom ask for corrections and our reviews are more of a cursory look at the PR rather than a deep review.
But the real work is not in the "development layer", it's now in the "agent layer". Making sure the agent knows how to write solid code so we don't need to write code by hand, making sure it doesn't make dumb mistakes so we don't have to correct it, and structuring our review process in such a way where an engineer only has to take a cursory look at the code.
The key difference we noticed between the "old way" and the "new way" is the "new way" is way more scalable and we're able to move way faster than we ever could before.
florianherrengt 20 hours ago [-]
What you’ve described solves a different problem. You’ve put a lot of effort into making sure generated code conforms to your standards. That’s all good.
But do the people still understand what the system is doing and why?
You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.
> an engineer only has to take a cursory look at the code
If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.
BrenBarn 16 hours ago [-]
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
This is why I don't have any patience for the people who say "but AI is so powerful! we can do so much!" It amplifies the bad stuff more than the good stuff, so it's a net negative.
renegade-otter 24 hours ago [-]
I think for senior devs, some of us are legitimately jaded, especially if have been facing the same or boring problems.
I am just tired of typing and looking up syntax for every line of code.
This, however, is a slippery slope, and one has to be mindful of falling into cognitive surrender.
FrustratedMonky 21 hours ago [-]
This is great.
We now need to talk about the 10xBad engineer.
mannanj 22 hours ago [-]
Part of the problem is self confidence bias. Everyone things they're the good engineer, while dunning Krueger would say maybe you are the bad engineer.
Prove who's good and bad.
And you can't really, because there's always tradeoffs you're making as an engineer. The really self confident ones think their tradeoffs win, and maybe they do, though often they don't and these people are just self aggrandizing and stroking their large egos. Are you a better engineer just because you made a big talk and had the confidence to share it with lots of people?
globalnode 23 hours ago [-]
seems a lot of comments below with disdain for "bad" coworkers. every industry has them, but if theyre objectively bad why not get rid of them? surely some periodic review would do that. how did they get hired in the first place? perhaps hiring managers are the "bad" employees.. or managers that let them go on not performing are "bad". or maybe your expectations arent aligned with reality? who knows? the worlds a complicated place.
j45 23 hours ago [-]
I'm not sure if it's replacing the middle class of software engineering, but I do feel it's generally true that the static approaches to middle class software engineering are evolving quicker than people are keeping up.
Hopefully when there's bad devs, there's a bit less making a mess where someone doesn't know better and as a result some amount of average or general best practices start happening.
This can be true not just for software development, but making a mess in anything, including a spreadsheet.
lookACamel 21 hours ago [-]
Despite the title this article doesn't seem to be saying anything about the "middle class".
OutOfHere 1 days ago [-]
What is A&D? Shouldn't it have been defined in your comment?
Syntaf 1 days ago [-]
Fair point! I edited my comment, A&D -> Architecture & Design
OutOfHere 24 hours ago [-]
What about the video's title?
robomartin 20 hours ago [-]
> I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it.
Absolutely on point. I just completed the port of a industrial application written in Python using a sophisticated console-based UI to C# and Avalonia UI. This is my second major coding project using Codex.
The one salient element of the experience has been that, as I keep saying to anyone who will listen, AI still does not understand anything it is doing. It presents an amazing simulation of it, but, no, it does not.
Here's a simple example: The original application had a clean communications protocol implementation. A single file with a class that implemented every single command you could have the industrial controller issue to the hardware. Codex was explicitly told to replicate that in C#. It did, at first, but then it started to duplicate command processor code in the individual functional blocks throughout the application. Which means that, when a bug surfaced, you had to fix it in five different places.
Another example: The application has a highly customized table view. Once again, it was told to make that a component to reuse throughout the application. It did, at first, and then weird bugs started to surface that made it clear that it had reimplemented the table control in different areas of the application.
If you don't know what you are doing you will probably not pick-up or even care about some of these things. It is easier to whack-a-mole bugs with AI than to worry about code structure, efficiency, maintainability, future-proofing, scalability, etc.
I purposely decided not to look or touch a single line of code during this project to see what's possible and where the issues might be. I learned a lot and continue to learn. I think the next step is some sort of an agentic approach, maybe using OpenClaw (or whatever, I don't really know right now) to create a team with coding, supervisory and testing agents.
While the project got done significantly faster than it would have without AI (four weeks instead of probably 4 to 6 months), the process was just as intense as coding, just operating at a different level, micromanaging architecture and implementation.
bwhiting2356 12 hours ago [-]
[dead]
ok123456 24 hours ago [-]
To everyone complaining about "slop" and "+20000 PRs," what kind of systematic quality assurance, test plans, and tech debt reductions were you doing before the "LLMpocalypse?"
Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?
florianherrengt 20 hours ago [-]
The difficulty of producing code WAS one of the circuit breakers.
We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.
Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work.
How many times have you had a completely green CI with 100% coverage and still shipped a bug?
apsurd 24 hours ago [-]
Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.
Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.
I quit because of it. Hell is working on other people’s AI code.
ok123456 23 hours ago [-]
At different times in recent history, you could have also said:
> Hell is working on other people's NoSQL code.
> Hell is working on other people's Python slop code.
> Hell is working on other people's enterprise Java code.
> Hell is working on other people's Windows Forms/GUI Builder code.
To quote Jean-Paul Sartre: Hell is other people.
fsnovask 24 hours ago [-]
Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.
This isn't coming solely from engineers wanting to produce more stuff faster.
jcranmer 24 hours ago [-]
We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.
24 hours ago [-]
bcrosby95 23 hours ago [-]
Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.
In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.
Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.
scronkfinkle 1 days ago [-]
I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code that was required to be written. This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This hand off is no longer necessary as that same senior can just kick off an agent and have it handle the implementation for them.
I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
sarchertech 1 days ago [-]
>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way.
This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM).
Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project.
If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
jasode 1 days ago [-]
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.
The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.
However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.
One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.
But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.
A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.
There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
sublinear 21 hours ago [-]
> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!
jasode 21 hours ago [-]
>, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective.
You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.
Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.
sublinear 20 hours ago [-]
All engineers should be spending more time "planning" than "doing".
Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.
You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can sometimes vary in points, but your tasks should not. A primary goal of the planning phase is figuring out how to keep them as low as you can. The points stop being meaningless when you think this way. They tell you where things are too lumpy. You throw more planning time at those lumps.
If assigning to a senior produces better code, you're not spending enough time planning ahead.
bluefirebrand 23 hours ago [-]
> However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
ed_elliott_asc 9 hours ago [-]
For what it’s worth I’ve not heard anyone ever say anything like that about SAAS developers, it’s a scary time for us all but software dev isn’t going to stop overnight.
SoftTalker 1 days ago [-]
Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.
Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.
I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.
Chyzwar 10 hours ago [-]
You would be surprised how many people struggle with "simply read error message".
skydhash 23 hours ago [-]
I'm more likely to have several tabs of the libraries/language docs open than opening Google. And when I do, it would be just a faster way to get to the docs. After a while in a project, my history and bookmarks list is much more useful than a web engine. If it goes into months and years, it's mostly tweaking the code to solve some bugs, meaning a lot of reading of source code.
Aurornis 1 days ago [-]
> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.
Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.
The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.
It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.
spamizbad 1 days ago [-]
Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!
Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.
rootusrootus 21 hours ago [-]
I'm there now. I have a team of low level engineers in Hyderabad and Bengaluru which can be useful but I have to spend a lot of time writing very detailed specifications and instructions to walk them through what has to be done. There are plenty of instances I can point to where it would have been faster for me to implement the solution myself, by hand, no Claude. Now bring Claude into the mix and I do not really have any use for these engineers at all aside from providing operational support during IST.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
fsnovask 1 days ago [-]
>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.
AppleBananaPie 1 days ago [-]
I've never thought about it this way before but this definitely mirrors my experience
dkarl 24 hours ago [-]
> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear
I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.
Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.
The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.
re-thc 1 days ago [-]
> but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice
I've seen a twist - not juniors but just offshore engineers.
_doctor_love 1 days ago [-]
> I’ve worked at a lot of places over 20 years
Primarily in Silicon Valley or outside of it?
I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.
DaveParkCity 24 hours ago [-]
While the picture painted here is viceral... I think the reality is closer to this..
Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it.
With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".
doctorwho42 1 days ago [-]
Again, this ignores the second order effect of entirely gutting the personnel pipeline that is required to create new senior devs...
So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....
florianherrengt 1 days ago [-]
I think that’s a completely different problem.
I’ve worked with two junior devs recently who are very good precisely because they’re trying to understand what they’re doing, rather than just producing code.
I’ve also worked with senior devs who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those 2 juniors.
They use it to explore things they don’t understand, ask me questions to clarify their reasoning, double-check assumptions. They generally use the tools available to increase their understanding.
Karrot_Kream 19 hours ago [-]
The same thing happened to mechanical engineering decades ago when CAD came onto the scene. I have a family friend of my parents' generation who remembers feeling like his "superpower" in solving fluidics differential equations completely went out of the window once solvers could handle everything he was good at. He survived and had a good career guiding engineers into using CAD correctly.
The way the industry "solved" it was basically raising degree requirements across the board. I went to a top 5 engineering school and one of my undergrad roommates was a mechanical engineer. I remember having a pretty eye-opening conversation with him about how their undergrad program just teaches them what is already commoditized in CAD application packages and is considered table stakes. Industry hires had MS minimums, and plenty of MechEs ended up getting PhDs so they could work on more cutting edge stuff.
My guess is software will end up similarly. The bottom end of this stuff will become purely commoditized and cutting edge stuff will require more education.
ehnto 2 hours ago [-]
I don't think I've seen any university teach anything but software table stakes. If even that. Fresh grads sometimes come to us having never actually written a program of their own volition.
ehnto 2 hours ago [-]
We sort of already did that though. There is basically no mentoring in software, juniors have to teach themselves, seniors are often just the juniors who managed to get competent enough to do the job generally, and are probably not the ones you want mentoring.
mkozlows 1 days ago [-]
It's true that developing junior devs is challenging (but it always was), but that's not what this is about: This is about the kind of not-that-good, mid-ass programmers who make up the silent bulk of the industry. The ones who have 20 years of experience, but who you still wouldn't trust to write fizzbuzz.
Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.
ehnto 2 hours ago [-]
Talented people should still be worried, the problem is not the developers, it's the type of work the industry can support. There aren't that many jobs that require above average software capabilities, and you're competing with all those people who just got shafted out of their mid tier positions but actually had talent. Hopefully there will still be enough roles for all these excellent engineers.
In the same way there is only so much artisan hand crafted furniture to sell, you're a lucky craftsman if you can make a living doing that these days.
rayiner 1 days ago [-]
Yeah. Technology and social change has done this all over the economy. E.g. from my dad's field, there's not enough public health people with field experience to replace the folks who are retiring. We have plenty of entry level people who can't get a job, but then there's a gaping hole in the pipeline between them and the graybeards who are retiring.
ddj231 1 days ago [-]
also who knows if prolonged ai development for years actually doesn't atrophy your coding muscles so to speak such that you are fully reliant on ai programming to get things done
gfody 1 days ago [-]
by then we'll have an mfc, instead of trying to get llms to write code our prompts will compile and execute efficiently. after that inversion "programming" becomes "using language to describe some processing" it's just writing. knowing a computer language of old helps but not necessarily
davidw 1 days ago [-]
It also ignores the effects of having a critical tool in the software pipeline controlled by a large corporation. That is an absolute sea change from the years when you could (and some of us did) run most of our software development on open tools.
Think about all the open source the world got from some random person in Finland or Sicily or wherever hacking on a cool idea. Will that still happen with a high (for someone who is not employed... maybe a student) monthly cost?
AnimalMuppet 1 days ago [-]
I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.
applfanboysbgon 1 days ago [-]
The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.
a34729t 1 days ago [-]
They'll become managers and PMs and TPMs instead.
Aurornis 1 days ago [-]
> Kind of like the fortran crisis of the last decade or so....
I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.
Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.
truckyday 20 hours ago [-]
> I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.
Most jobs involving Fortran I see are not looking for a programmer, software developer, etc. They're looking for a PhD scientist in whatever scientific/engineering domain they're in who can work on Fortran code. They almost exclusively want domain experts, excluding most juniors anyway.
SoftTalker 23 hours ago [-]
Pay them and they will. The problem with many people bemoaning the lack of Fortran and COBOL developers is that they are not willing to admit that the code they "need" to maintain isn't actually valuable enough to be worth paying what that maintenance costs.
It's like complaining that no mechanics work on carburetors anymore. Well some do, but they are expensive and not worth it to keep your old hoopty running. Might be worth it if you have a show-quality 1960's era muscle car.
StableAlkyne 1 days ago [-]
> This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code
I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it.
The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision.
I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.
unified101 11 hours ago [-]
> ask Claude if it makes sense to do X
This is a fantastic way of working with agents in my experience. It's like have a peer architect who can challenge you and help you improve. You're projecting your own feelings and fears by calling it infantalizing.
StableAlkyne 9 hours ago [-]
There is a world of difference between using it as a "peer architect" and outsourcing your entire thought process to it.
unified101 6 hours ago [-]
You're treating asking questions on everything as "outsourcing your entire thinking". It isn't.
StableAlkyne 2 hours ago [-]
This engineer would not do anything without asking the AI first. This includes extremely basic activities type hinting a function that takes a string and returns a string, which I know he knew how to do.
Sorry mate, but if that isn't outsourcing one's thinking then we live in different realities.
SpacePortKnight 1 days ago [-]
I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer.
I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
SoftTalker 23 hours ago [-]
By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).
Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
tayo42 24 hours ago [-]
My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
shimman 1 days ago [-]
Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
dzonga 22 hours ago [-]
you're one of the lucky ones.
usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.
very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
wetoastfood 1 days ago [-]
I agree the time it takes to go from planning to deployed is condensing. I'm not sure the hand off is no longer necessary (though it admittedly often feels like it). Perhaps it means we need better ways of planning and collaborating faster and on larger features? So you still end up with a hand off, but it looks different, is maybe more detailed, or spans a wider implementation than we previously might?
a2ff6eeb0 1 days ago [-]
I think AI is getting pretty good at generating the tickets as well. Not amazing, but it feels like ticket generation today is where code generation was a year ago.
I wonder if there's an agent harness that would work well for requirements gathering.
coffeebeqn 24 hours ago [-]
Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop
a2ff6eeb0 23 hours ago [-]
That assumes you're the one that's implementing it. If the agents get good enough at figuring out specs, I'd expect you could just pass it along to the next agent for implementation -- vibe coding today, vibe speccing tomorrow.
SchemaLoad 17 hours ago [-]
This is what the managers at my company think. But it ends up generating a wall of slop. I always end up scrolling to the bottom and looking for the original customer email or product request that was used to generate the ticket above.
JeremyNT 1 days ago [-]
> I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
I feel like this is a bit of cope.
Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.
dominotw 1 days ago [-]
what is so 'hard thinking' about building a crud app
florianherrengt 1 days ago [-]
Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.
graemep 24 hours ago [-]
The complexity I have seen in supposedly simple CRUD apps is amazing, especially what some less experienced people do.
bossyTeacher 18 hours ago [-]
[dead]
SchemaLoad 17 hours ago [-]
In my experience it's always the permissions system where messy real world business has to be translated in to SQL that doesn't lock up the system when some program admin added to 200 teams tries to load the index page.
"What can this user see" has always been a very complex question in every crud app I've worked on.
throwayay4929 1 days ago [-]
... And Django and React removed ("stole the jobs from under") the engineers handcrafting html and jQuery web pages/apps.
jameshart 1 days ago [-]
Django? Django is older than jQuery…
platevoltage 20 hours ago [-]
If you stopped learning during JQuery's heyday, You deserved to have your job stolen. This is not the same as watching AI ruin software platforms.
eshack94 23 hours ago [-]
This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM. And to never take shortcuts with learning. Learning is hard, but learning things properly allows you to understand what is happening and allows you to ask the right questions about whether the changes an agent wants to make are the changes that will best serve the goals of the project (without creating an unwieldy level of tech debt in the future).
Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.
In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
Valakas_ 10 hours ago [-]
"This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM."
This is a sentence that if written just 5 years ago would result in you being seen as crazy. "LLM capable of any sort of critical thinking? Haha. Not in 50 years."
It never ceases to amaze me how people are stuck in the here in the now and just accept the new reality as if it had always been this way, and will continue being this way in the foreseeable future.
This is the worst LLMs will ever be. Not outsourcing critical thinking to LLM will be seen as a liability in the not so distant future. Just a year or two ago almost no one even took LLM seriously for coding. Now the status quo has moved for also critical thinking, and we hear comments like this. LLM's chances of making a mistake will be orders of magnitude lowers than humans. Slowly learn to let the wheel go. AI will be much better at holding and controlling it.
"We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
palmotea 9 hours ago [-]
> This is the worst LLMs will ever be. Not outsourcing critical thinking to LLM will be seen as a liability in the not so distant future. Just a year or two ago almost no one even took LLM seriously for coding. Now the status quo has moved for also critical thinking, and we hear comments like this. LLM's chances of making a mistake will be orders of magnitude lowers than humans. Slowly learn to let the wheel go. AI will be much better at holding and controlling it.
If that's true, you're fucked. Because then what good are you for? How long do you think they'll pay you to be useless meat-in-the-middle?
Not outsourcing your critical thinking means trying to preserve a scrap of value-add for having you around.
> "We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
That's a dumb analogy. Automating one activity cannot be extrapolated justify automating all the activities, including some of the most human ones.
TrackerFF 3 hours ago [-]
We're moving toward a future where intellectual workers are, indeed, fucked. At least intellectual work will be the first real casualty.
I'm not AI maximalist. But with how things have progressed the past 4-5 years, I'm more confident on the above being true, than not.
I don't think intellectual work will drop off overnight. There will be a long period, perhaps decade or two, where many jobs will just gradually disappear, where salaries will be suppressed, and humans will just become AI-babysitters and auditors.
It is a uncomfortable scenario, but people - especially young ones about the enroll college or early in their career - should consider the possibility as realistic.
palmotea 3 hours ago [-]
> I don't think intellectual work will drop off overnight. There will be a long period, perhaps decade or two, where many jobs will just gradually disappear, where salaries will be suppressed, and humans will just become AI-babysitters and auditors.
What I'm sick of is this passive acceptance of technological determinism. Why build a technology that's so corrosive and so destructive to so many? You've got powerful people talking about creating a permanent underclass, and happily charging forward anyway. AI is literally the most anti-human thing ever, and should be opposed politically.
But there's been so much indoctrination it will be very difficult. For instance, software engineers were so fucking smug for decades, foolishly adopting libertarian ideas while imagining themselves to be capitalists. We resisted any efforts towards unionization to create translate our (former) economic power into political power. Now we're literally the first on the chopping block.
TrackerFF 2 hours ago [-]
Some see it as the road to dystopia, other see it as the road to universal basic income, and a less laborious future.
The real danger is not that AI becomes smarter. The real danger is that humans never learned how to justify their existence except through labor.
palmotea 2 hours ago [-]
> Some see it as the road to dystopia, other see it as the road to universal basic income, and a less laborious future.
A less laborious future is called mass unemployment. We have none of the sociological or ideological infrastructure to make that anything but a dystopia, and are making no progress on that front. Just look at what happened to the rust belt, what reason do you have to think things will be different this time?
If a happy, abundant communist future was in the cards, we'd have had it decades ago. The limit was never technological.
"Universal basic income" is just a sop to mute resistance to buy time while a small few grab most if not all economic power.
ATMLOTTOBEER 4 hours ago [-]
You need to git good
The fact that you’re nervous means you will be the first to be replaced!
palmotea 2 hours ago [-]
> The fact that you’re nervous means you will be the first to be replaced!
Is that sarcasm? Cause it's not too different from something I'd say sarcastically (e.g. it's very 10X AI engineer, very overconfident while missing pretty obvious things).
bluefirebrand 23 hours ago [-]
> In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
I know it's a cliche but the old IBM adage holds very true today
Machines should work, people should think
Maybe that's part of the problem I have with LLMs writing code. It would be nice if they just did the work, but there's a lot of underlying thinking and decision making with software work that is being offloaded any time you have the LLM do it
It seems like those decisions are being handwaved off as "not important" nowadays. Just let the LLM make those choices! But that is not sitting right with me for whatever reason. Something I should think about I guess
win311fwg 23 hours ago [-]
The decisions are important, but the understanding is that you define them as constraints. Which is what a segment of the software community, the upper class if you will, has always believed you should do, even before LLMs were a thing. The LLM simply becomes a constraint solver: machines do the work, people do the thinking.
This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.
bluefirebrand 20 hours ago [-]
> They aren't accustomed to working with constraint thinking
That's one way to frame it I guess
I would frame it as "they have been abused by AGILE and impatient PMs into never actually taking time to do constraint based thinking or design"
It is impossible to think about constraints, or really do any proper engineering, if you are constantly "sprinting"
Edit: I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go. I get that defining constraints and letting the software go is where a lot of useful emergent behavior lives, but I struggle a lot to think that way. Maybe I'm not wired right for software in the end
win311fwg 18 hours ago [-]
> "they have been abused by AGILE [...]"
That's ironic given that some of the Agile Manifesto signatories are some of the biggest proponents of constraint-based development. While the Principles behind the Agile Manifesto is not prescriptive, I am not certain you could, in practice, even satisfy many of the principles without constraint-based development.
> I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go.
Engineering is all about constraints. That you then shift to talking about constructing a building is curious as it would be atypical for an engineer to work on constructing a building. The engineer's role in building constriction is typically only in defining the constraints. Construction crews, made up of an entirely different group of people, then construct the building within the constraints set. "Constructing a building based on where walls aren't allowed to go" is essentially how buildings are usually constructed. It is an interesting parallel as the LLM is somewhat like the construction crew, which is something software hasn't really had before in any kind of big way.
Engineer gets thrown around pretty loosely in the world of software, but elsewhere, especially in places where failure can cause serious harm, someone who constructs a building by applying judgment, experience, and craftsmanship as they go would be considered an artisan, craftsman, or something to that effect rather than an engineer. That seems closer to the world you like to live in. There is nothing wrong with being a craftsman, of course, but the economic fit is becoming less clear as the industry matures. Which is something that seems par for the course. The early days of building construction was also dominated by craftsmen but as it matured engineers became dominant.
bluefirebrand 18 hours ago [-]
> someone who constructs a building by applying judgment, experience, and craftsmanship as they go would be considered an artisan, craftsman, or something to that effect rather than an engineer. That seems closer to the world you like to live in
Yes absolutely. I don't call myself an engineer, I'm a developer. Software Engineer is a title that my jobs give me, but I'm rarely given the time or resources to do any engineering.
It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
win311fwg 14 hours ago [-]
> I'm rarely given the time or resources to do any engineering.
Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary'?
Failure in (most) software isn't going to harm anyone, so there isn't much technical need for engineering in software. As I am sure you can attest, artisans are fully capable of delivering great software. Some of the best software out there was created by artisans!
The software industry is headed towards engineering anyway because engineers can build software faster, which is considered a virtue in business. That was true even before LLMs, but has become especially pronounced in this next era.
> It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
Understandable. I suspect a lot of engineers would rather be artisans—not just in software but in general. Artisans get to run at the forefront of new technologies and ideas before rigour is able to be established so it is, on balance, naturally more exciting.
bluefirebrand 13 hours ago [-]
> Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary'
I'm not certain of much these days, but I'm pretty sure of this.
Any time I have tried to properly "engineer" something with documentation and specs and planning I've been told to just deliver it instead
win311fwg 12 hours ago [-]
That doesn't mean your artisan ways aren't consuming time 'unnecessarily', even of it is an employer request that is driving the 'unnecessary' work. It's a bit like the employer asking you to clean the office for half the day. Your available working time is the same, giving you time, but it is being squandered on 'unnecessary' work.
However, it seems like both you and your employer both want artisans anyway, so it sounds like you have found a good fit. The software industry is putting more and more emphasis on engineers, but that is far from being universal yet (and will likely never be 100%).
gnarlouse 15 hours ago [-]
> NEVER
with critical thought*
fixed that for you, only sith's (and unreasonable people) deal in absolutes; you almost did!
rayiner 1 days ago [-]
Technology has been doing this for decades. I think a lot of our "K shaped economy" discourse is about the bifurcation of the upper middle class creating downwardly mobile educated young people. Nobody in my wife's immediate family finished college. She and all of her cousins are quite indisputably better off than their parents. My father in law drove a forklift at a soup factory. My sister in law is studying to be a nurse. It's a big step up. But the "white collar" middle class has become very winner-take-all. To use an example from my field, if your dad was a partner at a regional law firm, that path probably isn't open to you. Technology enabled consolidation and scaling, so you don't need lawyers in every city in the U.S. to be able to handle legal work there. Lawyers at national firms serving Wall Street clients are making more money than ever, but the drop below that has become pretty precipitous. The same has happened to small businesses all over the country competing with Amazon, etc. It's had a huge impact on the petit bourgeoisie.
Of course, this is economically efficient. Nobody is going to give up Amazon same-day-delivery so that some local small business owner's kids can live better than the median person.
matheusmoreira 6 hours ago [-]
Will it ever stop, though? I mean, why even try if social mobility has been destroyed? If we're the permanent underclass now, then there's no point in struggling against any of this.
tuesdaynight 3 hours ago [-]
The class consciousness from middle class lately has been funny to me. We always had poor people that were "permanent underclass" and middle class didn't care. They were not afraid of revolution or whatever we are afraid now.
If the bad scenario happens and 99% of the people becomes irrelevant to the economy, everybody will live their life's worried about basic necessities and smart hardworking people will be richer because your background or where you live or grew up doesn't matter.
Life is not fair. We should accept that AI companies and billionaires deserve to be aristocrats. They worked hard to create these conditions. In the end, it will trickle-down (this one I partly agree, irony aside)
matheusmoreira 3 hours ago [-]
> We always had poor people that were "permanent underclass"
I don't believe this at all. Social mobility definitely existed. It was at least possible to educate oneself and rise in society. Maybe the effort required wasn't equal for everybody, but it sure as hell wasn't impossible, because I've personally seen it happen.
That is fundamentally different from this supposedly K shaped economy world where it is literally impossible to rise. Education and talent don't matter anymore. It looks like the possible futures are either a post scarcity society or a cyberpunk dystopia.
tuesdaynight 1 hours ago [-]
> I don't believe this at all. Social mobility definitely existed. It was at least possible to educate oneself and rise in society. Maybe the effort required wasn't equal for everybody, but it sure as hell wasn't impossible, because I've personally seen it happen.
If you believe that, nothing will change much. It will still be possible, just the effort and luck required will be way bigger for the middle class to become rich. That's sad, but life is not fair and we are not entitled to social mobility the same way we are not entitled to housing, food and leisure.
If the cyberpunk dystopia happens, the trillionaires will live in the moon or Mars, and we will live here, maybe with shittier lifes, but that's on us. If we want to avoid that, we just need to become billionaires as well. Sadly, I'm too lazy for that, so I accept that it will never happen to me. I accepted that I will be "permanent underclass", because I don't see a reason for post scarcity to happen.
abnercoimbre 16 hours ago [-]
> It's had a huge impact on the petit bourgeoisie.
I always heard it as "petty" bourgeoisie and was a bit confused. Now I get it.
declan_roberts 1 days ago [-]
Between AI and competing against the world with H-1B, it's really never been harder to get an entry or mid-level software engineering job.
Which means our pipeline to senior engineer is completely broken.
whazor 2 hours ago [-]
I disagree with pipeline being broken.
Now with agents, you can get really bad (vibe coded) code bases in a week.
Before, to get this kind of experience, you had to work in a company for at least 2 or 3 years.
mikert89 1 days ago [-]
I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software, and the upper end will be filled with the top people in the country/from abroad.
Wages are certainly going down for most software roles
ryandrake 1 days ago [-]
> It will become very easy to build most software
We keep hearing this, but where is the Photoshop killer written by a gas station attendant? Where is the PayPal alternative written by a retired nurse?
Over and over we're told that software is now trivial to write, and Claude is evidently writing some billions of lines of code a day, but where are the results? Where is the vibe coded app toppling the legacy hand-coded monster product from 20 years ago?
tossandthrow 22 hours ago [-]
My non technical wife asked ai to brush up the photo for her cv.
Ai did that with whatever cli tools were available and what it would write itself.
Ai is not a faster horse. It is a phase shift.
We won't see a gas station clerk write photoshop because we won't need a photoshop.
squidsoup 20 hours ago [-]
The majority of artists abhor AI, this is a particularly bad example.
charlieyu1 7 hours ago [-]
I'm not sure how happy is a recruiter to see an ai photo in cv. Although they don't read cv themselves these days
tossandthrow 5 hours ago [-]
I am not sure what you are referring to?
A photo with adjusted cropping, background blurring, and contrast etc?
wildrhythms 3 hours ago [-]
Why are you sending a headshot in your CV?
johnnyanmac 16 hours ago [-]
Doesn't really answer the question. The relevant question with your example is "where is your wive's new business of brushing up other people's photos?"
edot 13 hours ago [-]
That’s his point, there isn’t one. You don’t need bespoke software anymore. We’ve got the basics already, all the standards we’d ever need, the agents can figure out how to put them together for whatever thing specific you need.
johnnyanmac 13 hours ago [-]
Well I'm not sure if that's a convincing premise, then. If micro libraries customized for the user's needs was all that was needed we wouldn't have most of the net moated out by overly invasive social media.
Even if people could find the tools, they won't seek it if a one button solution can come to them. But we can't outcompete Instagram in a prompt, nor some popular app.
joegibbs 6 hours ago [-]
There’s probably already a LibTouchupGl available since 2005, a perfect touchup tool in 83kb, but nobody had heard of it. On the other hand people can just say “ChatGPT do everything” and it can
tossandthrow 10 hours ago [-]
The issue is discoverability. Photoshop has that one magical button that solves all of your issues. But it is hidden behind specialized knowledge and a 10 step deep menu.
Agentic solutions just don't have these issues. You give them your image, that's it.
bossyTeacher 18 hours ago [-]
> We won't see a gas station clerk write photoshop because we won't need a photoshop.
100% agree. People are looking at the future through the lenses of the current paradigm just like when people from the past imagined the future (our present) in a way which we now find hilarious. Most of the time, the future doesn't bring developments which improve an action in a scalar way (faster, shorter, stronger, etc) but instead fundamentally change the nature of that action (handwritten letter communication vs video calls) or completely override the need for it (telephone boxes vs mobile phones).
johnnyanmac 16 hours ago [-]
And the issue here is that this future is bringing fundamental change to the nautre of labor without overriding the need for compensation in order to house and feed the populace. Hence the rejection.
pickleRick243 15 hours ago [-]
I notice your two comments straddle the contradiction "It's definitely not happening, but also it's terrible that it is."
johnnyanmac 15 hours ago [-]
Where was I saying it's not happening?
But if I can clarify my point. It's more that I'm trying to say "Company promises A is happening and B is the necessary consequences to achieve it".
I do not believe A is happening but B is occurring despite that, in order to achieve hidden agenda C. Though in this case, C is not that hidden since every other article has them blabbing out loud about "wow it's going to be so amazing when C happens!"
here,
A = AI is making us more productive than ever
B = This will cause impacts on jobs and the economy as a whole as we realign what labor is
C = Companies make more money than ever as it works towards eliminating labor on massive (90+%) levels in order to maximize profits and moating the idea of knowledge itself
unified101 9 hours ago [-]
If you think A is not happening for a software engineer's role, then you are mistaken.
We are all scrambling to figure out what else we need to do (and so are many other roles).
johnnyanmac 7 hours ago [-]
> If you think A is not happening for a software engineer's role, then you are mistaken.
En masse, I argue not. More productivity for engineers would not be met with mass layoffs if engineering production was why value was being added. On the contrary, other industries have had to hire back talent becsuse companies were too aggressive cutting people and needed that work to be done.
But I'm not an oracle. I can only speak for what I see today and won't predict tomorrow. Especially in these trying times.
unified101 6 hours ago [-]
You're reading too widely for a simple point I'm making: what an engineer did in Aug 2025, they can do in a fraction of the time in Aug 2026.
Everything else is something else you care about, but producitivty is simply proven for almost every engineer on the above point.
fatata123 17 hours ago [-]
[dead]
threatofrain 24 hours ago [-]
Why ask such extreme stuff? Why not ask about the solo entrepreneur who creates a convincing iOS app without a programming background? Advantage the problem on the side of ML and look for winning scenarios today.
mrbombastic 23 hours ago [-]
because this comment is responding to: "I think the field is basically over as a long term career unless you are truly exceptional. It will become very easy to build most software"
photoshop, paypal, and many more companies etc. have software of vast complexity that cannot be reproduced or maintained today solely with llms, ipso facto you still need software developers or some similar role to build and maintain the complexity of _yesterday_
some guy shipping an iOS app to zero users doesn't change that. although i think it is good we can have more bespoke software.
threatofrain 22 hours ago [-]
And today the line for amateur capability is being drawn at eager entrepreneur making an app on the back of Supabase and Lovable. The fact that iOS apps have zero users owes far more to sales and marketing than to software, so maybe that's where we should be putting our focus?
What can a mid level person do? Instead of a consultancy loaning out a team of 3-4 people, it might just be one person now. That could mean a lot of downsizing.
One thing mid level people wouldn't be counted on to do was create Photoshop or Paypal. The original thread is about top level pros being the ones who stay in the industry, right? That sounds about right if we're moving the conversation over to Photoshop and Paypal.
mrbombastic 21 hours ago [-]
this is a more reasonable argument IMO, but i would still disagree that that means only the top level pros stay for a few reasons (although it might happen / is already happening in the short term):
- if it is true that AI enhances our abilities it just means the goal posts move of what was expected for each level
- the complexity ceiling will rise for the level a superstar or a company is capable of maintaining, meaning there will still be stratified complexities for the mid levels of old to handle, it might just be higher than before
- counter intuitively but time and again increased software creation more often than not increases demand for more software rather than decreases
if the world decides it has no more problems to solve with software, then we are in trouble. i don't think that is happening anytime soon.
mikert89 23 hours ago [-]
You aren’t getting it. They can pay their engineers half what they used to, you don’t need the same level of skill to build photoshop. Yes, you need a bunch of engineers, but they will be driving coding agents, not writing code by hand. They can be hired and fired for cheap
jkman 22 hours ago [-]
Until the VC subsidies stop and the human devs are half the cost of the claude tokens lol
Moore's Law hasn't covered transistors in quite some time.
We get about 10% YoY now, which is actually impressive, but not even close to the past experiences. Computing power used to take 18 months to double, and was being attacked at a bunch of different angles.
Now we are literally out of tricks, to the point where we had to undo some of those tricks because they were fundamentally flawed, and it takes 100x the engineering investment to get that 10% YoY, or sometimes only every other year, and that isn't going to continue for much longer.
We can't increase clock speed much. We can't increase density much. We are out of clever tricks. It takes an entire earth's worth of human talent just to produce the machine that produces the chips. How the hell are people still insisting that computing power continues to follow Moore's Law?
Several of the limits we've hit are fundamental matters of physics.
Meanwhile, LLMs ask for orders of magnitude more compute than is cheap and cheerful right now. Do we even have a single order of magnitude left for compute?
kakacik 22 hours ago [-]
It won't be photoshop then. It will be shitty, buggy clunky app that costed a (major) fraction to develop but it will also earn a fraction. Companies like MS can afford this ie with Office suite but patience of markets and customers can allow them to go only so far, if ie Excel becomes semi-useless thats the end of Office and big cash cow for M$ (I'd say about time, that monopoly is not good for consumers at all).
This is in a way the same argument that all companies will use just boxed (albeit customized) software. In reality many, ie banks run their own custom software and for good reasons. Wake me up (in retirement) when any major bank decides to run their finances, regulatory stuff and transactions on llm-generated stuff made by underpaid devs like you describe.
mikert89 22 hours ago [-]
This is cope, ai coding agents will follow the path of self driving cars. They will be watched with extreme caution, but will slowly but surely expand outwards. Eventually manually writing code will be considered a dangerous/bug introducing act
2 hours ago [-]
cocoto 19 hours ago [-]
If AI coding agents follow the same path then any software engineer over 25yo can peacefully continue working for 30 years until the tech is capable. The comparison is futile…
deaton 18 hours ago [-]
I've yet to see this apply with self-driving cars.
johnnyanmac 16 hours ago [-]
>They will be watched with extreme caution
We're doing a great job of that right now, aren't we?
fatata123 17 hours ago [-]
[dead]
mrbombastic 22 hours ago [-]
[dead]
matheusmoreira 6 hours ago [-]
> Where is the PayPal alternative written by a retired nurse?
I'm a doctor and I'm building my own EMR system.
I've also been a hobbyist programmer for over a decade, but the point still stands because without LLMs I wouldn't have the time to even try it.
confidantlake 16 hours ago [-]
Software wins because of the sales team and the network effects. You could already create a better twitter or facebook that no one would use long before llms.
ex-aws-dude 23 hours ago [-]
Every time I see people say this I think: show me the money?
If its so good why aren't you rich?
SoftTalker 23 hours ago [-]
Why would anyone get rich doing something easy?
mrbombastic 22 hours ago [-]
Because the companies everyone claims are now obsolete are making a lot of money still doing the supposedly obsolete things?
codexon 19 hours ago [-]
Many of those companies like duolingo have already collapsed in stock price with YoY growth dropping off a cliff. It is happening, it just isn't instant.
batshit_beaver 12 hours ago [-]
And yet those companies aren't collapsing because it became easier to rewrite their software, but because llms themselves have replaced a core part of their business (such as translation or simple art).
Seems like so far the market is not convinced at all that SaaS companies as a whole are any more disruptable than before.
StrangeWill 2 hours ago [-]
That and talking to a lot of users, Duolingo reduced the quality of their service moving to LLM generated content -- a lot of people moved to other apps.
codexon 19 hours ago [-]
There are multiple "photoshop killers" already available, even for free like photopea. I would bet that you can ask AI to make a clone of it. People just haven't done it because there's no need to waste tokens on that.
eudamoniac 18 hours ago [-]
Then why isn't Photoshop killed?
codexon 18 hours ago [-]
Marketing? Who knows? I haven't used photoshop a single time ever since I found out about photopea.
pydry 24 hours ago [-]
In the "iceberg" of boring company systems I see working day to day I actually think delivery of production software has been slowed down. The cost of "writing" code went down a bit, while validation costs positively exploded.
There are definitely more apps developed these days but I haven't seen anything much vibe coded which actually seems to have staying power. Everything is prototype quality.
deaton 23 hours ago [-]
Now you can make a prototype without understanding what's going on internally or why the prototype wasn't good enough!
mikert89 1 days ago [-]
the future is already here, its just not evenly distributed
deaton 23 hours ago [-]
See this is the big issue I've been seeing. The only vibe coded product I can think of off the top of my head that's succeeding at all is Bun, and maybe I'm behind the times but it feels like Bun's success is mostly being pushed by Anthropic; I've yet to see much other than Claude Code use it.
codexon 18 hours ago [-]
There's very little incentive for people to advertise that their product was vibe coded. In fact there's many incentives to hide it. Many people hate AI and why would you invite more competition?
Bun gets a lot of hate for vibe coding.
I vibe coded to modernize one of my old hobby websites (so not even vibe coding from scratch) and I immediately got anti-AI comments, and I didn't even say I used AI.
johnnyanmac 16 hours ago [-]
Hope it keeps up, then. Social shaming is one of the last real hopes against this since government regulators are compromised.
codexon 15 hours ago [-]
There's nothing wrong with vibe coding as long as the quality is good.
johnnyanmac 15 hours ago [-]
>as long as the quality is good.
Well that's where we're seemingly at an impasse, no?
I don't even like the term "good vibecoding". The term was implied as a means to just let the computer type its own code and "go with the vibes". i.e. you have no deeper idea on how it works underneath.
Now, AI-assisted coding? It can be good. It can be a rush job. But the idea is that LLM's are in the passenger's seat, not the diver's. Much smaller chance where you have no idea where you're going since you're at the wheel.
codexon 15 hours ago [-]
The output is indistinguishable from manually written code.
johnnyanmac 14 hours ago [-]
I hope on HN of all places I don't need to explain the difference between "writing correct code" and "Software Engineering". We both know what a 20 year old million line legacy software needs.
codexon 12 hours ago [-]
Not everything needs to be amazon/google scale backed with things like sharded dbs or kubernetes.
johnnyanmac 12 hours ago [-]
Nope, not at all. But a million line codebase isn't close to Google scale. That's typical boring non-tech legacy code system scale. And I don't think I'm at a point where I'd want to vibe code my way though that and take responsibility for it.
weatherlite 1 days ago [-]
All fields are basically over as a long term career besides perhaps prostitutes and even there I'm not entirely sure.
But the questions of how soon and by how much matter a lot.
Being early is the same as being wrong a clever guy once said.
swat535 21 hours ago [-]
I hear you, but just to pedantic.. prostitution is certainly not a long term career either.. never has been. After 35, you're not going to find work as a sex worker..
ethagnawl 11 hours ago [-]
Depends on your definitions, I guess, but look up people who get busted for performing sex acts at massage parlors.
abnercoimbre 16 hours ago [-]
Can't believe I'm correcting you on HN, but MILFs and DILFs are a thing. (Granted you'll need the appropriate genes and gym fitness.)
weatherlite 5 hours ago [-]
> gym fitness
Not necessarily, there's a growing and somewhat untapped market for BBWs
confidantlake 16 hours ago [-]
It is over for me before it even started.
mikert89 1 days ago [-]
no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
IsTom 24 hours ago [-]
If you believe that I've got a halting problem oracle to sell to you.
weatherlite 24 hours ago [-]
Is it really that simple ? A programming function that has set inputs and determinstic outputs is rather verifyable.
A ten million lines code base is not easily verifyable. Knowing whether an agent is improving when it's working on a huge codebase is not that easy - it could easily start hurting code quality without it being clear in any output.
nanapipirara 1 days ago [-]
I think this is true.
A lot of AI believers (me too fwiw) seem to forget it’s a lot harder to ‘close the loop’ on non-code projects. I think this is because they are usually coders.
owebmaster 24 hours ago [-]
That's what all AI believers get it wrong about programming. Code doesn't create products, humans do.
palmotea 23 hours ago [-]
> no programming is verifiable, and the major LLM companies are focused on it. its the first domino to fall by probably 5+ years
Which is kinda proof they're populated by sociopaths with extremely little empathy. The people who are building that stuff are programmers, and if they had a tiny bit of functioning empathy they'd stop or slow down or at least be unenthusiastic.
And we're not talking about very high level empathy here, but the very basic kind of thinking about the effects on someone very much like yourself.
cardy31 17 hours ago [-]
People started saying this several years ago and yet it hasn’t really come to pass.
johnnyanmac 16 hours ago [-]
It's not over (far from it), but we certainly have spent the last few years shedding SWE's off by the millions. Try finding a new job as a SWE today.
Whether that is due to AI or other economic conditions is an exercise left to the reader.
mikert89 17 hours ago [-]
it certainly has, SWE wages have dropped and continue to do so
DataDaoDe 22 hours ago [-]
I agree. And I would remove the basically. I give it five years before essentially just a few very senior people are managing the whole cycle. Downward pressure on wages is just gonna keep ratcheting up.
dzonga 22 hours ago [-]
nah the world needs more software - it's just the delivery mechanism that's different.
we are entering the world of smaller service firms (1 - 3 people) - where technical chops will even get paid more. the age of cookie-cutter apps is over.
esafak 1 days ago [-]
Only if you run out of things to write. Is your back log ever empty?
ryandvm 24 hours ago [-]
My backlog is less empty than ever - it just happens to be overflowing with whispy Claude-written tickets for functionality that somebody else's Claude suggested after summarizing some other Claude-infused Slack chat.
mikert89 1 days ago [-]
ofcourse not, but they can pay someone 80k a year to work on the backlog, whereas maybe they used to pay 175k. its not about work going down, its the skill set needed to complete the work is lower than ever, and they need less people than ever
reactordev 1 days ago [-]
they won't even need that as agents talk to their own lanes in some Linear project management workflow that your sales team agents are connected. The entire system is going to end up agentic and even the CEO will be out of work unless they are founders and owners of the company. We'll all have our own business this way. Or it all collapses. Time will tell.
mikert89 1 days ago [-]
i think this is farther off, much sooner is just the subjugation of technical workers to be low skill drivers of LLMs
mrbombastic 1 days ago [-]
color me skeptical that the CEO or anyone non-technical is ever going to prompt their way out of a major incident when all the AI chickens come home to roost.
Tangurena2 1 days ago [-]
Maintenance will be forever. Tax laws change annually, so the payroll app will never stop being updated.
falcor84 1 days ago [-]
I don't accept that argument. As I see it, laws should be structured as data rather than code, using a clean non-Turing-Complete DSL for any embedded logic and calculations. Maybe there would still be occasional situations when new software features are needed, but it should be a rare occurrence rather than on every new change.
Terr_ 19 hours ago [-]
> laws should be structured as data rather than code
There was a submission a while back that might be relevant here: "Why Law Is Law-Shaped" (lawvm.org) [0]
People just need to add/subtract an input box and update the tax rates. They don't need an ontology of taxes and goods.
mejutoco 22 hours ago [-]
> laws should be
You are comparing what it is with what should be.
nwatson 1 days ago [-]
I'm hopeful that software will be applied in new areas where it was too costly before, with AI help it will be possible. Software will be cheaper, even more prevalent, lower quality in since respects, but SW engineering will still be a viable career.
stefan_ 21 hours ago [-]
There are really a ton of fields where people have done an absolutely terrible job of properly using the advantages of software, even pre AI. Like, even today there are people manually drawing footprints in PCB design software, manually determining what pins carry differential signals, manually forgetting to swap RX and TX lines..
except for the functions they absolutely had to have a computer do, they forgot to move out all the drudgery and footguns and continue operating in "PDF space". It's embarrassing for a profession that is supposedly made of engineers.
PDF space is still more advanced than the people typing into "word processors" however. Making software to emulate letters was such a massive mistake for the trajectory of computing, it let people effortlessly "adopt computers" by making a digital facsimile of their terrible analog processes. Only with AI we now have the ability to digest all this unstructured mess.
skinfaxi 1 days ago [-]
No one said there won't be work to be done, just that fewer people will be doing it.
esafak 1 days ago [-]
If the work to be done is infinite, why would there necessarily be fewer people doing it?
pjmlp 1 days ago [-]
Because most companies aren't software driven, they sell physical products and software is a cost center.
There is a budget and when it is gone, no contractors until next budget round.
andriy_koval 22 hours ago [-]
it could mean they are not completely out of automation opportunities, and will lose to more innovative players if won't invest into software.
The end state of these companies is grid of cheap robots controlled by software.
pjmlp 21 hours ago [-]
Exactly, because the amount of people on bench due to robots doesn't scale with the amount of customer opportunities.
There are only so much customers to chose from and all of them have finite budgets.
The exponential growth curve only exists in MBA books.
andriy_koval 21 hours ago [-]
In case of productivity surplus, exponential demand can be easily created by government: e.g. they print N trillions dollars, and say we spend it on some (hopefully useful) mega project(s): fusion, carbon capture, give nice home to everyone, fully verifiable, glitch free, hyper optimized software, etc. It will immediately create lots of demand, supply chains, customers, etc.
You can see current AI hype as example, and its government didn't step in and printed N trillions yet.
pjmlp 21 hours ago [-]
Sure, and I have a bridge to sell, to the same government.
Manfrednotfunny 1 days ago [-]
In a few years, it just might.
If maintenance and security is fully automated and for small changes or a small feature you will only dump some spec document into your agent platform, for sure.
mjr00 1 days ago [-]
> In a few years, it just might.
If you're in a product company and your development backlog is empty, run. That company is about to go out of business.
edukite 1 days ago [-]
Just another 6 months bro, only another funding bro, I promise, all devs will be replaced bro
I have stupid question here. Why they sell tokens instead of AI generated full application and AI fixes to your code without you needing a single dev?
Manfrednotfunny 20 hours ago [-]
Because of the current state of AI.
But the current state of AI is a very good indicator were it is going. Even if we don't achieve AGI, do you think AI in its current form will not be better in 5 or 10 years and we will have this solved a lot more/better than today?
Even with AI, you still need to design the software, test it, try it out, deploy it and scale it. An proper agentic platform still needs time to be build.
And the models need to be a little bit better and for that you want human feedback/reinforcement learning
edukite 19 hours ago [-]
Yes, I don't think this will be a lot better. Newest Claude is barely better, same with the rest of the model. In the same time cost of training new models and running them is increasing so taking this in the account I don't think this'll even last 5y
Manfrednotfunny 7 hours ago [-]
Tokens get cheaper and smarter every day.
This alone will lead to being able to run a fable class claude model 24/7 and potentially running something like this in parallel multiply times over.
johnnyanmac 16 hours ago [-]
>Even if we don't achieve AGI, do you think AI in its current form will not be better in 5 or 10 years and we will have this solved a lot more/better than today?
In my sector? No, not really. Because the core problem isn't tech, but labor rights. Those will only worsen.
pjmlp 1 days ago [-]
Because selling shovels is more profitable than digging holes themselves.
edukite 20 hours ago [-]
Really? Where do you live because in my country the opposite is true
pjmlp 19 hours ago [-]
In Germany, in this case selling shovels if you want to take the example literally is selling construction machines, or renting them, versus having guest workers digging the holes.
Naturally we can't use figures of speech.
edukite 11 hours ago [-]
Are you aware AI companies are subsidizing usage and have negative revenue?
And now your comparison is inaccurate. I said whole application. So the correct one would be selling/renting construction vehicles vs building entire building and here selling/renting is maybe 10% of developer income.
Digging a hole is like making small code change and if you wish to continue using this analogy then tokens are digging a hole and selling entire applications (thing Software house do) is construction company building entire building
Second obviously deliver more cash and here AI premise starts to crack. AI can't deliver anything good, costs much more than developing team (Uber proved it) and even if you use it as hard as possible and it does what it suppose to deliver max 5% increase across the board
Applejinx 1 days ago [-]
Wait.
edukite 20 hours ago [-]
I'm 40yo. Do you know how long I'm waiting? Only taking for an account this newest hype I heard like 4x next year and the current progress is slowing significantly over last year. Even foundings are starting to back off
pjmlp 1 days ago [-]
Yes, when the project budget runs out and contractor team has to leave.
johnnyanmac 16 hours ago [-]
My backlog is overflowing. My wallet, however, is depleting.
dauertewigkeit 1 days ago [-]
For some reason people never mention this, but aren't there also much more people graduating with CS degrees than ever before?
WarmWash 1 days ago [-]
Pretty much no other engineering field made sense to go into for about a decade. Even kids who did go EE, Mech E, or even Chem E ended up taking software jobs. The pay, benefits, and work/life balance of SWE just absolutely obliterates everything else. Or did at least
no_input 23 hours ago [-]
Exactly this. Went into physics but the academic landscape is hell so shipped off to SWE.
truckyday 20 hours ago [-]
Exactly why it's got to be broken now
doctorwho42 1 days ago [-]
And how do you think people go from fresh graduates to senior devs?
whateveracct 1 days ago [-]
Degrees take 4 years. It's a very laggy indicator.
francisofascii 23 hours ago [-]
Right. CS Enrollments dropped 8% this year. High schoolers got the message.
AnimalMuppet 1 days ago [-]
People can switch majors.
But despite me saying that, I think it's going to take longer than four years. It takes a while for people to realize that a dream is dead.
nwatson 1 days ago [-]
Some companies hire junior devs to adopt AI-first practices to then drag their seniors in the same direction.
pydry 24 hours ago [-]
This is a reliable recipe for turning your systems into an absolute clusterfuck.
whateveracct 24 hours ago [-]
should be a fun decade :)
AnimalMuppet 1 days ago [-]
Juniors to push the accelerator, seniors to pump the brakes. It could work.
bryzaguy 1 days ago [-]
What if the new entry level is what we consider senior today? Isn't it possible today to obtain entry/mid level skills with LLMs? I wonder if things will shift more in that direction.
unified101 9 hours ago [-]
Already seeing it in many places.
docmars 19 hours ago [-]
Even the senior, staff, and principal levels are a wild gamble where you're lucky to get any acknowledgment after applying, even with a strong profile.
lnrd 22 hours ago [-]
[flagged]
logicchains 21 hours ago [-]
It's not a scapegoat, it's basic economics that wages are determined by supply and demand; increasing the supply decreases wages. It's also basic economics that this ultimately reduces costs to consumers, but that doesn't make it any less painful for the workers whose wages face downward pressure due to increased competition from labor force growth.
lnrd 21 hours ago [-]
Never heard the words "basic economics" used outside of strawman political arguments.
To think that H-1B developers can meaningfully shift the supply to the point that is felt by other people it's very shortsighted. The job market has been very difficult for years with vastly more supply than demand and its due to plenty economic, financial and political reasons. Interest rates itself affect it way more than any H-1B developer could ever do it. If you were to actually sit down and look deeply into it and look at the data, I'm sure that H-1B would be a small percentage of the problem and you would get fired up about so many other things.
But that's difficult and time consuming, if anything it's advanced economics and requires effort to decode what's happening. What it's very easy to do is getting angry at a group of people and to feel deep unfairness about it, then think that if that group of people were to leave, the problem would improve or be solved. That's exactly the kind of thought that seems to be so pervasive at all levels and yes, it is a scapegoat.
Especially since that the only merit someone has over H-1B is to (by pure chance) having being born in a different place. I really feel that many people complaining against H-1B wouldn't even qualify for it if they were born somewhere else.
gadflyinyoureye 20 hours ago [-]
There are approximately 250,000 to 300,000 H-1B workers in software development in the United States at any given year. No the general idea behind the program is that these hundreds of thousands of individuals are so highly skilled that there are no Americans able to fulfill the role. While I fully agree with you on all the topics about financing and interest rates, here’s my question: would there be as slow of a market for software development if those hundreds of thousands of individuals were not here? There was a court case that showed the H1B visas reduced salaries by about 30%. The court ruled that 30% is not a large enough number to say that it has a negative impact on the market. Others disagreed.
TMWNN 19 hours ago [-]
>Never heard the words "basic economics" used outside of strawman political arguments.
Only someone ignorant of basic economic concepts—such as, in this case, supply and demand—would write the above.
davidw 1 days ago [-]
People have been fretting about 'foreigners' taking their jobs for decades and it never really happened. This is all about LLM's.
I mean, think about it; just a few short years ago there was a very strong market for software engineers, despite outsourcing and immigration being very much part of the landscape.
mikert89 1 days ago [-]
have you been inside any big tech company? lots of orgs are > 80% foreign.
a34729t 1 days ago [-]
Yeah my new VP is from a certain country in the eastern hemisphere, and the interviews I've conducted for US-based candidates oddly enough have been 100% of engineers from that same country (say 30 or so in the last 2 years).
andriy_koval 22 hours ago [-]
I hope one day there will be huge class action lawsuits and prosecutions given how clearly obvious this issue is.
davidw 1 days ago [-]
That's not actually true; people have been complaining about this for decades, and it's never been the zero-sum game that they claim it is.
What has changed is 1) the zero interest rate environment went away and 2) LLM's.
mikert89 1 days ago [-]
ive worked at multiple FAANG, almost always been the only american on a team of 10. theres some huge push by corporations to deny it to justify shipping in more foreign labor.
22 hours ago [-]
johnnyanmac 15 hours ago [-]
This doesn't explain the whole story because 1) despite the accusations of "overtiring", none of these companies actually have decreased headcount over the last 5-6 years. They have all grown, though perhaps not in North America. 2) LLM's have not been shown to significantly replace current work as of 2026. The most optimistic projects is that it could do maybe 5% of current jobs. That doesn't match the current death in hiring and mass layoffs.
chaps 1 days ago [-]
Orrrrrr... it could be a complex combination of outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring, etc etc etc.
I was very fortunate to get a job in a NOC a little bit after high school where I learned things one'd expect to learn in an entry level job. The team I worked on was all about mentorship, learning, and building people to the next level.
Haven't seen that attitude elsewhere in my entire career except in the non-profit world where I reside these days. It blows me away that people are surprised that these industries have failed to build entry level positions.
mattkrause 1 days ago [-]
I'd also throw in hiring practice. Whatever we're doing (across the board) to find candidates seems....less ideal.
johnnyanmac 16 hours ago [-]
given the statistics in ghost jobs, you can argue what we're doing is "nothing".
davidw 1 days ago [-]
> outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring,
Which of those things changed (along with higher interest rates) in the past few years though? All the other variables did not change. They were present 5 years ago and present 10 years ago too. To me that's indicative that those factors are not the cause of a soft market for software engineers in 2026.
chaps 23 hours ago [-]
Are you seriously suggesting that ten years of a systemic failure to mentor the new generation hasn't had an impact on the culture of mentorship?
davidw 22 hours ago [-]
Are you saying that precise thing changed 10 years ago and hasn't always kind of been with us?
I am talking about the weak market for software engineers right now and what caused it.
chaps 22 hours ago [-]
Erm, no. I'm saying that the entire industry failure to cultivate a wide spirit of mentorship is biting everyone's ass.
davidw 22 hours ago [-]
I mean that could also be true, but it is not - IMO - the cause of the fairly sudden weak market for software engineers.
chaps 22 hours ago [-]
IMO it is and I've been saying it for more than ten years that it would catch up with the industry. And it is now. The LLM shit is just a mask over the larger problem.
The front fell off because the base was never built to support a shakeup of the industry. There's so little support, now and for as long as I can remember, for people to fail gracefully in the field. It's just up up up. And now that programmers are finding their jobs to be a little more precarious, maybe folk will start supporting mentorship as a practice.
This isn't just a "market" problem. It's a problem of people not teaching others skills that help them thrive inside AND outside of work.
nsxwolf 1 days ago [-]
My job was just taken by Cognizant, which is technically American, so I guess you're technically right!
johnnyanmac 16 hours ago [-]
>just a few short years ago there was a very strong market for software engineers, despite outsourcing and immigration being very much part of the landscape.
A lot changed very fast in the last few years. It's not all nor even a major part due to outsourcing/immigration. It's a myriad of factors all colliding at the same time.
iLoveOncall 1 days ago [-]
There are 100K H1-Bs a year and 4 million grads a year in the US. Anyone who thinks H1-Bs are actually contributing to their inability to find a job is a moron.
weatherlite 1 days ago [-]
But those H1Bs all come for a very narrow set of work - mostly software development or other adjacent roles. So your 4 million figure that counts all graduates in all fields doesn't make sense when we talk about tech.
There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?
iLoveOncall 1 days ago [-]
You're counting only CS bachelors, in reality there's 400K graduates a year in software engineering fields.
There's also only 60,000 H1-Bs a year for private companies.
Lastly the majority of H1-Bs doesn't go to software engineering jobs, it's around 30-50%.
There's also basically no US company hiring juniors via H1-Bs, so yeah, I'm saying it doesn't make any meaningful impact.
30K H1-Bs versus 400K grads...
BeetleB 22 hours ago [-]
> There's also only 60,000 H1-Bs a year for private companies.
Actually, more like over 80,000. They have a separate pool for people with advanced degrees (MS or higher) in tech fields.
Agree with everything else.
weatherlite 1 days ago [-]
The way you handled those numbers makes me think you have leadership potential, perhaps even U.S presidency material
KetoManx64 24 hours ago [-]
-85,000 NEW visas granted each year, not including renewals
- The mass majority of those are going into the tech/software
- there are only around ~100k CS graduates each year
- H1B workers will take much lower salaries and benefits than their US citizen counterparts.
declan_roberts 22 hours ago [-]
And H-1Bs are easier to overwork and abuse because the threat of deportation and the dangling carrot of citizenship are very powerful motivators that don't exist with US citizens.
mikert89 1 days ago [-]
have you been inside a big tech company? there arent many american fresh grads working there, its mostly foreign
iLoveOncall 1 days ago [-]
[flagged]
fl4regun 1 days ago [-]
IME many big companies are filled with mediocre morons, or at least people who just don't care enough to do better than mediocre. Still not the fault of brown people either way.
shimman 1 days ago [-]
Why are you bringing racism into the equation?
It's not an unreasonable thing for people of a country to think that the government should do more to protect their livelihoods over a corporation's balance sheet.
fl4regun 1 days ago [-]
perhaps if you read the comment chain you would realize I'm not the one who introduced this into the conversation. Sorry that you disagree with my position.
shimman 1 days ago [-]
wow I did not read this thread fully, my bad.
throw-the-towel 1 days ago [-]
Can't help but laugh that even Amazon has someone who defends its honour.
mikert89 1 days ago [-]
hahaha i was laughing too, of all companies for someone to defend
ryandrake 1 days ago [-]
Every $1B+ company out there has at least one person on HN eager to passionately praise and defend it online. I've never understood it. People get devoted to a company like it's their religion.
iLoveOncall 18 hours ago [-]
I don't care at all about defending Amazon, I'm just correcting a completely false statement about H1-B visas, and answering a guy who claims something about big tech while myself being in big tech? I guess reading comprehension is just disappearing with LLMs.
WarmWash 1 days ago [-]
>The reason you're not getting a job at Amazon isn't because of brown people,
The correct framing is "The reason you're not getting a job at Amazon isn't because of people willing to work for less money,"
1 days ago [-]
iLoveOncall 1 days ago [-]
The compensation bands and the actual compensation are exactly the same regardless of immigration status.
snovymgodym 24 hours ago [-]
Bands yes, packets no.
Big tech companies aren't like a Government job with rigorous pay grades based on role and seniority. You can have people even within the same role and level at big tech with multiple $100k pay discrepancies.
If someone's continued ability to stay in the country where they currently live is contingent on employment then they will accept worse conditions and pay.
That's the entire reason why tech companies use H1B, it's not as though there's a dearth of Java developers or DevOps people who are US citizens.
mikert89 1 days ago [-]
amazon is crammed full of indians, its one of the worst offenders. i spent 5 years at the company
also nothing impressive about a senior SDE there, maybe 10 years ago it was impressive, best talent has either moved on or is L7+
weatherlite 1 days ago [-]
What's wrong with being mediocre?
calculatte 17 hours ago [-]
No it is true. But H1B is only a portion of it. OPT is unlimited and gives the employer the incentive of not paying FICA tax. Plus OPT candidates are willing to accept a fraction of the salary in the hopes that they can convert to H1B. Plus there are several other visa types being abused H4 EAD, CPT, O1.
On top of all that the commonplace practices of ethnic nepotism and hiring kickbacks.
I think many engineers are extremely naive about what is going on in the industry, which is why these abuses only continue to increase.
insane_dreamer 1 days ago [-]
Spend some time processing tech job applications and you’ll realize you’re wrong
declan_roberts 22 hours ago [-]
Take a walk through South Lake or San Francisco and he'll realize he's wrong.
jayGlow 19 hours ago [-]
only about 100k of those 4 million graduates are in computer science. more candidates applying for a limited number of jobs makes things more competitive and difficult for those applying understanding that doesn't make someone a moron.
aabdi 1 days ago [-]
> You were never expected to understand every service and every database. But at least someone did and would explain it to you.
I agree with most of this except this. Think there’s some rose tinted glasses here or I’ve got bad luck over time.
Life before ai was bad as well. There wasn’t any one to explain to you anything! You had to figure it out yourself. The people either already left or was busy with something else.
No one wrote tests (to my standard). Most of the ops works was skipped. Docs were just not there. Nobody linted properly. Just bad mannnn
estetlinus 22 hours ago [-]
+1
the vpn is called dev-test-prod and some containers are stored in a dev subscription, but still used in production. Some intangible network error forces you to use the production cluster for testing (the bucket is at least called test).
I feel this kind of setup is invariant everywhere I go to do engineering. Fable level intelligence has no effect!
Kuraj 22 hours ago [-]
If there is any positive to be had from this, it's that we finally started documenting the codebases for AI as we should have always done it for other teammates.
uncivilized 23 hours ago [-]
It’s just the typical BS where a Hacker News wants to feel smarter than they are
whywhywhywhy 1 days ago [-]
>AI makes projects with weak engineering culture fail much faster.
>There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
>The most tragic aspect of this way of working is that, to the untrained eye, it works.
>If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Isn't this the opposite of failing faster, it lets people who would have never made it past the first few hurdles and give up get deep in and then the false hope that they can then prompt their way out of whatever mess resulting in deeper and deeper spaghetti.
florianherrengt 1 days ago [-]
But now they can now move so fast that nobody has a realistic chance to stop them before the damage compounds.
They get into a much deeper mess much faster.
barbazoo 1 days ago [-]
We always talk about damage, what's the damage here?
florianherrengt 19 hours ago [-]
Corrupted or lost customer data, security vulnerabilities, incorrect financial transactions, regulatory breaches, production outages, irreversible migrations, important product change effectively impossible without a full rewrite. Every feature takes longer, incidents take longer to resolve. Engineers spend their time fighting the codebase instead of building things, burn out and quit. I could go on forever.
flatline 1 days ago [-]
You deploy an application that ostensibly has the desired capabilities but it fails at scale, or the architecture is not extensible to add new capabilities or fix bugs. Those are expensive mistakes and in safety-critical domains could be deadly.
The thing is I've worked on plenty of code like this written by humans. AI just accelerates the process and puts this type of code within reach of more people. It could be seen as a step backwards in good software engineering practices we've painfully learned over the last two decades. I see it as a cycle repeating itself in a new iteration, with the hope that we'll end up with still better tools and processes in another few years. But I agree it can and will result in real harm in the meantime.
whywhywhywhy 1 hours ago [-]
Time lost when the real developers have to pick up the pieces and the viber has just moved on to the next shiny thing.
josephg 1 days ago [-]
A giant pile of unmaintainable, brittle code nobody understands. At some point, even LLMs struggle to make changes without introducing bugs.
danparsonson 1 days ago [-]
Code that accidentally ships every 100th order out for free... exploits releasing customer PID and causing regulatory nightmares... self-driving cars that reboot at 70mph... The only limit is your imagination!
Kinrany 1 days ago [-]
For example, doing a marketing push assuming that the app works, and then having it fail in trivial ways at release.
jayd16 1 days ago [-]
Waste of time and therefore money is a big one.
greenavocado 1 days ago [-]
The next decade of software consulting will be defined by repairing the Big Ball of Mud https://www.laputan.org/mud/
whateveracct 1 days ago [-]
> Now they can just prompt an agent for a few hours and open a PR.
Bruh..I haven't consistently sat at my computer for even a hour at a time to code for a decade..people spend that much time in Claude??
whateveracct 11 hours ago [-]
from the downvotes, it seems that people do spend more time in Claude than I do meatcoding. "Efficiency gains" lol
level87 19 hours ago [-]
It’s difficult to have spent a long time learning something, only for that thing to suddenly become accessible to anyone; something that was once scarce and valuable is now abundant and cheap.
There are still machinists doing things by hand, but for real production or prototyping, most will now use a 5-axis CNC machine. It still requires an operator of sorts, but much of the work that once required skilled manual machining is now done by CNC.
I think the same thing is happening here; it’s just that the transition is messy.
Give it five years, and how we get to the end result will not matter nearly as much as it does now. A messy codebase will be irrelevant, as it will be something managed and controlled by the LLM, written in a way optimised for itself, not for you or I.
edot 13 hours ago [-]
My understanding of manual machining in the modern day is that only really big or really specialty jobs (as in, just a weird process that there isn’t a good CNC machine for) are done manually anymore. But specialty and low volume, which is exactly where LLMs are nice because I can spec it exactly how I want. I wonder what the software equivalent of “big” is. Like, you need a part made on a lathe with a 3 foot diameter throat, only one guy in a 500 mile radius has a machine that big, from 1962, so he’s your guy. That guy can stay in business with manual machining. But standard, high volume parts need to be on CNC to be competitive.
DC-3 6 hours ago [-]
The equivalent is probably weird, proprietary DSLs / standard libraries that AI has not been able to ingest so it performs poorly on. But maybe these days LLMs don't even really struggle with these sorts of domains.
edot 4 hours ago [-]
Yeah I’d have to imagine that as long as you have the same fundamental ideas (variables, functions, loops, arrays, etc.) the syntax doesn’t matter at all. Plus it can just try, see and error, and read the error. I doubt there’s a language out there that they haven’t a) ingested and b) can’t handle.
I think perhaps the equivalent would be “this environment quite literally can’t support having an LLM attached to it”, as in say some totally airgapped AND low-performance things (industrial computing, PLCs, military stuff, etc.).
solomonb 17 hours ago [-]
But CNC machining still requires a ton of physical skills. Its true that you maybe aren't planning out and executing every single tool pass by hand but there is still a tremendous amount of knowledge and physical skill that goes into setting up, indicating parts, etc.
spaqin 10 hours ago [-]
I never found a competent metaphor for LLMs taking over. Any tool brought up before still required skill and thought, and deep knowledge of its intricacies.
rootusrootus 17 hours ago [-]
> it will be something managed and controlled by the LLM, written in a way optimised for itself, not for you or I.
At that point we might as well invent an LLM-optimized language to use.
Chance-Device 18 hours ago [-]
This is exactly right, thank you for saying it. Nice example with the CNC machine too.
johnnyanmac 15 hours ago [-]
> how we get to the end result will not matter nearly as much as it does now
Sure, just wait for the poors to stop rebelling. It will all be over soon.
mancerayder 12 hours ago [-]
I'm simultaneously frustrated and I see a business opportunity - I now know that we senior folks are very far from replaceable - and soon there might be consulting to fix big problems. No one will say it's AI's fault necessarily - you'll just be living with painful complexity that works for a startup or an individual entrepreneur but not in an enterprise environment. To wit:
>The person adding Kafka should have been able to explain exactly why it was needed.
Here it is. People who don't know what they are doing are adding infrastructure layers they don't understand, can't envisage operationally in the future, and missing scalability. I'm seeing this. In fact I'm spending hours a week fighting it. I had to set up a call with a senior developer recently to explain why his prescriptive attempt to make infrastructure changes in his project can't be done with Claude like he did it.
It's playing wack-a-mole as the "velocity" has gone up of changes, and it's promulgated by every manner of product manager and senior developer under an attempt to please the brass.
>The person who built the feature should have been able to explain where the data came from without sending a link to a Claude conversation.
And they won't - because it's too embarrassing when you see what Claude responded with and someone failed to question.
We're in a new era, that's for sure.
xvilka 23 hours ago [-]
Now the question is - no one was born good or best engineer/programmer/scientist. Often it was a long path of sleepless nights, daily grinding, failing million times, doing dumb mistakes along the way, the usual package of suffering sometimes called "experience". What is the path now for the next generation of good or best engineers? There will be no opportunities/budget to do the same anymore.
doron 22 hours ago [-]
"The underlying purpose of AI is to allow wealth to access skill, while removing from the skilled the ability to access wealth"
logicchains 21 hours ago [-]
AI gives the skilled more ability than ever before to create wealth; they can realize an idea by themselves and a few hundred dollars of LLM spending, that would previously have been out of reach for anyone lacking the capital to hire 5-10 people.
efields 20 hours ago [-]
I agree with you in theory, but wealth goes hand in hand with relationships. If you can use your skills to make something great with AI in a short amount of time, someone else probably do it too. If they have better connections than you do, they win. Relationships get you farther than raw skill.
plaidfuji 20 hours ago [-]
This assumes that writing standalone apps (what is now implied by “realizing an idea” in the AI hype-o-sphere) still has defensible value
johnnyanmac 15 hours ago [-]
You make the naive assumption that wealth these days is generated through quality products, talent, and hard work. The wealthy know better and that's why they by far profited the most off of AI.
Kinrany 22 hours ago [-]
That's not an interesting question, it'll be the same path as before but somewhat longer.
johnnyanmac 15 hours ago [-]
a depression followed by rebellion by the public that requires the armies to be sent in to quell the working class? And after several campaigns of rebellion (and much unnecessarily spilled blood) the governemnt finally does its job and offers proper social protections and regulations so the working class can survive?
liendolucas 21 hours ago [-]
I have witnessed first hand this and must say is a disaster, the person that came up with a fix to an issue that I didn't understand tried everything to convince me that the automated fix works.
Indeed the fix did work, but when I asked him to explain me the problem and the fix he started to use the prompt to get answers.
At that point I just let it go, the only thing that I mentioned later on is that I'm ok with pushing that to prod if that was ordered to me but I'm not responsible for it.
I prefer to keep the bug live until I fully understand the problem, reproduce it, come up with a solution and maybe just maybe perform a check against what a computer generated.
Please note that the bug came from a real human code base but being complex and not familiar with that part of the code (moreover the code was handed to us without any type of support/documentation) rendered me in a weak position where I couldn't come up with a solution so far.
How can someone trust so much a computer generated hotfix without fully understanding a problem is what still baffles me.
Still resisting to use any aided coding, no LLM is not going to steal the capacity to use my brain. The day I'm forced to used these tools, the day I quit.
efields 20 hours ago [-]
This is a problem for sure. I don't care what writes the code, but if I commit it or approve the merge, I need to be able to explain it, full stop. I don't need go line by line, just point and explain this does this does that which leads to that.
If "can you explain this?" is a question a direct report has to put into a prompt, they are failing at their job.
20 hours ago [-]
petcat 1 days ago [-]
I think it is less about junior/mid engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
I’d expect that layer of the industry to shrink substantially.
Although, I don’t think immigration or country of origin is particularly relevant here. I never worked in the US but there are plenty of "assembly line" developers here in London too.
If your job is essentially taking a ticket and turning it into code without contributing much else, then yes, I think that category of developer is going to be decimated.
That applies equally to everyone.
sameesh 1 days ago [-]
What's with people using the number "0" for their first reference? I have only ever seen that practice here at Hacker News.
ebb_earl_co 1 days ago [-]
Lots of (most?) programming languages are 0-indexed so it feels natural for software developers and our ilk.
SoftTalker 23 hours ago [-]
Not really. 0-based indexing is different from counting and starting with 0 in a counting context is weird. Would you ever say a set has zero elements when it actually contains a single element?
ebb_earl_co 16 hours ago [-]
It's a remarkable coincidence that I'm reading the book The Nothing that Is: A Natural History of Zero by Robert Kaplan, and this passage on page 96 seems precisely relevant to this situation:
"""A Roman idiosyncrasy about counting reinforced this
avoidance. The 360 degrees of longitude, for example, were
always measured from the vernal equinox, which lies in the
zodiacal sign of Aries. This should be zero degrees, 0°. It was
common, however, to call it instead 'the first degree', Aries 1°,
as Pliny did around 60 AD, upsetting his calculations and those
of many who followed him. It amounts to this: if you lay out
four marks on the ground and step from the first to the last,
have you taken three paces or four? Clearly three; yet four
marks were involved. To get the right answer it helps to call
the starting-line 'zero'; then the number at the mark you step
on will correspond to the number of your steps. But the Romans
counted so that three days after Sunday was Tuesday; the Italian
for the fifteenth century is the quattrocento — and all of us still
call the two steps in music from C to E a major third, taking
the number from the three tones involved."""
I wouldn't say that the set that has one element, labeled 0, _has_ zero elements; it has one element with the label 0. Right?
People should realize that programming is not a liability.
Programming per se is the actual creation of detailed knowledge by writing.
You get a task, how does it interact with all other invariants?
What are the implications on data flow, processing and user workflows?
You can rarely answer those questions beforehand, you step on them during programming as the formal language forces you to take them into account sooner or later.
If you outsource this knowledge-building you’re losing the steering ability when stuff hits the fan.
You lose the ability to navigate the code properly in order to identify bug or violations of invariants.
LLM optimize locally, that’s their nature.
Invariants are often implicitly scattered around the whole code base.
Explaining them to the LLM is much more tedious than just to write the code in the first place.
At least for me as I have much better expression-ability in Code than in natural language when it comes to describing any form of computation.
rootusrootus 17 hours ago [-]
Do we yet have actual, irrefutable evidence of SWE job losses attributable to successful implementation of LLM coding agents? They've been around long enough and management has been horny enough about the whole thing long enough that we should be able to point to some notable examples.
danans 11 hours ago [-]
I've seen examples of non-hiring: new teams that are staffed at half or quarter the headcount that they would have before LLMs. Are those job losses? Maybe not. But they are much lower hiring relative to the amount of software engineering output.
antinomicus 17 hours ago [-]
So far my experience has been management shoving ai haphazardly down the throats of any semi technical person across the board, resulting in a fragmented hodgepodge of vibe coded frameworks and “ai apps” that pile on more requirements for more human attention to make those apps at least look superficially functional to management, than actual reductions in man hours saved by those vibe coded crApps.
I believe wholeheartedly that things like Claude code bring immense value but to management types they aren’t visible enough to prove their “ai first” narratives resulting in a bunch of crap they have us build that look and seem smart but in fact are just slop we have to deal with the consequences of. Good for job security I guess, but I’m getting pretty tired of it all.
rootusrootus 17 hours ago [-]
So far I'm finding that in a good subset of my regular work Claude can be pretty useful and will speed me up. But I also drive it with a heavy hand. Strong expectations, I know what I want, what success looks like, and I steer it to give me that.
Conversely, the product guys I work with are adept at producing proof-of-concept tools that look really good. Fake data, runs entirely in a browser, but conveys their goals way more specifically than Balsamiq ever good. And I think this is a great use case for Claude.
But what ain't happening here is product guys producing code that would go directly into production. And even if it could, they're not in a position to provide tech support or debugging when it breaks, so they don't want to be in that position anyway.
Nobody can really predict the future very well, it seems, but my personal best guess is that we end up moving the boundaries of what we work on and how, but the need for humans isn't going to go down. As magic as LLMs look sometimes, I constantly run into reminders of how much it relies on how I phrase a prompt when it delivers any kind of answer. That influence really drives how satisfying the results are.
ex-aws-dude 17 hours ago [-]
Literally none yet people keep stating it like it’s fact
Every layoff just automatically attributed to AI even though they have nothing to do with it
rsanek 12 hours ago [-]
> You were never expected to understand every service and every database. But at least someone did and would explain it to you.
This hasn't been my experience. Especially when it comes to enterprise software, eventually everyone that was involved with the design of and iteration on a system will have left the company. Yet, often those systems need to continue running because they support "legacy" customers (who sometimes actually tend to be more economically valuable to the company than the customers on the shiny new system).
Before AI, in these cases you just had to dive into the code and start trying to understand it yourself from zero. Usually, you would come to a very limited understanding of the system, just enough to fix the latest bug or keep it running until it hit another issue.
I'm not sure why it's necessarily worse to rely on an agent to do this for you these days.
hn_submit 1 days ago [-]
Look, stupid companies who use A.I. to generate their code will simply fail. Companies that use bright engineers to engineer their product and write code (and pay them accordingly) will thrive and thrash the competition.
Darwinism in action.
I don't believe A.I. will change much, but it will lead to winners and losers, that's certain. Lessons will be learned, A.I. will remain but play a minor role, just like IntelliSense and ReSharper.
People need to understand that when things break management will hold you accountable, not the A.I. If you can't fix it you'll be out of a job. So you'd better make sure that you understand the generated code and clean it up before putting it in production because you'll be maintaining it.
tantalor 1 days ago [-]
> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.
Bad news: by delegating the thinking to somebody else (Claude) you have become the management.
trey-jones 1 days ago [-]
This is exactly how I feel about my job now. I'm the new manager. But honestly claude is better than any team of developers I've ever had working under me. It does exactly what I ask it to, in 10 minutes instead of 3 weeks. And apparently we can't afford a development team now anyway...
I'm not working at massive scale. I've not built any public-facing projects from scratch. But I have done years-worth of cleanup and improvement on projects that I'm very familiar with and have been in my backlog. It's not 100% success, but it's better than I could have done on my own, in the last few months anyway.
eatsyourtacos 1 days ago [-]
Exactly this for me too. I don't know how to feel about this overall honestly, I'm able to do so much more but now I barely get to write any code. It's weird.
rootusrootus 20 hours ago [-]
> I don't know how to feel about this overall honestly
I'm at the "this takes the scut work off my plate but damn if it doesn't also take the fun stuff off my plate too, and might put me out of job before I'm ready to retire in 8 years" point.
Though I've done the corporate America thing long enough to appreciate that 8 years isn't really all that long, maybe there's hope.
florianherrengt 1 days ago [-]
A manager isn’t normally the person deciding how the software should be architected or implemented. Their job is largely priorities, people, coordination and resource allocation.
You are still an engineer but you’ve delegated your technical judgement to an LLM. You just stopped doing the most important part of your engineering job.
iugtmkbdfil834 1 days ago [-]
Nooo. But seriously, that does appear to be the end result on most of my recent sessions. The time I spend is on correcting, adjusting.. dare I say managing the process as opposed to actively editing every aspect of it.
jreynar 4 hours ago [-]
AI may indeed lead to a barbell shaped distribution - lots of people with modest skills and the need for lots of awesome people. But I don't think that's necessarily a bad thing.
One of the problems with the "middle class" in the past was that there were lots of mid-level jobs in big companies but people hit a ceiling and couldn't progress. Maybe the middle hollowing out will lead to more jobs with significant opportunity and responsibility rather than ones where you get trapped because you weren't at the company early enough or all the top jobs are filled.
Folcon 2 hours ago [-]
This is an interesting position, what makes you believe that a decline in positions in the middle would lead to an increase in positions at the top vs just more people stuck being on the bottom rungs of the ladder?
CM30 6 hours ago [-]
I think this might be the key point to be honest, though not quite in the way the article suggests:
> My bet is that AI pushes salaries further apart. To be employable, there's a bar you have to clear and that bar is whatever the current best model du jour can do.
Since well, there are a lot of jobs in the tech industry that for all extents can be 'solved' with AI. Like if you're developing themes and plugins for a CMS (like say, WordPress), something like Claude can do a very passable job at that exact type of work.
So, only the more senior developers are even needed in that type of work anymore. And even they only need to review what the LLMs provide and fix issues maybe 10% of the time.
Hence the most basic, most entry level friendly engineering opportunities are likely about to be decimated. If your work involves building simple themes and plugins, managing the website of a small to medium sized business or being contracted to build sites for mum and pop companies, then your job security right now is questionable at best.
Being better/more skilled than AI is basically the bar you need to clear to find meaningful employment in this field now.
ltsui 14 hours ago [-]
I thought this was a good read. From my experience and to my dismay, what is considered a "good" or "bad" engineer/developer can be surprisingly subjective. I completely agree that an engineer should never submit a massive PR and instead break the work down, question, and understand the AI-generated code. I also agree that any reviewer should push back on being asked to review that and request the PR to be divided up. Unfortunately, what I've seen happen is that someone else with more power in the organization might find that PR fine and approve it and management might be raving about how good (fast) said engineer is. Those weird bugs which appear down the road get offloaded to other engineers.
Faced with that situation repeatedly, most people would find it sensible to resign.
Which leads me to another point: if you leave, it will likely be difficult to land another job assuming that companies will impose a ridiculous interview process in fear of a bad hire which will be increasingly expensive as the author argues.
I realize that this is nothing new, but if there are fewer middle-class engineering roles, then I expect that these existing problems to become amplified.
maxnevermind 23 hours ago [-]
> - "Why are we doing this here?"
> They send you a link. It's a Claude conversation.
LLMs spared my neck of the woods for now but is this really how PR review looks like these days for an average SWE or its just an example of a Junior in a team?
user00005 1 days ago [-]
All of this is my fault.
I decided to start learning programming about 6 years ago as a possible new career path. The universe was not going to have that so AI was created.
gnarlouse 15 hours ago [-]
It's YOUR fault! I knew it had to be one of us. Now I know. At least you were honest about it.
platevoltage 20 hours ago [-]
I came on the market right as the Covid hiring boom ended and started to fall apart. Fun times.
lookACamel 21 hours ago [-]
From the title I thought this post would be about something completely different. The post is about splitting the world into "good" and "bad" engineers with an emphasis on the bad engineer. Ok but what does that have to do with the middle class? The post leaves the best part out.
What I thought the post would be about is the dissolution of the White Collar Kitchen Brigade
The kitchen is run by the Chef but it needs the Sous Chef, Line Cooks, Kitchen Hands to operate.
Many software engineers have made a good living acting as the sous chefs and line cooks underneath the rockstar chefs, but with AI companies are inclined to turn the whole kitchen over to the top dog and their AI crew and the ordinary human crew is slowly being churned out.
gadflyinyoureye 20 hours ago [-]
I think you and the author are arguing the same point. The middle class offer developer that’s unskilled is going to be on the chopping block. Let’s say that there’s a robot that can now be a sous chef. If you have a good sous chef, you might keep that person. If the sous chef poorly executed her role, the new robot sous chef is probably looking pretty good. Fundamentally this is an hollowing out of the middle class. Arguably these people should not have had a job, but they provided just enough benefit that they weren’t fired.
lookACamel 12 hours ago [-]
In my analogy, it's not because they are "unskilled" or "bad". But they become obsolete because the shareholders want the singular master chef and their army of robots doing all the cooking.
And it's not just because the agents execute faster than humans, it's primarily that they have lower friction to onboard and off board. In the past we needed a "standing army" (salaried, full time work). Again this is not about the soldiers in the army being bad of incompetent, those are excuses. The real reason is that it takes a lot to train and maintain a soldier. Bu t when we now have ephemeral agents which spin up and down as needed, then there is going to be a strong incentive to cut down on the salaried middle class.
Simultaenously platforms like Mercor which offer white collar task based gig work are on the rise.
The logic is that ordinary humans are becoming too expensive to maintain on a standing basis.
johnnyanmac 15 hours ago [-]
The reality using this metaphor is that you have good sous chefs who are being fired anyway because management thinks the rockstar can just get more done with the robot chef. This distinction into "the sous chef got fired because they were bad" is a distraction from the reality at hand in that the people being cut out are all across the spectrum. There are new engineers who dipped their toe in the water and got cut. There are domain experts of 30 years that architected core systems the company relies on that is cut.
Nevermind the aspect that thses sous chefs could one day be rockstars, because no rockstar came straight out of college outperforming their senior's skills decades prior. You're hollowing out whatever isn't profitable at the cost of future talent (and likely the future of the company), but those holding the money don't care. They'll move on the the next company to suck dry.
johnsmith1840 21 hours ago [-]
Agree with the article the way I think of it is basically like before AI good engineers put in effort either currently or over cumulated years of experience.
A bad engineer has been lazy for years and will never change.
You likely have experience with this already first hand. Ever had a lazy day and just hit "yes" "continue" on the AI over and over? I've had to revert entire days of work because I was so burnt out I didn't put effort into the design.
A good rule of thumb though is if an AI can't solve the bug and fixing it creates more you have a bad abstraction and architecture that needs a gutting and rebuild from near scratch.
tvbusy 1 days ago [-]
One thing this post did not discuss is the enormous effort required to explain to the management why number PRs has increased and number of lines changes, which in their view, means explosion of productivity, yet one engineer is destroying the team's momentum.
florianherrengt 1 days ago [-]
I tried to touch on that with this part:
> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.
> And what are you even thinking about? It would end up in the exact same state again in just a few months anyway.
The management side of this probably deserves a whole post of its own. There’s only so far I can take each tangent before the original post becomes too long for anyone to finish.
omosubi 16 hours ago [-]
I forget the economics term for this but doesn't an improvement in tools result in little net change because everyone across the industry is given effectively the same leg up? Doesn't this mean that things will mostly stay the same employment wise? Most people aren't 10x engineers even with agents. Certain things are true: most products need someone on call 24/7, a group of people who know how to support a product (with varying degrees of knowledge), someone who plans what to build, someone who builds it (usually different people), inefficiencies in communication, etc. at least at the company I work for, agents have all largely improved these things, but by no means eliminated them. So it seems like things will largely be the same. There are only so many incredible engineers out there. They'll become more and more valuable but they were valuable pre ai. It's not like the industry will consolidate to only amazing engineers.
Joel_Mckay 14 hours ago [-]
LLM are worse, papers have shown it can actually rot peoples skills by 17% at debugging tasks. It actually makes people stupid, and 250% more confident it isn't enshitification.
Some feel more productive, and we shouldn't kink-shame peoples cognitive dildo. =3
brap 1 days ago [-]
It baffles me that someone can just send a PR without knowing the gist of how it works and why it’s done this way.
If you can’t answer this basic question then why tf do we even need you around?
unified101 8 hours ago [-]
Most people are currently too polite to ask the last part out loud. I suspect it will start changing soon.
theflyinghorse 23 hours ago [-]
LLMs are an automated Indian dev-shop. That’s all. The code is poorly thought out, poorly implemented and doesn’t take performance into account. But the code works and you got it for cheap.
That’s my mental model and I’m happy with it
omosubi 16 hours ago [-]
If this is your mental model you will be disappointed in short order
ChrisMarshallNY 6 hours ago [-]
Hi Florian,
Sorry to post this publicly, but there does not seem to be any other way to contact you. Your GH page is fairly locked-down, and the link there, is dead.
Your “Hire Me” and LinkedIn links in your blog are kaput (for me). It may have to do with UK LinkedIn not talking properly with US LinkedIn. I can find your profile there, but not through your blog links.
@dang @tomhow I may ask you guys to delete this, if it gets ack'd.
BatteryMountain 6 hours ago [-]
Chickens are coming home to roost boys. All that tech debt needs to be repaid NOW. All your holes (security) needs closed. You will not able to "fix it in production next week" anymore. Only "real" developers will be able to keep up with the onslaught that has just begun. The industry will consume itself in the next two years.
harrouet 6 hours ago [-]
Inspiring article, I will keep the following bits:
- with AI, bad engineers (bad designs?) lead faster to catastrophe
- Frontier AI companies pay their SW engineers very much
--> we need highly-skilled sw engineers and the lesser ones will get out.
Kind of what outsourcing did but x100.
As a manager, I'll still have to think how I grow young SW engineers to top SW managers.
delduca 1 days ago [-]
I saw close some companies getting completely lost with AI code
i_idiot 1 days ago [-]
So, blame the engineers now? Most likely they were forced by a manager to push more PRs faster else piped.
johnnyanmac 15 hours ago [-]
Management's job is to take credit for success and deflect to the individuals when failure happens. That's never changed.
florianherrengt 23 hours ago [-]
[dead]
tarkin2 23 hours ago [-]
The main thing it's removing is the skills you gain through actual practice, and replacing those with the demand that you subscribe to OpenAI etc to do your job.
But, moreover, the demand your company subscribes. But not your company anymore, because you'll probably be replaced by one engineer (and an AI subscription) who's now trying to do your job and about four or five other jobs.
And this one engineer will become more and more reliant on AI companies, AI companies that'll go for the throat once they've hollowed out all the skills that used to exist in the engineering market.
15 hours ago [-]
rckt 21 hours ago [-]
> Good engineers have become more valuable because AI lets them move much faster. They don't need as many people around them just to do the implementation work anymore.
This would be true if the goal was to get good working code faster. But the actual goal is to get any code faster. So, in reality, it doesn’t matter whether you are a good or a bad engineer. It just amplified how good you are at manipulating the hiring process with your fine tuned resume and how smoothly you can talk your way through.
florianherrengt 19 hours ago [-]
That might get you hired once. But that’s not what I’m trying to optimise for.
I’m trying to build a career over decades. I want to keep moving into better positions, work with better people and take on more interesting problems.
People talk. I’ve had jobs where I didn't have to interview because someone I’d worked with before recommended me and they already trusted my work.
The opposite is true too. People remember. They won’t hire you again or recommend you.
Reputation compounds.
thraway3837 22 hours ago [-]
Interesting article, and it makes a lot of salient points.
I think I can agree with most of it while also arguing that I don't think good code has ever had an honest measurement of quality. From an end user perspective, the end product either works or doesn't. Working terribly is the same thing as doesn't work and working well is the same as works.
What AI changes is the actual code part. The actual code lines output by AI is identical to or better than the best programmers. The systems design, architecture, QA, integration into existing legacy systems, to just name a few, is where the strengths and skillset lies.
In order to be a good engineer, you have to be a systems thinker. AI or no AI does not change that. The entire picture has to be taken in to account, and I think this is going to obliterate the vast majority of engineers who cannot or don't want to think about systems. It's no longer about putting on your headphones and outputting code. It's about having to interact with other humans, systems, architectures, organizations, and an API or MCP is not going to help with that.
I truly do feel bad for terrible older aged engineers, and the young new grads. I think it's unfair that a lot of new grads were told that CS was a great career, only for them to start their freshman year before AI, and then graduate when AI coding is in full use at nearly every workplace.
Joel_Mckay 14 hours ago [-]
> I don't think good code has ever had an honest measurement of quality.
Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
AI will divide computer science in two:
1. Normal Computer Science as it exists today, just much fewer doing it due to job supply dropping off
2. AI driven Product/Application Engineering, bulk will go here and the course will be shorter and move up the technical stack.
This is the only way I can see it playing out at the moment, because AI has completely eaten away the need for juniors and its also made it hard to train juniors since they just want to yolo it with CC all the time.
wojciii 22 hours ago [-]
I got a person from my small team fired before the sommer holidays. Not that I wanted to, but he didn't deliver the quality that I was expecting from a thinking human with an engineering degree.
Adding AI to the mix just made things worse. I'm still finding issues in the codebase/documentation that I need to review, test and fix.
The replacement is being trained. I made sure that, while I expect them to use LLM supported development .. they own their contribution.
This is going to be a fun ride.
yohamta 8 hours ago [-]
In Japan still many system integrator company that large corporation relies on continue using waterfall approach. They keep to out source a lot of engineering work for making design documents, manual testing, etc. They would keep to hire many middle class engineers.
sagabai 6 hours ago [-]
I feel like it might remove not exactly the middle class, but entry level (or honestly middle too) that had only skill for their careers, which is coding, applying very little judgement.
ryandvm 1 days ago [-]
Lord, this hits close to home.
It doesn't seem to be happening everywhere, but if you are unfortunate enough to work someplace with a "LinkedIn thought leader" high up on the engineering food chain, there's a really high likelihood that your organization is currently in the throes of an "everyone must be using AI for everything" fever dream.
And boy let me tell you, it is every bit as disastrous as the OP claims. Engineering managers are asking Claude to write up entire initiatives, then they hand off these nebulous AI slop manifestos to the teams where the requirements folks are having Claude shit out tons of superficially plausible Jira tickets. It finally lands on some poor engineer's plate and since these tickets are the technical equivalent of Finnegans Wake, they just end up asking Claude to read all this shit on `ultracode` and draft up a pull request. Which is then peer-reviewed by somebody using Claude.
I wish I were exaggerating.
jadar 23 hours ago [-]
I appreciate that the OP puts his finger on the problem. I think he's right. I wish there was more optimism or ideas about how to solve it, though. How do I fight against it as an engineer? Or, how do I become a "good" engineer? It feels like sometimes the only solution people have is effectively "don't use it."
douglee650 17 hours ago [-]
First day of work, immediately Ultracode refactor the entire codebase, do a massive 800k line force push to main, git comment, "Hey guys! First day, first commit -- fixed codebase with Claude. Hope this works!"
zug_zug 23 hours ago [-]
I think that piece is half right and half wrong.
I think it's largely correct that hiring bad engineers is dangerous to the company. But that's always been true, especially those "hack out a prototype, get director applause, and leave it for somebody else to own" people. But management has usually chosen to keep such people around, because they can look good on paper (see how many tickets they closed?).
The question is really a management / business-owner question -- will managers/directors stop hiring yolo-engineers? Will they empower engineers to close PRs simply on complexity/size grounds? Will they fund refactors and simplifications as first-class concern? If not, it will be a problem, and I don't envy the engineers who try to be the glue at such a company.
game_the0ry 23 hours ago [-]
Writing code was never the job. Creating value was the job -- coding was just how to implement that goal.
Kinrany 22 hours ago [-]
"Creating value", "making money", etc. are meaningless
bibimsz 2 hours ago [-]
to many programmers, yeah
mattbettinson 21 hours ago [-]
I shudder to think of anyone in the industry this would be mind-opening to
alpha_squared 22 hours ago [-]
Anecdotally, the essay is so spot-on. In my last job, I'd regularly have to review +20k-line change PRs from mid/junior devs only to reach a point where I'd have to just shut down the PR and ask for it to be broken apart. Sometimes, the issue would get escalated and I'd have to speak to their management/director chain. More often, they'd realize that if they spent some time trying to understand how to break it apart, the changeset actually needed to be much smaller and I'd come back to a 400 or 500-line PR to review.
In one particular case, a senior teammate of mine went the extra effort to actually explore what the intent of the change is and created a whole new PR for the junior dev that was a simple configuration change of 5 lines instead of the 14k lines they put for review.
This is utterly unsustainable and something will give at some point.
meander_water 17 hours ago [-]
I think there's a corollary to this. Not only is it hollowing out the middle class, it's preventing the junior engineers from stepping up to the senior level.
Everyone starts off as a bad engineer. Just like any other profession, you to make lots of mistakes to learn. But now you're less likely to get wisdom from another human to build up the knowledge and experience you need. And more likely to delegate the hard stuff to Claude so you don't learn from your mistakes.
gnarlouse 15 hours ago [-]
If there's a real existential pressure on a certain group of engineers, those that escape with their employment will carry evolutionary DNA with them (along with a substantial helping of pure luck) in the form of experience. Those that don't will disappear.
Nothing else this article says matters much in my opinion. If you're concerned about something, do something about it.
AI is still just a tool.
bwest87 15 hours ago [-]
Has anyone seen any tools for enforcing that people understand each PR? It feels like there's a new missing piece here that is like CI for humans, where you as the code owner need to basically pass a test (auto generated by AI) about wtf is going on with this PR and why. If that quiz isn't green then you can't ship it...
gnarlouse 15 hours ago [-]
this might be the only comment on this post worth reading, much less the article...
seems like a petty easy construction, proof engagement kinda thing
lilerjee 21 hours ago [-]
Rubbish article, waste of my time.
No confirmation for the title, rubbish arguments and logic.
> Good engineers have become more valuable because AI lets them move much faster.
Bad prediction. This is likely another AI marketing article.
- but in your diagram titled "Word vectors plotted in semantic space" dont you think you need to add arrows to show where those vectors are actually pointing?
- because i dont get how you arrived at this Using vector arithmetic, you can calculate: woman + (uncle - man) = aunt without seeing the math vector directions
mrheosuper 13 hours ago [-]
>If all they needed was someone who could turn a specification into working code, why were they paying that much when they could already get it done cheaply elsewhere?
That's when companies began starting to outsource their work to much cheaper countries
mjr00 1 days ago [-]
It's very true, you used to have to hire people you knew were not very good just to have warm bodies who could throw together widgets, minor bug fixes, etc. You still had to have a competent developer review what they did, which was annoying, but ultimately a time saver over doing it themselves.
Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).
So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.
johnnyanmac 14 hours ago [-]
> it's ~free (relative to human salaries, even outsourced).
Even ignoring the shift to token based costs, the opportunity costs of throwing everything onto your "competent developers" isn't free. They still need time to review and correct output on top of whatever else they were doing in their day to day. And they probably aren't getting a pay raise either, so how long until they use that bullet point to jump jobs?
mjr00 1 hours ago [-]
> the opportunity costs of throwing everything onto your "competent developers" isn't free. They still need time to review and correct output on top of whatever else they were doing in their day to day.
Maybe it wasn't clear in my comment, but this was already happening in many large organizations pre-AI: you had a small contingent of competent senior developers whose job was to review and correct outputs from junior and/or outsourced staff. From people I've spoken to in these types of situations, they're very happy with getting rid of their offshore teams and using AI instead.
platevoltage 20 hours ago [-]
Well now you have lousy developers generating 1000 line PRs for their lousy colleague to approve while neither of them understand the code.
jimmont 8 hours ago [-]
Clearly that article shipped to production without QA. Having no testable definition of good, it must be bad. Fired.
adamtaylor_13 24 hours ago [-]
It's not clear to me what "the middle class" is supposed to be here. All engineers exist on some spectrum between "good" and "bad" and it's pointless to try to identify the exact markings, but we all know good engineers and bad engineers.
So AI isn't really doing anything but giving sharper tools to both groups.
So, as it was before, we simply need to set expectations and remove those who cannot adapt and meet expectations... You know, the way it's always been.
So why is AI the problem here?
wiradikusuma 23 hours ago [-]
I told my (small) team of developers that they're free to use anything to get them more productive: (company-provided) AI, black magic, WFH to avoid traffic, etc. But I also tell them that every human (including myself) is responsible for their own (direct/indirect through delegation) work so we can't say "a genie did that, not me". So far it's net positive for us with AI.
foxtrot8672 4 hours ago [-]
this article sounds like a lack of discipline rather than an issue with AI
markstos 22 hours ago [-]
Perhaps more broadly AI will hollow out "middle intelligence".
We could end up with a gulf between those who use AI for cognitive inquiry vs passive delegation. Those who accelerate learning by asking "help me understand this" vs those who relinquish understanding and analytical thinking to AI to complete their work.
qwertyforce 21 hours ago [-]
I think the worst part is that some companies may be okay with it. They will pay attention only when it's messed up beyond repair. And it’s possible that fixing it will be a task for more advanced models, not humans. Do they win or lose at the end of this martingale? I am not sure
maerF0x0 1 days ago [-]
> In the story above, everyone is failing:
IMO The author fails to list the hypothetical person with 13 PRs to review is also failing.
> * The engineer who refuses to change with the times
IMO many of the old ways of software engineering were local maxima. We're still seeking how to hit a new maxima and the journey may take us through zones lower than the previous local maxima.
florianherrengt 24 hours ago [-]
I use AI heavily, so this isn’t about refusing to change.
You still have to understand the change yourself if you’re going to take responsibility for approving it.
That work is fundamentally much slower than generating the code, even with the help of AI.
We’ve made producing a large change extremely cheap and fast. We haven’t found an equivalent shortcut for building a correct mental model of what that change does, how it interacts with the rest of the system and whether the decisions behind it are actually sound.
Maybe one day we'll find one. As of today, I don’t think we have.
jplusequalt 23 hours ago [-]
> * The engineer who refuses to change with the times
There is plenty of software in existence where being incorrect, even once, can spell disaster.
Everything about the picture being painted in the article is anathema to keeping such systems safe and reliable.
hemc4 13 hours ago [-]
> AI makes projects with weak engineering culture fail much faster.
Love this quote. Already seeing so many codebases which became unmaintainable.
crossroadsguy 13 hours ago [-]
Few years ago this very AI/ML created a frenzy and CS graduates started becoming many fold. Little did they know…
hyfgfh 11 hours ago [-]
I'm sure everyone reading this article thinks of themselves as a good engineer.
xyst 1 days ago [-]
AI generated code is the new "lines of code" metric used by middle management.
cbg0 1 days ago [-]
Actually "AI spending" is the new "lines of code" metric.
b40d-48b2-979e 1 days ago [-]
Too real. I got DMed by management recently asking if I was anti-AI because I had the lowest spend on the team as the lead, y'know, the one that has to review all the slop my peers are generating.
ethagnawl 10 hours ago [-]
I'm sorry. These charades are such a complete waste of time, energy and money. They're some real 21st Century Office Space nonsense.
I recently joked (only slightly) that it's currently possible to get yourself promoted at these orgs using tokens as a productivity proxy by spending your days having Claude OCR dictionary pages.
The concerning corollary of that joke and this management strategy is: when do orgs start offloading reviews to Claude? They're already surveiling a large percentage of peoples' day-to-day and are in a position (or will claim to be) to make a judgement about how those tokens are being used.
platevoltage 20 hours ago [-]
That is rough, and downright embarrassing. What is happening in this industry?
a34729t 20 hours ago [-]
Oooooh we just started doing this at my company. There is no target set yet, but management feels it's between 50% and 100%. But people will be evaluated on this!
brailsafe 9 hours ago [-]
This is something I've been concerned about. Out of work again for the something like the 7th time this decade, I'm not sure I even care to try and get another one. Unless a place is super low key and actually tests relevant skills, even with kore experience under my belt than last time I ran that gauntlet, I believe companies are likely to be even more conservative than they used to be, which was already comical. I don't believe I'm incapable or a detractor to a team, but the pressure to try and prove it in this economy and in this timeline feel... not really worth it exactly, especially when there's likely to also be pressure from management to move faster and take less time or affordance for actually thinking about what's being done. It feels like what I'm facing is a mountain that could be double the size it used to be, and that has a summit in the middle of a forest with no view.
Working on a small, existing, established product that can gradually be improved upon while aided by LLMs if necessary seems like the best place to be. Starting something new (not that I have any legit worthwhile ideas or the resources to pursue them) seems pointless because people are shitting out poorly designed AI slop constantly and poisoning the market.
But what do I do instead? Trades programs are already waitlisted or require another 5-10 yrs to earn something worthwhile. Transitioning to anything else seems like a tenuous prospect. I fear that unless I get incredibly lucky, the last job might have been the last chance to earn a living that made any sense.
To be clear, I'm not giving AI more credit than it's due, and this article describes the reasons for that which are valid, but the perception that they're magic engineer replacers is more important than reality. At least I can hope that the housing market completely crashes or enough crap code is produced by opportunists that I can ride it out, but other than that it's a confusing time.
TiccyRobby 23 hours ago [-]
The premise does not make any sense, it is a technical culture problem which you need to enforce. If you let it go wild, yes it will go wilder than ever but this is relatively trivial problem.
johnnyanmac 14 hours ago [-]
Problem is that many large companies all collectively decided that yes, we want it to go wild. because value proposition lies more in saying we use it than on what it's actually building.
asveikau 22 hours ago [-]
This subheading popped out at me:
> The new AI economy
I don't know if this phrasing is intentional, but it gives me a chuckle. The dotcom boom was called "the new economy" about 26-28 years ago.
a2ff6eeb0 13 hours ago [-]
It's removing all classes, or at least compressing them towards the bottom.
timedude 1 days ago [-]
This is really well written. I deal with the exact same issues almost daily. Senior engineers who want to guard quality are becoming a bottleneck.
florianherrengt 23 hours ago [-]
If the people trying to understand the changes and guard quality are now considered the bottleneck, the answer isn’t that the reviewers need to move faster.
timedude 23 hours ago [-]
I wasn't saying that either
florianherrengt 19 hours ago [-]
Then I’m not sure what you mean by calling them a bottleneck.
If the limiting factor is the rate at which experienced engineers can understand and validate changes, you have three options: generate less, find a genuinely better way to validate or accept lower quality.
bookofjoe 1 days ago [-]
It wasn't that long ago that many were demanding writing code be a required subject in elementary school.
rglover 24 hours ago [-]
It still should be. Any educator worth their salt should be able to connect the dots on where all of this leads.
I always joke with my wife and invoke a line from this [1] Art Bell episode "the disasters that are coming..."
People really don't seem to consider that our civilization is remarkably fragile and dependent on humans. Any given system can just fail at a moment's notice and you need people around who know how not to panic and what to do.
We seem to be adamant at disproving this reality for some weird reason (money, duh), but life isn't going to be fun when a large portion of the population needs a chat bot to do any form of work. And it's worth asking: what population will be left if we submit all of our faculties to LLMs? My guess is one that's either limited in size or practically inert.
An outright idiocracy doesn't have to happen, but we sure as hell seem to be speed-running our way there. It's actually worth watching Idiocracy and Wall-E and just contemplating "do I really want to live in this world?" Because, at least right now, we're charting course directly toward that.
you're right, some people should always be able to work without access to AI or the internet. I guess these people are essential services
florianherrengt 24 hours ago [-]
The fact that a machine can do something better than humans doesn’t automatically make learning it pointless.
We still teach arithmetic and algebra despite computers being vastly better at calculation. We teach spelling, grammar and essay writing. We even teach history and geography while everyone permanently has a device in their pocket that can look up almost any fact in seconds.
How else would you be developing the mental models required to understand, question and verify anything?
peterjliu 23 hours ago [-]
it seems not just the 'middle', but also the 'lower' classes are getting removed
Animats 13 hours ago [-]
There's a more general problem. We need to figure out how to use LLMs and still have decent code quality.
One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet.
This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written for humans and from unit tests. Code is cheaper than it used to be, but so is formalism.
This may be a way to put firewalls around AI slop.
unified101 13 hours ago [-]
It's your code review process (with or without agents). If you don't hold this fort, the battle is lost, and the repo is going to devolve.
Animats 12 hours ago [-]
What I'm getting at was covered in an article yesterday about the end of abstraction. There's an argument being made for layer-free software, where everything is one big blob of code, created and understood only by an LLM. The software is modified only by re-prompting.
There are a lot of people edging around this concept, but it's not solid yet.
unified101 9 hours ago [-]
Can you point to any place/post making this argument? I'm an active lurker here, and have not seen anyone arguing for layer-free/blob-of-code type of workflow.
The fact that some teams find themselves there is simply a realization of what I stated - inactive maintainership by not taking code reviews seriously.
mt97 17 hours ago [-]
How can I make myself better, asking as a middle swe
bibimsz 2 hours ago [-]
ask claude
dupflo 24 hours ago [-]
At the same time, it also brings very low level "vibecoder" to the pool
florianherrengt 24 hours ago [-]
I wrote about this before. I don't think the vibecoders will have a job for a long time. At best, it will be minimum wage.
See "AI Won't Take Your Job, Someone Using AI Will"
> There's no lucrative middle ground where 'AI whispering' is a high-value skill.
2026 is starting to slow time there emergency and 2027 will clean. Unfortunately they still contribute to overwhelm socials media with there content.
Nice first name btw
bibimsz 2 hours ago [-]
in 2 years there wont be many non-vibe-coders left employed
19 hours ago [-]
parkersweb 24 hours ago [-]
I have a theory that Claude regresses to complexity. It’s trained to mimic existing patterns - so the smallest grain of over-engineering or spaghetti-code is like a mind-virus, gradually infecting all future output and self-amplifying until all is spaghetti.
throwitaway222 1 days ago [-]
Probably a good thing, we need more people building major mega projects like the Line. Potentially we need AI to mass produce architecture and scale up and out city/county building departments to open the gates to massive buildings in the United States.
crnkofe 23 hours ago [-]
All this mindless droning about societal collapse, destruction of jobs, people moving on is really getting old. Sure people have caused mayhem by following (and enforcing) bad practices which resulted in a toxic workplace, a mix of pissed of client due to constantly failing to reach deadlines, unimaginably bad codebase that was a horror to work with and teammates each defending their own turf. LLMs now allow this deterioration to happen much quicker and more effectively.
On the other hand the problem can also be triaged quicker and rewritten faster. Pretty much every startup I joined had at its core disastrous code written by students and overworked techies. I can totally see this shitty base being the future base all startups. It'll likely need an army of agents or devs to make sense of all the spaghetti being written. I won't be surprised if demand for devs skyrockets after the first generation of spaghetti western code "matures".
johnnyanmac 14 hours ago [-]
>All this mindless droning about societal collapse, destruction of jobs, people moving on is really getting old
I mean, it's a huge issue and is still happening. It will be talked about until properly addressed.
22 hours ago [-]
v-mdev 1 days ago [-]
Great idea to include a link to Hacker News on your blog!
danielovichdk 24 hours ago [-]
"You can't afford bad engineers anymore"
You never could.
florianherrengt 24 hours ago [-]
Agreed. But it’s the difference between crashing at 30 km/h (19 mph) and crashing at 200 km/h (124 mph).
AI massively increases the speed and scale at which bad engineers can do damage while fixing it is still slow, difficult work.
t_e_s_t 9 hours ago [-]
Hello
zombot 10 hours ago [-]
> But what's the problem then? Just use AI to fix it.
Even if that were feasible in a sustainable way (i.e. LLM-generated code wouldn't drown your code base in technical debt over the mid- to long term), the asymptotic end state of this is that the LLM provider owns the means of your production, not you anymore. How can anyone in their right mind run into this obvious trap?
> By the time you've untangled one bad decision, five more have been merged.
And then there's that. What's the value of all this "speed" when it destroys the most valuable thing you have?
> At some point, someone still has to know what is going on. And that's the most valuable person on the team.
The best you can do is see that you keep being one of those.
Oras 21 hours ago [-]
Agree with the article, but good luck convincing upper management about it.
“If it works, don’t fix it” until it doesn’t and we shall see a new wave of software hiring in a year or two.
Every enterprise is talking about AI Transformation, and that great with the right expectations. But those who think AI will just make platforms quick with less people and least experienced engineers, will have to prepare for the deinshitification transformation in a year or two.
14 hours ago [-]
1294876 1 days ago [-]
"There are also people who essentially make it harder for everyone else. And now anyone can produce more code in a day than they used to in a year."
That is the "democratization" that AI shills speak of:
Is it long term pain if a small startup in a very competitive vertical gets to market quicker with code gen and finds market fit? Whether that results in a rewrite or a refactor, that is still a huge win and one that a lot of people will gamble on.
dgellow 1 days ago [-]
Do you have examples? Ideally a startup that isn’t itself selling AI to other AI companies
jqpabc123 3 hours ago [-]
Is it long term pain
Yes.
Whether any gain is worth the pain is left as an exercise for the user.
florianherrengt 23 hours ago [-]
Debt is debt. Some of it is absolutely worth taking on.
I don’t have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.
packetlost 1 days ago [-]
Oracle banned AI code for copyright reasons, you cannot interpret that as a assessment of the practical output of the models.
stonefoot 1 days ago [-]
That's only one of the three reasons in the article:
1) Reviewer burden - LLMs can produce a deluge plausible but incorrect code which can overwhelm human reviewers.
2) Safety and Security - Many corporations depend on the JDK so stability is a high priority.
3) Copyright/IP about who owns submissions generated by AI is not settled in law.
The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.
It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.
ok123456 1 days ago [-]
Oracle banned AI code from a public project they maintain and backport/share with a commercial product because they're a very litigious company, anticipating future legal cases.
SpicyLemonZest 1 days ago [-]
It strongly argues against a position that many people including myself have taken, that all code will soon be AI code and the only people still writing code by hand are those who haven’t gotten the memo. (I don’t mean to rule out the possibility that Oracle, despite their involvement in AI infrastructure, is just being dumb and the lawyers made them create a policy that’s not compatible with the modern practice of software development.)
gfhhnki 1 days ago [-]
Just look at how they bragged for a year now about how AI built entire apps with a single prompt.
And now that code is being watermarked by AI, suddenly they’re artists, painstakingly prompting, crafting, to get just the right code; the watermark is unethical even!
AI psychosis is real, and even some of the smartest people I know how succumbed to it.
14 hours ago [-]
aussieguy1234 14 hours ago [-]
> bad engineers were always a liability
So. AI Makes good engineers better, more productive and able to deliver well designed systems.
But it makes the bad engineers 10x worse. Before, they had negative productivity in a team environment. Now, its 10x negative productivity. The mess they create as one person might need 10 people (and their AI's) to clean up.
I would also put people who don't know how to code in that bad engineer basket. They would be delivering code they don't understand, accepting unnecessary complexity etc just like your standard bad engineer.
bibimsz 2 hours ago [-]
> ... accepting unnecessary complexity
you think theyre not going to fix that?
somehow elite humans are the only ones who can ever reduce complexity?
the tooling is in its infancy. this is the worst it will ever be.
platevoltage 13 hours ago [-]
Maybe it does make good engineers better, but that is meaningless when that good engineer has an idiot manager telling them how and when to use AI and judging them based on token usage. You still end up with the same result.
GrayHerring 23 hours ago [-]
More like AI is exposing bad engineers faster than it would've been possible earlier. Previously they would simply outsource all their thinking to someone else, now they see massive progress with AI and delude themselves into wishful competence.
anarticle 19 hours ago [-]
hahah this is all well and good until the 20k+ line a day person is considered the good engineer, based on kpis alone. Your VPs aren't reading any of that.
Bonne chance fired senior!
I have depicted you as the 100 line a day weakling, and myself as the 20k+ line chad.
The systems at bigcos are too ruthless to risk gambling your career on this kind of reasoning which you have no recourse to. Best to start small teams and destroy them from the outside.
docmars 19 hours ago [-]
To the headline: Yep, and for false reasons they'll have to pay for later, alas.
gambiting 20 hours ago [-]
I work in software and I wonder what companies are letting in those 25k line PRs? If I change more than 3 files at once that's already rising a sea of eyebrows and it will be a week or more to get it through code review. I can't even imagine what kind of supernatural circumstance would lead to anyone accepting a 25k PR at all.
dmezzetti 22 hours ago [-]
As an open source maintainer, I can chime in on this.
With TxtAI, I've seen a large uptick in PRs (https://github.com/neuml/txtai/pulls?q=is%3Apr+is%3Aclosed+s...). While the extreme verbosity of Claude messages and commits is very annoying (plus the constant defending itself on why it's a bug), I do think it's a positive that more people are enabled.
It does require reviewing the PRs. Some can be tricky just like a human. For example I did merge this PR (https://github.com/neuml/txtai/pull/1136) and it would have completely broke search. But a human could also do that.
From an open source standpoint, I say the more the better. You just have to be willing to do the work to review and no not just having AI agents to review what the AI agents are submitting. There still needs to be a human in the loop, if you care about quality.
waffletower 24 hours ago [-]
While there are bad engineers, I imagine that teams that have evolved alongside AI and have maintained their size and consistency without adjustment may have structural issues. I would argue that team size counts ought to be smaller now than before Claude. Unfortunately this idea could feed an AI-induced layoff trend, but it could instead lead to product diversification instead.
jdw64 1 days ago [-]
I'm not sure what skill really means, or what's considered bad anymore. AI coding ability and human coding ability are different, and different organizations need different skills. No skill is inherently bad—it just depends on what the organization needs.
I understand that AI writes better code than people like me in many cases. But an industry should still provide opportunities for those people. And sometimes those people create things that are better than AI in certain areas. The problem is when even those opportunities are taken away.
florianherrengt 23 hours ago [-]
The industry doesn’t really owe people opportunities. Even if you think it should, that’s not how companies are going to behave.
jdw64 22 hours ago [-]
That is an incredibly short sighted view. By acting this way, the industry is essentially selling its future for short term gains. A systemic reduction in the number of people capable of maintaining systems directly correlates with an inevitable collapse in overall software quality.
The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)
It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.
Is it truly right to eat tomorrow's seed corn today?
The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.
You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.
Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.
Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.
oliculipolicula 14 hours ago [-]
PP is (probably) a market maximalist. Many rationalists end up there. Strangely, there are market maximalists who try to answer all your questions..
E.g. Buterin, Weyl, Friedman. How we started talking in the first place, remember? It was rather regrettable that we stopped asking each other questions..
In place of that, I'd like to see you, jdw64, try to debate with these high-ranked people (in their own community, anyway) :)
To everyone: How can market reward advantageous situation-dependent temperaments in the long term, is I think my question. That sounds like climate (or weather) manipulation, but somehow I sense both theory and practise are much simpler.
In fact, I think I can even eliminate jdw64's ingredient of "temperament".., framing the issue of conflicting temperanents as one between "generalists" & "specialists". Note that you can (probably) use "Marxist theory" to defeat PP without calling it that.
(I think this is more complex than the debate between "wise" and "clever"?? The gap is itself interesting)
This last one, even all of YC would be interested in, I'd argue. In VC lingo, that'd be "T-shape". see also the thread "Felix & I [& D]". That's either like a person who is like both Jobs and Wozniak, depending on situation, or a Wozniak (/Jony Ive) who has the ability to become Jobs, thus sidestepping the situation-dependence-dependence.
Side-quest one is to redefine both "making a billion dollars" and "writing good prompts" as specialities, so that markets as they are imagined now don't necessarily reward these
Side-quest two is make the chameleon skill teachable (or at the very least into an _identity_
;)
florianherrengt 20 hours ago [-]
[dead]
j45 23 hours ago [-]
Ai isn't removing the middle class of software engineering.
Software engineering is evolving, and the middle class (and beginner) is going to have to grow instead of being able to leverage the same skills for longer and longer.
It's so true from some of the other posts that you can outsource your thinking, but you should never outsource your learning and understanding.
fithisux 1 days ago [-]
Very good article.
But it does cover the case where someone makes it to the top if he/she is junior. Who experience is gained?
Maybe I ask too much from a short article.
fithisux 9 hours ago [-]
it does cover - it does not cover
florianherrengt 23 hours ago [-]
[flagged]
m3kw9 13 hours ago [-]
This is why I think if you are need a 20x plan to code/do software engineering, there is no way you will read most of it, and it is likely 100% slop. A rare few can use it and not create a mountain of tech debt in a few days of use.
KronisLV 20 hours ago [-]
> But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.
Migration plan? Just ask Claude when shit hits the fan. You'll make a plan when you need one.
> By the time you've untangled one bad decision, five more have been merged.
I'm slowly (partially ironically/sardonically/nihilistically) adopting a mindset of accelerationism towards the collapse of software development - it was largely done wrong from day 1 and wasn't "real engineering" to a sufficient degree to not lead to the mess that we've been in maybe for the past 20-40 years. The only thing AI did was take away the brakes and press down on the accelerator, we're already headed towards a cliff and have been for a long time.
If the code in airplanes and spaceships was developed with the same degree of care and attention as "good code", you'd see those dropping out of the sky regularly. If they built bridges like we build software, they'd fall apart regularly as well. Good code CANNOT hinge on the opinions of some senior dev, or even a group of them - it must be provably good. And if it must be provable, then these checks must be automatable. Bad code (whatever that means, however you'd manage to classify the difference between AI slop and what you want to see) should be IMPOSSIBLE to get into the system at all, due to those automated checks.
Be it good enough test coverage, automated checks for usability and end to end coverage of the features, project/domain specific lists of architectural rules (think ArchUnit), needing proofs not just tests etc. We will never have that - our OSes are bad, our browsers and other essential software is bad, our programming languages are bad (the fact that unchecked exceptions even exist in languages is a cardinal sin), same for databases and tbh any other class of software you can look at.
This impassioned comment might border on a rant, but my argument is that the past decades aren't the baseline of good code, we'd probably need to spend 10-100x more effort to produce 100-10x less code, but make the existing code bulletproof - there is no reason for more than one OS to exist, no reason for more than one UI framework to exist (or even all of the egregious ways how the web platform was transformed from documents and links to a collection of badly written apps, which eventually infected the desktop with Electron, due to the native GUI development also being severely neglected), no reason for more than one web framework to exist or even more than one programming language to exist in mainstream usage outside of research and looking for the solution to use for the next decade/century of software development. Yes, I'm exaggerating, but the correct answer is probably closer to 1 than to 1000.
Obviously that'd lead to death by comittee and some degree of experimentation is necessary, so hey we end up with a new slopped together library every week and I know nothing and nothing works anyways. I wonder if we had ONE high level programming language, whether over time it would have evolved from C++ to Rust (sans odd parallelism), and if it was based on formal proofs, then migrating between language features could have also been fully automated, alongside enough pushback to any feature deemed not worth it. On the other hand, even with all of the world's developers concentrating effort, something like that might be above our cognitive abilities, so probably not - just too hard to reason abuot.
14 hours ago [-]
deadbabe 23 hours ago [-]
A pattern I have noticed is you get way better results if you just have one skilled senior engineer coding everything with AI vs a lot of people.
Having large teams in the age of AI is pointless. It slows things down and spreads accountability too thin.
When you have one good engineer doing many things, a lot of stuff lives in their head and they know what to look for in their own PRs. Also, people tend to like their own AI slop, but not others. So overall you will have at least an engineer who is satisfied with the codebase vs a lot of people who either have some gripe about something someone else did, or just don’t care at all.
That means you have to put way more trust in a single individual, but if it’s the right individual you propel the organization further ahead than a team of mediocre engineers or senior engineers limited in what they can accomplish.
jplusequalt 23 hours ago [-]
This blog conflates productivity with expertise.
Are LLMs rewarding experienced developers with tons of productivity gains? Yes.
Are LLMs actively degrading their expertise of understanding code? Also yes.
This article has made the implicit assumption that the top quartile of engineers are immune from skill decline. They're not. If you're an engineer who increasingly outsources the planning, writing, and analysis of code to an LLM, you're losing your ability to plan, write, and analyze code.
All of this is to say--senior engineers who have fully adopted AI tools are blowing smoke up their asses to dodge the reality of their own obsolescence. The senior engineers can talk about productivity all day, but they're only marginally closer to understanding a complex system that was written by LLMs than the "middle class" of engineers are.
You reading this--yes you--get over yourself. Your skills are depreciating too.
florianherrengt 21 hours ago [-]
I don’t think I’m assuming experienced engineers are immune from this at all. In fact, I think the opposite.
I’ve seen senior engineers adopt AI in a way that made them noticeably worse. If you outsource the reasoning and accept plans you don’t understand then your previous experience isn’t going to save you. Nothing will.
The skill atrophy from outsourcing too much thinking is a real risk. I just don’t think that’s the point I’m trying to make here.
I’m describing a pattern I’m seeing in today. What matters is whether you understand the change being made. If you don’t, then you’re not adding much value, because the LLM can do that part better and faster than you anyway. It doesn’t matter whether you have 2 years of experience or 20.
zackmorris 24 hours ago [-]
Wait till we realize that nobody is buying the software we vibe code anyway.
We've seen this game before, with the Dot Bomb and 9/11. A lot of you have 6 figure jobs that will simply be gone next year after the election, never to return.
That winter lasted about 5 years until 2007 when the iPhone and social media sites like Facebook went mainstream. This winter won't end. Or more accurately, it is the end.
Maybe we should stop debating whether we're in a crisis and start looking at the 5-10 year endgame of the Singularity. We're entering the eventuality that many of us have predicted since the arrival of the internet 30+ years ago, that prices will get lower but nobody will have any money to buy anything anyway. The feeling that we're doing something wrong with our lives will continue to intensify. We'll try so hard, and get so far, but in the end, it doesn't even matter.
I don't know about the rest of you, but I'm turning my attention away from trying to play the job game with AI. I'm looking instead at how we can provide time/money/resources to the middle class after capitalism can no longer provide them.
A conservative friend of mine just read the Communist Manifesto by Karl Marx, which I didn't see coming, especially since he beat me to it. In the neurodivergent spirit of not being able to do anything alone, what if we all read it?
I'm predicting that it stops just short of what full automation can provide. Loosely the evolution of economics goes: hunter-gatherer -> agrarian- > feudalist -> capitalist -> socialist -> communist. And now solarpunk (or something).
The working class is looking forward to the next chapter, but the capitalist class is looking backward to neofeudalism.
Those two directions can't coexist, so what does the future hold? Well, it's always darkest before dawn:
"It's easier to imagine the end of the world than the end of capitalism." - Mark Fisher.
If the endgame of capitalism is that it inevitably eats itself, then the game now isn't how to get more money and do nothing with it, but instead how to start doing something with no money.
I should add that even if I'm exploring anti-capitalist futures, that doesn't make me socialist. I don't like the 6 hour daily work requirement of many socialist societies. I think we can do better than that and get closer to 0, so that we can shrug off wage slavery and finally get real work done.
florianherrengt 23 hours ago [-]
This is extrapolating several steps beyond anything we actually know.
Whether people will buy AI-generated software is a different question. The problem I’m describing already exists inside businesses with paying customers.
I’m talking about established teams working on products that already have users and make money, where AI lets individual engineers introduce changes faster than the rest of the team can properly understand and review them.
johnnyanmac 14 hours ago [-]
Looking towards a socialist future seems to imply some goodwill that governments will just magically come around to proper welfare programs and billionaires will agreed to be taxed properly to support it.
Or you simply take for granted the bloodbath the next decade will be before we come to proper talks of this. I don't think that is something to handwave unless you have your billionaire bunker ready.
pojzon 9 hours ago [-]
[dead]
mikert89 1 days ago [-]
AI gives more leverage to exceptional people, its an amplifier not an extender
happytoexplain 1 days ago [-]
Right, it's a multiplier only if we define bad engineers as negative numbers, and "bad" as "most".
iugtmkbdfil834 1 days ago [-]
I know what you mean, but the amplifier could genuinely work both ways ( magnify bad and good outcomes ).
b800h 1 days ago [-]
There was an old truism of "acid fascism" that went like this: "LSD makes smart people smarter and stupid people jump out of windows". This is like that.
onesandofgrain 1 days ago [-]
Maybe
api 1 days ago [-]
That is true of all tools. AI is a tool. A tool provides leverage. It does not make a bad craftsperson good.
dgellow 1 days ago [-]
I hate that framing because it glosses over what makes AI distinct from other technology. Pretty much anything can be used as a tool, that’s not an interesting aspect of AI. However standard tools do not take decisions on behalf of the user, they do not apply judgement. They come with assumptions and constraints that make some decisions more likely to be made. But the whole thing about LLMs is that they apply judgement and take decisions. When you use an LLM you delegate both aspects to it with very little overview or control.
I don’t think it’s “just a tool”, it’s something that directly compete with the role of humans in a system, by design
api 24 hours ago [-]
If you go back in time and imagine yourself in 1950, would you have said that about computers in general? Yes their decisions are the result of pre programmed heuristics, but to the operator that can feel as opaque as AI. In fact in the early days of computing AI was used to refer to a broader swath of what we now call heuristics and machine learning.
Is a very sophisticated computer driven adaptive control system making decisions for the user? Arguably yes. If your car has a bunch of assist tech you are not driving. You are commanding a nonlinear control system.
AI today is quantitatively far beyond these systems but internally it is still just a giant decision table. It’s just a differentiable table that can be automatically programmed by back propagation at what would be unimaginable scale for manual implementation.
As soon as you put a machine between you and the target action that is more complex than what you can hold in your head and that has multiple layers or feedback loops, you are ceding fine grained direct control in favor of a simpler abstract control surface.
I will change my mind a little if I start seeing evidence of genuine volition, but as of now I suspect that’s a property of life not intelligence. One interesting result of AI when viewed as an experiment is: I think it proves that life and intelligence are separate phenomena and that consciousness and intelligence may actually be unrelated.
I have the hypothesis that consciousness (and therefore true volition) is a property of life. You have to be metabolic and tied in some intimate way to thermodynamics and the arrow of time. Solid state electronics doesn’t have this property. It’s unrelated to intelligence. A bacterium may be conscious.
mwcampbell 5 hours ago [-]
The difference is that with software before the rise of giant machine-learning models, the software is derived entirely from human-understandable source, and often a full software stack can be built on a single computer, as anyone who ever ran Gentoo knows. While the source of any non-trivial software stack is too large for any single human to understand in full, a single human can understand any part of it. That's not true of model weights. And my understanding is that even the smallest open-weights models that are remotely in the same class as LLMs require large computing clusters with powerful GPUs to train. That puts training a model, or retraining one from its true source materials (the training data and processes), in an entirely different class than rebuilding Gentoo, even with GNOME, Firefox, LibreOffice, etc., even if the training data and processes are available, which they're usually not. So, we should treat these models as a different kind of thing than the tools that we developers have worked with until now.
dgellow 20 hours ago [-]
LLMs don’t have a will of their own and will (very likely) never have one, they aren’t an entity or anything that can have a sense of self. They are a compressed dataset with a next token prediction engine. From the token prediction + complexity of the dataset + reinforcement learning + whatever other techniques AI folks are using we are able to derive judgement and decision making (of course the LLMs don’t judge or decide anything, they have no free will of any sort, it’s purely derived from the patterns within the dataset).
Though I personally don’t find the topic of consciousness interesting, it’s not something we are able to define and is distracting from all the other aspects of LLMs that should be discussed or evaluated for what they are.
happytoexplain 20 hours ago [-]
>If you go back in time and imagine yourself in 1950, would you have said that about computers in general?
I'm not the parent, but personally, no, I don't believe so.
I always appreciate the "it's like past changes" thought when things change, but in my opinion, this one simply isn't. It's notably different both quantitatively and, critically, qualitatively, than all previous increments in computers/software. This is much more lateral than punch cards -> assembly -> compilers -> frameworks.
Also, regardless of that thought, the "it's like past changes" argument relies on a false implication: That all changes that survive are "good" in the broad sense. Many changes often persist simply because they are inevitable - not because they are good. They have both good and bad parts, and it's subjective as to which side it leans towards.
dgellow 20 hours ago [-]
I agree, and you wrote that better than I could have. Though it’s difficult to say why exactly I feel that way
subygan 1 days ago [-]
Ai is a tool in the same way an employee is a tool. very unlike a hammer.
Economics would have always created this downward pressure on demand for software engineers regardless, either companies would replace the number of engineers they need with AI, or with low paid offshored workers.
pelagicAustral 1 days ago [-]
I don't know what kind of company has got a large codebase and it's taking 20,000 loc pr's expecting that shit to be sustainable, but I work AI first and at the most PR's are touching 12 to 15 files, with the more radical ones sitting at 30. They are still human-reviewable. They are still the kind of change you can revert back to original without breaking all the rest... there are ways of doing this stuff, dear luddites.
mezyt 1 days ago [-]
I was wondering how anyone could reach the token limit of a 200$/month Claude subscription. I never did on a 20$ one, and I'm parallelizing Claude to the absolute limit of what I can reasonably keep in mind. And I do that day and night, on week-end too with open-source. Now I'm absolutely convinced that it's by doing crap architectures and design that require 200k token of context before adding a single checkbox. If you apply good design principle and course correct the AI in real time before it commits to really stupid way to fix things (i.e. you don't ask it or let it do things that would make zero sense if you had to do it yourself), then the vibe coding cost way less and is way faster and easier to reason about.
florianherrengt 23 hours ago [-]
I’m hardly a Luddite and you’re basically making my point.
You’re deliberately constraining the output so changes stay small, human-reviewable and reversible. That’s good engineering culture.
It isn’t all or nothing. I use AI heavily but that doesn’t mean I have to pretend there aren’t serious problems with how it’s being used.
oceanplexian 1 days ago [-]
> The engineer opening a 25,000-line PR should have stopped the agent long before it got there.
So many A car is simply a faster horse arguments being made here.
The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.
rfgplk 21 hours ago [-]
> The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
I'm working on this right now, will have a release probably in a week or two. Not machine code but it's essentially a custom assembler/compiler pipeline (close enough) that an LLM can operate via the CLI (you can do it too, it's just way slower) and it emits native asm optimized chunks that can then be inserted back into cpp (working on a rust et al impl). The results are _obscenely_ good. It's outright outperforming gcc vis-a-vis by a MONSTROUS margin, and it's not even close. As in, gcc can do abour 3-4 cyc/byte (arbitrary workloads on a wide variety of tests) and my tool does it in 0.5 cyc/byte if not better. It outright emits kernels that run at a flat 4 IPC for more or less _anything_. You can then have an LLM convert it back into high level C++ intrinsics (not always, gcc doesn't always expose all the levers needed to do so) if you wish. The one downside is that you need to provide fairly accurate cpu arch maps (ie agner fog instruction port/latency tables) for the tool to work right, which is what i'm focusing on right now.
florianherrengt 23 hours ago [-]
I do have a genuine question though: what value are you adding at that point?
If you don’t understand the system, don’t know what the code is doing and you’re mostly prompting an LLM to make the decisions and implementation for you, what exactly is your contribution?
The ability to operate the tool isn’t much of a moat if everyone else has access to the same tool.
I don’t review assembly produced by a compiler because the compiler isn’t deciding what my system should do. It’s translating a program whose semantics were already specified. More importantly, that translation is deterministic.
A compiler takes a human-specified program and translates it into another representation while preserving its semantics.
If in five years I can give an agent a complete specification and reliably verify the resulting machine code against it, then sure, reviewing code may become obsolete and I’d happily stop doing it.
Also, keeping changes small isn’t just about making individual lines readable. It limits blast radius, makes behaviour easier to reason about, isolates mistakes, makes changes easier to revert and so many other things. None of those properties suddenly become obsolete because code generation got faster.
shishy 22 hours ago [-]
Do you think it's impossible for someone to have a 25K line PR / diff but not know what's going on in the system?
I ask because I've pushed some of this to the limit in my own testing and when I get the right building blocks / primitives in place in the repo, I'm able to get plans written in a way where I don't just describe what I want but specifically mention outcomes, verifications, constraints, etc. that utlimately describe the shape of my system and my intent.
My plan is my understanding of my system and the changes I'm making, and the execution of that plan (e.g. with subagents), verified against my spec, is the code itself.
With the correct building blocks, I've found that frontier models can write code in fairly predictable ways that lets me maintain my understanding and confidence in pretty large PRs.
I think perhaps the quoted part of your post seems to imply it's not possible / isn't phrased with that nuance?
Chaosvex 8 hours ago [-]
> Do you think it's impossible for someone to have a 25K line PR / diff but not know what's going on in the system?
If you didn't write any of it? Yes, you only think you know what's going on.
florianherrengt 21 hours ago [-]
For the vast majority of 25K-line PRs, especially AI-generated ones, I would bet money that the person opening it does not actually understand all of it.
If you genuinely understand the resulting system, then that's fine. That’s not the behaviour I’m criticising.
This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.
I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu
I remember people used to debate all the time about if there were "10x" engineers or whatever. A few I'm sure, but I think the real problem is we have a lot of 0.1x engineers or worse.
And more directly, I believe good software engineering is really hard. I think it takes a certain mindset to begin with that many people just do not and will never possess, and it takes years of experience to get a good sense of what works and what doesn't, especially with respect to the entire relationship between code, business, people and teams. Yet we constantly see all this devaluation of the practice of software engineering ("code was always the easy part" - bull-fucking-shit), often times by our own practitioners of the craft.
For one, the industry never did professionalize to begin with, certainly not in the way accountants, lawyers etc did. We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.
Additionally, it wasn't software engineers doing this, but people looking to cash in on students looking to get a 6-figure job. They were business people, not software engineers.
"Professionalize" is an interesting way to frame this. As Milton Friedman argued, occupational licensure is almost always pursued by the practitioners rather than consumers. The licensing boards are mostly run by practicing lawyers and CPAs, so you have practicing lawyers and CPAs determining who can compete with them. So what you get are cartel-like bodies.
Most people don't know the histories of how these professions came to be what they are today in the US. If you take 15 minutes to read up on it, it leaves little doubt what the intentions are and how much consumers have been screwed.
> We never had any real body that could certify proficiency, which is what contributed to companies having to resort to leetcode and other such styles of interviewing.
Except that basically everyone in the industry knows that leetcode doesn't test real-world proficiency. It's equally dubious to believe that some sort of body (ostensibly run by practicing software developers) would be able to come up with a means to certify proficiency.
Incidentally, many of the outfits "looking to cash in on students looking to get a 6-figure job" placed a heavy emphasis on teaching their students how to interview, not how to be proficient.
I very much mostly agree with you, but I did take the Google Cloud Associate exam a year and a half ago and honestly it felt like a pretty rigorous exam. I definitely could not have passed that exam if I was incompetent in my knowledge of cloud and IT. Exams like these, I think, might become more mainstream in certifying developers in my opinion. (Though whether this is desirable is another question.)
Are you happy that the license is much less a license to do the work and much more of a license to hire unlicensed people to do all the work.
And lastly are you happy that private equity can "hire" the licensed professional to hire 100s more unlicensed people to run a huge company with a catchy slogan?
> In the Balanced Budget Act of 1997, Congress capped the number of residency positions that Medicare would fund at each teaching hospital at 1996 levels.
https://thehill.com/opinion/healthcare/5550556-residency-cap...
People don't need a government body to tell them to check for credentials. If people care they can ask (I had to give a copy of my degree certificate thingo to my employer a job or two ago, they cared that I was qualified). The whole and only point of mandating licensing is to raise prices for consumers.
EDIT
Just while I'm thinking about it, the law is expected to be easy enough for everyone to follow while simultaneously there is is an absurd legal fiction that only a licensed professional can talk sensibly about the law. It is internally inconsistent that lawyers would require a license.
Rarely does anybody care. I heard it's useful for safety-critical stuff but have never met anyone who has made use of the designation.
But it's not certain you would even be able to continue to do the job if you botched things in a horrendous fashion. There is precedent for individuals being barred from working in certain industries if it is considered necessary to protect the public, even when those industries are unlicensed. Granted, it is rare and a lot more complicated than where licenses are found, but if you've botched things in a horrendous fashion anything is possible.
Accountants and lawyers effectively controlled their customers. You can't use accounting or legal work for business purposes without those things coming from licensed practitioners. And they have no other use than to work with regulatory agencies (loosely speaking such as courts, IRS, etc).
If you lock down software development too hard, people will write their own. It's easier to hack something together that solves a specific problem than to write general purpose software that can be sold. And eventually the licensed programmers will break their own rules, for instance by using un-approved computers, languages, and development tools, in order to compete with software smuggled in from overseas.
- Submarines.[1]
- Homeland Security [2]
[1] https://www.buildsubmarines.com/
[2] https://www.dhs.gov/homeland-security-careers
Regulatory bodies generally need a raison d’etre to exist (like people will die, or go to jail, if we screw up). They also need to provide clear benefits (to the licensees), like medical practice, or CPA licenses.
I don’t think that ever worked, for software. Companies have been hiring anyone that can spell “algorithm,” for a couple of decades, and making money, hand over fist.
In my case, I’m sort of grateful. I have no “on paper” qualifications (high school dropout, with a GED), yet managed to have a long career, working with some pretty heavy-duty pros.
Would we be insisting everyone writes bad 90s style OO code because that's the professional standard? How do you have standards when the field is still figuring itself out?
Are we at a stable spot now or am I just overindexing on my personal understanding?
Good!
> having to resort to leetcode and other such styles of interviewing
Such test filter out the obvious frauds.
I know everyone says that, but I really don't think that they do a good job filtering out shitty engineers. I have worked with plenty of incompetent people who managed to get past the leetcode challenge but are wholly unable to do anything useful involving software.
I feel like what leetcode primarily tests is "does this person know how to use a hashmap in a way that you shouldn't actually use it because you lose cache locality", and that's literally all they test.
Generally they are just wanky bullshit from some middle manager’s slightly-incorrect recollection of their first “data structures and algorithms” class, and the solution is almost invariably “use a hashmap” or “use a minheap”, even though the scope of these problems is usually so small that in a real implementation you would probably do in a more naive big-O-unfriendly fashion because constant factors are going to matter more. Let’s ignore the fact that most of the people who are designing these leetcode problems haven’t actually done any actual optimization and optimization is virtually never part of the job you’re interviewing for.
I don’t know what the “correct” way to interview is, but I am fairly certain that the masturbatory leetcode problem is not correct.
The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
if you need garbage like leetcode to filter out "obvious frauds" you got a whole lot of problems in your company/team/...
He did so. He aced the test. He got the job with a huge offer. He agreed that the ROI was out of the park!
P.S. I'm curious what your test is for obvious frauds?
Your friend would have spent three weeks practicing their sketching, right? And they would have made a decent drawing at the interview. And that would have the exact same ROI as spending those weeks on practicing leetcode.
The point is not that studying leetcode is good ROI. The point is that large orgs are testing for something that isn't relevant to commercial coding.
Also, if someone is unwilling to do the work to pass the leetcode test, they likely don't have the ambition to get the high pressure jobs.
If the bar is that low, just use an accredited degree, certification, references, or a proctored quiz with questions like "define a linked list in < 3 sentences," and it would be just as effective at filtering the very lowest, while more pleasant for everyone involved and maybe cheaper. Crammable puzzles that don't represent real software engineering don't provide much more value than those filters would.
What absolute drivel. I've done plenty of leetcodes. I don't care about writing a qsort algorithm, I know the trade-offs, unless you're working for a FAANG or FAANG-adjacent company, the need to write your own sorting algorithm implementation is probably zero or near zero.
A dice throw and some chitchat would be better recruiting.
...and everybody clapped?
I have news for you: passing an online leetcode is now so easy that an AI can do it. If you think you're catching the cheaters, you're just wrong.
Leetcode was always a stupid test of competence, but it was cheap and it had a high true-negative rate, which filtered the riff-raff. That isn't true anymore.
Man, there are times when I really hate this industry.
So this is a new presentation of an old problem, I guess is the takeaway there.
I'm sorry, but if I'm doing the hiring, the person who isn't willing to come on site to do an interview will be one of the first people off the list to hire (I mean, unless it is a remote job, and the person is nowhere near the employer, obvious exceptions would apply).
In-person interviewing can be extremely valuable. Will it filter out every bad candidate? No, some people excel at faking it. However it can be a big help in finding a good candidate.
Nobody said anything about not coming on site. That's how we used to do it, in the ancient pre-history of 2019. What I said was that if you bring someone on site only to leetcode them, you deserve not to hire anyone.
The downside, of course, is that you don't have the cheap, dumb pre-filter of a memorization test anymore, so you'll have to figure out a better way to winnow down the applicant pool whom you're willing to pay to bring on site.
Maybe finally software engineering will achieve a level of interview maturity seen in other professional fields...but I doubt it.
Or as I'd like to call it - Wednesday :)
After they rejected me I had to point out that their test is selecting for the cheaters.
When you check in at the airport, the machine asks you to certify you are not carrying banned items. Of course, one wanting to break the law and carry banned items would certify it. The purpose is that if you get caught with the banned items, and you certified you did not, it's an extra charge they can paste you with.
To me, the difficult parts of software engineering are in the design. That's where you're defining the problem you're trying to solve, picking what technology to build upon, what kind of architecture you're planning on implementing, ruling out what does/doesn't make sense, taking input from stakeholders, and finding the balance between price and performance. Once all that is covered I generally have a good high-level mental map of a system's structure, and actually writing the code to bring those ideas to life truly is the easier part.
That being said, I still believe writing good code is a skill that is only learned through experience/the practice of actually writing code. And that experience is necessary for reviewing code - regardless of whether the code you're reviewing was written by humans or AI.
Kind of like baking. Putting it in the oven was always the easy part. But combining the right ingredients in the right ratios is necessary, and much more difficult than the putting-it-in-the-oven part. And even then, it takes experience to know when something needs to be pulled early or left in longer. Because ovens are non-deterministic.
This is exactly why I became a PM [1]. I wanted to do "harder" things that had bigger scope than I could do as "just an engineer", and the kind of roles that offer that scope within engineering end up being thin on the ground. Unfortunately, what I've generally found is that being a technical PM is a good way to have people try to knife you constantly. Most PMs are technically illiterate MBA types, and carry a deep grudge against anyone who gives the technology any consideration. They're also good at politics, and want you to die. On the other side of the coin, because most PMs are technically illiterate, engineers often instinctively reject you like a tumor. To overcome this, you need to appeal to the technology, which puts more of a target on your back from the other PMs...
Anyway, my point is that this is all very sad, because you're describing is exactly what a PM does -- but with technical competence. And because of the way the industry is structured, the people who can do that either get shuffled into people management, or reach a rapid career ceiling when so-called "architecture" roles aren't available.
There's this pervasive myth that you cannot be good at technology while also prioritizing the business needs, but usually what this really means is that the "business types" bias in one direction exclusively, and treat the technology as the enemy. It's why so many companies are AI-maxxing now -- the promise of replacing the expensive nerds is the eternal flame for the MBA.
[1] well, that, plus after being a founder, people were suddenly willing to hire me to be a PM...
I used to do a lot of interviews in my previous career, and I can't tell you the number of times I'd be interviewing someone who could talk a good game, but the second it got to writing code, if the world depended on them being able to write a simple correct loop, we'd all be dead. I know everyone shits on Lee code, and I agree the "brain teaser-y" nature of it doesn't often match real world development, but often times I'd tell folks almost exactly what the code needed to do, in English, and they still couldn't translate that to sensible code.
Last side note, when this topic comes up I feel some folks are really biking it down to the absurd "typing was never the hard part". Well, yeah, sure. But actually writing correct, maintainable, well-structured code is (was?) very much at least one of the hard parts.
Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two.
People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.
> ovens are non-deterministic
Uhhh… no? Modulo calibration drift, they will get to and hold a commanded temperature for as long as you tell them to. The ambient humidity and temperature in your house / bakery may differ - which can absolutely affect some foods - but ovens are pretty binary.
Whenever I've used this phrase or seen other people use this phrase it's never been in the context of software engineering. It's always been in the context of literally just spitting out code that a compiler will accept. Believe it or not, a lot of students in CS cohorts have significant struggles fighting the compiler because they just don't understand the language they're programming in and are slow to become proficient (if they ever do). Thus, a lot of people have this idea that writing code, and I mean literally just spitting out something that compiles and runs is hard.
Doing that is indeed quite easy today. That's what we mean by "coding was always the easy part".
Writing code that actually scales into something bigger and is constructed in a way that meets requirements and is flexible? That's a whole different ball game. That's software engineering.
Most of the dolts I interviewed in the UK had a 6 week bootcamp behind them and called themselves "JavaScript Experts". No joke.
To be fair, there were a bunch of students that did listen and worked hard on their assignments and projects and went on to integrate what they learned into their chosen profession and progressed in their jobs. I was very proud of that bunch.
Surprisingly, I wasn't asked by the organizers to teach again. It also didn't help that midway I was asked to switch from teaching web development to machine learning and they didn't really like it when I said "but those are two very different things".
It's the great strength of software engineering as a profession that formal barriers to entry are so low.
You are right that good engineering is hard, and many people who went to these bootcamps didn't make it. But that doesn't mean we need more bureaucracy and paperwork to keep people out.
You can learn a new language, in a couple of weeks, if you’re experienced.
But you’re gonna have a heavy accent.
Learning the language without an accent, takes years, no matter how good you are.
There’s always stories of apocryphal John Henry types, but I’ve never actually met one, and I’ve worked with some pretty sharp characters.
Any profession with scammers, con artists, and snake-oil sellers?
There is very little innovation going on. And most companies do everything they can to stick to standard patterns, technologies etc where all the risk is removed and known in advance.
Often "good" programmers are worse - they over complicate the architecture, go off on tangents, try to solve problems the business didn't ask for either etc.
So bootcamps filled a need.
because they've been bitten plenty times before by business telling them that certain requirements are not needed, just to be told 2 weeks later that they are...
This is not any different with offshoring before, and AI now.
Why? While the rest of your comment explains why the plan failed, it seems like it should be pretty obvious why business would try to attract an increased supply. Hint: It puts downward pressure on price. Same reason they are trying again with AI.
> every other job I can think of at a similar salary level has entrance requirements'
Yes, the artificial restrictions on supply is how those careers have similar salaries. Other occupations moved to have restrictions so that they could have high salaries. Software never felt the need to do the same because the natural market propped up salaries just the same, but we'll see how long that lasts now before software practitioners panic and clammer for restrictions to prop salaries back up like the others. AI does actually seem to be making inroads where "learn to code" failed.
Granted, like as suggested at the top of this, the upper class of software engineers who have the necessary reputation and prestige to drive software towards being a licensed profession are not feeling the same pinch that the middle class is feeling, so that is going to make it hard to see restrictions come to fruition even now. When the upper class of software engineers start becoming afraid of shrinking incomes, that's when software engineering will start needing a license.
You say it like it's a bad thing.
About occupational licensing for software: it's also a uniquely global market, so I'm not sure how any one economy moving ahead with occupational licensing would work, unless they also restricted what software you can import or use in the cloud.
Relatively easily, tbh. Just create a regulation that requires either the country's standards or equivalent ones to be used in the creation of any software sold to people/businesses in the country/region.
What to you suggests it is said as a bad thing? It reads neutrally to me.
It's the same behavior around consulting firms, code boot camps, and now AI.
Management types really really really loathe software developers for making good money, and have spent decades now jumping at any advertisement that suggests it can undercut the salary of your current crop of engineers.
Devaluing software developers has always been the point. Whether you take the cynical view of "They resent us for being expensive" or the apathetic view of "Capitalism simply wants to eliminate any and every cost by definition"
Of course. I bet you loathe having to spend $70,000 to buy a nice car, too!
> Capitalism simply wants to eliminate any and every cost by definition
You could look up what life was like under Soviet communism. Me, I prefer capitalism.
Advances in computing can not be pinned just to planned economy/capitalist economy. For example the West Germany computer industry, French computer industry, UK computer industry (with exception of ARM), Japanese computer industry have fallen behind.
Increasingly I am of the opinion that software engineering aught to be a licensed profession, similar to civil engineers, medical professionals, or lawyers. A board of peers to hold you accountable and a licence that can be revoked at any time. Additionally, legislation could be written to require such licensed individuals in safety critical roles.
I suspect the debate around AI assistance tools would be quite different if there was greater accountability for programmers and a constant threat of losing a licence.
If you brick millions of machines impacting hospitals and airports, you should probably never be trusted to write code again.
https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...
Those people would be writing the regulations.
I'll admit I am unsure how such individuals would be chosen. I imagine it would be prudent to learn what processes are used by other licensed professions when choosing such individuals.
> who write lots of blog posts and books about programming and give lots of conference keynotes
I do not think people who write blog posts and give conference keynotes should be awarded with roles that regulate the profession because they write blog posts and give keynotes. I would hope that any regulation is evidence driven.
Licensing organizations disproportionately attract people who enjoy "administrating" over "doing."
What kind of data will they look towards? Here, we have a precedent from frantically points to absolutely everywhere around us. So the people with "engagement" and "reputation", i.e. they gushed on their blog and farmed engagement, will be exactly who gets appointed to make the decisions.
Have you found existing regulation in any field that's evidence-driven?
My impression is that regulation is not made in a way that has much to do with evidence, but I would be delighted to be shown evidence I'm wrong.
It's hardly a perfect system, but the problem is mostly that it's too conservative and risk aware, making it difficult to impossible to innovate and ignoring the risk this creates. (The world's most popular light aircraft is the 1950s-vintage Cessna 172, mostly because it's impossibly slow and costly to get a reasonably priced modern competitor certified.)
Plenty of regulations in many many fields are evidence based.
Sure, many are not.
But to make such a blanket statement is absurd.
Bring a software engineer into a courtroom as an expert witness, and the jury's eyes will glaze over. Bring in the PE who told their firm not to cut that corner, and the hammer comes down hard.
Even if the certification for software engineers starts as barebones as knowing what WASP is, it still provides an avenue for the feedback mechanism to work (the rules "written in blood"), so that the entire industry can study and learn from what happened, instead of this mess we have now, the peak of which is postmortem blog posts. Even now we have plenty of examples of regulatory frameworks where the regulations adapt to the field like the FDA where you've got a huge spectrum ranging from diagnostics to medical devices of which where are many classes, and drugs where every clinical trial can be tailored to the exact nature of the disease.
The problem for regulating software development is still who gets to formally determine who the "good" people are. This kind of thing should clearly be objective and evidence-based but what useful evidence do we have available?
In physical engineering disciplines there are often clearly evident problems if something was built without being adequately specified by the responsible engineers. In a disastrous case a bridge might literally fall down but you're also going to see that a bridge wasn't designed properly if it's distorting in ways it shouldn't under loads that it should be able to support. There are lots of experienced engineers who have proven records specifying buildings or planes or ships that need to not break using established and peer reviewed techniques.
In software we can all agree catastrophic failures that result in loss of life or half the Internet going down are obviously bad. For something controlling a life-saving medical device or the launch authorisation system for the nuclear missiles we can probably all agree that the answer to what quality level we want in the software is "the best quality we can achieve". But those systems have unusually serious consequences if anything ever goes wrong and probably also very high development budgets that can justify such an extreme position on quality. In general we don't have clearly defined levels of software where different trade-offs between cost and risks and other factors might be considered reasonable and acceptable. Nor do we have well tested and universally accepted standards for how to reliably achieve a specified quality level.
There is zero useful evidence because there is no one to collect it.
The Institution of Civil Engineers was founded in 1818, after decades of random civil engineering societies in Britain doing the exact same thing we are now (running around like chickens with their heads cut off). It wasn't until after the ICE's Royal Charter a decade later that civil engineering began to get really systematized into the "real engineering" we know today and that charter effectively established them as a regulatory body that allowed that to happen.
I'm not sure that is entirely true. There have certainly been a few people who have attempted to study what did or didn't work in industrial settings - either pure academics or people working in industrial research labs. But I agree that currently we have nowhere near enough data to form robust conclusions about almost anything in this field and I think this is the strongest argument that the industry is not ready for any kind of licensing and regulation regime.
My experience with civil engineers and lawyers is many of them aren't worth spit. Licensing is not a magical cert that proves competence.
BTW, if you hire a lawyer in WA state, be sure to ask if they passed the bar. The state has been licensing lawyers who don't pass it.
The way licensing fundamentally works is industry basically strikes a bargain with government to it's benefit. Government lets the licensing organization run a supply cartel and collect protection money (dues, test fees, whatever) so long as they promise to enforce (low) minimum standards along the way. Government gives licensees favorable treatment in court (statutory limits to liability, licensed professionals opinions are more equal than average peasants, etc, etc), etc. And all this stands so long as they do whatever the government's rules say (to the detriment of the customers). And of course the professionals make money hand over fist (or at least more than they're worth) in the process because the licensing organization constrains supply.
Society gets just enough scraps to provide the political will to get it done and keep it rolling (the low minimum standards).
For instance, a lawyer spends most of their time reading and writing, but no one would ever say "you can read and write? Have a crack on our legal team". It's a particular type of writing, and the writing is really a means to an end. This is a distinction that is lost in software development. Every engineering discipline now learns programming, but the ability to write code shouldn't be a license to write software in the same way that knowing how to read and write doesn't just grant you the ability to join a legal team and start writing contracts.
Civil engineering or medicine is hardly a desirable career model to follow.
Btw doctors make mistakes that kill people all the time. It’s a top 3 cause of death in the US AND they often keep their jobs.
Yes, but they make a lot FEWER such mistakes than would people who could not pass the exams and maintain a license.
The standard is not perfection; the standard is as good as practical and better than if nothing were done. Medical licensing definitely meets both of those criteria. Unless you are arguing that anyone who takes a ten-week "Medical Bootcamp" is ready to be a surgeon you would trust to operate on you or your children?
Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
You have it exactly backwards — Credentialing RAISES the skill floor. It does not raise it to perfection, and "Certificates" in the computing industry are a joke, but real medical or engineering credentials certainly raise the floor higher than the software floor
I don’t know if that’s true. More schooling does not mean more trustworthy or careful doctors. And I suspect some negative trait selection.
Milton Friedman wrote a PhD dissertation on the topic of medicine that I invite you to take a look at.
> than if nothing were done.
The alternative is not to invite people who have no experience to build bridges or perform surgeries.
There are no credentials to work at Google. But you’ll find very skilled and capable people running large projects.
Investors want capable people. Those people are vetted through their reputation in their professional circles.
> Would you also be happy to commute to work over a bridge designed by someone with a 10-wk bootcamp in civil engineering?
No. But I would like to drive over bridges from people with 30 years of bridge building experience over a 4-7 year degree.
If you live in Europe you drive over bridges built without credentials all the time.
> Credentialing RAISES the skill floor.
Correct. That’s my mistake.
The point is if cut off the bottom 20th percentile the field doesn’t get much better. Those people aren’t trusted leaders anyway.
You do however lose a significant amount of upside. Including countless top performers from non traditional backgrounds, which is characteristic of computer hackers.
You can maybe argue that the general public, unlike a corporation is not capable of vetting their own doctor, so the government classified those options for them. And that’s reasonable. But that does not apply at all to software engineers who don’t solicit public work.
I have all the traditional credentials and this is not a projection of my own career.
The medical boards are well aware of this, which is why the standards are far more than just about having more schooling.
I am familiar with Friendman's dissertation, and while the economic claims it makes are solid, it isn't a take down about the medical impact of the boards. It really doesn't say one thing or another about them. Let's put it this way: if you are going to inflate the cost of a service, it's hard if the quality of the service is terrible and easily replicated by someone else.
Hardware technology jobs have some of these credentials and are part of that system.
The same as in other regulated professions. It would give the people on the front line who can see the consequences of the corner cutting an effective right to say "No, we're not doing this user hostile thing". This would be a significant barrier because it wouldn't be legal to ship software without the required professional approval and the professionals would be heavily incentivised not to sign off any corner cutting because they would be personally and professionally responsible for any adverse consequences if they did.
What actually happens is that you as an engineer become paid to frame the desired leadership goals in compliant terms.
It’s similar to how lawyers and regulatory compliance rarely change the product. They change how the product is talked about and framed for the purpose of regulation.
This skill among engineers is highly sought after in large companies with political organizations and greater encouraging it changes the composition of the workforce.
Top civil engineers don’t design buildings.
This is true, and basically what tends to happen is that if the Head of some compliance function (e.g. internal audit) is causing problems for the business, then they are replaced with someone who won't cause such problems.
It's still better than nothing. Like, software basically runs our society now, so either software professionals get together on this, or regulations will be imposed on us, and they will be much worse than what we'd get in the first option.
It really depends on the status of the profession in society and the company. I'd expect lots of software organisations to fire a bunch of people looking for people pleasers until this becomes an accepted part of the business approach.
You glibly say "More schooling does not mean more trustworthy or careful doctors.". Yet the schooling and credentialing clearly cuts off huge numbers of would-be doctors who never pass the exams, never graduate med school, or never even get into med school, or decide it is too difficult in the first place. In the software realm, those people just go to some boot camp and they're off to the races...
Another huge aspect of credentialing is required ongoing education, which REQUIRES physicians and engineers to take updated continuing education just to maintain their license. This again continuously improves the talent pool.
And, if your main concern is that they be "more trustworthy or careful", credentialing also helps that by finding the worst, least trustworthy and careful and cancelling their license, so they are NOT doctors anymore. The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere, probably taking one from the actual good engineer because their talent is not engineering, but bullshitting.
I disagree to the extent to which this is real leverage. It changes the language and approach, but not the outcome, Ask a civil engineer the degree to which they can fight their leadership on these grounds.
> clearly cuts off huge numbers of would-be doctors who never pass the exams
Yes the fallacy is that more exclusive is better. You don’t understand the traits you select for.
> those people just go to some boot camp and they're off to the races
I don’t see any kids who just got off a boot camp running large software projects. Does this happen at your workplace? Why not?
> This again continuously improves the talent pool.
I just disagree to the extent to which the talent actually increases.
The people who excel already learn and study all time.
This slightly raises the floor by forcing the least curious person to be exposed to some PowerPoints and videos.
> The untrustworthy or careless SWE just gets a new job to ruin stuff elsewhere
They can only ruin the extent of responsibility and scope given to a new hire with no reputation.
> least trustworthy and careful and cancelling their license
Once again you assume the system works as stated. I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
The image that comes to mind is someone who made a mistake, cares a ton about medicine, and hates the organizational administration.
>>Ask a civil engineer the degree to which they can fight their leadership on these grounds. Both civil engineers and doctors both can and absolutely do refuse to sign off on unsafe situations.
That does not mean they detect them 100% of the time, or never cave to pressure, but they absolutely do. We just never hear about the incidents that didn't happen because a doctor or engineer forced the right solution or no action — precisely because nothing newsworthy happened. We DO hear about the ones that did happen, Therac-25, Mars Climate Orbiter loss, Cloudflare outage, it is endless
>>I think it actually selects against those who are bad at avoiding responsibility and not legally savvy.
You might think that, but clearly you have never read even the summaries of cases where doctors lost their licenses. Hint: it was not some mistake that could have been covered up by better schmoozing. If anything, the system is too lenient.
The rest isn't even worth the bytes to respond; just handwaving an attitude. There are very good arguments to not have licensing on software engineering but you are not making them
You state this so confidently, like every person who walks through the door to interview will be 100% honest about their level of experience.
Have you ever interviewed? Nobody _wants_ a software engineer on their team who is awful.
Sometimes they slip through the cracks for a variety of reasons.
How do you think companies hire for key roles like CEOs?
Only in certain industries, where outcomes can hurt people in any way. There's opportunity to engineer software in just about every industry, but I don't think a widget vendor that wants to connect to a WMS should be compelled to hire licensed anything. Of course, licensed engineers should cost more too.
Direct licensing requirements from the state are prone to abuse via regulatory capture. Big or entrenched players can give to politicians who’ll change the rules in their favor, setting who needs a license and who can get one.
The profit maximizing incentive for insurance is a double edged sword, but if there’s a government backed insurer that just does the prime rate for licensed developers, the commercial market can build off that and fill in the gaps.
If you need a special license and insurance to drive a commercial truck on public roadways, why not the same for commercial traffic on the public internet? A good way to drive adoption from nontechnical folks could be something like the lock icon in the browser for TLS. Issue a domain cert for certified software, you can go to their website and confirm they are compliant right away. People are free to publish and use non-certified apps, they just won’t unless they have a reason to trust them.
Like sure, if you're writing software for medical professionals, or lawyers, or aviation companies then I can see that being something you'd want people licensed for. A major bug in a pacemaker or plane's autopilot system is a huge deal that could injure or kill a lot of people.
At the same time though, a lot of software engineering/programming work is extremely low stakes, and I think expecting that to be licensed would be kinda ridiculous. Having someone need to be licensed to create a small business WordPress site, or local desktop software to solve a personal need, or most video games in general feels kind of absurd. Do people need to be licensed to make say, Minecraft mods or hack a game from the 80s?
The difference with the legal and medical industry is that if someone is incompetent or screws up in those fields, there are almost certainly going to be negative, if not dire consequences for those involved. If someone screws up in tech, then there may be dire consequences in some industries/sub-fields, or no/positive consequences in others.
Government involvement almost always just makes the problem worse, not better. There is a place for control in some areas (medical, military applications, etc), but I think broad-sweeping regulation would do far more damage than good.
Because it isn't creative work. Software underpins payment processors, medical services, emergency alerts, infrastructure. In the UK not long ago a ransomware attack took the healthcare system offline and surgeries had to be postponed. in 2021 the Colonial Pipeline attack took 50% of the US East Coast's oil supply offline. The entire German train system died a few weeks ago for half a day because of a software bug.
People's entire communication is in digital services, all of their private data, the economy grinds to a halt or national security is impacted monthly now by either deliberate attacks or just bugs.
Of course professionals themselves need to be licensed, how else is any company supposed to have any confidence in who they employ or any legal security?
So unfortunately, for those like me who spent a decade in the trades, saw that it could destroy your body by your 40s and decided I’d like to not have that happen to me the number of exits into knowledge work is shrinking.
I'm not the best person to talk to, because I'm not a salaried programmer for some corporation, and I'm not looking for a job from a startup or something. I'm in a unique position where I wrote a suite of proprietary software that clients pay for that they would have a hard time replicating or migrating away from, even if AI helped them. Lucky me, I happened to get into a specialized industry and start writing code for it 20 years ago, and I kept all the data and code logic in my own silos and never shared anything with anyone. So I am somewhat protected because it would cost 3x more to replace what I wrote than to just pay me for the rest of my life to maintain what I built.
By the way, I started this software in my 20s when my body was already being destroyed by physical jobs. I started it while I was driving a taxi and waiting tables at the same time. I learned by reading books in my cab. I don't think that's an option for people anymore.
My best friend worked for a massive multinational similar to Salesforce and he ran a team of 60 people under him until last year. He was not AI-proof. They laid off everyone on his team except for him and 3 helpers, and told him to use AI to do everything else. After awhile, they laid him off too. After interviewing for a couple months, he found a new job, and his job is to manage two people running AIs. It was a 30% pay cut and he feels lucky to have it.
Under any external hierarchy, where I didn't have this lifetime of private code and clients in my pocket, his job would have been way, way above mine. I would have been one of the 60 people laid off.
Okay, so I'm going to say something about this "knowledge work" thing because I've known a lot of people who took courses and transitioned to it from the trades. Almost all of them did not get decent jobs. One of them was a bartender who just somehow got it. This was around 2018. Her husband works in construction. She just sat down and it clicked, she learned to write javascript in 3 months. I'd sit at her bar and tell her what to improve and she'd write it down and memorize it. In six months she was writing like a native, and she got a job at [huge multinational retail company] working on their website. And somehow she survived round after round of layoffs to keep going and become the only person left on her team. I'm immensely proud of her. And she will still probably lose her job in the next six months.
But my ex-girlfriend tried to learn to code at exactly the same time, and it went nowhere. Just didn't make sense to her.
So that's why I wouldn't recommend it. Honestly, if I didn't have the little pile of code I was sitting on that pays my bills, I would go to school to be a plumber or air conditioning specialist, or to repair helicopters or be a car mechanic. That's basically what I do anyway, I just do it in code instead of parts. At one time, what I did was equivalent to building custom cars and engines, only in code. At this point, fixing a car would be more satisfying. No one's paying to build their hot rod in code anymore, that's all being thrown at AI. And the rest of the jobs suck.
I've interviewed many bootcamp graduates. You're right. Many of them can't do the job. We don't hire those guys. But that begs the question - what companies are hiring incompetent people?
I would also throw in the toxic positivity and gas lighting sorrounding that. We got a lot of churn on "we have to be nice to everyone" and fears that people weren't "being included." I'm not saying you have to go all Linus on everyone, but it really catered to those who didn't want to learn a lot of the details or were resistent to testing their own code.
For a lot of people, they have no need to ship production grade software that scales to babel. But a custom script that solves an immediate business need is a common thing.
I think that aim is more important than the harm learn to code might have caused our profession. And for similar reasons, I feel the agency AI brings to individuals is something that shouldn't be discounted either. No idea what the total calculus on cost benefits turns out to be, but I would hope this benefit is not missed.
At my workplace, the earliest programmers were a combination of self-taught and people with real CS degrees. The CS people wrote the OS and languages for an in house minicomputer. The apps were written by people with app experience, mostly scientists. And there were a few odd characters like the secretary who learned programming because it was quicker to fix bugs herself than get clarification from the engineers.
-John Cook
It's similar to why there's hundreds of books about learning the basics of a language, but comparatively few books about good software architecture/design
I’m not in it for the money, and that I can make a good (better than most) living from it is just pure luck and I am genuinely thankful.
But there are lots of people in it only for the money, and they will be very disappointed when it dries up, because the #1 thing these bosses want is for us to have less leverage.. They want it even more than they want revenue.
So how many people "learned to code" and then ended up back on non-software related careers?
I think the industry highly skewed towards the former back in the 90s (and earlier!) when I first entered it. There certainly were vast differences between the best and the worst, but nothing like the gigantic gulf there is today between say a competent kernel driver developer who can get code mainstreamed into Linux vs. a boot camp style disinterested frontend dev who leet coded and brute forced themselves into a FAANG job.
Working closely with other white collar “generic” jobs and the folks who just show up each day and are not interested in the fundamentals at all make me believe this is kind of the baseline for most industries.
Most folks are in it for the money and are happy to just be good enough to not be fired. Since most middle management is utterly incompetent at performance management the results tend to not be great for pretty much the entire corporate white collar industries. A stellar manager though really stands out in such situations, but they are so rare many won’t work for or with one their entire career.
And most businesses aren’t managed in a way that’s interested in adapting to the microshapes of personnel.
They've been replaced by Markdown files asking Claude to burn tokens on doing something deterministic tools already do faster and better, like checking variable names for typoes (I wish I was making this up).
Blame the patrons for demanding more with little care to the quality.
I mostly gave up on software development roles in business when the vast majority of developers and, particularly management and executives, made clear that they couldn't give a fuck about craftsmanship. It was just about shipping, good, bad or otherwise.
AI in software development predates on that appetite for MORE at any cost. When the business doesn't really care about quality, because, let's be honest, most don't, this is what you get. You get massive volumes of garbage.
2010’s was when more traditional CS courses also started moving from traditional languages and content to JS etc…following industry demand.
A lot of tech conferences were pure tech. Now a lot of them are agile, soft skills based, introverted nerds pushed out.
It’s certainly a different place from the 2010’s.
For a certain class of professionals, slowness is a kind of superpower able to restrain their damage. LLMs have turned off those guardrails.
On one hand, I'm not fully surprised -- LLMs are powerful tools, but of course they can be misused. On the other hand, I'm impressed by how fast things are deteriorating in some shops. At my job they got encouraged, over-confident even, to finally do some long-awaited major overhaul in the code base. I'm genuinely concerned about our ability to continue maintaining this mess in the mid and long-term.
I don't think this is attributable to the 'learn to code' push; I know many fine engineers who came through boot camps, and many, many poor ones who came in the 'official' way.
The problem is that we trained too many people, many of them without the aptitude, not how we trained them.
And, as a "Learn to Code" guy who's had a successful and interesting career filled with self-study and continual improvement, I'll call you a gatekeeper.
That is a problem whenever people do things for money. It suggests that a big problem with our society is people are encouraged (in some cases effectively forced) to want money too much.
To work on engineering real time communications systems, banking systems, or transit systems and low level infrastructure, you definitely need some chops. To design and build out core network infra at the web giants, chops also certainly required.
To build out a basic crud app, pwa, or the next feature in the massive products that major companies ship? Yes you need some understanding but it really isn't that difficult or onerous. TBH if you ask me the profession always had a problem where the term "engineer" was a tad over applied. The boot camps are mostly churning out people who can write basic apps, not (hopefully) anyone being placed into a a senior IC and systems design role.
We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.
Our biggest consumer of CPU right now is HTTP connection churn because engineers are creating new clients every request we handle. If the engineers would just think for a second, push back on Claude, even Claude would tell them this is bad. But they don't... Platform engineering is now 10x harder with terrible engineers and unlimited code machines.
Don't even get me started on ffmpeg usage, engineers act like the resources are unlimited.
He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.
I’m personally of the opinion that everyone who works in software should have to rack a server and bootstrap it. Physically mount it, cable it, and get the *nix distribution of your choice running on it, serving Hello, World.
Everywhere I’ve worked, there is a marked difference in the quality of engineers who had played with hardware - even those who merely had expressed interest in it, and maybe had an RPi - and those who had not. There is something about physically touching the thing that runs your code that makes you better at it. Maybe it’s a correlation between “wants to play with something unnecessary but adjacent” and “curious enough to ask why more frequently,” but I swear, it exists.
But you don’t really want lots of idle or underused servers, aside from burst capacity management. So if they universally and consistently wrote more efficient code I’d expect a smaller datacenter. Full of still busy servers but just less of them.
The term for that is "10x AI engineer." Anyone who has anything negative to say about such people is just jealous of their insane productivity and speed.
You measure the output of one person while ignoring the cost they impose on their team.
If I generate 10 PRs in a day but three engineers now have to spend the next two days reviewing them, figuring out what I changed, correcting bad assumptions, debugging regressions and explaining why half of it needs to be redone, I haven’t become 10x more productive. I’ve just moved the work onto other people.
Worse, I’m consuming the time of the people who are usually the hardest to replace and whose attention is already scarce.
That’s why PR count, lines changed or features “completed” are terrible measures of productivity. You can make your own numbers look incredible while reducing the throughput of the entire team.
Taken how some companies award promotions and bonus this is actually a double win. You not only improve your own numbers but also make this of your competition worse! /s
Really? I have never seen that. The expectation was that you could create the code that compiled on day one.
Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.
Just look at how they're merging ~300 commits a week into bun.
https://github.com/oven-sh/bun/graphs/commit-activity
Natural consequence: Then they never grasped the concept of computational complexity.
O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!
The missing part of mathematics education, IMO, would be to focus more into developing the intuition of what something means, instead of the current focus on getting some (numeric) results.
You can't just skip arithmetic drills in favor of intuition and still come out with students who are prepared for further study in math. There's a reason Kumon etc are so popular - parents are replacing the lack of mathematics drills in schools with after school options, leaving behind all of the kids whose parents can't afford it.
And there still are arithmetic drills, it's just not the only focus in early math education.
Kids can absolutely learn complex concepts early, they just may not be able to formally write them out until a few years later. But they’re kids, so who cares? By the time they need to be able to write out math equations, they’ll understand the underlying concepts on such a deep level that it doesn’t matter how long you make it, they’ll plow through it.
I was a skeptic, and am aware that I sound like a cultist, but damn if Montessori isn’t something special. I highly recommend it.
0: https://www.montessori-theory.com/montessori-trinomial-cube/
But the core question of “how does this behave as N -> \infty?” is asymptotic behavior (ie: limits) which were developed for calculus and are very much part of the foundational calculus canon.
Big O notation was invented in 1894.
The visual interpretation/intuition of Big O notation can be a useful way to build a visual intuition of what a function's derivative and integral "shapes" may look like, so some Calculus books teach Big O notation, too.
AI disease is encouraging "sketchy process and minimal checks on the software quality." QA has been eliminated from my team, and the QA engineers that are left have been declared to be developers now.
Gotta move fast, and I guess making sure the stuff we ship works was "slowing us down."
i've gone this route a few times in my career, it's very stressful and involves angry/panicked people and many all nighters. Also, the glory fades fast. would not recommend.
Hiring pipelines that tested the wrong thing have existed for years but the problem is magnified 10x when you test for something that weakly correlates with ability at best which an AI can do better than a human.
This is leading to stuff like incompetent junior-level engineers being hired as principals.
That's basically it. It is surprising hard to find people that can do both, but engineers are becoming much, much better at the first gate while flaming out on the second.
You assume those people haven't already left, been kicked out, or were hired to begin with. We're not in a rational job market right now.
If you are closing one ticket per week with "good" code but your teammate does three with "bad" code - it's actually you are a bad employee. Also they may say you are a toxic one.
I would much rather have someone on my team who ships less but whose work I can trust than someone much faster whose changes leave me wondering what problems we’re going to discover later.
And when production breaks (and it will), I need the person who made the change to actually understand it well enough to help fix it, instead of showing up with no idea what is going on.
You can obviously be an asshole about how you do it but I don’t think pushing back makes someone toxic.
You need to be flexible and compromise when the business trade-off makes sense. But you also need a backbone. If you think something is going to cause real problems, bringing it up is part of the job.
Me too, but it is not what happening across the industry. Instead they are pushing for more LLM usage as well as more features. And faster, faster!
You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.
Trace the increase back to specific deployments, call out those teams, and make them fix their shit.
I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).
Not necessarily, great engineers do also ship temporary code they didn't have the time to trim.
Our process is of 1) make it work, 2) make it right and 3) make it fast; not necessarily that engineer had time for the 3rd step.
Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).
There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).
There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.
JavaScript evaluation for example is complex. Before Chrome the approach was to use a slow interpreter. IIRC, Chrome was the first browser to introduce JIT (Just-in-Time) compilation, leading to faster JavaScript and eventually more complex applications running in that language. Modern browser JavaScript pipelines are complex in order to achieve and maintain performance:
1. start interpreting the code on the AST so it is run immediately (or only rely on (2));
2. generate a machine code equivalent of that interpreted code (for faster baseline performance);
3. run more aggressive optimizations on known types based on profiling/analysis for even faster performance, including special handling of things like asm.js.
[1] https://v8.dev/blog/ignition-interpreter
[2] https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-no...
[3] https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/tracem...
[4] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
There's only so much you can do -- making reasonable assumptions, choosing suitable data structures, database indices, testing various workloads, etc. -- in a limited test environment.
You may spend a week optimizing a feature that only 10 people use or that never gets to the point where it becomes an issue. Or you may have something that can't easily be tested at scale, such as various counts or other dynamic data that are determined by complex queries that you may (likely) find you need to cache but don't necessarily know which values will become issues until you start using the system.
It's even worse than that. We've got a CEO who has suddenly learned how to vibe code and the stuff he's coming up with is... kind of horrendous. He's coming up with new "products" and proclaiming them the next big thing for us to work on and we're kind of over here scratching our heads asking who would want this? Who would pay for it? I mean, he was able to put together a kind of a cool web app (with 0 web app knowledge) that's supposedly going to let users design thingys with AI, but it just seems like he re-invented a harness/IDE. I suggested that maybe what he wants is a VS Code plugin like Cline or KiloCode... but he hadn't used VS Code.
Oh and he's altering course from the previous "AI only where it makes sense" to "everyone should code, even the sellers" and "AI is not optional, we're an AI first company".
Talk about drinking the Kool-Aid...
> With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization.
Yup, and that's going to be the comeuppance for a decade of aggresive overhiring.
There are so many "bad engineers" filling the ranks now that in many teams and divisions there's not even anyone left around who can recognize them as such.
This was already manifesting as a rapid decline in software quality and worsening practices, and the amplification effect of AI is mostly going to make everything worse for a while as we wait for all these declining projects to buckle under their weight.
If you are a good engineer, it's a good time to work on small teams with other good engineers and rigorous practices. You can be using AI to amplify what you do (and probably should), but you need to be rigorously considering your processes and guarding yourself from seduction by blind-leading-blind hype you see on social media or in iconference talks.
>>a rapid decline in software quality
It's hard to expect anything else if budget for QA teams is reallocated to cover llm bills.
I wouldn't be so quick to judge the long tenured engineers. They probably realized that moving business forward is more important than writing artisan code.
You always have some young hotshot who comes in and wants to rewrite your old boring Java monolith into a micro services disaster for "better architecture".
The greybeards learned the life lessons the hard way.
The other aspect to consider is this: stay in this industry long enough and it will beat the soul out of you.
All those smart people are probably using genAI to generate their codebases.
So far, that does not seem to have resulted in a robust, stable system.
Certainly no better than the results the hyperscalers got doing things by hand, and arguably worse.
But, right now I'm paralyzed with fear in how to make a successful career switch without starting from literally "new grad level." I have wisdom, so it doesn't feel like I should have to start at the bottom rung again. Egotistically, I don't even mind, it's just the salary hit that would be the main issue.
Maybe it's not even a paradigm shift (though, I've always wanted to work on film productions). I've sort of lost the passion for being an IC, but how can I make a transition to management without any management experience? Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.
>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?
I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.
It just seems like there’s a reckoning coming for our field. I’m going to keep doing it, I don’t see any other choice right now.
The issue is that with no reins, the LLM is a fire hose of bad code compared to the garden hose of bad code orgs had before. A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.
Let the LLM wars start!
A good engineer, without LLM assistance, will still produce great stuff.
Not fast enough to keep their job these days.
Time was always the limiting factor to code quality, good engineers satisfied the classic "good", "fast" but not "cheap" selection of those three classic options.
I very sincerely doubt it is possible for even an incredible engineer to keep up with the delivery schedules required to ship products now. Not to mention that frontier models do ship pretty consistently good code. By far the biggest source of issues I see is not "poorly coded" but "problem poorly specified". We still need good engineers, because they can understand how to do decompose problems well, but I don't know anyone who writes code by and anymore (other than for fun).
What's the current delivery rates? From my past experience, any feature can take several weeks from idea to be in a somewhat usable shape for production. While the actual coding is often less than a few days. A lot of time is spent on gathering requirements and resolving conflicts between them.
I believe most current improvement in speed is just moving from idea to demo in a few days, then spend several months fighting bugs. While the customer can't really use said feature.
This is an outdated view.
Current timelines I'm facing are to be going from "thought", through customer trials and being fully live in the product and ready for sales in ~3 weeks (from kick off to live in app is a bit more than a week). This is for a full product feature that could easily be standalone. In 2023 I would say the timeline for a similarly shaped feature at another startup was around ~3 months (and the team at the time agreed that was an aggressive timeline). Bug rates are not noticeably different than other teams I've been on in the past 20 years.
Nobody I know working in startups is still building demos with AI like they were a year or more ago (for work), that's seen as largely a waste of time since you can just ship the feature and be experimenting with customers much faster.
On top of that everyone working in startup land knows that SaaS's days are numbered, so you need to be shipping working software fast enough you can get ahead of the curve to navigate where things are going next.
My issue with these kind of numbers is that they never contrasted them with a NO_LLM practice while keeping everything the same. It's always perfectly fine to YOLO generated code straight into prod, but if you handwrite it, you need to fill several forms in triplicate to even make it to the review phase. Then someone claims they are 10X-ing their productivity with AI.
> you can just ship the feature and be experimenting with customers much faster.
That's basically what I said. Instead of shipping something that have some value to the customer/user from the get go, which may takes one or two months, you spend one or two weeks on it, ship it, then frustrate your customers/users when things aren't working or keep shifting around.
For all of AI being touted as the best thing since sliced bread, there's been little to no value for humanity as a whole.
I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.
There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.
...as Mickey Mouse was fond of telling me as I waiting for the ride at Disney World. Or it was my drill instructor. can't remember which.
my take is everyone in the industry should read grog-brained developer, & no silver bullet before working as a professional.
the other is a mindset change - the best working code is code that's never written as it doesn't have bugs or suffer technical debt. Agentic coding doesn't solve that. Human taste does, which means our job is to reduce the amount of lines we write. agents etc are useful for the filler or bullshit part of our jobs e.g generating tests.
but ultimately I think the whole spec-driven development & agents spitting 100000s of lines era will be looked upon as mass psychosis.
last thing to give an analogy - you don't carve a David statue by gluing together pieces of marble - but you carve it by cutting pieces of a huge block of marble.
So yes, garbage in -> garbage out, but framed in a way that makes it clear what is garbage. The ideas, not the engineer themselves :-)
This suggests we need to be doing more designing and planning; introducing that friction intentionally to make sure bad ideas get culled, viable ideas get refined. Critical thinking becomes the bottleneck; the quality of the idea becomes the deciding factor in success.
I think the real pain though is that AI also often removes the feedback loop between "good" engineers and "bad" engineers. A lot of "good" engineers started as "bad" engineers that learned, sometimes the hard way and sometimes with patient mentorship, how to be better engineers. Patient mentorship becomes harder as code reviews become less personal. "The Hard Way" becomes harder when the consequences get divorced from actions. For a bad engineer it becomes "Claude broke Production" more often than "I broke Production" and learning mostly ceases.
We're starting to recognize how many junior developers AI is replacing, making the pipeline to senior developers harder (if not disappearing), but we also maybe aren't focusing enough on how much we are also losing the pipeline from "bad" to "good" engineers.
Which is an incentive problem, they have likely reached an equilibrium with their company. Genuinely few companies provide any incentive and critically, the space, to ship good code.
Because frankly it doesn't matter in the middle grounds. Which is where 90% of developers are.
I wish we all had fulfilling edge of our seat projects to work on, that challenged us just right, mattered to our community etc. AI is absolutely poised to disrupt the middle 80% of development because the middle 80% of dev is not that important or hard.
It's just a shame for all of us who loved the craft, and didn't mind being in the middle making a living. That's a totally noble place to be, and it could get taken away from many of us.
The past 5-10 years or so saw me pretty beaten down though with software engineering, and AI was the final nail in the coffin that caused me to leave the profession in later middle age. I thought software as a business had "lost its way" from building great products with attention to detail to "how do we addict as many people as possible as quickly as possible". Think about the degradation in Apple software from say the "it just works" era to now.
With respect to AI, I'm not really against it, and I find it extremely valuable in my personal projects. I just feel in a large group/enterprise context that it's replaced a lot of tasks I actually enjoy doing with becoming an editor for what feels like a slightly inebriated junior developer. Or maybe it's better to say a junior developer on a mild amount of meth, because as you say this developer can churn out semi-but-not-fully-working code at an astonishing rate, and then I feel like it's often my job to mop the slop off the floor. Pass, not interested.
I feel lucky to have had my career during what I consider the golden age of software engineering, but I'd note I don't think that golden age lasted even a full career of one person.
Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.
Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.
Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.
Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.
Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.
The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.
For the vast part of my career I worked for good companies that I thought were comparatively very well managed, and I was especially fortunate that overall I think I had excellent bosses. But the reality of the Internet age and CICD in particular is that speed is much more important than quality. I don't even really disagree with the business imperative of "ship, ship, ship", but for people who really value their craft, it can be discouraging shipping stuff you know is always kinda half baked. I was definitely not a "gold plater" either, and time pressure was certainly a thing pre-Internet, but as you say mistakes were a lot more expensive then so there was more business rationale to ensure quality before a release.
Since it sounds like you built software during that era, thanks. Thanks for the memories.
To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.
What year did you leave? And what are you doing now?
It's actually this that leaves me feeling optimistic. We're definitely bad at this today, but will we always be bad at this into the foreseeable future? I'd like to think not. I'd like to think that we'll get better at working with agents in the future and eventually develop better practices around this new weird technology once it's better understood.
I'm seeing a bad pattern of vibeslop being used to solve the immediate complaint of the user without stepping back and reconsidering things from a product perspective. Just add another conditional statement to make this very specific scenario the user complained about work the way they want.
For everyone adding value with LLMs there will be way more destroying value. If you roll a critical failure a mediocre LLM enhanced VP convinces the org to sail aggressively in the wrong direction.
I know this happens, but don’t really understand it.
In my experience, quality hits usually resulted from external pressure (bad managers, trade show-driven schedules, etc.). I always wanted to do better.
Now that I’m retired, I take the time to really get Quality right. LLMs have helped (but they need close watching).
I'm having the impression business decisions always win, time is always reduced and requirements always changed half-way during a project, having a much greater impact than any bored old engineer.
This is where the quality magnification seems to be occurring.
Goal-driven loops can make good code great, or bad code worse.
one good swe out of ten with high authority may be enough in most organisation
and
> I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.
those people who lack the right skills today – are they the bad engineers you'd mentioned previously?
It seems pretty clear that the current crop of executives strongly prefer the latter scenario.
Yeah, that sure sounds like paperclip maximizing hypercapitalists. Real big on sharing, not so big on minding the cost, but they just can't show their love for us all while employee labor still has some value to them. Once that's out of the way and they've taken or mulched everything of value from others, that's... that's when they'll start giving it all back, yeah.
I know the sarcasm isn't helpful. But goddamn I can't understand this take, I don't know why people believe people-shaped entities like [your favorite wealthy sociopath's name here] will become society's mommy if given the power, and it's incredibly fscking frustrating. Like people who think once their home and everything is burned to the ground, the fire will rebuild everything, but better.
If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.
At my org we use Github Copilot as our AI tool for devs, both internally and for vendors (Including a WITCH =/).
Where it gets ugly, is that we have a -lot- of WITCH provided code already in our systems, and as a result GHCP winds up often preferring the existing (terrible) patterns.
I've done some things to help mitigate at least; Adding instruction/skill/agent files, tossing in some LLM-built .NET analyzers to catch the worst anti-patterns to warn on build and error on CI, and making sure to call out when the vendor people are obviously not even reviewing what the LLM generated for them [0]
[0] - Simplest case being, EF Core mappings where the datatypes do not even exist in the target DB...
I've often had it test and benchmark against the wrong things = no test.
It also writes over-engineered code. So yes sort, maybe.
i think i fall into this bucket. our "leaders" and executives have told us they dont care about 'shipping good' . we are simply responding to incentives.
This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.
I for one tend to care less about the minutiae of solutions implemented by AI as long as it gets the job done, I do care about architecture and design decisions and correctness and I have ways to steer and verify these when working with LLMs but I couldn't care less about it writing "good" code. Bad engineers also produce better results with AI at least when they're working in established frameworks, AI doesn't really need a lot of high level architecture input when designing or building a web app with a common stack, so as long as you're not working on something that's completely novel I don't think it will make a strong difference.
Maybe designers think the same way about the AI generated web designs I have Claude Code do for me but to be honest I don't care, I just know that before this tool existed it would have taken me weeks or months to come up with a good design and I would have to rely on prefabricated UI libraries and stuff like that or pay a designer tens of thousands of USD to make one for me, now I can get a (for me and my customers) perfectly acceptable and professional design within a few hours. So maybe I'm also a bad designer that amplifies my bad design taste 10x in my company, but the fact is the stuff ships and makes money and the customer is happy! And I can tell you customers or users don't give a shit about how good your code is, they only care if the software works and does what they want!
There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.
I think with AI coding, what we call "good" code changes. Lots of abstractions really only exist to help load the context into the human brain so that they can solve the next problem. If an agent can just search and find all the places to make a change, or to duplicate code with small changes for the next problem, is that bad? Does is just feel bad because that's not what we're used to?
We use structured looping instead of gotos because that makes sense to us, but the compiler still turns it into jumps in assembly. If our interaction is now at a higher layer, do we need good "code" or do we just need good "architecture"?
I don't know, but it's just something I've been thinking about lately.
On a large system, the customer being happy today isn’t enough. You need other engineers to be able to understand the system.
Have you ever been on call and been woken up in the middle of the night to fix a production incident in a system you didn’t write?
If everything you build is small, isolated and easy to replace (basically fire-and-forget), then yeah... who cares? Ship the ugly thing, get paid and move on.
If you’re going to be working on something for the next 5+ years, you should definitely spend some time thinking about what you’re doing.
Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D
It's much easier for people to pump out absolute garbage, you know the kind of "just get it done fast" slop that management types cry out for. And then they wonder why everything end ups broken, not being maintained etc.
And I think the contrast between good and bad code output is much more impactful. Someone can pump out 10x the bad code they used to before, never test it never read through it just push push push baby. And then for good code, sure it's increased my output for slop tasks like repetitive unit tests, but a lot of TLC and review is required for good code and I'd say I've had maybe a 2-3x speed up on a lot of things. But not 10x; you only get that when you don't give a fuck.
Specifically, I’m spending a lot of time on the first few instances of a pattern that I hope to have the AI scale out for me. My thought is that I can provide an opinionated project structure, feel it out myself, then point the AI to those working examples in the future. Until then, I’m mostly just using ai as fancy autocomplete + domain research.
I would expand this even further and say that the worst problem for people in the trenches isn't even just that this is happening, it's the it creates a situation where managers are held to some expectations (their team shipping product features) that incentivize not looking too carefully at what their team members are putting out. It makes it really hard to tell a boss "we need to stop and spend a few days reviewing and rewriting because one of my teammates likes to one-shot everything with poorly thought out Claude prompts making multithousand line PRs" when their own bosses are breathing down their neck.
It's the same struggle we face to get refactor work prioritized, just at a much more frequent cadence. "It's working so why do we need to spend another sprint on it?"
A big part of this is ensuring that a "bad" engineers can still write solid code and also investing in systems that make it easier for us to review code.
When it comes to writing code, we have this entire library of coding standards that we've moved from one project to another. It describes, sometimes in excruciating detail, exactly how we want our code structured, antipatterns, best practices, etc.
On the review side we have invested equally into skills that split up code into readable chunks, take screenshots of any UI changes for quick validation, and a whole battery of tests to ensure that we're not generating slop.
If you were to look at just our development process, you would conclude that we're very lazy engineers. We seldom write code by hand, we seldom ask for corrections and our reviews are more of a cursory look at the PR rather than a deep review.
But the real work is not in the "development layer", it's now in the "agent layer". Making sure the agent knows how to write solid code so we don't need to write code by hand, making sure it doesn't make dumb mistakes so we don't have to correct it, and structuring our review process in such a way where an engineer only has to take a cursory look at the code.
The key difference we noticed between the "old way" and the "new way" is the "new way" is way more scalable and we're able to move way faster than we ever could before.
But do the people still understand what the system is doing and why?
You can have code that perfectly follows every standard and passes every test while gradually building a system nobody has a mental model of.
> an engineer only has to take a cursory look at the code
If that means you’ve automated away checking syntax and implementation, great. But we already had that before. If it means nobody needs to understand the change anymore, then this is exactly the risk I'm talking about in the article.
This is why I don't have any patience for the people who say "but AI is so powerful! we can do so much!" It amplifies the bad stuff more than the good stuff, so it's a net negative.
I am just tired of typing and looking up syntax for every line of code.
This, however, is a slippery slope, and one has to be mindful of falling into cognitive surrender.
We now need to talk about the 10xBad engineer.
Prove who's good and bad.
And you can't really, because there's always tradeoffs you're making as an engineer. The really self confident ones think their tradeoffs win, and maybe they do, though often they don't and these people are just self aggrandizing and stroking their large egos. Are you a better engineer just because you made a big talk and had the confidence to share it with lots of people?
Hopefully when there's bad devs, there's a bit less making a mess where someone doesn't know better and as a result some amount of average or general best practices start happening.
This can be true not just for software development, but making a mess in anything, including a spreadsheet.
Absolutely on point. I just completed the port of a industrial application written in Python using a sophisticated console-based UI to C# and Avalonia UI. This is my second major coding project using Codex.
The one salient element of the experience has been that, as I keep saying to anyone who will listen, AI still does not understand anything it is doing. It presents an amazing simulation of it, but, no, it does not.
Here's a simple example: The original application had a clean communications protocol implementation. A single file with a class that implemented every single command you could have the industrial controller issue to the hardware. Codex was explicitly told to replicate that in C#. It did, at first, but then it started to duplicate command processor code in the individual functional blocks throughout the application. Which means that, when a bug surfaced, you had to fix it in five different places.
Another example: The application has a highly customized table view. Once again, it was told to make that a component to reuse throughout the application. It did, at first, and then weird bugs started to surface that made it clear that it had reimplemented the table control in different areas of the application.
If you don't know what you are doing you will probably not pick-up or even care about some of these things. It is easier to whack-a-mole bugs with AI than to worry about code structure, efficiency, maintainability, future-proofing, scalability, etc.
I purposely decided not to look or touch a single line of code during this project to see what's possible and where the issues might be. I learned a lot and continue to learn. I think the next step is some sort of an agentic approach, maybe using OpenClaw (or whatever, I don't really know right now) to create a team with coding, supervisory and testing agents.
While the project got done significantly faster than it would have without AI (four weeks instead of probably 4 to 6 months), the process was just as intense as coding, just operating at a different level, micromanaging architecture and implementation.
Were you only relying on the difficulty of producing "working" from replacement skill/rate "software engineers" and their level of disinterest being the only real circuit breaker?
We had tests, CI, code review, QA, architectural reviews, etc. None of those disappeared. But they were designed for a world where producing such a large amount of change was impossible.
Tests don’t solve that. Tests can tell you that the behaviours you thought to test still work. How many times have you had a completely green CI with 100% coverage and still shipped a bug?
Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.
I quit because of it. Hell is working on other people’s AI code.
> Hell is working on other people's NoSQL code.
> Hell is working on other people's Python slop code.
> Hell is working on other people's enterprise Java code.
> Hell is working on other people's Windows Forms/GUI Builder code.
To quote Jean-Paul Sartre: Hell is other people.
This isn't coming solely from engineers wanting to produce more stuff faster.
In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.
Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.
I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.
This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.
What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM).
Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project.
If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.
The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.
However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.
One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.
But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.
A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.
There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.
I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.
By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!
You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.
Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.
That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.
Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.
Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.
You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can sometimes vary in points, but your tasks should not. A primary goal of the planning phase is figuring out how to keep them as low as you can. The points stop being meaningless when you think this way. They tell you where things are too lumpy. You throw more planning time at those lumps.
If assigning to a senior produces better code, you're not spending enough time planning ahead.
That's great and all, but that's a small minority of all software written. I'd love to work on projects like that but ultimately I have to pay the bills. Many software engineers are in the same boat I am.
Now I guess I'm just up shit creek because I built a career on SAAS work that was available instead of holding out hope I could get in at my dream job working on game engines or some other non-SAAS product?
Sorry if I sound bitter. I'm variations tired of hearing variations "If you only worked in SAAS you were always close to meaningless and now we've automated you so you don't deserve to earn anything anymore". Feels like every day.
Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.
I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.
I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.
Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.
The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.
It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.
Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.
We're not too much an AI-friendly company yet, so we don't officially have Claude access, but I can tell with certainty that several of my Indian teammates are using Claude anyway. I'm pretty familiar with the style of code it creates. And the comments are decidedly better English, which is a big giveaway itself.
Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.
I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.
Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.
The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.
I've seen a twist - not juniors but just offshore engineers.
Primarily in Silicon Valley or outside of it?
I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.
Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it.
With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".
So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....
I’ve worked with two junior devs recently who are very good precisely because they’re trying to understand what they’re doing, rather than just producing code.
I’ve also worked with senior devs who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those 2 juniors.
They use it to explore things they don’t understand, ask me questions to clarify their reasoning, double-check assumptions. They generally use the tools available to increase their understanding.
The way the industry "solved" it was basically raising degree requirements across the board. I went to a top 5 engineering school and one of my undergrad roommates was a mechanical engineer. I remember having a pretty eye-opening conversation with him about how their undergrad program just teaches them what is already commoditized in CAD application packages and is considered table stakes. Industry hires had MS minimums, and plenty of MechEs ended up getting PhDs so they could work on more cutting edge stuff.
My guess is software will end up similarly. The bottom end of this stuff will become purely commoditized and cutting edge stuff will require more education.
Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.
In the same way there is only so much artisan hand crafted furniture to sell, you're a lucky craftsman if you can make a living doing that these days.
Think about all the open source the world got from some random person in Finland or Sicily or wherever hacking on a cool idea. Will that still happen with a high (for someone who is not employed... maybe a student) monthly cost?
I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.
Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.
Most jobs involving Fortran I see are not looking for a programmer, software developer, etc. They're looking for a PhD scientist in whatever scientific/engineering domain they're in who can work on Fortran code. They almost exclusively want domain experts, excluding most juniors anyway.
It's like complaining that no mechanics work on carburetors anymore. Well some do, but they are expensive and not worth it to keep your old hoopty running. Might be worth it if you have a show-quality 1960's era muscle car.
I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it.
The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision.
I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.
This is a fantastic way of working with agents in my experience. It's like have a peer architect who can challenge you and help you improve. You're projecting your own feelings and fears by calling it infantalizing.
Sorry mate, but if that isn't outsourcing one's thinking then we live in different realities.
I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.
very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
I wonder if there's an agent harness that would work well for requirements gathering.
I feel like this is a bit of cope.
Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.
"What can this user see" has always been a very complex question in every crud app I've worked on.
Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.
In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.
This is a sentence that if written just 5 years ago would result in you being seen as crazy. "LLM capable of any sort of critical thinking? Haha. Not in 50 years."
It never ceases to amaze me how people are stuck in the here in the now and just accept the new reality as if it had always been this way, and will continue being this way in the foreseeable future.
This is the worst LLMs will ever be. Not outsourcing critical thinking to LLM will be seen as a liability in the not so distant future. Just a year or two ago almost no one even took LLM seriously for coding. Now the status quo has moved for also critical thinking, and we hear comments like this. LLM's chances of making a mistake will be orders of magnitude lowers than humans. Slowly learn to let the wheel go. AI will be much better at holding and controlling it.
"We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
If that's true, you're fucked. Because then what good are you for? How long do you think they'll pay you to be useless meat-in-the-middle?
Not outsourcing your critical thinking means trying to preserve a scrap of value-add for having you around.
> "We should NEVER outsource number crunching to calculators. They are not 100% reliable and we can make mistakes when inputting the data." Someone in 1920's probably. I know it's a metaphor, and like all metaphors can't be compared 1-1. But it's to make a point how it illustrates my argument above.
That's a dumb analogy. Automating one activity cannot be extrapolated justify automating all the activities, including some of the most human ones.
I'm not AI maximalist. But with how things have progressed the past 4-5 years, I'm more confident on the above being true, than not.
I don't think intellectual work will drop off overnight. There will be a long period, perhaps decade or two, where many jobs will just gradually disappear, where salaries will be suppressed, and humans will just become AI-babysitters and auditors.
It is a uncomfortable scenario, but people - especially young ones about the enroll college or early in their career - should consider the possibility as realistic.
What I'm sick of is this passive acceptance of technological determinism. Why build a technology that's so corrosive and so destructive to so many? You've got powerful people talking about creating a permanent underclass, and happily charging forward anyway. AI is literally the most anti-human thing ever, and should be opposed politically.
But there's been so much indoctrination it will be very difficult. For instance, software engineers were so fucking smug for decades, foolishly adopting libertarian ideas while imagining themselves to be capitalists. We resisted any efforts towards unionization to create translate our (former) economic power into political power. Now we're literally the first on the chopping block.
The real danger is not that AI becomes smarter. The real danger is that humans never learned how to justify their existence except through labor.
A less laborious future is called mass unemployment. We have none of the sociological or ideological infrastructure to make that anything but a dystopia, and are making no progress on that front. Just look at what happened to the rust belt, what reason do you have to think things will be different this time?
If a happy, abundant communist future was in the cards, we'd have had it decades ago. The limit was never technological.
"Universal basic income" is just a sop to mute resistance to buy time while a small few grab most if not all economic power.
The fact that you’re nervous means you will be the first to be replaced!
Is that sarcasm? Cause it's not too different from something I'd say sarcastically (e.g. it's very 10X AI engineer, very overconfident while missing pretty obvious things).
I know it's a cliche but the old IBM adage holds very true today
Machines should work, people should think
Maybe that's part of the problem I have with LLMs writing code. It would be nice if they just did the work, but there's a lot of underlying thinking and decision making with software work that is being offloaded any time you have the LLM do it
It seems like those decisions are being handwaved off as "not important" nowadays. Just let the LLM make those choices! But that is not sitting right with me for whatever reason. Something I should think about I guess
This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.
That's one way to frame it I guess
I would frame it as "they have been abused by AGILE and impatient PMs into never actually taking time to do constraint based thinking or design"
It is impossible to think about constraints, or really do any proper engineering, if you are constantly "sprinting"
Edit: I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go. I get that defining constraints and letting the software go is where a lot of useful emergent behavior lives, but I struggle a lot to think that way. Maybe I'm not wired right for software in the end
That's ironic given that some of the Agile Manifesto signatories are some of the biggest proponents of constraint-based development. While the Principles behind the Agile Manifesto is not prescriptive, I am not certain you could, in practice, even satisfy many of the principles without constraint-based development.
> I also don't personally like engineering based on constraints. It feels like constructing a building based on where walls aren't allowed to go.
Engineering is all about constraints. That you then shift to talking about constructing a building is curious as it would be atypical for an engineer to work on constructing a building. The engineer's role in building constriction is typically only in defining the constraints. Construction crews, made up of an entirely different group of people, then construct the building within the constraints set. "Constructing a building based on where walls aren't allowed to go" is essentially how buildings are usually constructed. It is an interesting parallel as the LLM is somewhat like the construction crew, which is something software hasn't really had before in any kind of big way.
Engineer gets thrown around pretty loosely in the world of software, but elsewhere, especially in places where failure can cause serious harm, someone who constructs a building by applying judgment, experience, and craftsmanship as they go would be considered an artisan, craftsman, or something to that effect rather than an engineer. That seems closer to the world you like to live in. There is nothing wrong with being a craftsman, of course, but the economic fit is becoming less clear as the industry matures. Which is something that seems par for the course. The early days of building construction was also dominated by craftsmen but as it matured engineers became dominant.
Yes absolutely. I don't call myself an engineer, I'm a developer. Software Engineer is a title that my jobs give me, but I'm rarely given the time or resources to do any engineering.
It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
Are you sure it is that you are not given the time rather than your artisan ways consumes your time 'unnecessary'?
Failure in (most) software isn't going to harm anyone, so there isn't much technical need for engineering in software. As I am sure you can attest, artisans are fully capable of delivering great software. Some of the best software out there was created by artisans!
The software industry is headed towards engineering anyway because engineers can build software faster, which is considered a virtue in business. That was true even before LLMs, but has become especially pronounced in this next era.
> It has become very clear to me over the years that I would much rather be an artisan than an engineer though.
Understandable. I suspect a lot of engineers would rather be artisans—not just in software but in general. Artisans get to run at the forefront of new technologies and ideas before rigour is able to be established so it is, on balance, naturally more exciting.
I'm not certain of much these days, but I'm pretty sure of this.
Any time I have tried to properly "engineer" something with documentation and specs and planning I've been told to just deliver it instead
However, it seems like both you and your employer both want artisans anyway, so it sounds like you have found a good fit. The software industry is putting more and more emphasis on engineers, but that is far from being universal yet (and will likely never be 100%).
with critical thought*
fixed that for you, only sith's (and unreasonable people) deal in absolutes; you almost did!
Of course, this is economically efficient. Nobody is going to give up Amazon same-day-delivery so that some local small business owner's kids can live better than the median person.
If the bad scenario happens and 99% of the people becomes irrelevant to the economy, everybody will live their life's worried about basic necessities and smart hardworking people will be richer because your background or where you live or grew up doesn't matter.
Life is not fair. We should accept that AI companies and billionaires deserve to be aristocrats. They worked hard to create these conditions. In the end, it will trickle-down (this one I partly agree, irony aside)
I don't believe this at all. Social mobility definitely existed. It was at least possible to educate oneself and rise in society. Maybe the effort required wasn't equal for everybody, but it sure as hell wasn't impossible, because I've personally seen it happen.
That is fundamentally different from this supposedly K shaped economy world where it is literally impossible to rise. Education and talent don't matter anymore. It looks like the possible futures are either a post scarcity society or a cyberpunk dystopia.
If you believe that, nothing will change much. It will still be possible, just the effort and luck required will be way bigger for the middle class to become rich. That's sad, but life is not fair and we are not entitled to social mobility the same way we are not entitled to housing, food and leisure.
If the cyberpunk dystopia happens, the trillionaires will live in the moon or Mars, and we will live here, maybe with shittier lifes, but that's on us. If we want to avoid that, we just need to become billionaires as well. Sadly, I'm too lazy for that, so I accept that it will never happen to me. I accepted that I will be "permanent underclass", because I don't see a reason for post scarcity to happen.
I always heard it as "petty" bourgeoisie and was a bit confused. Now I get it.
Which means our pipeline to senior engineer is completely broken.
Now with agents, you can get really bad (vibe coded) code bases in a week.
Before, to get this kind of experience, you had to work in a company for at least 2 or 3 years.
Wages are certainly going down for most software roles
We keep hearing this, but where is the Photoshop killer written by a gas station attendant? Where is the PayPal alternative written by a retired nurse?
Over and over we're told that software is now trivial to write, and Claude is evidently writing some billions of lines of code a day, but where are the results? Where is the vibe coded app toppling the legacy hand-coded monster product from 20 years ago?
Ai did that with whatever cli tools were available and what it would write itself.
Ai is not a faster horse. It is a phase shift.
We won't see a gas station clerk write photoshop because we won't need a photoshop.
A photo with adjusted cropping, background blurring, and contrast etc?
Even if people could find the tools, they won't seek it if a one button solution can come to them. But we can't outcompete Instagram in a prompt, nor some popular app.
Agentic solutions just don't have these issues. You give them your image, that's it.
100% agree. People are looking at the future through the lenses of the current paradigm just like when people from the past imagined the future (our present) in a way which we now find hilarious. Most of the time, the future doesn't bring developments which improve an action in a scalar way (faster, shorter, stronger, etc) but instead fundamentally change the nature of that action (handwritten letter communication vs video calls) or completely override the need for it (telephone boxes vs mobile phones).
But if I can clarify my point. It's more that I'm trying to say "Company promises A is happening and B is the necessary consequences to achieve it".
I do not believe A is happening but B is occurring despite that, in order to achieve hidden agenda C. Though in this case, C is not that hidden since every other article has them blabbing out loud about "wow it's going to be so amazing when C happens!"
here,
A = AI is making us more productive than ever
B = This will cause impacts on jobs and the economy as a whole as we realign what labor is
C = Companies make more money than ever as it works towards eliminating labor on massive (90+%) levels in order to maximize profits and moating the idea of knowledge itself
We are all scrambling to figure out what else we need to do (and so are many other roles).
En masse, I argue not. More productivity for engineers would not be met with mass layoffs if engineering production was why value was being added. On the contrary, other industries have had to hire back talent becsuse companies were too aggressive cutting people and needed that work to be done.
But I'm not an oracle. I can only speak for what I see today and won't predict tomorrow. Especially in these trying times.
Everything else is something else you care about, but producitivty is simply proven for almost every engineer on the above point.
photoshop, paypal, and many more companies etc. have software of vast complexity that cannot be reproduced or maintained today solely with llms, ipso facto you still need software developers or some similar role to build and maintain the complexity of _yesterday_
some guy shipping an iOS app to zero users doesn't change that. although i think it is good we can have more bespoke software.
What can a mid level person do? Instead of a consultancy loaning out a team of 3-4 people, it might just be one person now. That could mean a lot of downsizing.
One thing mid level people wouldn't be counted on to do was create Photoshop or Paypal. The original thread is about top level pros being the ones who stay in the industry, right? That sounds about right if we're moving the conversation over to Photoshop and Paypal.
- if it is true that AI enhances our abilities it just means the goal posts move of what was expected for each level
- the complexity ceiling will rise for the level a superstar or a company is capable of maintaining, meaning there will still be stratified complexities for the mid levels of old to handle, it might just be higher than before
- counter intuitively but time and again increased software creation more often than not increases demand for more software rather than decreases
if the world decides it has no more problems to solve with software, then we are in trouble. i don't think that is happening anytime soon.
We get about 10% YoY now, which is actually impressive, but not even close to the past experiences. Computing power used to take 18 months to double, and was being attacked at a bunch of different angles.
Now we are literally out of tricks, to the point where we had to undo some of those tricks because they were fundamentally flawed, and it takes 100x the engineering investment to get that 10% YoY, or sometimes only every other year, and that isn't going to continue for much longer.
We can't increase clock speed much. We can't increase density much. We are out of clever tricks. It takes an entire earth's worth of human talent just to produce the machine that produces the chips. How the hell are people still insisting that computing power continues to follow Moore's Law?
Several of the limits we've hit are fundamental matters of physics.
Meanwhile, LLMs ask for orders of magnitude more compute than is cheap and cheerful right now. Do we even have a single order of magnitude left for compute?
This is in a way the same argument that all companies will use just boxed (albeit customized) software. In reality many, ie banks run their own custom software and for good reasons. Wake me up (in retirement) when any major bank decides to run their finances, regulatory stuff and transactions on llm-generated stuff made by underpaid devs like you describe.
We're doing a great job of that right now, aren't we?
I'm a doctor and I'm building my own EMR system.
I've also been a hobbyist programmer for over a decade, but the point still stands because without LLMs I wouldn't have the time to even try it.
If its so good why aren't you rich?
Seems like so far the market is not convinced at all that SaaS companies as a whole are any more disruptable than before.
There are definitely more apps developed these days but I haven't seen anything much vibe coded which actually seems to have staying power. Everything is prototype quality.
Bun gets a lot of hate for vibe coding.
I vibe coded to modernize one of my old hobby websites (so not even vibe coding from scratch) and I immediately got anti-AI comments, and I didn't even say I used AI.
Well that's where we're seemingly at an impasse, no?
I don't even like the term "good vibecoding". The term was implied as a means to just let the computer type its own code and "go with the vibes". i.e. you have no deeper idea on how it works underneath.
Now, AI-assisted coding? It can be good. It can be a rush job. But the idea is that LLM's are in the passenger's seat, not the diver's. Much smaller chance where you have no idea where you're going since you're at the wheel.
Not necessarily, there's a growing and somewhat untapped market for BBWs
A lot of AI believers (me too fwiw) seem to forget it’s a lot harder to ‘close the loop’ on non-code projects. I think this is because they are usually coders.
Which is kinda proof they're populated by sociopaths with extremely little empathy. The people who are building that stuff are programmers, and if they had a tiny bit of functioning empathy they'd stop or slow down or at least be unenthusiastic.
And we're not talking about very high level empathy here, but the very basic kind of thinking about the effects on someone very much like yourself.
Whether that is due to AI or other economic conditions is an exercise left to the reader.
we are entering the world of smaller service firms (1 - 3 people) - where technical chops will even get paid more. the age of cookie-cutter apps is over.
There was a submission a while back that might be relevant here: "Why Law Is Law-Shaped" (lawvm.org) [0]
[0] https://news.ycombinator.com/item?id=47945861
You are comparing what it is with what should be.
PDF space is still more advanced than the people typing into "word processors" however. Making software to emulate letters was such a massive mistake for the trajectory of computing, it let people effortlessly "adopt computers" by making a digital facsimile of their terrible analog processes. Only with AI we now have the ability to digest all this unstructured mess.
There is a budget and when it is gone, no contractors until next budget round.
There are only so much customers to chose from and all of them have finite budgets.
The exponential growth curve only exists in MBA books.
You can see current AI hype as example, and its government didn't step in and printed N trillions yet.
If maintenance and security is fully automated and for small changes or a small feature you will only dump some spec document into your agent platform, for sure.
If you're in a product company and your development backlog is empty, run. That company is about to go out of business.
I have stupid question here. Why they sell tokens instead of AI generated full application and AI fixes to your code without you needing a single dev?
But the current state of AI is a very good indicator were it is going. Even if we don't achieve AGI, do you think AI in its current form will not be better in 5 or 10 years and we will have this solved a lot more/better than today?
Even with AI, you still need to design the software, test it, try it out, deploy it and scale it. An proper agentic platform still needs time to be build.
And the models need to be a little bit better and for that you want human feedback/reinforcement learning
This alone will lead to being able to run a fable class claude model 24/7 and potentially running something like this in parallel multiply times over.
In my sector? No, not really. Because the core problem isn't tech, but labor rights. Those will only worsen.
Naturally we can't use figures of speech.
And now your comparison is inaccurate. I said whole application. So the correct one would be selling/renting construction vehicles vs building entire building and here selling/renting is maybe 10% of developer income.
Digging a hole is like making small code change and if you wish to continue using this analogy then tokens are digging a hole and selling entire applications (thing Software house do) is construction company building entire building
Second obviously deliver more cash and here AI premise starts to crack. AI can't deliver anything good, costs much more than developing team (Uber proved it) and even if you use it as hard as possible and it does what it suppose to deliver max 5% increase across the board
But despite me saying that, I think it's going to take longer than four years. It takes a while for people to realize that a dream is dead.
But that's difficult and time consuming, if anything it's advanced economics and requires effort to decode what's happening. What it's very easy to do is getting angry at a group of people and to feel deep unfairness about it, then think that if that group of people were to leave, the problem would improve or be solved. That's exactly the kind of thought that seems to be so pervasive at all levels and yes, it is a scapegoat. Especially since that the only merit someone has over H-1B is to (by pure chance) having being born in a different place. I really feel that many people complaining against H-1B wouldn't even qualify for it if they were born somewhere else.
Only someone ignorant of basic economic concepts—such as, in this case, supply and demand—would write the above.
I mean, think about it; just a few short years ago there was a very strong market for software engineers, despite outsourcing and immigration being very much part of the landscape.
I mean, I wrote this 12 years ago in response to similar discussions on this same site, and in the intervening years, we had a great market for software engineers: https://journal.dedasys.com/2014/12/29/people-places-and-job...
What has changed is 1) the zero interest rate environment went away and 2) LLM's.
I was very fortunate to get a job in a NOC a little bit after high school where I learned things one'd expect to learn in an entry level job. The team I worked on was all about mentorship, learning, and building people to the next level.
Haven't seen that attitude elsewhere in my entire career except in the non-profit world where I reside these days. It blows me away that people are surprised that these industries have failed to build entry level positions.
Which of those things changed (along with higher interest rates) in the past few years though? All the other variables did not change. They were present 5 years ago and present 10 years ago too. To me that's indicative that those factors are not the cause of a soft market for software engineers in 2026.
I am talking about the weak market for software engineers right now and what caused it.
The front fell off because the base was never built to support a shakeup of the industry. There's so little support, now and for as long as I can remember, for people to fail gracefully in the field. It's just up up up. And now that programmers are finding their jobs to be a little more precarious, maybe folk will start supporting mentorship as a practice.
This isn't just a "market" problem. It's a problem of people not teaching others skills that help them thrive inside AND outside of work.
A lot changed very fast in the last few years. It's not all nor even a major part due to outsourcing/immigration. It's a myriad of factors all colliding at the same time.
There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?
There's also only 60,000 H1-Bs a year for private companies.
Lastly the majority of H1-Bs doesn't go to software engineering jobs, it's around 30-50%.
There's also basically no US company hiring juniors via H1-Bs, so yeah, I'm saying it doesn't make any meaningful impact.
30K H1-Bs versus 400K grads...
Actually, more like over 80,000. They have a separate pool for people with advanced degrees (MS or higher) in tech fields.
Agree with everything else.
It's not an unreasonable thing for people of a country to think that the government should do more to protect their livelihoods over a corporation's balance sheet.
The correct framing is "The reason you're not getting a job at Amazon isn't because of people willing to work for less money,"
Big tech companies aren't like a Government job with rigorous pay grades based on role and seniority. You can have people even within the same role and level at big tech with multiple $100k pay discrepancies.
If someone's continued ability to stay in the country where they currently live is contingent on employment then they will accept worse conditions and pay.
That's the entire reason why tech companies use H1B, it's not as though there's a dearth of Java developers or DevOps people who are US citizens.
also nothing impressive about a senior SDE there, maybe 10 years ago it was impressive, best talent has either moved on or is L7+
On top of all that the commonplace practices of ethnic nepotism and hiring kickbacks.
I think many engineers are extremely naive about what is going on in the industry, which is why these abuses only continue to increase.
I agree with most of this except this. Think there’s some rose tinted glasses here or I’ve got bad luck over time.
Life before ai was bad as well. There wasn’t any one to explain to you anything! You had to figure it out yourself. The people either already left or was busy with something else.
No one wrote tests (to my standard). Most of the ops works was skipped. Docs were just not there. Nobody linted properly. Just bad mannnn
the vpn is called dev-test-prod and some containers are stored in a dev subscription, but still used in production. Some intangible network error forces you to use the production cluster for testing (the bucket is at least called test).
I feel this kind of setup is invariant everywhere I go to do engineering. Fable level intelligence has no effect!
>There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.
>The most tragic aspect of this way of working is that, to the untrained eye, it works.
>If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.
Isn't this the opposite of failing faster, it lets people who would have never made it past the first few hurdles and give up get deep in and then the false hope that they can then prompt their way out of whatever mess resulting in deeper and deeper spaghetti.
The thing is I've worked on plenty of code like this written by humans. AI just accelerates the process and puts this type of code within reach of more people. It could be seen as a step backwards in good software engineering practices we've painfully learned over the last two decades. I see it as a cycle repeating itself in a new iteration, with the hope that we'll end up with still better tools and processes in another few years. But I agree it can and will result in real harm in the meantime.
Bruh..I haven't consistently sat at my computer for even a hour at a time to code for a decade..people spend that much time in Claude??
There are still machinists doing things by hand, but for real production or prototyping, most will now use a 5-axis CNC machine. It still requires an operator of sorts, but much of the work that once required skilled manual machining is now done by CNC.
I think the same thing is happening here; it’s just that the transition is messy.
Give it five years, and how we get to the end result will not matter nearly as much as it does now. A messy codebase will be irrelevant, as it will be something managed and controlled by the LLM, written in a way optimised for itself, not for you or I.
I think perhaps the equivalent would be “this environment quite literally can’t support having an LLM attached to it”, as in say some totally airgapped AND low-performance things (industrial computing, PLCs, military stuff, etc.).
At that point we might as well invent an LLM-optimized language to use.
Sure, just wait for the poors to stop rebelling. It will all be over soon.
>The person adding Kafka should have been able to explain exactly why it was needed.
Here it is. People who don't know what they are doing are adding infrastructure layers they don't understand, can't envisage operationally in the future, and missing scalability. I'm seeing this. In fact I'm spending hours a week fighting it. I had to set up a call with a senior developer recently to explain why his prescriptive attempt to make infrastructure changes in his project can't be done with Claude like he did it.
It's playing wack-a-mole as the "velocity" has gone up of changes, and it's promulgated by every manner of product manager and senior developer under an attempt to please the brass.
>The person who built the feature should have been able to explain where the data came from without sending a link to a Claude conversation.
And they won't - because it's too embarrassing when you see what Claude responded with and someone failed to question.
We're in a new era, that's for sure.
Indeed the fix did work, but when I asked him to explain me the problem and the fix he started to use the prompt to get answers.
At that point I just let it go, the only thing that I mentioned later on is that I'm ok with pushing that to prod if that was ordered to me but I'm not responsible for it.
I prefer to keep the bug live until I fully understand the problem, reproduce it, come up with a solution and maybe just maybe perform a check against what a computer generated.
Please note that the bug came from a real human code base but being complex and not familiar with that part of the code (moreover the code was handed to us without any type of support/documentation) rendered me in a weak position where I couldn't come up with a solution so far.
How can someone trust so much a computer generated hotfix without fully understanding a problem is what still baffles me.
Still resisting to use any aided coding, no LLM is not going to steal the capacity to use my brain. The day I'm forced to used these tools, the day I quit.
If "can you explain this?" is a question a direct report has to put into a prompt, they are failing at their job.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
Although, I don’t think immigration or country of origin is particularly relevant here. I never worked in the US but there are plenty of "assembly line" developers here in London too.
If your job is essentially taking a ticket and turning it into code without contributing much else, then yes, I think that category of developer is going to be decimated.
That applies equally to everyone.
"""A Roman idiosyncrasy about counting reinforced this avoidance. The 360 degrees of longitude, for example, were always measured from the vernal equinox, which lies in the zodiacal sign of Aries. This should be zero degrees, 0°. It was common, however, to call it instead 'the first degree', Aries 1°, as Pliny did around 60 AD, upsetting his calculations and those of many who followed him. It amounts to this: if you lay out four marks on the ground and step from the first to the last, have you taken three paces or four? Clearly three; yet four marks were involved. To get the right answer it helps to call the starting-line 'zero'; then the number at the mark you step on will correspond to the number of your steps. But the Romans counted so that three days after Sunday was Tuesday; the Italian for the fifteenth century is the quattrocento — and all of us still call the two steps in music from C to E a major third, taking the number from the three tones involved."""
I wouldn't say that the set that has one element, labeled 0, _has_ zero elements; it has one element with the label 0. Right?
You get a task, how does it interact with all other invariants? What are the implications on data flow, processing and user workflows? You can rarely answer those questions beforehand, you step on them during programming as the formal language forces you to take them into account sooner or later.
If you outsource this knowledge-building you’re losing the steering ability when stuff hits the fan. You lose the ability to navigate the code properly in order to identify bug or violations of invariants.
LLM optimize locally, that’s their nature. Invariants are often implicitly scattered around the whole code base. Explaining them to the LLM is much more tedious than just to write the code in the first place. At least for me as I have much better expression-ability in Code than in natural language when it comes to describing any form of computation.
I believe wholeheartedly that things like Claude code bring immense value but to management types they aren’t visible enough to prove their “ai first” narratives resulting in a bunch of crap they have us build that look and seem smart but in fact are just slop we have to deal with the consequences of. Good for job security I guess, but I’m getting pretty tired of it all.
Conversely, the product guys I work with are adept at producing proof-of-concept tools that look really good. Fake data, runs entirely in a browser, but conveys their goals way more specifically than Balsamiq ever good. And I think this is a great use case for Claude.
But what ain't happening here is product guys producing code that would go directly into production. And even if it could, they're not in a position to provide tech support or debugging when it breaks, so they don't want to be in that position anyway.
Nobody can really predict the future very well, it seems, but my personal best guess is that we end up moving the boundaries of what we work on and how, but the need for humans isn't going to go down. As magic as LLMs look sometimes, I constantly run into reminders of how much it relies on how I phrase a prompt when it delivers any kind of answer. That influence really drives how satisfying the results are.
Every layoff just automatically attributed to AI even though they have nothing to do with it
This hasn't been my experience. Especially when it comes to enterprise software, eventually everyone that was involved with the design of and iteration on a system will have left the company. Yet, often those systems need to continue running because they support "legacy" customers (who sometimes actually tend to be more economically valuable to the company than the customers on the shiny new system).
Before AI, in these cases you just had to dive into the code and start trying to understand it yourself from zero. Usually, you would come to a very limited understanding of the system, just enough to fix the latest bug or keep it running until it hit another issue.
I'm not sure why it's necessarily worse to rely on an agent to do this for you these days.
Darwinism in action.
I don't believe A.I. will change much, but it will lead to winners and losers, that's certain. Lessons will be learned, A.I. will remain but play a minor role, just like IntelliSense and ReSharper.
People need to understand that when things break management will hold you accountable, not the A.I. If you can't fix it you'll be out of a job. So you'd better make sure that you understand the generated code and clean it up before putting it in production because you'll be maintaining it.
Bad news: by delegating the thinking to somebody else (Claude) you have become the management.
I'm not working at massive scale. I've not built any public-facing projects from scratch. But I have done years-worth of cleanup and improvement on projects that I'm very familiar with and have been in my backlog. It's not 100% success, but it's better than I could have done on my own, in the last few months anyway.
I'm at the "this takes the scut work off my plate but damn if it doesn't also take the fun stuff off my plate too, and might put me out of job before I'm ready to retire in 8 years" point.
Though I've done the corporate America thing long enough to appreciate that 8 years isn't really all that long, maybe there's hope.
You are still an engineer but you’ve delegated your technical judgement to an LLM. You just stopped doing the most important part of your engineering job.
One of the problems with the "middle class" in the past was that there were lots of mid-level jobs in big companies but people hit a ceiling and couldn't progress. Maybe the middle hollowing out will lead to more jobs with significant opportunity and responsibility rather than ones where you get trapped because you weren't at the company early enough or all the top jobs are filled.
> My bet is that AI pushes salaries further apart. To be employable, there's a bar you have to clear and that bar is whatever the current best model du jour can do.
Since well, there are a lot of jobs in the tech industry that for all extents can be 'solved' with AI. Like if you're developing themes and plugins for a CMS (like say, WordPress), something like Claude can do a very passable job at that exact type of work.
So, only the more senior developers are even needed in that type of work anymore. And even they only need to review what the LLMs provide and fix issues maybe 10% of the time.
Hence the most basic, most entry level friendly engineering opportunities are likely about to be decimated. If your work involves building simple themes and plugins, managing the website of a small to medium sized business or being contracted to build sites for mum and pop companies, then your job security right now is questionable at best.
Being better/more skilled than AI is basically the bar you need to clear to find meaningful employment in this field now.
Faced with that situation repeatedly, most people would find it sensible to resign. Which leads me to another point: if you leave, it will likely be difficult to land another job assuming that companies will impose a ridiculous interview process in fear of a bad hire which will be increasingly expensive as the author argues.
I realize that this is nothing new, but if there are fewer middle-class engineering roles, then I expect that these existing problems to become amplified.
LLMs spared my neck of the woods for now but is this really how PR review looks like these days for an average SWE or its just an example of a Junior in a team?
I decided to start learning programming about 6 years ago as a possible new career path. The universe was not going to have that so AI was created.
What I thought the post would be about is the dissolution of the White Collar Kitchen Brigade The kitchen is run by the Chef but it needs the Sous Chef, Line Cooks, Kitchen Hands to operate.
Many software engineers have made a good living acting as the sous chefs and line cooks underneath the rockstar chefs, but with AI companies are inclined to turn the whole kitchen over to the top dog and their AI crew and the ordinary human crew is slowly being churned out.
And it's not just because the agents execute faster than humans, it's primarily that they have lower friction to onboard and off board. In the past we needed a "standing army" (salaried, full time work). Again this is not about the soldiers in the army being bad of incompetent, those are excuses. The real reason is that it takes a lot to train and maintain a soldier. Bu t when we now have ephemeral agents which spin up and down as needed, then there is going to be a strong incentive to cut down on the salaried middle class.
Simultaenously platforms like Mercor which offer white collar task based gig work are on the rise.
The logic is that ordinary humans are becoming too expensive to maintain on a standing basis.
Nevermind the aspect that thses sous chefs could one day be rockstars, because no rockstar came straight out of college outperforming their senior's skills decades prior. You're hollowing out whatever isn't profitable at the cost of future talent (and likely the future of the company), but those holding the money don't care. They'll move on the the next company to suck dry.
A bad engineer has been lazy for years and will never change.
You likely have experience with this already first hand. Ever had a lazy day and just hit "yes" "continue" on the AI over and over? I've had to revert entire days of work because I was so burnt out I didn't put effort into the design.
A good rule of thumb though is if an AI can't solve the bug and fixing it creates more you have a bad abstraction and architecture that needs a gutting and rebuild from near scratch.
> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management. > And what are you even thinking about? It would end up in the exact same state again in just a few months anyway.
The management side of this probably deserves a whole post of its own. There’s only so far I can take each tangent before the original post becomes too long for anyone to finish.
https://www.youtube.com/watch?v=axOcn--n_lM
Some feel more productive, and we shouldn't kink-shame peoples cognitive dildo. =3
If you can’t answer this basic question then why tf do we even need you around?
Sorry to post this publicly, but there does not seem to be any other way to contact you. Your GH page is fairly locked-down, and the link there, is dead.
Your “Hire Me” and LinkedIn links in your blog are kaput (for me). It may have to do with UK LinkedIn not talking properly with US LinkedIn. I can find your profile there, but not through your blog links.
@dang @tomhow I may ask you guys to delete this, if it gets ack'd.
- with AI, bad engineers (bad designs?) lead faster to catastrophe - Frontier AI companies pay their SW engineers very much
--> we need highly-skilled sw engineers and the lesser ones will get out.
Kind of what outsourcing did but x100.
As a manager, I'll still have to think how I grow young SW engineers to top SW managers.
But, moreover, the demand your company subscribes. But not your company anymore, because you'll probably be replaced by one engineer (and an AI subscription) who's now trying to do your job and about four or five other jobs.
And this one engineer will become more and more reliant on AI companies, AI companies that'll go for the throat once they've hollowed out all the skills that used to exist in the engineering market.
This would be true if the goal was to get good working code faster. But the actual goal is to get any code faster. So, in reality, it doesn’t matter whether you are a good or a bad engineer. It just amplified how good you are at manipulating the hiring process with your fine tuned resume and how smoothly you can talk your way through.
I’m trying to build a career over decades. I want to keep moving into better positions, work with better people and take on more interesting problems.
People talk. I’ve had jobs where I didn't have to interview because someone I’d worked with before recommended me and they already trusted my work.
The opposite is true too. People remember. They won’t hire you again or recommend you.
Reputation compounds.
I think I can agree with most of it while also arguing that I don't think good code has ever had an honest measurement of quality. From an end user perspective, the end product either works or doesn't. Working terribly is the same thing as doesn't work and working well is the same as works.
What AI changes is the actual code part. The actual code lines output by AI is identical to or better than the best programmers. The systems design, architecture, QA, integration into existing legacy systems, to just name a few, is where the strengths and skillset lies.
In order to be a good engineer, you have to be a systems thinker. AI or no AI does not change that. The entire picture has to be taken in to account, and I think this is going to obliterate the vast majority of engineers who cannot or don't want to think about systems. It's no longer about putting on your headphones and outputting code. It's about having to interact with other humans, systems, architectures, organizations, and an API or MCP is not going to help with that.
I truly do feel bad for terrible older aged engineers, and the young new grads. I think it's unfair that a lot of new grads were told that CS was a great career, only for them to start their freshman year before AI, and then graduate when AI coding is in full use at nearly every workplace.
Bad workmanship writes bad code in any language. Typically the "easier" the compiler is to use... the more complex the failure mode. =3
This list of rules applies to most languages: https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
A bit of history where these rules came from, and why they matter. =3
"Why Fighter Jets Ban 90% of C++ Features" https://www.youtube.com/watch?v=Gv4sDL9Ljww
The basis of the cited 10 rules helped form many standards for reliable code: https://www.stroustrup.com/JSF-AV-rules.pdf
"Reflections on trusting trust" (Ken Thompson, 1984) https://dl.acm.org/doi/10.1145/358198.358210
This is the only way I can see it playing out at the moment, because AI has completely eaten away the need for juniors and its also made it hard to train juniors since they just want to yolo it with CC all the time.
Adding AI to the mix just made things worse. I'm still finding issues in the codebase/documentation that I need to review, test and fix.
The replacement is being trained. I made sure that, while I expect them to use LLM supported development .. they own their contribution.
This is going to be a fun ride.
It doesn't seem to be happening everywhere, but if you are unfortunate enough to work someplace with a "LinkedIn thought leader" high up on the engineering food chain, there's a really high likelihood that your organization is currently in the throes of an "everyone must be using AI for everything" fever dream.
And boy let me tell you, it is every bit as disastrous as the OP claims. Engineering managers are asking Claude to write up entire initiatives, then they hand off these nebulous AI slop manifestos to the teams where the requirements folks are having Claude shit out tons of superficially plausible Jira tickets. It finally lands on some poor engineer's plate and since these tickets are the technical equivalent of Finnegans Wake, they just end up asking Claude to read all this shit on `ultracode` and draft up a pull request. Which is then peer-reviewed by somebody using Claude.
I wish I were exaggerating.
I think it's largely correct that hiring bad engineers is dangerous to the company. But that's always been true, especially those "hack out a prototype, get director applause, and leave it for somebody else to own" people. But management has usually chosen to keep such people around, because they can look good on paper (see how many tickets they closed?).
The question is really a management / business-owner question -- will managers/directors stop hiring yolo-engineers? Will they empower engineers to close PRs simply on complexity/size grounds? Will they fund refactors and simplifications as first-class concern? If not, it will be a problem, and I don't envy the engineers who try to be the glue at such a company.
In one particular case, a senior teammate of mine went the extra effort to actually explore what the intent of the change is and created a whole new PR for the junior dev that was a simple configuration change of 5 lines instead of the 14k lines they put for review.
This is utterly unsustainable and something will give at some point.
Everyone starts off as a bad engineer. Just like any other profession, you to make lots of mistakes to learn. But now you're less likely to get wisdom from another human to build up the knowledge and experience you need. And more likely to delegate the hard stuff to Claude so you don't learn from your mistakes.
Nothing else this article says matters much in my opinion. If you're concerned about something, do something about it.
AI is still just a tool.
seems like a petty easy construction, proof engagement kinda thing
No confirmation for the title, rubbish arguments and logic.
> Good engineers have become more valuable because AI lets them move much faster.
Bad prediction. This is likely another AI marketing article.
- you have a very nice article on how llms work here https://blog.florianherrengt.com/how-llms-work.html
- but in your diagram titled "Word vectors plotted in semantic space" dont you think you need to add arrows to show where those vectors are actually pointing?
- because i dont get how you arrived at this Using vector arithmetic, you can calculate: woman + (uncle - man) = aunt without seeing the math vector directions
That's when companies began starting to outsource their work to much cheaper countries
Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).
So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.
Even ignoring the shift to token based costs, the opportunity costs of throwing everything onto your "competent developers" isn't free. They still need time to review and correct output on top of whatever else they were doing in their day to day. And they probably aren't getting a pay raise either, so how long until they use that bullet point to jump jobs?
Maybe it wasn't clear in my comment, but this was already happening in many large organizations pre-AI: you had a small contingent of competent senior developers whose job was to review and correct outputs from junior and/or outsourced staff. From people I've spoken to in these types of situations, they're very happy with getting rid of their offshore teams and using AI instead.
So AI isn't really doing anything but giving sharper tools to both groups.
So, as it was before, we simply need to set expectations and remove those who cannot adapt and meet expectations... You know, the way it's always been.
So why is AI the problem here?
We could end up with a gulf between those who use AI for cognitive inquiry vs passive delegation. Those who accelerate learning by asking "help me understand this" vs those who relinquish understanding and analytical thinking to AI to complete their work.
IMO The author fails to list the hypothetical person with 13 PRs to review is also failing.
> * The engineer who refuses to change with the times
IMO many of the old ways of software engineering were local maxima. We're still seeking how to hit a new maxima and the journey may take us through zones lower than the previous local maxima.
You still have to understand the change yourself if you’re going to take responsibility for approving it.
That work is fundamentally much slower than generating the code, even with the help of AI.
We’ve made producing a large change extremely cheap and fast. We haven’t found an equivalent shortcut for building a correct mental model of what that change does, how it interacts with the rest of the system and whether the decisions behind it are actually sound.
Maybe one day we'll find one. As of today, I don’t think we have.
There is plenty of software in existence where being incorrect, even once, can spell disaster.
Everything about the picture being painted in the article is anathema to keeping such systems safe and reliable.
Love this quote. Already seeing so many codebases which became unmaintainable.
I recently joked (only slightly) that it's currently possible to get yourself promoted at these orgs using tokens as a productivity proxy by spending your days having Claude OCR dictionary pages.
The concerning corollary of that joke and this management strategy is: when do orgs start offloading reviews to Claude? They're already surveiling a large percentage of peoples' day-to-day and are in a position (or will claim to be) to make a judgement about how those tokens are being used.
Working on a small, existing, established product that can gradually be improved upon while aided by LLMs if necessary seems like the best place to be. Starting something new (not that I have any legit worthwhile ideas or the resources to pursue them) seems pointless because people are shitting out poorly designed AI slop constantly and poisoning the market.
But what do I do instead? Trades programs are already waitlisted or require another 5-10 yrs to earn something worthwhile. Transitioning to anything else seems like a tenuous prospect. I fear that unless I get incredibly lucky, the last job might have been the last chance to earn a living that made any sense.
To be clear, I'm not giving AI more credit than it's due, and this article describes the reasons for that which are valid, but the perception that they're magic engineer replacers is more important than reality. At least I can hope that the housing market completely crashes or enough crap code is produced by opportunists that I can ride it out, but other than that it's a confusing time.
> The new AI economy
I don't know if this phrasing is intentional, but it gives me a chuckle. The dotcom boom was called "the new economy" about 26-28 years ago.
If the limiting factor is the rate at which experienced engineers can understand and validate changes, you have three options: generate less, find a genuinely better way to validate or accept lower quality.
I always joke with my wife and invoke a line from this [1] Art Bell episode "the disasters that are coming..."
People really don't seem to consider that our civilization is remarkably fragile and dependent on humans. Any given system can just fail at a moment's notice and you need people around who know how not to panic and what to do.
We seem to be adamant at disproving this reality for some weird reason (money, duh), but life isn't going to be fun when a large portion of the population needs a chat bot to do any form of work. And it's worth asking: what population will be left if we submit all of our faculties to LLMs? My guess is one that's either limited in size or practically inert.
An outright idiocracy doesn't have to happen, but we sure as hell seem to be speed-running our way there. It's actually worth watching Idiocracy and Wall-E and just contemplating "do I really want to live in this world?" Because, at least right now, we're charting course directly toward that.
[1] https://www.youtube.com/watch?v=gkPHMEvp-Tk
We still teach arithmetic and algebra despite computers being vastly better at calculation. We teach spelling, grammar and essay writing. We even teach history and geography while everyone permanently has a device in their pocket that can look up almost any fact in seconds.
How else would you be developing the mental models required to understand, question and verify anything?
One possibility is to have firmer APIs for known components. APIs that come with the entry and exit conditions for proof of correctness. That gives an LLM a hard definition it can work to meet.
This isn't as bad as it used to be. We may be able to use LLMs to create entry and exit conditions from specs written for humans and from unit tests. Code is cheaper than it used to be, but so is formalism.
This may be a way to put firewalls around AI slop.
There are a lot of people edging around this concept, but it's not solid yet.
The fact that some teams find themselves there is simply a realization of what I stated - inactive maintainership by not taking code reviews seriously.
See "AI Won't Take Your Job, Someone Using AI Will" > There's no lucrative middle ground where 'AI whispering' is a high-value skill.
https://blog.florianherrengt.com/vibe-coder-career-path.html
Nice first name btw
On the other hand the problem can also be triaged quicker and rewritten faster. Pretty much every startup I joined had at its core disastrous code written by students and overworked techies. I can totally see this shitty base being the future base all startups. It'll likely need an army of agents or devs to make sense of all the spaghetti being written. I won't be surprised if demand for devs skyrockets after the first generation of spaghetti western code "matures".
I mean, it's a huge issue and is still happening. It will be talked about until properly addressed.
You never could.
AI massively increases the speed and scale at which bad engineers can do damage while fixing it is still slow, difficult work.
Even if that were feasible in a sustainable way (i.e. LLM-generated code wouldn't drown your code base in technical debt over the mid- to long term), the asymptotic end state of this is that the LLM provider owns the means of your production, not you anymore. How can anyone in their right mind run into this obvious trap?
> By the time you've untangled one bad decision, five more have been merged.
And then there's that. What's the value of all this "speed" when it destroys the most valuable thing you have?
> At some point, someone still has to know what is going on. And that's the most valuable person on the team.
The best you can do is see that you keep being one of those.
“If it works, don’t fix it” until it doesn’t and we shall see a new wave of software hiring in a year or two.
Every enterprise is talking about AI Transformation, and that great with the right expectations. But those who think AI will just make platforms quick with less people and least experienced engineers, will have to prepare for the deinshitification transformation in a year or two.
That is the "democratization" that AI shills speak of:
https://xcancel.com/dhh/status/2087538364580835804#m
Once a CEO with a snowboard-optimized brain gave you a board seat, there is no way back.
Any apparent short term gain is really a prescription for long term pain.
Ignore what AI fanboys say and instead look at what they do.
https://northeasttimes.com/2026/08/07/oracle-bans-ai-code-fr...
Yes.
Whether any gain is worth the pain is left as an exercise for the user.
I don’t have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.
The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.
It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.
And now that code is being watermarked by AI, suddenly they’re artists, painstakingly prompting, crafting, to get just the right code; the watermark is unethical even!
AI psychosis is real, and even some of the smartest people I know how succumbed to it.
So. AI Makes good engineers better, more productive and able to deliver well designed systems.
But it makes the bad engineers 10x worse. Before, they had negative productivity in a team environment. Now, its 10x negative productivity. The mess they create as one person might need 10 people (and their AI's) to clean up.
I would also put people who don't know how to code in that bad engineer basket. They would be delivering code they don't understand, accepting unnecessary complexity etc just like your standard bad engineer.
somehow elite humans are the only ones who can ever reduce complexity?
the tooling is in its infancy. this is the worst it will ever be.
Bonne chance fired senior!
I have depicted you as the 100 line a day weakling, and myself as the 20k+ line chad.
The systems at bigcos are too ruthless to risk gambling your career on this kind of reasoning which you have no recourse to. Best to start small teams and destroy them from the outside.
With TxtAI, I've seen a large uptick in PRs (https://github.com/neuml/txtai/pulls?q=is%3Apr+is%3Aclosed+s...). While the extreme verbosity of Claude messages and commits is very annoying (plus the constant defending itself on why it's a bug), I do think it's a positive that more people are enabled.
It does require reviewing the PRs. Some can be tricky just like a human. For example I did merge this PR (https://github.com/neuml/txtai/pull/1136) and it would have completely broke search. But a human could also do that.
From an open source standpoint, I say the more the better. You just have to be willing to do the work to review and no not just having AI agents to review what the AI agents are submitting. There still needs to be a human in the loop, if you care about quality.
I understand that AI writes better code than people like me in many cases. But an industry should still provide opportunities for those people. And sometimes those people create things that are better than AI in certain areas. The problem is when even those opportunities are taken away.
The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)
It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.
Is it truly right to eat tomorrow's seed corn today?
The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.
You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.
Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.
Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.
E.g. Buterin, Weyl, Friedman. How we started talking in the first place, remember? It was rather regrettable that we stopped asking each other questions..
In place of that, I'd like to see you, jdw64, try to debate with these high-ranked people (in their own community, anyway) :)
To everyone: How can market reward advantageous situation-dependent temperaments in the long term, is I think my question. That sounds like climate (or weather) manipulation, but somehow I sense both theory and practise are much simpler.
In fact, I think I can even eliminate jdw64's ingredient of "temperament".., framing the issue of conflicting temperanents as one between "generalists" & "specialists". Note that you can (probably) use "Marxist theory" to defeat PP without calling it that.
(I think this is more complex than the debate between "wise" and "clever"?? The gap is itself interesting)
This last one, even all of YC would be interested in, I'd argue. In VC lingo, that'd be "T-shape". see also the thread "Felix & I [& D]". That's either like a person who is like both Jobs and Wozniak, depending on situation, or a Wozniak (/Jony Ive) who has the ability to become Jobs, thus sidestepping the situation-dependence-dependence.
Side-quest one is to redefine both "making a billion dollars" and "writing good prompts" as specialities, so that markets as they are imagined now don't necessarily reward these
Side-quest two is make the chameleon skill teachable (or at the very least into an _identity_ ;)
Software engineering is evolving, and the middle class (and beginner) is going to have to grow instead of being able to leverage the same skills for longer and longer.
It's so true from some of the other posts that you can outsource your thinking, but you should never outsource your learning and understanding.
But it does cover the case where someone makes it to the top if he/she is junior. Who experience is gained?
Maybe I ask too much from a short article.
Migration plan? Just ask Claude when shit hits the fan. You'll make a plan when you need one.
> By the time you've untangled one bad decision, five more have been merged.
I'm slowly (partially ironically/sardonically/nihilistically) adopting a mindset of accelerationism towards the collapse of software development - it was largely done wrong from day 1 and wasn't "real engineering" to a sufficient degree to not lead to the mess that we've been in maybe for the past 20-40 years. The only thing AI did was take away the brakes and press down on the accelerator, we're already headed towards a cliff and have been for a long time.
If the code in airplanes and spaceships was developed with the same degree of care and attention as "good code", you'd see those dropping out of the sky regularly. If they built bridges like we build software, they'd fall apart regularly as well. Good code CANNOT hinge on the opinions of some senior dev, or even a group of them - it must be provably good. And if it must be provable, then these checks must be automatable. Bad code (whatever that means, however you'd manage to classify the difference between AI slop and what you want to see) should be IMPOSSIBLE to get into the system at all, due to those automated checks.
Be it good enough test coverage, automated checks for usability and end to end coverage of the features, project/domain specific lists of architectural rules (think ArchUnit), needing proofs not just tests etc. We will never have that - our OSes are bad, our browsers and other essential software is bad, our programming languages are bad (the fact that unchecked exceptions even exist in languages is a cardinal sin), same for databases and tbh any other class of software you can look at.
This impassioned comment might border on a rant, but my argument is that the past decades aren't the baseline of good code, we'd probably need to spend 10-100x more effort to produce 100-10x less code, but make the existing code bulletproof - there is no reason for more than one OS to exist, no reason for more than one UI framework to exist (or even all of the egregious ways how the web platform was transformed from documents and links to a collection of badly written apps, which eventually infected the desktop with Electron, due to the native GUI development also being severely neglected), no reason for more than one web framework to exist or even more than one programming language to exist in mainstream usage outside of research and looking for the solution to use for the next decade/century of software development. Yes, I'm exaggerating, but the correct answer is probably closer to 1 than to 1000.
Obviously that'd lead to death by comittee and some degree of experimentation is necessary, so hey we end up with a new slopped together library every week and I know nothing and nothing works anyways. I wonder if we had ONE high level programming language, whether over time it would have evolved from C++ to Rust (sans odd parallelism), and if it was based on formal proofs, then migrating between language features could have also been fully automated, alongside enough pushback to any feature deemed not worth it. On the other hand, even with all of the world's developers concentrating effort, something like that might be above our cognitive abilities, so probably not - just too hard to reason abuot.
Having large teams in the age of AI is pointless. It slows things down and spreads accountability too thin.
When you have one good engineer doing many things, a lot of stuff lives in their head and they know what to look for in their own PRs. Also, people tend to like their own AI slop, but not others. So overall you will have at least an engineer who is satisfied with the codebase vs a lot of people who either have some gripe about something someone else did, or just don’t care at all.
That means you have to put way more trust in a single individual, but if it’s the right individual you propel the organization further ahead than a team of mediocre engineers or senior engineers limited in what they can accomplish.
Are LLMs rewarding experienced developers with tons of productivity gains? Yes.
Are LLMs actively degrading their expertise of understanding code? Also yes.
This article has made the implicit assumption that the top quartile of engineers are immune from skill decline. They're not. If you're an engineer who increasingly outsources the planning, writing, and analysis of code to an LLM, you're losing your ability to plan, write, and analyze code.
All of this is to say--senior engineers who have fully adopted AI tools are blowing smoke up their asses to dodge the reality of their own obsolescence. The senior engineers can talk about productivity all day, but they're only marginally closer to understanding a complex system that was written by LLMs than the "middle class" of engineers are.
You reading this--yes you--get over yourself. Your skills are depreciating too.
I’ve seen senior engineers adopt AI in a way that made them noticeably worse. If you outsource the reasoning and accept plans you don’t understand then your previous experience isn’t going to save you. Nothing will.
The skill atrophy from outsourcing too much thinking is a real risk. I just don’t think that’s the point I’m trying to make here.
I’m describing a pattern I’m seeing in today. What matters is whether you understand the change being made. If you don’t, then you’re not adding much value, because the LLM can do that part better and faster than you anyway. It doesn’t matter whether you have 2 years of experience or 20.
We've seen this game before, with the Dot Bomb and 9/11. A lot of you have 6 figure jobs that will simply be gone next year after the election, never to return.
That winter lasted about 5 years until 2007 when the iPhone and social media sites like Facebook went mainstream. This winter won't end. Or more accurately, it is the end.
Maybe we should stop debating whether we're in a crisis and start looking at the 5-10 year endgame of the Singularity. We're entering the eventuality that many of us have predicted since the arrival of the internet 30+ years ago, that prices will get lower but nobody will have any money to buy anything anyway. The feeling that we're doing something wrong with our lives will continue to intensify. We'll try so hard, and get so far, but in the end, it doesn't even matter.
I don't know about the rest of you, but I'm turning my attention away from trying to play the job game with AI. I'm looking instead at how we can provide time/money/resources to the middle class after capitalism can no longer provide them.
A conservative friend of mine just read the Communist Manifesto by Karl Marx, which I didn't see coming, especially since he beat me to it. In the neurodivergent spirit of not being able to do anything alone, what if we all read it?
https://oll.libertyfund.org/pages/marx-manifesto
https://www.marxists.org/archive/marx/works/download/pdf/Man...
I'm predicting that it stops just short of what full automation can provide. Loosely the evolution of economics goes: hunter-gatherer -> agrarian- > feudalist -> capitalist -> socialist -> communist. And now solarpunk (or something).
The working class is looking forward to the next chapter, but the capitalist class is looking backward to neofeudalism.
Those two directions can't coexist, so what does the future hold? Well, it's always darkest before dawn:
"It's easier to imagine the end of the world than the end of capitalism." - Mark Fisher.
https://www.youtube.com/watch?v=aCgkLICTskQ Mark Fisher: The Slow Cancellation of the Future
https://www.scribd.com/document/835022535/Mark-Fisher-The-Sl... (transcript)
https://goodscienceproject.org/articles/the-slow-cancellatio...
https://mediationsjournal.org/articles/end-of-world
If the endgame of capitalism is that it inevitably eats itself, then the game now isn't how to get more money and do nothing with it, but instead how to start doing something with no money.
I should add that even if I'm exploring anti-capitalist futures, that doesn't make me socialist. I don't like the 6 hour daily work requirement of many socialist societies. I think we can do better than that and get closer to 0, so that we can shrug off wage slavery and finally get real work done.
Whether people will buy AI-generated software is a different question. The problem I’m describing already exists inside businesses with paying customers.
I’m talking about established teams working on products that already have users and make money, where AI lets individual engineers introduce changes faster than the rest of the team can properly understand and review them.
Or you simply take for granted the bloodbath the next decade will be before we come to proper talks of this. I don't think that is something to handwave unless you have your billionaire bunker ready.
I don’t think it’s “just a tool”, it’s something that directly compete with the role of humans in a system, by design
Is a very sophisticated computer driven adaptive control system making decisions for the user? Arguably yes. If your car has a bunch of assist tech you are not driving. You are commanding a nonlinear control system.
AI today is quantitatively far beyond these systems but internally it is still just a giant decision table. It’s just a differentiable table that can be automatically programmed by back propagation at what would be unimaginable scale for manual implementation.
As soon as you put a machine between you and the target action that is more complex than what you can hold in your head and that has multiple layers or feedback loops, you are ceding fine grained direct control in favor of a simpler abstract control surface.
I will change my mind a little if I start seeing evidence of genuine volition, but as of now I suspect that’s a property of life not intelligence. One interesting result of AI when viewed as an experiment is: I think it proves that life and intelligence are separate phenomena and that consciousness and intelligence may actually be unrelated.
I have the hypothesis that consciousness (and therefore true volition) is a property of life. You have to be metabolic and tied in some intimate way to thermodynamics and the arrow of time. Solid state electronics doesn’t have this property. It’s unrelated to intelligence. A bacterium may be conscious.
Though I personally don’t find the topic of consciousness interesting, it’s not something we are able to define and is distracting from all the other aspects of LLMs that should be discussed or evaluated for what they are.
I'm not the parent, but personally, no, I don't believe so.
I always appreciate the "it's like past changes" thought when things change, but in my opinion, this one simply isn't. It's notably different both quantitatively and, critically, qualitatively, than all previous increments in computers/software. This is much more lateral than punch cards -> assembly -> compilers -> frameworks.
Also, regardless of that thought, the "it's like past changes" argument relies on a false implication: That all changes that survive are "good" in the broad sense. Many changes often persist simply because they are inevitable - not because they are good. They have both good and bad parts, and it's subjective as to which side it leans towards.
You’re deliberately constraining the output so changes stay small, human-reviewable and reversible. That’s good engineering culture.
It isn’t all or nothing. I use AI heavily but that doesn’t mean I have to pretend there aren’t serious problems with how it’s being used.
So many A car is simply a faster horse arguments being made here.
The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.
Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.
I'm working on this right now, will have a release probably in a week or two. Not machine code but it's essentially a custom assembler/compiler pipeline (close enough) that an LLM can operate via the CLI (you can do it too, it's just way slower) and it emits native asm optimized chunks that can then be inserted back into cpp (working on a rust et al impl). The results are _obscenely_ good. It's outright outperforming gcc vis-a-vis by a MONSTROUS margin, and it's not even close. As in, gcc can do abour 3-4 cyc/byte (arbitrary workloads on a wide variety of tests) and my tool does it in 0.5 cyc/byte if not better. It outright emits kernels that run at a flat 4 IPC for more or less _anything_. You can then have an LLM convert it back into high level C++ intrinsics (not always, gcc doesn't always expose all the levers needed to do so) if you wish. The one downside is that you need to provide fairly accurate cpu arch maps (ie agner fog instruction port/latency tables) for the tool to work right, which is what i'm focusing on right now.
If you don’t understand the system, don’t know what the code is doing and you’re mostly prompting an LLM to make the decisions and implementation for you, what exactly is your contribution?
The ability to operate the tool isn’t much of a moat if everyone else has access to the same tool.
I don’t review assembly produced by a compiler because the compiler isn’t deciding what my system should do. It’s translating a program whose semantics were already specified. More importantly, that translation is deterministic.
A compiler takes a human-specified program and translates it into another representation while preserving its semantics.
If in five years I can give an agent a complete specification and reliably verify the resulting machine code against it, then sure, reviewing code may become obsolete and I’d happily stop doing it.
Also, keeping changes small isn’t just about making individual lines readable. It limits blast radius, makes behaviour easier to reason about, isolates mistakes, makes changes easier to revert and so many other things. None of those properties suddenly become obsolete because code generation got faster.
I ask because I've pushed some of this to the limit in my own testing and when I get the right building blocks / primitives in place in the repo, I'm able to get plans written in a way where I don't just describe what I want but specifically mention outcomes, verifications, constraints, etc. that utlimately describe the shape of my system and my intent.
My plan is my understanding of my system and the changes I'm making, and the execution of that plan (e.g. with subagents), verified against my spec, is the code itself.
With the correct building blocks, I've found that frontier models can write code in fairly predictable ways that lets me maintain my understanding and confidence in pretty large PRs.
I think perhaps the quoted part of your post seems to imply it's not possible / isn't phrased with that nuance?
If you didn't write any of it? Yes, you only think you know what's going on.
If you genuinely understand the resulting system, then that's fine. That’s not the behaviour I’m criticising.