8 ms·

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abst

What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and harddrives, and responded by wrapping it in managers, sub-agents, memories, tools, permissions, workflows, and orchestration layers so we don’t have to look directly at the fact that it still doesn’t understand anything. Now we’re expected to maintain a mental model not just of our system, but of a swarm of half-reliable interns talking to each other in a language that isn’t executable, reproducible, or stable. Work now feels duller than dishwater, enough to have forced me to career pivot for 2026.

jsk2600 10mo ago
What are you pivoting to?
- coldpie 10mo ago
  I'm also interested in hearing this. For me, I'm planning to ride out this industry for another couple years building cash until I can't stand it, then pivot to driving a city bus.
  - layer8 10mo ago
    > then pivot to driving a city bus. You seem to be counting on Waymo not obsoleting that occupation. ;)
  - baq 10mo ago
    Gardening and plumbing. Driving buses will be solved.
    - Buttons840 10mo ago
      Plumbing seems like a relatively popular AI-proof pivot. If AI really does start taking jobs en masse, then plumbers are going to be plentiful and cheap. What we really need is a lot more housing. So construction work is a safer pivot. But, construction work is difficult and dangerous and not something everyone can do. Also, society will collapse (apparently) if we ever make housing affordable, so maybe the powers-that-be wont allow an increase in construction work, even if there are plenty of construction workers. Who knows... interesting times.
Q6T46nT668w6i3m 10mo ago
It’s wild that programmers are willing to accept less determinism.
- dahcryn 10mo ago
  The good ones don't accept. Sadly there's just many more idiots out there trying to make a quick buck
  - lazystar 10mo ago
    Delving a bit deeper... I've been wondering if the problem's related to the rise in H1B workers and contractors. These programmers have an extra incentive to avoid pushing back on c-suite/skip level decisions - staying out of in-office politics reduces the risk of deportation. I think companies with a higher % of engineers working with that incentive have a higher risk of losing market share in the long-term.
    - doug_durham 10mo ago
      I’ll answer that with a simple “No”. My H1B colleges are every bit as rigorous and innovative as any engineer. It is in no one’s long term interest to generate shoddy code.
      - lazystar 10mo ago
        I'm not stating the code is shoddy - I agree the quality's fine. I'm referring to the IC engineer's role in pushing back against unrealistic demands/design decisions that are passed down by the PM's and c-suite teams. Doing this can increase internal tension, but it makes the product and customer experience better in the long run. In my career, I've felt safe pushing back because I don't have to worry about moving if my pushback is poorly received.
- zephen 10mo ago
  There has always been a laissez-faire subset of programmers who thrive on living in the debugger, getting occasional dopamine hits every time they remove any footgun they previously placed. I cannot count the times that I've had essentially this conversation: "If x happens, then y, and z, it will crash here." "What are the odds of that happening?" "If you can even ask that question, the probability that it will occur at a customer site somewhere sometime approaches one." It's completely crazy. I've had variants on the conversation from hardware designers, too. One time, I was asked to torture a UART, since we had shipped a broken one. (I normally build stuff, but I am your go-to whitebox tester, because I hone in on things that look suspicious rather than shying away from them.) When I was asked the inevitable "Could that really happen in a customer system?" after creating a synthetic scenario where the UART and DMA together failed, my response was: "I don't know. You have two choices. Either fix it where the test passes, or prove that no customer could ever inadvertently recreate the test conditions." He fixed it, but not without a lot of grumbling.
lo_zamoyski 10mo ago
> It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. The ubiquitous adoption of LLMs for generating code is mostly a sign of bad abstraction or the absence of abstraction, not the excess of abstraction. And choosing/making the right abstraction is kind of the name of the game, right? So it's not abstraction per se that's a problem.
torben-friis 10mo ago
Our industry wants disruption, speed, delivery! Automatic code generation does that wonderfully. If we wanted safety, stability, performance, and polish, the impact of LLMs would be more limited. They have a tendency to pile up code on top of code. I think the new tech is just accelerating an already existing problem. Most tech products are already rotting, take a look at windows or iOS. I wonder what will it take for a significant turning point in this mentality.
- rgreeko42 10mo ago
  disruption is a code word for deregulation, and deregulation is bad for everyone except execs and investors
  - rambojohnson 10mo ago
    it's sadly telling how this comment got greyed out to oblivion.
- ip26 10mo ago
  One possible positive outcome of all this could be sending LLMs to clean up oceans of low value tech debt. Let the humans move fast, let the machines straighten out and tidy up. The ROI of doing this is weak because of how long it takes an expensive human. But if you could clean it up more cheaply, the ROI strengthens considerably- and there’s a lot of it.
simonw 10mo ago
I think AI-assisted programming may be having the opposite effect, at least for me. I'm now incentivized to use less abstractions. Why do we code with React? It's because synchronizing state between a UI and a data model is difficult and it's easy to make mistakes, so it's worth paying the React complexity/page-weight tax in order for a "better developer experience" that allows us to build working, reliable software with less typing of code into a text editor. If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all. How often have you dropped in a big complex library like Moment.js just because you needed to convert a time from one format to another, and it would take too long to hand-write that one feature (and add tests for it to make sure it's robust)? With an LLM that's a single prompt and a couple of minutes of wait. Using LLMs to build black box abstraction layers is a choice. We can choose to have them build LESS abstraction layers for us instead.
- tyre 10mo ago
  For moment you an use `date-fns` and tree shake. I'd rather have LLMs build on top of proven, battle-tested production libraries than keep writing their own from scratch. You're going to fill up context with all of its re-invented wheels when it already knows how to use common options. Not to mention that testing things like this is hard. And why waste time (and context and complexity) for humans and LLMs trying to do something hard like state syncing when you can focus on something else?
  - simonw 10mo ago
    Every dependency carries a cost. You are effectively outsourcing part of the future maintenance of your project to an external team. This can often be a very solid bet, but it can also occasionally backfire if the library you chose falls out of date and is no longer maintained. For this reason I lean towards fewer dependencies, and have a high bar for when a dependency is worth adding to a project. I prefer a dozen well vetted dependencies to hundreds of smaller ones that each solve a problem that I could have solved effectively without them.
    - 10mo ago
scellus 10mo ago
My work is better than it has been for decades. Now I can finally think and experiment instead of wasting my time on coding nitty-gritty detail, impossible to abstract. Last autumn was the game changer, basically Codex and later Opus 4.5; the latter is good with any decent scaffolding.
- chasd00 10mo ago
  I have to admit, LLMs do save a lot of typing a d associated syntax errors. If you know what you want and can spot and fix mistakes made by the LLM then they can be pretty useful. I don’t think it’s wise to use them for development if you are not knowledgeable enough in the domain and language to recognize errors or dead ends in the generated code though.
AndrewKemendo 10mo ago
Every technical person has been complaining about this for the entire history of computer programming Unless you’re writing literal memory instructions then you’re operating on between 4 and 10 levels of abstraction already as an engineer It has never been tractable for humans to program a series of switches without incredible number of abstractions The vast majority of programmers never understood how computers work to begin with
- casey2 10mo ago
  This is true, though the people that actually push the field forward do know enough about every level of abstraction to get the job done. Making something (very important) horrible just to rush to market can be a pretty big progress blocker. Jensen is someone I trust to understand the business side and some of those lower technical layers, so I'm not too concerned.
- Trasmatta 10mo ago
  People keep making this argument, but the jump to LLM driven development is such a conceptually different thing than any previous abstraction
- fwip 10mo ago
  And if you're writing machine code directly, you're still relying on about ten layers of abstraction that the wizards at the chip design firms have built for you.
kayo_20211030 10mo ago
Could we all just agree to stop using the term "abstraction". It's meaningless and confusing. It's cover for a multitude of sins, because it really could mean anything at all. Don't lay all the blame on the c-suite; they are what they are, and have their own view. Don't moan about the latest egregious excess of some llm. If it works for you, use it; if it doesn't, don't. But, stop whinging.
christophilus 10mo ago
What are you pivoting to?
casey2 10mo ago
So you're washing dishes now?
dandanua 10mo ago
Don't forget you are expected to deliver x10 for the same pay, "because you have the AI now".
- baq 10mo ago
  The system is designed to do exactly that. This is called ‘productivity increase’ and is deflationary in large dosages. Deflation sounds good until you understand where it’s coming from.
exssss 10mo ago
Out of curiosity, what did you pivot to? It sounds crazy to say this, but I've been thinking about this myself. Not for the immediate future (eg 2026), but somewhere later.
aleph_minus_one 10mo ago
> It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. No profession collectively made such a decision. Programming was always very splitted into many, many subcultures, each with their own (mutually incompatible over the whole profession) ideas what makes a good program. So, I guess rather some programmers inside some part of a Silicon Valley echo chamber in which you also live made such a decision.
teleforce 10mo ago
This whole things of AI assisted and vibe coding phenomena including the other comments remind me of this very popular post on HN that keep appearing almost every year on HN [1],[2]. [1] Don't Call Yourself A Programmer, And Other Career Advice: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... [2] Don't Call Yourself A Programmer, And Other Career Advice (2011): https://news.ycombinator.com/item?id=34095775 https://news.ycombinator.com/item?id=34095775
akulbe 10mo ago
What are you pivoting to?
godelski 10mo ago
> the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. I've usually found complaints about abstraction in programming odd because frankly, all we do is abstraction. It often seems to be used to mean /I/ don't understand, therefore we should do something more complicated and with many more lines of code that's less flexible. But this usage? I'm fully on board. Too much abstraction is when it's incomprehensible. To who is the next question (my usual complaint is that a junior should not be that level) and I think you're right to point out that the "who" here is everyone. We're killing a whole side of creativity and elegance while only slightly aiding another side. There's utility to this, but also a cost. I think what frustrates me most about CS is that as a community we tend to go all in on something. We went all in on VR then crypto, and now AI. We should be trying new things but it more feels like we take these sides as if they're objective and anyone not hopping on the hype train is an idiots or luddite. The way the whole industry jumps to these things just feels more like FOMO than intelligent strategy. Like making a sparkling water company an "AI first" company... its like we love solutions looking for problems
zx8080 10mo ago
That's similar to what happened in Java enterprise stack: ...wrapper and ...factory classes and all-you-can-eat abstractions that hide implementation and make engineering crazy expensive while not adding much (or anything, in most cases) to product quality. Now the same is happening in work processes with agentic systems and workflows.
karakoram 9mo ago
A career pivot sounds interesting. Any ideas or recommendations for others considering this? I have seen someone leave SWE to become a commercial pilot which was pretty cool.

jsk2600 10mo ago

What are you pivoting to?

coldpie 10mo ago
I'm also interested in hearing this. For me, I'm planning to ride out this industry for another couple years building cash until I can't stand it, then pivot to driving a city bus.
- layer8 10mo ago
  > then pivot to driving a city bus. You seem to be counting on Waymo not obsoleting that occupation. ;)
- baq 10mo ago
  Gardening and plumbing. Driving buses will be solved.
  - Buttons840 10mo ago
    Plumbing seems like a relatively popular AI-proof pivot. If AI really does start taking jobs en masse, then plumbers are going to be plentiful and cheap. What we really need is a lot more housing. So construction work is a safer pivot. But, construction work is difficult and dangerous and not something everyone can do. Also, society will collapse (apparently) if we ever make housing affordable, so maybe the powers-that-be wont allow an increase in construction work, even if there are plenty of construction workers. Who knows... interesting times.

Q6T46nT668w6i3m 10mo ago

It’s wild that programmers are willing to accept less determinism.

dahcryn 10mo ago
The good ones don't accept. Sadly there's just many more idiots out there trying to make a quick buck
- lazystar 10mo ago
  Delving a bit deeper... I've been wondering if the problem's related to the rise in H1B workers and contractors. These programmers have an extra incentive to avoid pushing back on c-suite/skip level decisions - staying out of in-office politics reduces the risk of deportation. I think companies with a higher % of engineers working with that incentive have a higher risk of losing market share in the long-term.
  - doug_durham 10mo ago
    I’ll answer that with a simple “No”. My H1B colleges are every bit as rigorous and innovative as any engineer. It is in no one’s long term interest to generate shoddy code.
    - lazystar 10mo ago
      I'm not stating the code is shoddy - I agree the quality's fine. I'm referring to the IC engineer's role in pushing back against unrealistic demands/design decisions that are passed down by the PM's and c-suite teams. Doing this can increase internal tension, but it makes the product and customer experience better in the long run. In my career, I've felt safe pushing back because I don't have to worry about moving if my pushback is poorly received.
zephen 10mo ago
There has always been a laissez-faire subset of programmers who thrive on living in the debugger, getting occasional dopamine hits every time they remove any footgun they previously placed. I cannot count the times that I've had essentially this conversation: "If x happens, then y, and z, it will crash here." "What are the odds of that happening?" "If you can even ask that question, the probability that it will occur at a customer site somewhere sometime approaches one." It's completely crazy. I've had variants on the conversation from hardware designers, too. One time, I was asked to torture a UART, since we had shipped a broken one. (I normally build stuff, but I am your go-to whitebox tester, because I hone in on things that look suspicious rather than shying away from them.) When I was asked the inevitable "Could that really happen in a customer system?" after creating a synthetic scenario where the UART and DMA together failed, my response was: "I don't know. You have two choices. Either fix it where the test passes, or prove that no customer could ever inadvertently recreate the test conditions." He fixed it, but not without a lot of grumbling.

lo_zamoyski 10mo ago

> It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. The ubiquitous adoption of LLMs for generating code is mostly a sign of bad abstraction or the absence of abstraction, not the excess of abstraction. And choosing/making the right abstraction is kind of the name of the game, right? So it's not abstraction per se that's a problem.

torben-friis 10mo ago

Our industry wants disruption, speed, delivery! Automatic code generation does that wonderfully. If we wanted safety, stability, performance, and polish, the impact of LLMs would be more limited. They have a tendency to pile up code on top of code. I think the new tech is just accelerating an already existing problem. Most tech products are already rotting, take a look at windows or iOS. I wonder what will it take for a significant turning point in this mentality.

rgreeko42 10mo ago
disruption is a code word for deregulation, and deregulation is bad for everyone except execs and investors
- rambojohnson 10mo ago
  it's sadly telling how this comment got greyed out to oblivion.
ip26 10mo ago
One possible positive outcome of all this could be sending LLMs to clean up oceans of low value tech debt. Let the humans move fast, let the machines straighten out and tidy up. The ROI of doing this is weak because of how long it takes an expensive human. But if you could clean it up more cheaply, the ROI strengthens considerably- and there’s a lot of it.

simonw 10mo ago

I think AI-assisted programming may be having the opposite effect, at least for me. I'm now incentivized to use less abstractions. Why do we code with React? It's because synchronizing state between a UI and a data model is difficult and it's easy to make mistakes, so it's worth paying the React complexity/page-weight tax in order for a "better developer experience" that allows us to build working, reliable software with less typing of code into a text editor. If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all. How often have you dropped in a big complex library like Moment.js just because you needed to convert a time from one format to another, and it would take too long to hand-write that one feature (and add tests for it to make sure it's robust)? With an LLM that's a single prompt and a couple of minutes of wait. Using LLMs to build black box abstraction layers is a choice. We can choose to have them build LESS abstraction layers for us instead.

tyre 10mo ago
For moment you an use `date-fns` and tree shake. I'd rather have LLMs build on top of proven, battle-tested production libraries than keep writing their own from scratch. You're going to fill up context with all of its re-invented wheels when it already knows how to use common options. Not to mention that testing things like this is hard. And why waste time (and context and complexity) for humans and LLMs trying to do something hard like state syncing when you can focus on something else?
- simonw 10mo ago
  Every dependency carries a cost. You are effectively outsourcing part of the future maintenance of your project to an external team. This can often be a very solid bet, but it can also occasionally backfire if the library you chose falls out of date and is no longer maintained. For this reason I lean towards fewer dependencies, and have a high bar for when a dependency is worth adding to a project. I prefer a dozen well vetted dependencies to hundreds of smaller ones that each solve a problem that I could have solved effectively without them.
  - 10mo ago

scellus 10mo ago

My work is better than it has been for decades. Now I can finally think and experiment instead of wasting my time on coding nitty-gritty detail, impossible to abstract. Last autumn was the game changer, basically Codex and later Opus 4.5; the latter is good with any decent scaffolding.

chasd00 10mo ago
I have to admit, LLMs do save a lot of typing a d associated syntax errors. If you know what you want and can spot and fix mistakes made by the LLM then they can be pretty useful. I don’t think it’s wise to use them for development if you are not knowledgeable enough in the domain and language to recognize errors or dead ends in the generated code though.

AndrewKemendo 10mo ago

Every technical person has been complaining about this for the entire history of computer programming Unless you’re writing literal memory instructions then you’re operating on between 4 and 10 levels of abstraction already as an engineer It has never been tractable for humans to program a series of switches without incredible number of abstractions The vast majority of programmers never understood how computers work to begin with

casey2 10mo ago
This is true, though the people that actually push the field forward do know enough about every level of abstraction to get the job done. Making something (very important) horrible just to rush to market can be a pretty big progress blocker. Jensen is someone I trust to understand the business side and some of those lower technical layers, so I'm not too concerned.
Trasmatta 10mo ago
People keep making this argument, but the jump to LLM driven development is such a conceptually different thing than any previous abstraction
fwip 10mo ago
And if you're writing machine code directly, you're still relying on about ten layers of abstraction that the wizards at the chip design firms have built for you.

kayo_20211030 10mo ago

Could we all just agree to stop using the term "abstraction". It's meaningless and confusing. It's cover for a multitude of sins, because it really could mean anything at all. Don't lay all the blame on the c-suite; they are what they are, and have their own view. Don't moan about the latest egregious excess of some llm. If it works for you, use it; if it doesn't, don't. But, stop whinging.

christophilus 10mo ago

What are you pivoting to?

casey2 10mo ago

So you're washing dishes now?

dandanua 10mo ago

Don't forget you are expected to deliver x10 for the same pay, "because you have the AI now".

baq 10mo ago
The system is designed to do exactly that. This is called ‘productivity increase’ and is deflationary in large dosages. Deflation sounds good until you understand where it’s coming from.

exssss 10mo ago

Out of curiosity, what did you pivot to? It sounds crazy to say this, but I've been thinking about this myself. Not for the immediate future (eg 2026), but somewhere later.

aleph_minus_one 10mo ago

> It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. No profession collectively made such a decision. Programming was always very splitted into many, many subcultures, each with their own (mutually incompatible over the whole profession) ideas what makes a good program. So, I guess rather some programmers inside some part of a Silicon Valley echo chamber in which you also live made such a decision.

teleforce 10mo ago

This whole things of AI assisted and vibe coding phenomena including the other comments remind me of this very popular post on HN that keep appearing almost every year on HN [1],[2]. [1] Don't Call Yourself A Programmer, And Other Career Advice: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... [2] Don't Call Yourself A Programmer, And Other Career Advice (2011): https://news.ycombinator.com/item?id=34095775 https://news.ycombinator.com/item?id=34095775

akulbe 10mo ago

What are you pivoting to?

godelski 10mo ago

> the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. I've usually found complaints about abstraction in programming odd because frankly, all we do is abstraction. It often seems to be used to mean /I/ don't understand, therefore we should do something more complicated and with many more lines of code that's less flexible. But this usage? I'm fully on board. Too much abstraction is when it's incomprehensible. To who is the next question (my usual complaint is that a junior should not be that level) and I think you're right to point out that the "who" here is everyone. We're killing a whole side of creativity and elegance while only slightly aiding another side. There's utility to this, but also a cost. I think what frustrates me most about CS is that as a community we tend to go all in on something. We went all in on VR then crypto, and now AI. We should be trying new things but it more feels like we take these sides as if they're objective and anyone not hopping on the hype train is an idiots or luddite. The way the whole industry jumps to these things just feels more like FOMO than intelligent strategy. Like making a sparkling water company an "AI first" company... its like we love solutions looking for problems

zx8080 10mo ago

That's similar to what happened in Java enterprise stack: ...wrapper and ...factory classes and all-you-can-eat abstractions that hide implementation and make engineering crazy expensive while not adding much (or anything, in most cases) to product quality. Now the same is happening in work processes with agentic systems and workflows.

karakoram 9mo ago

A career pivot sounds interesting. Any ideas or recommendations for others considering this? I have seen someone leave SWE to become a commercial pilot which was pretty cool.