Everyone in SWE (who got into it for the love of writing code) is experiencing this. I've been direct with my team about it being a legitimate feeling of grief and the grieving process that comes along with it. It's been helpful for folks to hear that they aren't alone in that feeling.
And also that on the other side of that grief is something new and potentially exciting, but very different than what we're all used to.
Like many, I became a SWE because I loved writing code. Ruby, in particular (whatever one thinks of its other strengths and weaknesses) can be very expressive and beautiful.
However, most code is corporate CRUD stuff. The world sort of runs on CRUD. But it's rarely particularly fun, or beautiful, or fulfilling. It tends to be pretty ugly because there's rarely time to make it beautiful. So I'm not losing much joy there.
Additionally, even with an agentic workflow, my team still thinks deeply about architecture issues. We believe that well structured code is better for bots and humans alike. So I am still exercising my engineering brain; I'm writing blueprints and supervising the bricklayers now instead of laying bricks.
Does that match your teams' experience at all? Sometimes I feel like folks on these threads are working in a parallel universe where the majority of coding tasks and somehow fulfilling and fun and not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities. Maybe people found joy in those aspects. I guess there are all types of people in the world. I mean, I'm a sicko who loves writing SQL, something that most coders seem to hate.
I've been direct with my team about it being a legitimate
feeling of grief and the grieving process that comes along
with it. It's been helpful for folks to hear that they aren't
alone in that feeling.
This is super great. God, I wish all leaders had half this much empathy! Good on you.
I am one of those weirdos that found joy in business software. The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.
I find that I struggle more with personal projects, as I tend to take things where I'm not even in the skirts of the learning curve, and consequently redo my work a few times.
> The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.
I have no idea where you work but 90% of companies are not like that. In fact, it's the opposite: filled with awful management, terrible timelines and legacy code.
Engineering had always been a nuisance to them and getting basic approval for maintenance regarding technical debt has been an uphill battle.
Wow. That was hardly ever the case in my experience in ~30 years in the industry. I enjoy(ed) what you’re describing too but… how common was this for you?
Different person but I’ve been a SWE about ten years now - my favorite work has been improving the CRUD stuff people have left behind. Like the time I took a proprietary document they were using to document their REST apis and wrote a converter to turn those into OpenAI spec compliant yaml files, taking a single tenant application and making it a secure multienant application so instead of 80 different app services we had two, coalescing all their data sources into one normalized DB. There’s a lot of work I’ve done I’m really proud of. I’ve always found myself being the “in the muck” guy fixing up and bettering legacy code, I’ve always felt that was really rewarding and interesting.
Thats badass! I like doing that kind of work, but I got very jaded about it over the years, because management generally acted as if the engineers took a shit on the conference table in the middle of a Zoom call with their most important customer whenever anybody attempted to address technical debt, as opposed to delivering more more more features. Unless it was billable agency work, in which case they’d hate it even more.
With massive amounts of effort and strong communication it was usually possible to get some tech debt time, but management acted like they were doing YOU a huge favor. It was kind of a career killer, generally.
Alternatively it was possible to get this kind of work done on my own time… but that’s a marriage killer instead of a career killer.
Sure. If you get pleasure in fixing really badly broken shite, there’s tons of opportunity for that, but no money in it. Only money in new features, which is why the codebase is what it is. I have, on rare occasion, been the fixit guy called in temporarily to fix another teams work or get it out the door: that was fun. Short lived , but fun.
It's a shame, because there is money in it. It's just (like most sensible preventative maintenance) that the financial benefits are typically delayed. And when it comes to software, they're notoriously impossible to quantify.
Generally the only way to get it done in a corpo environment (and receive any kind of thanks or glory, as opposed to just torpedoing your own career) is to let things get so bad that production stability suffers and/or the team's ability to ship features is severely impacted.
...I realize I'm basically just echoing what you said, except more verbose. I'm venting!
The fun thing is: I don't think this will change that much with AI in the mix ;)
Shitty devs without AI are slowly building BS that wants to be cleaned up.
Shitty devs with AI are much more fasterly building BS that wants to be cleaned up.
I have a similar experience as yours, just add another 10-ish years to the timeline. Literally my first job out of uni, I got to work on a legacy code base that was another 15 years older than that which had a ton of reports all built differently over time with slight variations in both code and end user output that really all wanted to be "the same" both on the code and end user side. So I slowly but surely, one user/PM requested change at a time would build out a common layer of abstractions and shared code that both made the code shared and easier to maintain (great for me!) and consistent for users (great for the PM/users).
Heck, I built a rudimentary TransactSQL parser that'd output stored procedure call graphs to graphviz and then I printed it and hung it on the wall to get through all this and having an LLM to just make a mermaid out of this in 5-ish minutes would definitively have been faster than I was ;)
With an LLM all of that would just have been faster to do but still worthwhile and useful on both levels. I.e. both code abstraction/reuse and PM/user level. Similarly there was a report that one of the devs had to actually run manually and it took him a full week, so users that wanted the report would only request it once a year-ish. When I was asked to learn how to run it from him I was appalled and just took that week to put it into a script that we ran and emailed the report out once a month automatically. They ran that report manually like that for like 10 years prior to that :mindblown:
None of this is an "AI thing". It's a good dev vs. not so good dev thing. And none of it really has to do with coding as in "writing source code" as much as "solving problems for humans" somehow and the "language" you do that in changes over time. If you're the guy that's tied up with the particular language: yeah LLMs are gonna eat your lunch. If you're the problem solver type that uses whatever tools they have available, you're still in demand.
About 80% of the time. It wasn't all about setting a new foundation, even making the existing one solid enough so you can have time to refactor the cruft was enjoyable. I had more trouble in my youth, as I didn't understand why the business didn't change to accommodate my 'masterpieces', and I'd like to think I started enjoying it more as I became wiser.
Disclaimer: I had to take an opportunity at management in cybersecurity, and haven't coded in about five years. It helps a lot when talking to developers about risk mitigation, though.
> The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.
The nicest thing was when you nailed down the architecture and then you are mostly twiddling your thumbs while waiting for the PM guys to have the next feature idea. Maintenance and bug fixing is a breeze.
One of the fun things to do would be to use the 8 hrs of work to spend about 4-5 hrs working on deliverables, which was usually sufficient to exceed expectations, using 2-3 of the remaining hours (I’d keep 1-2 hrs for myself), to make significant architectural improvements.
I’d bring in an improvement every 6 months or so and suddenly the app would get significantly better and I’d get credit for it.
Sorry for the delay. Mostly midrange (AS/400) consulting at manufacturing plants, then full time jobs at a heavy machine dealership, and a bank. Changed to PC development after about 15 years of that, then management, and it hasn't been the same after that, ha ha.
I think the technical freedom plays a big part, not because you're chasing the shiniest, but because you're choosing the tools that will hopefully outlast you. One of my former employers was 'modernizing' their IBM i (former AS/400) systems by porting them to Java and Windows Servers, and they were having all kinds of problems. Couldn't even get the EBCDIC to Unicode conversion quite right. I was lucky not to be there anymore.
I smile whenever I see EBCDIC, probably because I never had to deal with it.
But I'm sorta old and some of my school's texts were outdated so they had programming examples and explanatory text that treated EBCDIC on equal footing with ASCII.
So unlike anybody who dealt with EBCDIC conversions in the wild, seeing that acronym actually takes me back to happier days!
> not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities.
Those are the parts the LLM is bad at. The 1% of stuff that was interesting was worth looking forward to.
I’m unconvinced about architecture mattering much. I used to think that, but these days I’m leaning towards it being the product of a problem we don’t have anymore. Architecture used to be dangerous and time-consuming to redo. If an AI can do that safely for $100 or $1000 in tokens (one day), that ROI is maybe negative
In a big production codebase with lots of active customers and data, architecture changes still feel pretty difficult even with LLMs accelerating them by an order of magnitude — migrating and backfilling data and all of that. That’s more complex than pointing Claude at a repo and saying “rewrite this in Rust.”
I guess you’re right, though - what is the ROI of keeping the architecture clean? It certainly saves time and money later, but it’s unclear if it’s a net win.
(It’s of course also significant to note that the upfront work of figuring out the right architecture and keeping the code clean has also been correspondingly reduced as well. Both sides of the equation are affected…)
The industry never really figured out a way to reliably answer this question in the pre-LLM days either, so… I suspect it will continue to be hard to determine.
in my experience it takes more than a day to sufficiently migrate bad architecture to a good one. like, many more days than it took to vibe the original implementation. having the prototype is good to understand what you want, but then going back and rebuilding it properly is a longer task. which is fine.
I think this is not "parallel universe". Selection bias: people who love to code often choose non trivial frontier work. They tend to grirf about agentic workflow the most. Myself included.
I got into SWE because I like solving problems. I like solving problems using code. I also like solving problems using AI.
I have very mixed feelings.
- AI lets me plough through issues which previously would
require debugging, troubleshooting, googling, stackoverflow
- my coding abilities are starting to atrophy
- not having to deal with low-level language quirks is nice (parameter differences of subString in C# vs Java).
- but I'm seeing the same as OP: when working on a team, the sense of ownership and community is gone. You have AI un-AI-speak for you to properly read the Jira ticket another dev created using AI. Pull requests are echo chambers between the AI used to create it, review bots, other devs using AI for PR reviews manually.
- there's little denying that we devs are feeding the very machine that will replace us
There's a lot of code I never wanted to be an expert on. I might care about an algorithm. I might care about the UX. There are other things I might let an AI tackle because I don't care about them.
That is a problem though with AI currently. E.g. I've found a severe issue with Claude Code and prose writing when trying to make an explainer site. Instead of "plain" english it likes to use "flowery" phrases and "punchy" statements. This forces the user to spend extra time thinking about it.
And code comments are terrible. It can use 3 paragraphs to describe something when only one sentence is enough. Then further agents (or humans) have to waste their context window to figure out what the "riddle-ly" worded sentences mean.
But the things you care the most about, the AI doesn't unless you tell it to care. And even then, you have to be very careful because it acts more like a contractor with the potential to stop in the middle of a project (lack of tokens) and leave it in a very bad state until it's complete.
Or worse, it forgets what you want and does it's own thing for a while until you remind it.
We were always replacing ourselves: Every "reusable" function or class or library you ever wrote represents lines of code won't get paid to write again. Every compiler takes jobs away from assembly coders.
The looming thing today is qualitatively different, because it's not formalizing something to reliably mass-produce.
> We were always replacing ourselves: Every "reusable" function or class or library you ever wrote represents lines of code won't get paid to write again
In theory, but not in practice. Instead, somehow we ended up writing essentially the same app over and and over, usually without reusing libs. You know because this time we'll use vue, or svelte, or phoenix, or htmx, or go, because this time we actually know what we're doing. so gotta start from the ground up and figure out how to store a row in a db as if we haven't done the same thing a million times before.
And that all under one roof. Now multiple that by thousands of roofs.
At least the devs were having fun and making good money writing all that code.
It’s a point that isn’t made often. AI is mostly saying the quiet part out loud.
The big money valley bros figured it out just before they embraced regressive conservatism for their politics. There’s a reason we went from massages and pet daycare to rentier agriculture executive style management of the peons.
Obviously this is not true for every SWE. A lot of people feel liberated now that the burden of actually writing the code is being replaced by molding it through the interaction with AI. I see people that struggle because they've identified with the writing code part a lot and that's gone now that the machine is doing it, I bet that's hard.
Yes. The people that didn't enjoy coding say that.
AI is great enabler for stuff that you don't want to be good at, it cut a ton of chore type jobs out of my workflow, but for stuff you do want to get better and care for, it's both joy killer, and if you're not careful you will only learn how to prompt, not how the stuff works.
I enjoy coding deeply, and my feelings are not that simple.
I love code as a craft. I love spending time designing the perfect abstraction. I love seeing it come together in the implementation stage. I love the troubleshooting process and the understanding that comes when you finally engage with the root cause of the issue. I love all of this so much that I ship little, all my time is spent in process.
I also love code as a tool. I love working tirelessly towards describing a goal and then watching it come to completion. I love knowing my projects consume terabytes of data and spit out useful results. I love seeing my assumptions on the outcome proved right or wrong.
Now I can do the latter without the former, and it leaves me deeply conflicted. A large part of me is more excited than I've ever been. Another part of me is quite sad, and this is unfortunately the part where my ego lives. For now, I keep it in check by asking the LLM to describe the pros/cons of alternative architectures. That way I stay learning about the products I create.
As I like to tell others: before my job was 70% architecture & patterns and 30% coding & algorithms. Now my job is 100% architecture & patterns. While I still spend the majority of my time on architecture & patterns, and while I enjoy this aspect more than coding and algorithms, I am still working a "different job" than I was when my hands steered the code completely.
People say stuff like this all the time, but what does it actually mean? Like, isn’t the details of the code, at least at some level, part of the “architecture”? I’m so curious about what people who say this are actually making where they just sit around all day and dream up new lego structures without ever having to look at any of the bricks.
The bricks are pretty standardized? I mean, you're not reinventing singly-linked and doubly-linked lists from first principles no? When I program I think in terms of data structures, data hierarchy, and algorithms. I want to use a queue here, a lock here, a double linked list there, an array list over here, maybe a hash dictionary with linked-list chaining for collisions. It's only a few times in my career that I built a bespoke data structure from the ground up and they were all for very hot loops and one case involved working on a lock-free algorithm.
I've done a lot of functional coding in the past (in academia, in Haskell as a hobby, and Scala for a unicorn where I was an early hire.) This probably affects how I think. But I find it quite natural to organize my code this way. After all the fundamental data structures and the hierarchies relating them are what often determine core properties of your programs such as being CPU, Memory, or IO bound.
I also work as a pretty senior engineer and my tasks before agents were usually about leading a team to implement something. I would often do the v0 implementation to make sure we met customer requirements and then take a step back and help the team scale the service up. These days the team is a lot smaller and maybe just another engineer; the agents make up the rest.
Surprisingly enough, before I led teams I wrote software by hand from tickets the way any other mid level software engineer did. And also quite oddly, when I contribute to open source I still just write it by hand, from scratch, and am at the mercy of the maintainers who give my patch feedback or reject it. So somehow, I know it's crazy but somehow, I am able to use my experiences to weigh in on this.
I may have it wrong, but I think 'architecture' can include relatively low-level details: you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
> you could even design a program down to the level of what each function does, and still only be doing 'architecture', not coding, so long as you're not writing the code or specifying exactly how it should work.
So it all wishes and prayers? no wonder software quality is down.
Software is built on wishes and prayers. Programmers don't ship pixels to be installed in monitors, nor do we (mostly) work with compiler internals. We write a detailed set of instructions and hope that a bunch of systems we don't necessarily comprehend follow them well enough to get the intended results. It works because some folks got together and wrote down their wishes and prayers so good that others were able to understand and follow them later.
We can be curious about how others approach problems or we can try to find the faults. I feel like this comment is a great example of jumping to the negativity rather than trying to understand a different perspective.
I ultimately think learning how other people structure programs is an enriching task and not one that should cause you to dig in and discredit differently-shaped approaches.
> I ultimately think learning how other people structure programs is an enriching task
Learning from others is great. But there should be actually something to learn. When someone says
so long as you're not writing the code or specifying exactly how it should work.
It means they’re not creating software. They’re just playing with randomly generating something.
A software is the recipe for some process. The code is the formal version where everything is exhaustively specified. Not thinking about the code means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
What's the point of leaving a comment if you're not going to change your mind and they're not going to change theirs? Is it just to advocate for your position?
As you're being very vague, I write more about my opinion, which is based on a guess of what your approach. Basically the Q of P imply Q where P is the guess (and P is the thing you're being vague). I'd like if you can prove that either P is not valid or that there's a different Q that exists.
Axiom: A software is the recipe for some process. The code is the formal version where everything is exhaustively specified.
P: Not thinking about the code
Q: means you’ve stopped thinking about the software somewhere and no longer can say if it’s ok or not.
To further go with my point, it's like explaining how to make a cake and you said that instead of a recipe, it's fine to provide just the name of the ingredients and a general instruction like: mix everything together and put it in the oven.
When we write code we sit atop a tower of abstractions. You're trusting your language's stdlib, its compilers, the syscalls offered by your kernel, the virtual memory implementation of the kernel. Your coworkers wrote code that you only interact with as a library or over an API of some sort. Let's not even think about the lossy abstraction of taking the ultimate bytecode generated and actually mapping it to the actual CPU pipeline that's running the code.
Modern computing is an exercise in trusting abstractions and then zooming into the abstractions and figuring out what went wrong when something breaks. Just because I wrote a web route doesn't mean I've audited the code behind the web framework, the event loop, the HTTP implementation, the TCP implementation and so forth. By your argument then I've already stopped thinking about my software and can't tell you if it's okay or not.
I'm sympathetic to both the perspective of sadness from the loss of hand coding and the perspective of joy from working at a higher level of abstraction, despite its costs in understanding. It actually seems very simple to me to hold both perspectives within me.
The thing you’re forgot to mention is that the trust in the layers below your code is not blind. Sure you treat it as axiomatic foundation. But when something breaks and you’re sure it’s not about your code, then you can investigate the actual part that is wrong in that foundation.
Once that’s done, there’s a matter of accountability where you can report the issue to the people responsible for that. Then because they know their own code they can repeat what you did and try to find where things went wrong.
That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
I never care about code, whether you wrote the majority of it or it’s just a glue that hold several library. What I care about is that the semantics of that module that I interact or build upon can be trusted, and when something wrong is an accident and not a daily event.
Even when you’re writing an application and not a library or a platform, you’re not free to write whatever. Your users depends on you, and themselves may have clients that depends on them. Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
> That chain of accountability is the main issue there. We still have tower of abstraction, but no one knows about their layers. Accountability is lost and with it the trust is gone.
Right this is the main difference between our viewpoints. I don't work on completely open systems. A lot of my life I've worked on closed platforms, cloud runtimes, a mix of work that's been in my control and out of my control. I've filed my share of AWS tickets but ultimately most of them ended up not fixed by AWS. I've made peace with not having accountability for layers of the stack and am comfortable assuming that there are bugs on the foundation that I have to work around.
> Being cavalier about what you write is just recklessness and in any other (real in some countries) type of engineering, it would be labelled as malpractice.
I just design the fun part and let LLM deal with the chores.
For example recently I did tiny little hobby project, taking metrics of ESPHome/homeassistant MQTT and pushing it into prometheus. Coded the main parts, told LLM to do the boring part of setting up test suite, guided it thru making tests, it worked fine, tested it, then told LLM to do another boring task, taking all the datatypes it support and unit conversions (which is hundreds).
I got to do all the fun design stuff, but had code review assistant that also did all the boring tasks.
It's like making animation but you only have to make keyframes and initial coloring, with AI filling the blanks, just cutting out the tedium
> and if you're not careful you will only learn how to prompt, not how the stuff works.
I’ve been coding over four decades and it is clear to me that most programmers don’t know how the stuff works, and not just script kiddies but some PhDs I worked with.
For those who want to know how it works, LLMs are massive enablers. I’ve written so many debugging and inspection tools with an LLM; had a model explain the assembly language produced; had rubber duck conversations with it. I’m having such fun tbh.
So are you gonna write assembly language now? Or have the LLM do it for you?
You are aware that the LLM (or anything/anyone) explaining stuff to you is just going to atrophy if you don't use it, so maybe you weren't actually learning but just scratching a curiosity itch.
I’ve shipped products I wrote entirely in assembly back in the 90s. I don’t mind that I don’t remember most of it. I am very aware that expertise is a muscle that requires constant training.
I think the benefit is that now I get to choose what I want to focus my limited attention on; from a much broader range of subjects; with expert knowledge on tap. For sure, some of it was just scratching an itch. I didn’t waste much time getting to that point before I could go down another interesting rabbit hole. It’s just much more fun!
That's a very simplistic view. I'm very good at writing tests and I'm happy to offload writing tests to LLMs, as long as they follow the structure I've provided.
You're saying that I must not be good in writing tests, irregardless on how I feel about test writing.
> A lot of people feel liberated now that the burden of actually writing the code is being replaced by molding it through the interaction with AI.
I venture to say that this number is small. Most SWEs get into it because they don't view writing code as a "burden".
The people who are "liberated" aren't the SWEs, it's the people higher up the ladder than the SWEs, who can't or don't want to be bothered with coding anymore. For them, managing a fleet of agents is easier than managing a group of SWEs.
Most of the code I was paid to write is a burden. I've spent far more hours writing generic CRUD apps, debugging overly complex javascript tooling (almost always out of date) and other tedious grunt work.
I don't think it's fair to say that all SWEs swing one way or the other. I absolutely love the fact that I will never have to waste time debugging cargo culted, trendy libraries ever again while I am also sad I'll also never to get hand write elegant implementations of interesting problems ever again either (unless for fun).
I would be happy to keep writing code but I'm also happy to be liberated from the type of code I was often paid to write.
For me typing out code was always the annoying part. The fun comes from fixing problems, optimizing for speed, making the UX flow better and visuals look nice, all things that are on the level of software not code.
Agents help you bang out good code faster if you know how to use them. My relationship to Claude and DeepSeek is somewhere between an IDE, a coworker and a friend (I still have real friends don't worry).
I don't treat it as a world changing magic wand that fundamentally changes the way everything works. It's more like a fast forward button that lets me skip the boring part in exchange for some hand holding. No more dealing with syntax errors or finding trivial bugs.
> For me typing out code was always the annoying part. The fun comes from fixing problems, optimizing for speed, making the UX flow better and visuals look nice, all things that are on the level of software not code.
This always read like
Writing sentences was the annoying part. The fun come from sharing ideas, optimizing for brevity, making the rhythm flow better and words more impactful, all things that are on the level of communication, and not grammar.
Then you start wondering about the actual level of education of the person and their claims about writing a nice novel.
Code is formal writing. Expressing an idea in such formal forms means you have thought exhaustively about the evolution of the algorithm/process. If you’ve not done that, you can’t guarantee the correctness of that algorithm/process. Is it just toying around with an idea of software?
sure, it works like that if you're still the one doing the thinking and figuring out how to do things, and just using agents for the boring templating and to translate your pseudocode into syntax-free real code, without you having to look up the arguments for every call that you haven't used recently, etc.
but most SWEs are being pushed to delegate the _thinking_ to agents.
so instead of "here's a solution to load this page faster that I came up with: X. Implement this in JS", which is along the lines of what you describe, most people are doing "this page needs to load faster, what's the best way to do that?" claude: "X". "OK, implement X." What fun is that? What's the point of developing skills and acquiring knowledge if you can't use them anymore. that's the loss.
If all you care about is having pages that load fast, then yeah, agents are great. If you care about being the architect who figured out how to load pages faster, then agents take the wind out of your sails.
Your example is great because I literally just did this:
"you need to improve performance of the graph especially rollover and highlighting it's VERY Slow there are too many updates"
In the past I would have cracked open a profiler, and spent a couple days probably tuning this thing. I probably would have gotten a big dopamine hit and felt really accomplished when I finally got buttery smooth performance.
But I'm happy to delegate this task to the agent, because this is one step in 1000 steps I have to accomplish, and no I can't just tell the agent to accomplish them all from the start because I don't know where it's going. I'm very very happy I don't have to waste a day making the graph load faster, because I can get back to my real work, which is not making graphs load faster.
At the end of the day, solving that problem will make someone's use of my project a little better, but it's not adding value to anyone's life -- that's what the project is (supposed to be) for. In the past, it was those little problems and 1000s more like them that would derail a large project. Today, they are mere bumps in the road, so the large project has a better chance to come to fruition.
in this context, those are really 2 different things. what people are lamenting is the fact that "I built a career on building these skills because it's something I care about doing with my life, and now I'm being relegated to QA at best, or replaced at worst". That's completely different than, "I can now get my personal project out faster, or maybe create 10 personal projects, and can have the agent take care of the parts of the project I don't really care about doing (like improving graph performance) and focus instead on the overall design of the project, more features, etc.".
It's like going through med school and residency to become a doctor, and instead of practicing medicine, you're feeding prompts into an AI and passing on the responses. Sure, on you might appreciate not having to field medical questions from all your friends and relatives ("personal project"), but that's not your career.
My day job, but I am not a software developer (I'm a teacher), although I was in the past.
I can appreciate that perspective, but at the same time: it's a job, the whole arrangement is you sign away your autonomy, you do what you're told, and people were paid more in one year than I've made in 5 for this. Now the balance has been disrupted, and that's a shame, but the gravy train can't go forever. Moreover, this particular job, software developer, has changed fundamentally again and again over the years, and those changes definitely disrupted people's careers, so although the blast radius is significant, this too shall pass.
And we're not exactly talking about doctor-level of training here, it was only about a dozen years ago that it was very fashionable to land a 6-figure salary at a top Silicon Valley tech firm after having only attended a bootcamp, for a job that was characterized as being a "code monkey". The whole thesis of the "Theil Fellowship" was that the job was doable without any formal education at all. At my institution, the CS major was the most popular because it was the shortest path to the largest salary. Now that equation has changed, no one wants to be a CS major, enrollment is through the floor.
> you're feeding prompts into an AI and passing on the responses.
Okay but is the job writing code or building software? A lot of people seem to think the job was writing code, and that's what they liked about it, but it was always the case that if you like your job it's not going to pay well. That software engineers were paid so well to do something they love is an aberration, not something to expect forever.
As a teacher, I definitely understand this. I love my job, doesn't pay well, and it's also changed fundamentally as well in the last year. So I empathize -- I used to grade student papers which was rewarding; then all of a sudden I was grading LLM output, which is not. A lot of my colleagues have complained endlessly about this, have made it their job to become the LLM "police", or have quit the profession entirely because like you said it's not how they started in this field. It's bleak.
But you can also adapt to the times. We just completed a module where students use AI to create games in Lua, and they made the best games I've seen in years, each one different and unique and fun. Before the class was "we'll spend 4 weeks and hopefully we'll get to animations if we're lucky". Now the final projects are all animated with interesting gameplay mechanics, graphics, animations, and they're all different despite them each using AI. I like this situation better.
People who hated coding, technology, problem solving and only were in it for the money love managing a bunch of agents. Unfortunately, it seems like a lot of them were in technology. I hope agents quickly become good enough to completely commoditize any supposed function they perform, and forces them to leave this industry.
This is an extremely “all or nothing” take. I love computers and started programming in elementary school. I am having more fun now building software than I can remember.
I happen to love the process of building software by coordinating agents. It’s an addictive form of flow state that I enjoy a great deal - similar to the flow state I get playing real time strategy games like Age of Empires. It’s a different kind of flow state than writing code, for sure.
But to say that the only people who enjoy building software in this new way are those who hated coding, technology, or problem solving is simply untrue.
I’m glad you mentioned flow state because that’s exactly the high I’m trying to chase with AI and why I like it despite programming since elementary school as well.
I realized I most enjoy higher level problem solving but don’t really enjoy implementation. Like I enjoy algorithms, data structures, memory allocation strategies, SIMD optimization, etc. But writing the code, and debugging it is tedious and takes me out of flow.
And if I’m really interested in the project itself then the algorithms take a back seat and I enjoy the even higher level problem solving of building a cool project.
I don’t think it makes you lesser to enjoy these things more than literally banging out code, and hunting down bugs. Perhaps I’ve written enough code that I don’t find the same joy in that. Who knows.
You can love technology and still have thought that coding was a required path to get to technology and not the ends unto itself.
If someone loves building technology products that doesn't mean they were "only in it for the money". Beyond just being disparaging for no reason, you're missing the path out of the depression-pit here.
It’s not the act of coding, you have to really hate problem solving, to love managing agents. Such people are only in it for the money, it may sound disparaging but it’s just true.
If tech paid less, say minimum wage, they would all leave and none of them would ever tinker around anything in their free time. I’m not depressed, I’m just disappointed by how many folks are like that in this industry I loved.
There are infinite problems and agents help us solve problems faster. Sure they're not coding puzzles, they're actual problems actual human beings have, but they're still problems. Id way rather help a school district track its roster properly than argue with eslint. I'd rather get a rocket to the moon than triage garbage collection quirks too.
You're certainly welcome to miss what coding was, but being rude to engineers who are trying to build businesses is just as ridiculous and entitled as this article is.
It's funny how people produce tons of code they can't even read and somehow feel like they "solved the problem". Do you feel like you built the shed when you hire carpenter and ask him to do it..?
And why school district need you when any highschooler can produce similar code..?
If agent did all the technical work of sending a rocket to the moon, and all that was left for me was deciding whether a rocket to the moon should be built or one to mars, which is better for our “customers” and I actually enjoyed that then I would be honest and say I was never into technology, which is completely fine, majority of humanity isn’t into it.
I don’t need to see why you feel the desperate need to larp as a technologist when you’re happy with letting an agent solve all the technical problems.
You only think it is rude because you have tied your identity to being a technologist when you are not, I’m just saying it like it is.
> I don’t need to see why you feel the desperate need to larp as a technologist when you’re happy with letting an agent solve all the technical problems.
This is a false comparison. Agents cannot solve all the technical problems, so the entire statement falls apart.
What you and I are saying is synonymous. I’m simply reusing language that the post I’m responding to used. And also de-glamorizing/de-romanticizing things a bit, sure.
And given that fast food is the pinnacle of sustenance as a product and Hollywood has been content-brained since 1977, sure!
I’ve coded for 30 years. But I’ve always been motivated by outcome, imagination, intuition, & speculation. Coding was always a means to an end not the end itself. This is the funnest I’ve ever had creating software.
You can feel free to cope by inventing imaginary bad guys. But the reality is that there are a wide variety of reasons people coded by hand. And people that are different than you aren’t somehow inferior or bad.
I love writing code, but I don't love every single part of writing code. In particular, I really disliked getting stuck on some irrelevant detail, some mysterious error that had nothing to do with my code (dep issues, OS quirks, silent changes, auth failures, researching alternatives), and spinning my tires, unable to work on what I wanted to accomplish. Often I never made it through the far side; I've got a project directory littered with half-finished projects.
Having an AI to figure all that junk out for me so I can focus on the thing I want to build is fantastic. I worry about losing the grip I still have, but for now I've lost some things I loved (a lot of actual code-writing, solving nice straightforward problems), but gained what might as well be superpowers to help with some real shortcomings I had. It's been a net-positive trade for me so far.
And none of my personal projects have made me rich yet...
I got into software later in life because I wanted to be able to send my kids to college, have healthcare and not destroy my body by 50. Up until my 40s I was a landscaper who had been an amateur programmer and technologist since my teens. I worked really, really hard to get where I am. I went to a bootcamp 5 nights a week for a year after breaking my back all day at my “real job”, while also taking care of a wife and two kids.
I enjoy what I do but I confess to being “in technology” because I need to earn a living not because it’s some sort of passion project. I think it’s pretty horrible to wish us all out of job so you can feel superior again.
Your response here says a lot about who you are as a person. Maybe it's time to step away from the keyboard and do some self-reflection and growing up.
I wasn't "attacking your comment", just trying to get you to relate to me as a human being. But I should've known that would be a futile exercise.
I'm good at my job, I like what I do and I work hard six years into my career. I just don't go home at night and do it as a hobby too. I know there are people like you would like to see me kicked out of the clubhouse for having needs and pursuing a career in one of the few middle class jobs left that pays a living wage. Sorry I'm not cool enough for you.
Stop acting like an asshole to people on HN. These comments are absolutely not cool here. We've had to ask you before to observe the guidelines, and these comments in this thread are worse than ever. If you keep up this kind of activity, we'll have to ban the account. https://news.ycombinator.com/newsguidelines.html
Why did you expand it from what he said? I love technology, I enjoy being able to solve problems with technology and coding. I've always felt neutral about the actual act of coding, it was always just a means to the end and now I love that I can do more problem solving in less time and with less toil (from my view). But I guess I was just in it for the money.
You've been quite rude in this thread, so I'll just say that I'm glad you were able to get paid for years for your hobby of coding. For the organization paying you, that was only ever a means to an end of solving larger organization problems that you probably never bothered to understand because you just loved the thrills you experienced writing code.
Most organizational goals for tech are just horrible for society. What is FAANG anymore but monopolizing your attention and time, and selling targeted ads, even Apple has gone into that full swing. I frankly worry about the people who actually care deeply about such organizational goals,
At least I’m honest, I never cared for what my company does, I only liked the interesting technical problems it let me solve, and the high salarye it gave me, now I can only thank it for its high salary.
> People who hated coding, technology, problem solving and only were in it for the money love managing a bunch of agents.
Why do they have to hate coding, technology and problem solving, that makes no sense. They just use coding agents to write the code for them to use technology and solve problem.
FWIW I hate huge chunks of the industry + its inhabitants and am somewhat happy that my GPU can replace a significant amount of interactions with it and them.
Let's not forget that there is this silver lining of the tech.
We can be free[1].
__
[1] Requiring a one-time payment of about $200000 + a small gas turbine
Totally, I can't quite imagine an AI automating my use of AI tough, how it would infer what prompt I would use at any given time, the problem space is infinite. Am I adding another *arr app to my stack, are we building a SPA, a home automation plugin, whatever. These are things that I want to do and AI helps with that.
In the corporate setting I think though it won't take a lot of time to reduce the layers and number of people that are required to run a software company. Either one becomes a more general work manager or obsolete I guess.
It is remarkable to me how few people seem to understand it is a much smaller step for AI-generated software to kill the need for companies of idea men than it was for them to kill the need for people writing code.
All of your potential customers are just going to vibecode their own software. In many cases they won't even realize that the software they vibecoded even exists as it will just be an invisible tool the LLM built for itself to reproduce a similar solution to a similar prompt over and over.
Once AI flattens out any company enough, the company itself no longer needs to exist, it can trivially be replaced by the model providers. Companies exist to be collections of skilled people with a common goal. When you don't need that, you don't need companies. The agents can work for your customer instead of you and nothing changes except who gets paid (not you).
There's a ton of magical thinking out there where people seem to assume AI will progress right up to the point where it is maximally beneficial to their job without replacing them. Keep huffing that copium, folks.
> There's a ton of magical thinking out there where people seem to assume AI will progress right up to the point where it is maximally beneficial to their job without replacing them.
I've commented previously that there will be much more political interest in AI causing unemployment when the first CEOs are replaced.
That's going to happen. It's part of the "creative destruction" of capitalism.
If AIs maximize shareholder value better than some CEOs, those CEOs are toast.
They either get replaced in the same organization, or a new company arises and crushes them.
I don't think that's ever going to happen when models still hallucinate and prompt-refuse, especially since one of the two SOTA model makers insists on aligning their models toward a progressive ideology.
Just imagine what would happen if JP Morgan did this and the model decided it needs to dump their position in AI data centers. Or maybe it's a health insurance company that fires all of the claim deniers for being unaligned with Dario's ethics.
> There's a ton of magical thinking out there where people seem to assume AI will progress right up to the point where it is maximally beneficial to their job without replacing them. Keep huffing that copium, folks.
Because you are singularly right about the issue? Have some intellectual modesty, brother.
I think it's fair to expect tha AI capabilities will more likely end up far over or under that magic threshold than close to it. Given the way that technology develops, it's probably going to be over.
Its nice to know others feel this way. I do feel some kind of despair when I think about the kind of work I used to do even just a year ago compared to now. A coworker of mine took FMLA recently to figure out what they want to do next because they no longer feel even the slightest fulfillment from swe.
> And also that on the other side of that grief is something new and potentially exciting
Well, no, for a lot of us, there really is no other side. Slop farming is not software engineering and it never will be; scribbling some Markdown that begs agents to omit bugs is not equivalent to using high-level languages with thoughtful abstractions to directly define program behavior. I didn't want to be a manager when I worked in the industry and I certainly don't want to be one now. Moreover, it's downright offensive for a purported expert to defer their expertise to a SAAS black box.
On the bright side, we will probably (eventually) self-segregate into communities that code however they want and leave the other side the fuck alone.
> Well, no, for a lot of us, there really is no other side. Slop farming is not software engineering and it never will be; scribbling some Markdown that begs agents to omit bugs is not equivalent to using high-level languages with thoughtful abstractions to directly define program behavior.
Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?
> Moreover, it's downright offensive for a purported expert to defer their expertise to a SAAS black box.
With programming, it's just the opposite, though.
Programmers work with abstractions. Understanding the full system down to how atoms work is too much to think of when e.g. writing an API handler. So instead you work with modules and their interfaces.
Pre-LLM, if you need some task done, you wouldn't write it all out yourself if there was some external package which did the work for you.
Of course, when using an LLM, you don't need to surrender your ability to think about the problem and solution.
What is an abstraction? An abstraction is far more than a black box. From a previous comment:
> High-level programming languages use well-defined, limited syntax to encode program behavior in a deterministic way. Compilers translate these directions into programs that should have identical behavior between compiler runs and between different compilers. (If they don't, that's a compiler bug, or else an artifact of UB.) This means you can structurally and provably rely on the high-level programming layer without worrying about what's underneath: the assembly is abstracted away. You also get the massive benefit of being able to tweak and improve the assembly layer independently of the programming language layer, so long as the contract between language and compiler is not violated.
> If AI is a "layer of abstraction," so is working with a bunch of contractors to make your app. The definition is broadened to the point of absurdity. (Solely: "I don't have to think about code anymore," which only touches on the most superficial aspect of an abstraction.)
With a good high-level abstraction, I can mostly think on the level of the abstraction, but I can also dive down through the layers and figure out what's actually going on in each one.
> Would you look at a piece of code elegantly using high-level abstractions to model some problem written by a human and go "see, look, code is beautiful"... and then look at the exact same code written by an LLM and say "this is slop"?
Using is one thing; inventing is another. I have seen no evidence that LLMs have the capacity to discover and leverage new abstractions. To me, that's the most exciting part of programming: finding ways to reify powerful concepts and then turn complex tasks into simple ones, ad infinitum.
Interesting take and I certainly agree that lots of people think that way.
In my case I had prior experience with tech support and I saw lots of people struggling to use computers and it's interfaces.
So my joy comes equally from coding or seeing people relieved that their problems were solved.
With that mindset that I'm able to fly with Claude or codex.
And even doing my comp sci more than a decade ago many professors told that I should worry more about the outcomes and what problems I'm solving, instead of building this life game around coding only. So I'm grateful for them.
Maybe that can help other people getting out of this dread feeling whenever they are using A?
My frustrations changed, nonetheless, with AI. When it forgets cases that the LLM session and I forgot to cover, that for me is pretty obvious if I had or gave more time to evaluate and review things.
This week I realized that running a separate session and asking dumb questions about the plans and recent pull requests helps grounding again.
I have to agree, but I think some people find the joy in finding their solutions in code rather than from code…meaning that for some it is the puzzle solving that is their interest. That can be rather hard to find an analog for, especially if coding is the skill they are good at.
The lack of AI mental model between conversations or even within the conversation is a definite frustration. “No, I didn’t just decide to entirely change everything I’ve planned based on one ambiguous word…”
Your use of a separate session for q&a is actually something I find interesting in the new Granite Switch architecture’s KV Cache Normalization, where the kv cache is essentially frozen while the model performs certain other tasks in order to prevent the mental ‘conversation’ from getting polluted. However, I’m also assuming what you mean by “helps grounding” is that it helps keep the agent grounded in the context by not introducing a bunch of external information, which is certainly beneficial.
The other side is management, instead of being team leader for an offshoring team, which at least were human, those that manage to keep their jobs will be a robot manager.
I certainly did not come to computing to be a manager, in fact I already had that role and freely downgraded myself.
Of course this does not undo any grief, dismiss it, or better their situation:
I don't know if it helps, but they should know that for every one of them that experiences this grief, it brings joy to ten other people that are now able to do things (make vibe-coded programs) that used to be out of reach for them.
We aren't suddenly seeing 10x the software output that these 10 joyful people are producing. I think it's more likely that 10x people are suddenly trying to figure out a way to low-effort scam money with AI. And a few of those people have teamed up with VC's to make AI products to scrape the bottom of the pond for desperate suckers looking to scam money. There's 10x the headaches for existing projects that suddenly have to deal with low-effort bugreps from people looking to show that they are now "expert software engineers" because they can write "go find the bugs in Project X" and an AI will possibly do that.
There are some interesting things being built by AI, but 10x the number of joyful software engineers ain't it.
Not everyone is going to publish their creations, not everyone is on HN, and not everyone on HN is going to shout from the rooftops about how they are in that larger group of newly-enabled people.
Every new technology is going to also enable bad people, just like the Internet enabled scammers, it enabled a lot more people to be more productive.
But are we actually seeing those results or are people just burning 10x more money?
What I'm not seeing is news promoting how we're suddenly doing 10x better in any aspect of our daily lives, nor 6x or 4x or even 2x better. You'd think if we were suddenly getting 10x more productive, even if it was never published in the news, we'd see something, anything that affected our lives in a positive manner.
We're not.
Or at least, I'm not. And a lot of other people seem to be in the same boat.
I think you're 'putting words in my mouth'. I didn't say that people were becoming 10x better or more productive, just that there are 10x more people being enabled by AI versus programmers who see AI as destroying their jobs.
That just makes it feel like I wasted a lot of time. I spent years eschewing social gatherings, foregoing other opportunities, and depriving myself of things I enjoy, to cultivate a set of skills. Now I feel like they are rapidly becoming largely irrelevant (vuln hunting, kind of on the leading edge of ai displacement, not sure bug bounties as we currently know them will exist in five years time). What's more I don't feel like I'm positioned to remain employed in the field. I didn't expect my status or stability to be thrown into jeopardy so rapidly. I wish I were as selfless as you. I'm not sure many people are, maybe the world would be a kinder place if they were
All this supposed fun, is always something fairly simple that would take maybe a hundred or thousand hours of practice to build, it was never out of reach of them, they just felt they didn’t have the time or motivation to build that skill. (even a 1000 hour project can be done in 6 months outside of work time) Now they don’t need it. If there is any fun in this, it is an extremely shallow, garden variety sort of fun that comes from consuming content. They will never experience the deep fun that comes from being immersed creatively in a project, which I would trade anytime for something shallow.
that probably makes it feel even worse for most people
imagine spending years to develop mastery of something that anyone can do now? For example, sitting your ass down in college, debugging lines of code on a Saturday night while people are out partying? It's fun to do, sure, but there's still a huge opportunity cost.
It's easy to say that such people are prideful, arrogant, only cares about being better than others, but I think such a feeling sucks for 99% of the population that are not siddharthas.
Doubly so when you consider the history of every previous advance that was supposed to free people from the tyranny of needing a developer to make software, from COBOL forward. Some people indeed made their own applications, while everyone else rejected doing that and preferred to pay someone to do it for them.
Comparative advantage ("Is this the best use of my time?") is a real thing, and the human time to make and maintain non-trivial software will always itself be real.
The Luddites literally turned to violence when their profession was replaced by better technology. This has been happening for generations to every profession. There is joy in learning new things and developing new skills though.
The Luddites did not resort to violence (unless you count sabotage of machinery as violence), and they were not protesting against better technology. They were protesting against the exploitation of the workers that these machines enabled. Formerly, weaving textiles was a relatively well paid and highly skilled profession, then these machines largely automated the process. This lead to the means of production being owned by the wealthy, employing badly paid and overworked people, to make themselves even richer.
The “violence” was a simple act of sabotage, nobody got hurt except some peace of machinery and the wallets of the rich exploiters.
Well, that is not entirely true. The British parliament made sabotaging work machinery punishable by death. So people did in fact get hurt, the people who were hurt were the Luddites, and the people hurting them was the British state executing them.
> Everyone in SWE (who got into it for the love of writing code) is experiencing this.
I love writing code. But I also love solving problems. AI allows me to solve problems in different ways. And I am totally enjoying that as well. If someone got into this SWE only to code, yes, they may not love where things are today and appear to be going in the future.
There are 12,000+ data centers around the globe including ~1300 "hyper scale" DCs. It seems like at a glance that we are actually fairly distributed physically. Not to say that DCs wouldn't be valuable military targets but I would not call it centralized.
Most of their products have an AI harness embedded and it works well, at least for me. Has tools to let the models access proper debugging too(my experience is Clion) so that my build is available to them even when using remote/docker builds. The integration with codex works well too.
They host a lot of models too, and that is probably where they burned the cash.
> believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
have you ever used a library after only reading the README and documentation, or do you always pull the source and read through it before you think you understand it?
I would draw the difference here that a library is used by hundreds (of thousands) of people, and established across different scenarios. I don't read the boto3 library AWS provides, but I can trust them and the amount of customers enough to be certain enough that it behaves the way I expect it to.
The same can't be said with code we write in silos at our workplace or at home. It simply does not have the same test bench.
Yes, libraries aren't bug-free, but they give me a reliable abstraction tested in the field. Not rarely you dig into library code if you notice unexpected behavior.
If we could rely on our LLM or colleague written code, or own code, have run through the same amount of requests, sure I wouldn't need to review it, as my confidence can be north of 99.9999% it works correctly. But we can't.
I've used libraries before, where I call the API surface that they expose based on method names and parameter types, without reading all the source. Generally those libraries don't implement my software's entire problem domain area; they tend to implement things like "CSV parser" or "HTTP server". The important code, that I'm actively reading and writing, tends to be the code around those library calls.
This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.
People do that latter thing, and we call them "users", not "developers".
Of course. And then we fix the problem. It's no different here. The point is that reading the code first is absolutely not a requirement when adopting a new library.
It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.
That's because it's new. libflac and libcurl didn't come out as battle tested code. That takes time and...battles. And what are those battles if not people seeing issues with what those libraries are doing and fixing the code? There absolutely no reason that AI written code can't or won't become battle tested.
> There absolutely no reason that AI written code can't or won't become battle tested.
I can think of 2:
1. Low trust: I'm not going to trust some rando's AI-generated code/PR when I can make my own AI generated code. Maintainer will (rightly) not trust my awesome AI-generated PR because I'm a rando to them.
2. Fragmentation, if a lot of people are doing (1), they wont contribute to the same upstream codebase like they would in the past, which means each codebase only runs through a small subset of potential environments.
The interplay between 1 & 2 will result in a lot of siloed code, with no accounting for taste (i.e. sensibilities developed by maintainers)
Low trust is not a reason that code can’t be battle tested. All non battle tested code starts as low trust by default. AI written or otherwise. I’m not even sure what you mean by fragmentation tbh. This feels like a very vague argument in general.
But you’re right that it’s the hill climb of human trust that AI is going through right now. Some of us are just farther along than others. Some of us refuse to consider trusting AI out of fear, and not rational evaluation of its capability.
The battle tested part is the reason I suspect my code rather than theirs first. The trust part is in their engineering process. New project from OpenBSD or Debian, I’m ready to try. Random guy on Github, bring out the 10 foot pole.
Whenever there is a bug in a library or a hard to diagnose issue and there is no information on the internet about it, I tend to just dive right into the dependency source code for debugging.
I am sure OP cannot understand the Unix file API without actually reading every line of its implementations (on each different architecture)! Or any function for that matter , what does sort do?? Impossible to know without reading the source. And I’m sure after reading the source you will know every detail of how it works and will never forget it.
It's hard for me to understand how you could work on software and not understand the qualitative difference between the Unix File API and some code that an AI spat out 5 minutes ago.
I don't know anything about this specific case but this exact thing will be a major barrier for autonomous vehicles to overcome. Instead of benchmarking AVs against the current, human-caused number of vehicular deaths - people will naturally benchmark AVs to 0 and treat every instance of death as a failure of AVs, even if the reality is that AVs end up 99% safer than human controlled vehicles.
As it should be. “Safer on average” is not a defense for failing something as basic as stopping at a stop sign. The bar for not running one and killing someone is not unreasonably high.
Safer than average is totally defensible, because every year the margin of what is "average" changes.
I'm just pulling numbers out of my ass here, but if say, one person is killed by an automobile every 100m miles, if the next year the average is 0.999 per 100m miles, that's a good thing provided the trend continues. We should not step over a dime to pick up a penny.
I do think there's a point where introducing different failure modes is harmful. Say they end up causing more pedestrian crashes and more head-on & angle crashes (such as the one in this article), but less loss-of-control and fixed-object crashes. That would make it safer for occupants but less safe for non-occupants of the self-driving vehicle. Since the occupant is the ones engaging self-driving mode they should be the one carrying the risk, so IMO even if it reduces number of deaths overall it should not be allowed
We do tend to impose them on individual drivers who make egregious and consequential failures, that’s the point. If every car running the same software is functionally the same ‘driver’ this class of failure absolutely should trigger a moratorium.
>We do tend to impose them on individual drivers who make egregious and consequential failures, that’s the point.
Do we? It's a common saying that if you want to kill someone with no penalties, have them run over with a car.
Then there are examples like these all over the place. Not to mention distracted driving and DUIs don't even get your license suspended in many or most jurisdictions.
>The Audi, which Jones had bought one month before the crash, was the third car he had totaled in a crash within 11 months. Speed was a factor in all three collisions, but police did not cite Jones in the first two crashes, prosecutors said.
Also see the 80-year-old woman in SF who killed an entire family at a bus stop, while speeding, while going the wrong way on a one way street, and was sentenced to probation and community service and banned from driving for three years.
No, because you can punish bad drivers, remove them from the driving pool, put them in jail, or in some way achieve justice (this may not always happen, but at least it's posible). There is no way for FSD to have any accountability, and so no justice can be served. "Sorry, your son was just unlucky that he was killed by the AI, but we can't do anything about it" is an intolerable breakdown of justice. Same problem we have with qualified immunity.
"Sorry, the driver could have turned on FSD, but decided to drive [drunk/tired/distracted] and killed your son. Thankfully we can ban them from driving for a while."
This could play out a million times at the population level. If you can decrease the chances of needing justice in the first place, shouldn't that be considered?
“Who to blame” turns out to be one of the most important facets of humanity, and it turns out we structure our entire society around it: assigning liability and pursuing justice. That’s not something that can be handwaved away to technocratically chase a metric (traffic deaths).
A person needs to die for us to assign liability and pursue justice.
If fewer people die, there is no liability to assign.
It sounds like you're arguing for a human being to die to preserve a human being to blame. Which yeah, sounds just like us! "This is the way we've always done it!"
If fewer people die, there is only less liability to assign. Remember that the original argument was "FSD needs to have 0 fatalities before we adopt it". And it's not valid to argue that some traffic fatalities are unavoidable; I know people who work at the DOT and "Vision Zero"[0] is a thing, and already implemented in some European countries/cities. Without FSD. So FSD needs to clear this bar.
> It sounds like you're arguing for a human being to die to preserve a human being to blame.
God I hate technocracy. There’s a reason we elect politicians and not technologists who think everything is simple and we just aren’t making the technically correct policy decisions.
“I’m sorry ma’am, we won’t be investigating anyone for your daughter’s death at the hands of the Sexy Deathmobile 5000 because technically no one is liable. But just think, there would have been so many other children killed this year if we didn’t allow these Sexy Deathmobiles to take over the roads! I hear there’s even a software update that will reduce toddler deaths by 5% at the expense of a 10% rise in dog and raccoon deaths, but it’s a choice our technocratic overlords are ecstatic to implement!”
You’re also arguing against a false alternative, which is the status quo. I’d rather have our money put towards safe streets and reducing demand for toddler-bulldozers (cars with raised grills) than a FSD pipe dream that would only enrich a few billionaires and the lucky SWEs who happen to pick the correct company to work for.
But you can take their license, fine them, jail them.
Corporations just pay a fine and move on. I don’t want that to be the standard for road accidents and frankly outside of this techie niche no one does.
It should be a critical part of the evaluation. If you set the bar higher than “safer on average” then you’re going to delay the switch, and every month of delay will cost more lives. “Safer on average” is exactly when you should start using the new thing, even if it’s uncomfortable and even if it’s a low bar.
No it shouldn’t. Low risk behaviors should equal low risk outcomes. If it’s safer on average yet causes low risk behaviors to suddenly become unpredictably dangerous, folks will very reasonably push back
Often we do not. The Freakonomics podcast had an episode titled The Perfect Crime where they basically say if you want to kill somebody, hit them with your car because that’s often not punished beyond a ticket.
>According to evidence presented from law enforcement at trial, on September 30, 2024, Burke was operating his patrol vehicle at a high rate of speed without emergency lights or siren activated when it crashed with another vehicle. Burke's partner was injured in the crash, and 34-year-old Cedric Hayden Jr. and 33-year-old Dejuan Pettis were killed.
Not sure why you are getting downvoted here though yes, the system is not perfect, in some states more so than in others. it is a fine line between giving someone who deserves it a 2nd chance vs. someone with 17 priors. but guessing you would also agree that allowing "self-driving" tech to kill people on the road without any repercussions isn't all that ideal either?
You can't compare autonomous systems that drive hundreds of thousands of vehicles to a single person. You have to compare it to hundreds of thousands of people.
American drivers kill ~100 people every day behind the wheel of a car. If autonomy were 50% safer and was deployed at such scale that it replaced 50% of all hours driven it would save 25 lives every day. It would also kill 25 people every day.
Sadly, many people will clutch their pearls at inevitable headlines like Bloodthirsty Elon Sacrifices 25 Innocents on the Altar of Profit Every Day! and, their emotions sufficiently primed, they will happily pull the plug on autonomy, sending 25 people per day to their deaths and feeling great about themselves as they do it.
Ok, in my country, you actually get your license removed and jail time if you kill someone (usually 2 years, up to 10 if you're drinking).
Let's say Tesla kill 50% less than a human driver, I'd agree to give Tesla's board 50% of the sentence for each person autopilot kills. As an incentive to make the cars kill less.
Let's reformulate it as a railroad problem. In the proposed hypothetical, if you effectively ban self driving cars until they're literally flawless, 50 people per day will be killed by human drivers every day. If you pull the lever and allow imperfect-but-better-than-human self-driving, 25 people per day will be killed by by autonomous vehicles.
As a reference point, non-suicide gun-related deaths total ~45 people per day.
What moral principle could possibly justify not pulling the lever?
But, even as everyone talk about morality as an ideal, no one really cares about it (else the world would be very, very different). What most people care about is feeling that things are 'fair', at least the appearance of fairness. I guarantee you that if a company accepts that it's board (or executives) get jailed if their car makes a mistake that kills someone, like any random driver, people will accept it.
Imho part of isuse here is that you cannot "partial AV" it.
You cannot have a car that will EVER need you to intervene or else it does not work because of awful human nature. The amount of tesla uber drivers ive had literally browsing tiktok, watching youtube UNTIL the car beeps that it is a green light detected, then they immediately hit the accelerator before looking up is ridiculous. You cannot have a half ass "autopilot" driving experience where you are expected to zone out and then be expected to take control within a millisecond during uncertainty. It does not help that FSD, AP, aAP, bAP, the model, whether the car is visual only all apply differently
Another huge problem is that error rate it not error shape. We have an enormous body of knowledge and process for guessing what might cause problems for human drivers, how to deter the problems, and how to mitigate the damage.
For example, you'll have a pretty good idea how our fellow humans will react to rumble-strips if I describe them or play a recording. I don't need to consult a datasheet or design an AI test suite with a zillion simulations and a bunch of closed-course tests.
What percentage of road accidents involve broken down old cars, drugs and alcohol, irresponsible and risky behavior?
Because most of us don’t have that problem, and insurance stats suggest we’re a hell of a lot safer drivers than a hypothetical aggregate including stolen car joyrides by teens and 50 year old teetotalers in a well maintained, modern car.
Safer than the highest level numbers isn't really a win though for autonomous driving. All human caused deaths includes drunk drivers, inexperienced drivers, and elderly drivers. An autonomous system should never be any of those things, so comparing them against is disingenuous at best and outright manipulative at worst.
That's extremely silly. drunk, inexperienced, and elderly drivers are all human drivers. You can't just exclude them from your baseline because they are not in perfect driving form.
Let's also exclude young drivers, stupid drivers, distracted drivers, drivers who never took driver's education classes, short drivers, barefoot drivers, glasses-wearing drivers who forgot their glasses, and one handed drivers.
The insane variation of human drivers is exactly why AVs should ultimately bring vehicular deaths down..which is the goal.
You absolutely can and should exclude the known bad drivers from the stats because they are essentially outliers. If you don't, it's very possible that widespread adoption of AVs actually makes the average driver more dangerous.
reply