> That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.

Nor even €50k/year.

Two things are true:

1) The coding part of my career is over. LLMs are capable of doing everything I've ever been paid to *write*.

2) My actual job also included non-coding work: Does this attempted solution even work at all? Is this solving the right problem? Even if it's a valid solution to the right problem, is it the best solution given the time constraints?

That last one, "given the time constraints", is a place where my experience is still useful. The AI is as lazy (or as optimised for fast wins) as the humans whose examples it was trained upon; but an LLM costs so little that the answer is always "do it right" rather than "do it fast". A lot of people don't know what "do it right" even looks like, having only ever known e.g. websites that take 5 seconds to load because of all the adverts and analytics, and never the world where machines with 1% of the CPU and no GPU at all could fit a fully playable first person shooter in the same memory footprint as that page.

At least, I hope this "is a place where my experience is still useful"; I may just be telling myself a nice story, same as all the other people through history who have found themselves obsoleted when the automation came for them.

We have a product guy on the team who was in a deeply not technical role before AI who is trying to do the “hey Claude, read this Jira ticket, implement” thing.

It doesn’t work for the vast majority of tickets he attempts because he doesn’t have the necessary understanding to even start thinking about if the solution that the autocomplete generates is even remotely workable. And that’s with fancy dev loops and whatnot.

The spacer between the keyboard and the chair still matters in my experience.

Boris: "I don't prompt Claude anymore. I have loops prompting Claude and figuring what to do".

Boris: "I haven’t written a line of code by hand in, I think, eight months now… Claude Code, 100% written by Claude Code".

Boris: "There’s no manually written code anywhere at the company… All of the SQL is written by models. Everything is just built by the models... Claude instances communicate with each other (e.g., over Slack) in autonomous loops"

This does not sound like they review the code either. So, either the frontier labs like Anthropic have figured out something that very few companies could replicate, or they are being incredibly deceptive. I don't know which is true.

People are fundamentally short-term thinkers. Just imagine spraying neurotoxins on your lawn. You're "saved" from the "terror" of noticing more than one kind of grass, but of course you're incrementally increased the cancer risk for yourself, your children, and who knows who else. This is just one example; people do this constantly. Plastic fleece puts an untold amount of poison into the environment, but "I need to be warm RIGHT NOW." etc. Or lead paint. "It's only toxic when it breaks down, and that won't be for decades!"

Why would programming be any different?

> That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.

When you factor in overhead and benefits, many companies were regularly paying that much for someone (many someones) to "read this Jira ticket and implement the feature".

We are currently in the "centaur" phase where a human-AI combination produces the best output, but I think some people are betting on the fact that the AI only product will eventually outperform the centaur. And with the cost of tokens falling thanks to fierce competition from the Chinese open weight models, it's definitely possible that those that bet on AI early will reap payoffs in lower expenditures for more output.

Honestly not sure which side I land on that bet but I definitely can't rule it out.

Mythical man month should still apply for AI coding. If you look at the code you're shipping, and you can't quickly edit it by hand, or fix a bug with it, you will be in trouble if the models are down, and your website is down at the same unfortunate time.

> the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it

The word "engineering" means doing things using a repeatable process to get predictable results. If you can get predictable results (e.g. guaranteeing the absence of data integrity issues, security issues, anything that will cause downtime, etc.) without looking at the code, you're still doing the work of engineering.

Your job as an engineer is to choose high-value problems to work on, solve them in the correct way, and guarantee that the functional and non-functional requirements are met. If you no longer need to read the code to guarantee that it has the right set of ilities, then I'm not sure that's obviously a bad thing, as long as the ilities you're enforcing result in a codebase that is sustainably secure and maintainable over the long term.

I think there are two parts to it

1. Execution of engineering task - Companies happen to focus on this mostly and this is the metric to measure easily. Using LLM tools gives a impression of improvement on this area which is what everyone is chasing

2. Growth of the Engineer - This is the one which was always a side product of company culture, individuals interest, work being done, time being spent to understand, learn from failures. A job being executed perfectly for the first time itself does not gives the opportunity for learning, no memories/experiences are built up mind of the person executing the job after a while.

The second part is the one which is under appreciated in current scheme of things since it was a by product. There is a concept of muscle memory which pretty much applies to everything.

My job improved significantly since I managed to get into their (managers) thick skulls to tell Claude to not be verbose. I'm tired of 1200-word tickets for "put the totals in the automated emails".

Up to now, manual coding has produced mountains of code, faster than humans can un derstand it! Already!

The nincompoops at the top think that if mountains of code can appear by snapping your fingers, they will be less of a problem.

If the mountain doesn't work, no problem; since it was so cheap to produce, just scrap it and snap you fingers again. The next one will be better.

Comparatively evaluating 2, 3, ... mountains of code is harder than trying to understand one.

Maybe some day, not in the short term. I've seen output of bad developers using Fable and after that I sleep safe.

A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.

Decades ago, enterprises said, "If you're writing assembly you're doing it wrong".

That led to a reduction in knowledge of assembly in the average programmer but the people who specialize in it haven't gotten any worse at it.

The result was a generation of programmers who make useful software while very few of them understand the machine they program. You could easily make either a positive or negative value judgement about that result.

> We are indeed producing a shit-ton of code, but the reality is that engineers are pumping out code faster than the humans can understand and (honestly) review it. That sounds great until you realize that "hey Claude, read this Jira ticket and implement the feature in this code base" isn't really worth $200K/year.

My argument here is that what is worth $200k+ is the ability to distinguish the changes that must get thorough, critical review from those that need only a couple of specific things verified and those that require no manual review at all.

Our jobs have never been to write code. We’ve been saying for decades that LoC isn’t a rational way to measure engineering output, and now we have our chance to structurally change that system before processes re-solidify. In fact, I think the flexibility to adopt new systems and the experience and foresight to choose a path that is better than the status quo without throwing out everything we’ve learned is going to be what sets companies apart and makes individual careers over the next few years.

> we have leadership air dropping AI generated manifestos on the product owners and product owners having to use AI to transmute all that shit into 1,500 word Jira tickets that are 10% necessary feature work and 90% LLM boilerplate.

There’s an important criticism here IMO - the relationship between “business” and “engineering” is changing drastically. It’s going to be a challenge to set the expectation that just because Marketing was able to vibe-code a prototype in a day, actual implementation may well take weeks or months. Engineering should be considering things like security, scalability, and systems integration that aren’t a concern for Marketing - that’s why we’re being paid!

> So now you have software engineers whose job has changed radically to the point that the hardest part about being a software engineer is just filtering through AI generated artifacts from all directions just to try to get a feature out the door.

I think it’s an extremely heterogenous landscape right now. Where I work I’m struggling mostly with organization - keeping the (literal) dozens of inbound features that come in every day straight long enough to hook up an agent harness, review, validate, and deploy. At other companies the issues seem to revolve around their Agile-based processes. Or maybe it’s non-technical vibe-coders and their expectations. Or maybe it’s executive leadership flirting with AI psychosis.

Everything is in flux. It’s stressful and exciting, and I’m thankful to be around for it, even if I am in my 40s at this point and looking at the core skills I’ve built rapidly become worth exponentially less. It’s a huge opportunity for growth.

Engineers, free from writing thousands of lines of boilerplate, now have more time to review code and be more efficient in that armed with LLMs. E.g. instead of asking a question about the code and waiting for the author to respond, I can ask an LLM and get the answer almost immediately. Or, if I see some strange code being changed, I am always curious why it was there in the first place and, instead of tracing it through git blame over formatting, renaming, and moving files around dirs I can delegate this to an LLM. If I have doubts about it working in some environment I can, again, make an LLM test it out instead of asking the author etc. etc.

And no, telling Claude to implement a Jira ticket is not worth $200K/year. Checking if it has not done something stupid and correcting it when it's trying to - is.

I think this expresses what I've been trying to form in my mind.

I've been trying to map the LLM advancements and the current state of software development onto prior technological improvements. History is littered with similar cases where the abstraction layer ends up getting lifted, and people struggle with getting accustomed to working at that higher abstraction level.

For the people that fall in love with a single abstraction layer or don't have an interest in learning new paradigms, when their known pattern is abstracted away, they're condemned to being left behind, either unwilling or unable to adapt.

I don't think any industry is free from this, any person in any industry/profession over a period of 20 years or more has likely had to undergo massive adjustments as technology changed their field.

We're not unique, but that doesn't stop it from feeling so jarring when it happens to us

I think coding experts who are only experts at writing code will also be hit pretty hard. Every problem given to them is solved by writing code, and only code, their way and only their way. I think people like that are having a very hard time relinquishing control regardless of the quality and correctness of the LLM output. If it didn't come from them, or conform to their conventions and style, then it's wrong. These are the people that seem to be terrific developers but then when asked to be a team lead and bring a group of developers to their level completely fail.

Curiosity is really key, and I find that LLMs diminish curiosity in people that might otherwise have it because the allure of the answer is often a lot stronger than the allure of the friction. I guess that's just the distilling of the industry over time, but that could certainly lead to a shortage of expertise.

I mean if you think about it, that sounds like a miserable existence to begin with. I would not rule out that some people will use this.. uh.. disruption, to start pursuing something that actually brings them joy.

Of course, bills need to be paid and it's not all that simple. But at least there might be such a silver lining.

Maybe I’m naive, or misguided, or something else, but I decided almost 2 years ago that I’m going to bank on not using LLMs to do my job. I still write code by hand everyday. I don’t use AI to write code or lookup docs, or anything else. I just figure that if we really, truly, indisputably hit the point of AI assisted coding being mandatory, I can learn it and get up to speed in a few weeks (or at worst a couple months), whereas uncooking my brain is way way more expensive and time consuming and difficult. We’ll see how it plays out, but so far I don’t feel left behind at all really.

Why do you trust the non-deterministic LLM with your skill?

It doesn't matter if the LLM is not deterministic.. the OUTPUT of typed code is deterministic in the sense that it can be seen to be type safe, compiled, and run appropriate unit tests on it.

If I use two LLM's to create some chunk of code and they both do it slightly differently but they both compile and pass appropriate tests.. it honestly doesn't matter if the LLM itself is not deterministic in exactly what it's going to output.

I would also argue- doesn't that make sense? You give two human coders the same task and they are also going to come up with slightly different results.

A deterministic LLM is possible. Would you trust it?

Not to detract from your point, but there were software-programmable computers in the 50s. Check out Usagi Electric's videos about the Bendix G-15, where he loads software from punched tape.

> cognitive friction is the engine of learning. I agree 100% too.

This is why in order to understand new codebase or to ramp up to new projects, I use AI to generate a textbook style reading material for me along with "verify yourself" types of exercises along the way. Then I print them on a paper and read it using a pencil/pen and take notes.

Because of my math training, I am in the habit of slowing down to read textbook style texts which helps.

> "...if you stop training the "muscle" of logic and reasoning, it gradually atrophies, just like unused physical muscles. You become dependent on external tools that replace a capability you once had yourself."

For a bit of extra unease, consider that these people will retain their right to vote, both in making business decisions as employees, in shareholder meetings as shareholders, and in government elections as voters, despite their atrophied reasoning abilities. Who will wind up whispering what to vote for in the ears of these reverse centaurs?

Another example is autocorrect absolutely destroying the world's ability to spell even the most basic words. Ever since mobile phones came along and removed the friction of walking to the dictionary, everywhere I look people write as if they have extremely serious brain trauma - grown adults struggling to write as well as we used to as children!

> Today, having a piece of furniture in our home depends on a massive production and supply chain; the "average" person no longer has the ability to build it themselves.

Tangential, but this is one of many reasons that I (and I suspect many others here) have taken up wood working.

theres even more recent things to learn from > https://en.wikipedia.org/wiki/Ironies_of_Automation

> Bainbridge argues that new, severe problems are caused by automating most of the work, while the human operator is responsible for tasks that can not be automated. Thus, operators will not practice skills as part of their ongoing work. Their work now also includes exhausting monitoring tasks. Thus, rather than needing less training, operators need to be trained more to be ready for the rare but crucial interventions

Yea, it does apply. Honestly I'd argue that as you move up the abstraction layer cake, it applies even more. If a team gets a tool which 2x's their output (maybe a higher level language vs writing in C), then the difference in absolute output someone who produces 1 widget per day and 5 widgets per day becomes substantial. If you're given a tool which 10x's your output in a day, then it's even bigger. And of course you can have devs on a team who produce -.5 widgets per day.

Think about the worst colleague you've had, now give them a tool which 10x's their output :)

And not just the high level language output, or even the assembly. No no, every single piece of microcode produced.

If you actually look at Cobol job listings, they pay like 50k and want a master's degree. The myth of them being paid really well is not true at all.

> backing up the brinks truck

now that's a phrase I have only heard in one other context: as an alleged quote from former Boston Celtics player Isaiah Thomas (who was really about 5'7 despite his official listed 5'9; yes, professional basketball player in NBA). This was around 2017 when he had just come off a career year and was soon due for a contract extension in the low 9 figures. He got injured and bounced around for a few years before eventually leaving the league, and never got that payday.

It's like I said in another article, I've spent my life in C# and JavaScript. I'm a low-level programmer now, did even have to learn C or assembly.

that would be nice, but unfortunately I think the supply vs demand situation is quite different this time

I don't think that's quite correct; every CS program I've seen involves writing code, quite a lot of it. What they don't teach is /software engineering/: working large codebases, maintaining code, dealing with legacy code, long-term collaboration, working with product managed and designers, etc. That's stuff that you mostly end up having to pickup in the real world outside school.

> especially if you are reading the code that is produced and at least understanding the flow of it.

This is the key point. Should we stay vigilant and review all the code, ensuring we have a decept grasp of what it does. Or just green light everything and treat the code itself as a black box. I would hope we do the former, but many are pushing for the latter.

> Most computer science programs don't teach "coding" though. There is pretty heavy emphasis on datastructures, algorithms, and system design

Those skills are often taught in an idealized situation like very small projects. In the real world, there are a lot more practices and techniques to develop software in a pragmatic way. Those "engineering practices" are much more useful than the above, unless you're in some specific domains.

The end result is a total and complete reliance on AI providers. It's not really a secret; that's why I started the article with the direct quote from Altman. They would love to see a world where nobody is able to do any type of development work without an LLM subscription enabled...even though they also admit that these models perform best when they are steered by someone who is highly capable and knowledgeable in the first place. They're powerful, but they are also VERY fallible.

Local AI would thwart this vision (which is why they're desperately also trying to ruin the hardware market at the same time), but the effort it would take to get local models to run as well as these frontier models is an odd thing to pursue just to avoid learning the fundamentals and gaining direct experience.

yes, this seems sadly very true for me, too.

In some ways, it feel like I'd be "stuck" at my 2024 capabilities if I didn't push myself constantly, and I'm really glad for every hour I spent learning/applying new stuff before that, because now it feels way harder.

This analogy breaks down because computers aren't going away unlike horse drawn carriages or sailing vessels. Computers aren't being replaced by something. It's that fewer people will understand how they work while the efficiency and reach of computers extends into areas of life previously unreachable due to the scale of having humans build it or the refusal of humans.

I could wax philosophical about what that leads to but enough people already have.

If my horse is ‘a useful piece of software’, what are the cars and motorboats that AI coding is going to give me?

Yeah, I have to say some of this deskilling argument sounds like Socrates complaining about the invention of writing ruining people's ability to truly own the text. I really don't mourn my lost assembly skills or my lost C skills. And I'm not missing the details of whatever web framework du jour my Claude is vibing for me on my extremely useful dataviz internal tools; and I have learned how to rein the agents in to not ruin my high-performance Go code and yet debug concurrency issues. Maybe coding qua coding is what some people find their summum bonum, but for me programming is instrumentive - to build real things in the world that do things to make something better. When I want pure virtuosity of intellectual construction, I read maths papers in arxiv.

(Not to say that the current state of the art with LLMs merits borrowing money for a multi-trillion spend on hardware that will be obsolete in 5 years, but for me that is a different issue).

The master decrying the invention that resulted in more wisdom for more people than anything prior:

"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem [275b] to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise." (quoting from https://www.historyofinformation.com/detail.php?id=3439)

May I ask how many years experience you have?

It is guaranteed to happen. The key question is when is it a problem? We've lost lots of knowledge as a society but we're still going. Some skills decline in usefulness, others gain utility with the passage of time. Tale as old as time.

Depends on what you are programming. I have been using it to build things that have never existed before, that I have wanted for over a decade. Experience gives one more imagination.

> post agentic LLM as programs are going to be mostly bloated ad-hoc, poorly thought-out and patched in a way that does not concern it's self with the correctness of the algorithms or data structures chosen.

This is an accurate description of 90% of corporate software pre-LLM.

LLMs are introducing a unique kind of bloat and dysfunction but it's not like they are replacing pristine code. Most software that is subject to market pressures and is generating a profit is painful to look at and difficult to work in.

How many programs can dispense with 50% of their complexity by just offering an API for LLMs to execute?

By way of example I use Kdenlive 90% less and just use Codex to issue the ffmpeg CLI commands directly when I want to crop/format video on my PC.

>at work, i can tell that people are not thinking and losing the ability to thinking hard.

its also wild how quickly and willingly many people handed this over. the apathy and desire for connivence runs extremely deep among my coworkers. we are at the point where people are not even running their local dev servers and clicking around to ensure their work is functionality correct, they just ingest the ticket, dump it into the model, commit the output, and say they're the most productive they've ever been.

I think a lot of good might come from medical sciences or chemistry, where LLMs will be used in coming up with new medicines, methods or synthesis.

They haven't. They have made the world significantly worse.

I originally found the paper through this video:

https://www.youtube.com/watch?v=HTUh0OO6Kmo

The video seemed to indicate it was a study they ran (she refers to the examples as "our subjects were two of twenty four participants"). It seems they are just citing the study. While it doesn't change the study or the takeaways, I'll update the post for clarification!

It's different though because for structural engineering finite element models (set up correctly) will give you a deterministic, mathematically correct answer.

In fact FEM is arguably more deterministic than the old school pen and paper methods (yield line analysis etc.) which often rely more on correct judgement of the structural engineer doing the analysis.

So I don't think the analogy quite holds

No matter how robust my code is and however many eventualities I considered, it certainly feels like AI can find and address issues.

Your inclusion of FP is interesting in an unintended way: LLMs actually thrive in a highly constrained system like you describe. "It's hard to switch your mindset" - isn't nearly as true for an LLM, it can usually adopt those languages quite readily.

LLMs don't particularly care how hard the type system or borrow checker is (as long as it has good error messages that can guide it to a solution), they can grind away at these things, and what you describe as a negative actually becomes a strong positive. I think we'll see strongly typed systems plus some level of formal verification become popular as an AI-preferred language.

When the burden of review is lowered because you have purely functional building blocks, with lots of formally verified chunks - people will choose that simply out of (productive, beneficial) laziness. Not to mention we're in a ram crunch, and being able to run your stuff far cheaper has an immediate financial incentive.

> Eliciting the right requirements and user needs. Creating a sound architecture and design. Validating final product meets the requirements. Ensuring there is good test coverage.

Besides your first point, the rest can be delegated to AI as well. And you don't need to be a "software engineer" to spec out requirements and user needs.

Literally all those skills are the result of decades of friction, challenge, and deep domain knowledge...all of which are circumvented when LLMs are utilized early in the process.

CAD is also useless to Mechanical and Electrical engineers who didn't learn fundamental the skills that it streamlines.

> Mechanical and Electrical engineers didn't go away because of CAD.

that is a very good point! I'm going to use it in the future.

> It took me less than 6 months from no knowledge to my first job.

I agreed with you up until this sentence. Entry-level devs with 6 months of require an enormous amount of time and mentoring until they're able to really perform well. I think the greater concern being expressed is not will people be able to type syntactically correct code?, it's will people be able to write software well?.

just add to your prompt or to an agents.md "don't write any code, just present me the solution so i can learn from it". that should do it.

If current trends are anything to go by, who's to say that these aren't stepping stones towards it?

Speaking on a handful of these that I'm familiar enough with to opine on:

- Photography hasn't erased other visual arts. Both require a separate skillset; both have their uses and their enthusiasts. Photography benefits from having a lower skill floor, in my experience doing it, and this in turn has led to commercial photography eclipsing commercial painting (barring things like painting buildings) as a viable business model, largely.

  I'm not sure if we're better or worse off as a society for having gone through that shift.

  This has more- and less-pronounced areas. In the US (which is geographically close to me and which has an outsize proportion on my own country's culture), Fox News is an excellent example of how TV can erode critical thinking.

  Just like with TV, smartphones have clear benefits and utility in daily life. They aren't abjectly bad inventions, but they have a serious societal toll, and it's difficult to ignore that.

  In the wake of that accident, many aviation regulators instituted or began requiring that manufacturers and airlines formalize training and operational procedures that protect thoroughly against this sort of cognitive gap.

In software, we like to think that we're a serious industry, sometimes. We spent much of the 2010s going in what I found to be a good direction: the development of IaC, the popularization and standardization of tools like Git, registries for vulnerabilities like the NVD, and even the development of languages like Rust which address historical technical shortfalls of high-performance, low-level languages like C; but we always fell short, industry-wide, on matching these toolchain upgrades with technically-rigorous procedures.

For every borrow checker, there's vibe coding.

Plato wasn't against just "writing" in a general sense, or that he felt it was going to hold humanity back. He was against treatises and felt that someone could "memorize facts" without having to actually think about them on a deep level. Which I think, ironically, is not all that off the mark especially in the age of the internet and now LLMs, right? He also felt that memory could decay if we relied on written facts instead of having dialogues, which again, not all that off the mark, either. He underestimated the compounding capability of technology and our ability to record data and information, but people remember a lot less these days than they used to because we'd largely given up that ability in exchange for the instant information machines.

Of course, he's just one man (or two, if you consider he was conveying Socrates' thoughts, as well) who lived in ancient times and couldn't possibly foresee how technology would evolve...but when I went back and read his concerns, it was ironic to admit that much of what he warned about still applies to this day. People are far less informed despite having access to more information than we've ever had because we've exchanged the ability to remember for the ability to just look things up. And, we also have less meaningful dialog than ever before; people just sit on social media, copying and pasting "facts" to each other, instead of having actual productive discourse.

AI tooling can be a boon to learning, but it requires us to stop using them for code generation as a primary purpose (at least for juniors) and instead advocate for Socratic workflows that still require manual coding practices. When someone decides to code something, it's not just learning syntax; it engages a variety of mental disciplines from critical thinking to planning to creative problem solving to logic and math, even.

> without having much depth in either domain

I don't mean to pick on you, but to present this in the service of this kind of fatalism... you know the inevitable follow-up question, right?

Do we even need to get LLMs to create code in the end then? Can we imagine a future where the thing simply does it all, you deploy the LLM like a docker image and have it process all requests directly. Sounds far fetched today, coming to your cluster in five years.

> It is important to ensure that any LLM code is named and shamed.

You need to take it further.

We need to shame and mock the people (read: delusional imbeciles) who think this is acceptable if we want it to stop.

AI users need to fear for their careers and reputations if we want to get software development back on the right track.

Do you think LLMs and compilers have a lot of overlap?

Flagged for the expressing the most obvious and legitimate concern about LLM-backed "research".

"I use AI to generate a summary which I print out and read slowly every time I use a new codebase" is the new propaganda line pushed by Anthropic and OpenAI. They cannot tolerate this rebuttal.

Yeah I'm not convinced people are just going to give up solving problems

There's something weird about nurse pay where it doesn't seem to raise even during large shortages of qualified nurses. I think it's artificially lowered by hospital admin, with temporary traveling nurses acting as "scabs" to avoid the normal wage increasing

The Labor Theory of Value was defeated decades ago, get with the times

I'm solving harder and harder problems for real users/customers than I was a year ago and our sales are increasing as a result.

While it depends on the market, job, and hours, but the bedside nurses I know make in the low $100k range. Typical shift structure at the hospital is three 12 hour shifts in a row and then four days off. Most of the time, they are union jobs, so they receive many benefits from collective bargaining such as increased holiday and overtime pay in the range of 1.5-2x normal rate. A nurse practitioner tends to make something in the 180-220k realm.

Again, to be clear, this is highly dependent on the market, job, and hours and one needs to understand the difference between a CNA, RN, NP, etc. However, it's a regulated typically union job that's very secure and in high demand. It probably pays more than what you expect.

Yes, they are still making that much. I am. I don't fully understand why yet but I think it is because of a few reasons:

1. We still need to keep the lights on. If things go wrong, which they still do, humans have to debug it.

2. Jevon's paradox: now the expectation is that we ship stuff faster and there is still a LOT of stuff to do, not less.

3. We are still in the very early days of this and it is too soon for corporations to make a dramatic call like laying off 80% of engineering. We just don't know how that would look like.

I want a world where teachers on average make more than software engineers. If we figure that out, everything else will be fine in the long run.

I think nurses in the Bay Area make like 200k a year

Don't you worry about salaries of any trained medical professionals:)

The effort/pay ratio never made sense though.

Did this not happen?

ASM is still used in some areas, such as:

1. function trampolines, such as in libraries like ATL (Microsoft's COM template library);

2. hand-optimized encoders/decoders for things like ffmpeg;

3. niche applications such as Ben Eater's 6502 breadboard computer (using a modified WozMon and Microsoft BASIC);

4. reading ASM output from C/C++ code in things like the GodBolt site for performance comparisons/analysis;

5. reverse engineering old DOS games;

6. people working on things like compilers (generating optimized assembly), JIT engines, or other code generation -- though this will typically be machine code, possibly with assembly instruction comments;

and other performance critical places where assembly can speed up that part of the code.

ASM to a higher level language is a jump to a clearly defined higher level language through a deterministic compile step. The jump away to LLMs is something completely different.

A $1200 GPU is all a reasonably capable engineer needs for each work stream. The cloud prices are a scam.

> I don't know how you teach that without coding

That's the neat part: you don't!

Even Robert "Uncle Bob" Martin, who's as AI pilled as they come and doesn't read code any longer, says that junior developers shouldn't even look at AI tooling for the first three years:

https://www.youtube.com/watch?v=RxxxGkFIUJ0&t=1356s

In contrast with Pascal, I could see in my mind the PDP-11 instructions behind my C code. By the time I started running code on x86, there were debuggers that could step through source code, and I didn't really want to think like an i386.

> LLMs are just another abstraction layer above programming languages, machine language, etc.

Programming languages are (largely) deterministic. LLMs are not. The boundary between an abstract concept and something executable sits comfortably in the mind of the programmer in non-LLM contexts. This boundary shifts when using an LLM and becomes shared between the programmer and the matrix multiplication machine.

The "layer of abstraction" analogy is therefore technically true but essentially false. "Just another" papers over how seismic of a paradigm shift all of this is.

We don't teach kids math with access to calculators, and so on. Making students code by hand at first is a very moderate proposition

Actually, they have for a large majority of the population. And fun fact: that debate is still going on, and the Mathematical Association of America (MAA) enacted a rule prohibiting calculator use in AMC.

https://ivyleaguecenter.org/2024/03/12/over-reliance-on-calc...

Math fosters critical thinking, and we've been in a critical thinking deficit for decades and decades. I don't think we can afford to sink even deeper...

I have heard stories of cashiers being incapable of giving correct change. So yes it has happened.

A more apt analogy is the diminishing understanding of assembly language and machine instruction sets. I love programming and something got lost in both transitions, first to high level languages and now to coding agents. I am quite sure some contexts will require programming by hand for a long while as there are still people who are writing amd64/avx512/sass by hand. I hope in time we will find new ways to enjoy solving problems with this new programming modality. By now, I am pretty sure it is here to stay and evolve from its current crude form.

Math skills had never anything to do with arithmetic. Maybe Ramanujan discovered a couple of theorems by dealing with numbers themselves. That is it.

Online discourse though is collapsing under dumb AI talking points.

Arithmetic skills. And they probably have?

Not really the same, since your average calculator doesn't take over executive function. The user thought and decided what needs to happen, down to one extremely well-specified task, which is so unambiguous that it can be completed by rote and without context.

This is more like paying someone else to read your math homework, generate answers, and maybe even submit them on your behalf. If that had been the (average) student experience, math skills really would have collapsed.

> And math skills are going to collapse from calculator reliance.

People can no longer drive a stick-shift car, whereas it used to be that a valet would always be able to drive one to park it.

That's a very good point. People don't pull out their calculator in the grocery store to do analysis of unit costs or whatever, it's too much of a hassle for that small kind of analysis. But calculators have robbed us of the need to be good at doing that math in our heads. So the math doesn't get done.

This is exactly the right analogy. Granted LLMs are a more sophisticated calculator and engineering is still adapting to this wonky/evolving technology. But to pretend it's a coming catastrophe is to ignore every past parallel development - where this has not happened.

"Mental math skills" literally did collapse tho??? "Math skills" to write proofs (which a calculator cannot do) is a fundamentally different skill set than that "math skills" of mechanically doing arithmetic (which a calculator does do).

Seems like critical reading skills have already collapsed.

No.

With a calculator you still need to understand the fundamentals of mathematics. You also need to understand how to operate a calculator and know its functions.

Even when removing numbers and manual calculation, being a function or formula oriented mathematician still requires you to know the theory and functionality.

With an LLM, you don't even need to know anything other than asking the robot to perform. You don't understand the output, nor can an unskilled person explain it.

They probably have though.

This is the same kind of analogy people make when they "poo-pooh" any sort of technological advance, especially with AI.

"Oh, that old simple device didn't displace anything, so this one which is now quickly taking over every job will be just like that simple one". So I guess people today know how to sew and knit and bake bread?

"Oh, humans were always needed, so it'll be the same this time." Is that true of horses and oxen after cars and tractors were invented?

Your calculator isn’t designed to keep you addicted to it and doesn’t have baked in orders like “be humorous and irreverent when appropriate.”

Also, yes I am dependent on a calculator.