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.

> 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.

https://en.wikipedia.org/wiki/2024_CrowdStrike-related_IT_ou...

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?

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.

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.

> 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.

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.

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.

"One bad programmer can easily create two new jobs a year."

-John Cook

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.

"learn to code" is just learning to read and write in a software language. But the industry expected those with basic literacy to perform any specialised task related to reading and writing.

Meanwhile, software engineering courses taught it as abstractions and algorithms, and electronic engineering taught control flow on bare metal.

No one, it appears, is taught design or system architecture outside the context of operating systems. Even requirements engineer is a rare job title.

As more complexity has fallen into the domain of software, nobody has been given responsibility for it. The way we treat junior developers now would be like expecting a carpenter or bricklayer to figure out building architechure and structural engineering, without formal training.

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?

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.

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.

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.

“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.

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

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.

> Call me a gatekeeper if you want but, we ended up with a lot of people that just can't do the job.

The vast majority! I think I've come across 1 or 2 competent engineers in 20+ years. It's a miracle that software works, ever. Increasingly, it doesn't.

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.

> 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.

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.

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.

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

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.

Just because you CAN code doesn’t mean you SHOULD code.

> 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.

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?

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.

[dead]

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.

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!

> 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.

https://github.com/oven-sh/bun/graphs/commit-activity

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!

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.

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.

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.

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).

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.

Mind sharing where you're at?

Sounds like bad management to me

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.

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...

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.

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.

> 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.

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!

A single bad dev with AI can overwhelm multiple good devs trying to hold back the tidal wave of slop.

>> 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.

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.

[dead]

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.

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.

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.

> 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?

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.

Despite the title this article doesn't seem to be saying anything about the "middle class".

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.

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.

> 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.

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.

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.

AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.

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...

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.

> 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.

Jury is still out here

Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.

If those bad engineers are in a very well defined box. Give bad engineers greenfield and watch it implode

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.

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

If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem

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.

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.

[dead]

Fair point! I edited my comment, A&D -> Architecture & Design

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.

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.

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?

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.

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.

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.

>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.

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.

> 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.

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.

> 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.

>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.

> 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.

I've never thought about it this way before but this definitely mirrors my experience

> 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.

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.

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.

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.

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.

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?

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.

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

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.

I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.

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

> 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.

> 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.

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.

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).

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.

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.

Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop

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.

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.

Django? Django is older than jQuery…

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.

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.

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.

> 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.

"This is the worst LLMs will ever be." does not logically preclude "This is the best LLMs will ever be." Telling people to count their chickens before they've hatched is the hallmark of the swindler.

It reminds me of the part in the film `I, Robot (2004)`. The protagonist, Detective Spooner, is driving down a freeway. Driving has been automated at this point in the future, however drivers can manually drive if they elect to do so. And the driver's passenger (the robot shrink) was utterly shocked that Detective Spooner engaged manual driving.

Will we eventually be so accustomed to LLM's that we will be similarly shocked when someone elects to not use them?

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)

> 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?

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.

Only if you run out of things to write. Is your back log ever empty?

People started saying this several years ago and yet it hasn’t really come to pass.

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.

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.

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

Degrees take 4 years. It's a very laggy indicator.

And how do you think people go from fresh graduates to senior devs?

Already seeing it in many places.

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.

My job was just taken by Cognizant, which is technically American, so I guess you're technically right!

have you been inside any big tech company? lots of orgs are > 80% foreign.

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.

>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.

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?

-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.

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.

have you been inside a big tech company? there arent many american fresh grads working there, its mostly foreign

Spend some time processing tech job applications and you’ll realize you’re wrong

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.

We always talk about damage, what's the damage here?

from the downvotes, it seems that people do spend more time in Claude than I do meatcoding. "Efficiency gains" lol

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.

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.

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.

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?

Lots of (most?) programming languages are 0-indexed so it feels natural for software developers and our ilk.

See https://en.wikipedia.org/wiki/Zero-based_numbering, e.g. “computer programmers might use zeroth in situations where others might use first”.

Hey everyone! I found the COBOL developer!

[dead]

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.

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.

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.

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.

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.

to many programmers, yeah

Do you have examples? Ideally a startup that isn’t itself selling AI to other AI companies

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.

Is it long term pain

Yes.

Whether any gain is worth the pain is left as an exercise for the user.

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.

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.

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.)

> 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.

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.

I wasn't saying that either

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

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

in 2 years there wont be many non-vibe-coders left employed

>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.

My point is that your ability to understand what a change is doing is tied to your ability to write and analyze code in the first place.

If you no longer engage with either of those (also your ability to review requires you still understand how to write effective code), then AI will be removing you too.

[flagged]

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.