5 ms·

> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervis

> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervises a team of AI coding agents as if they are a team of human junior software engineers.... > In reality, though, the code review load for software engineers will gradually increase as fewer and fewer of them are expected to supervise an ever-growing number of coding agents, and they will inevitably learn to become complacent over time, out of pure necessity for their sanity. I’m a proponent of code review...but even I often consider it a slog to do my due diligence for a large code review (just because I think it’s important doesn’t mean I think it’s fun). If it’s your full-time job to review a swarm of agents’ work, and experience tells you they are good enough 95%+ of the time, you’re not going to pay as much attention as you should and bad changes will get through. Another way to look at this is that AI coding agents take the fun out of a software engineer's job. The machine takes many of the fun parts and leaves the human with more of the unenjoyable parts. Under our new ways of working, you are required to be excited an curious about this evolution three times per day.

jonah 7mo ago
Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". Same thing happens here, you get complacent and miss critical failures or problems. It's also similar in that it "take[s away] many of the fun parts". When I can focus on simply driving it can be engaging and enjoyable - no matter the road or traffic or whatever.
- deleted 7mo ago
  [deleted]
- gruez 7mo ago
  >Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". That might be an issue for supervised "self-driving" cars (eg. tesla FSD), but not really applicable to self driving cars as a whole. Waymo seems to be doing just fine for instance.
  - jonah 7mo ago
    Exactly why I put "self-driving" in quotes. Right now AI assisted coding might generally be at the equivalent of Level-2 or -3 self-driving. Getting to autonomous coding agents will be like the step change that is Level-4 or -5 driving.
  - teatro 7mo ago
    Aren’t Waymo‘s 5% covered by some people in the Philippines? [1] And aren’t they still failing occasionally? [2] [1](https://www.techspot.com/news/111233-waymo-admits-autopilot-often-guys-philippines.html https://www.techspot.com/news/111233-waymo-admits-autopilot-...) [2] (https://www.bloomberg.com/news/articles/2026-01-23/waymo-probed-by-us-safety-agency-over-austin-school-bus-mishaps https://www.bloomberg.com/news/articles/2026-01-23/waymo-pro...)
    - gruez 7mo ago
      >Aren’t Waymo‘s 5% covered by some people in the Philippines? [1] If you look at waymo's prior blog posts, you'll realize that the people in Philippines aren't making split second decisions that was implied by "you’re not going to pay as much attention as you should". https://waymo.com/blog/2024/05/fleet-response https://waymo.com/blog/2024/05/fleet-response >And aren’t they still failing occasionally? [2] What's the failure rate of humans? For both AI drivers and coders, if they make less mistakes than humans, that's still a win.
      - stavros 7mo ago
        > What's the failure rate of humans? 5x more than Waymos, last I saw.
mark242 7mo ago
> Another way to look at this is that AI coding agents take the fun out of a software engineer's job. Completely backwards - the fun in the job should be to solve problems and come up with solutions. The fun in the job is not knowing where to place a semicolon.
- bluefirebrand 7mo ago
  > the fun in the job should be to solve problems and come up with solutions Who are you to tell anyone what the fun "should" be? Personally, I find writing code very fun, because building the solution is also very gratifying. Besides which, in my experience until you actually write the code you haven't proven that you solved anything. It's so easy to think you have solved a problem when you haven't, but you won't figure that out until you actually try to apply your solution > The fun in the job is not knowing where to place a semicolon. This can be solved with simple linters, no need for LLMs
- chris_money202 7mo ago
  Exactly, the fun part is when the code works and does what you wanted it to do. Writing code itself is not fun. People forget this because they get small wins / dopamine hits along the way, a clever function, an elegant few lines of code, a bug fix, but the majority of that time coding is just a grind until the end where you get the big dopamine hit.
  - HendrikHensen 7mo ago
    Fun is not measured objectively. Different people find different things fun. I enjoy writing code very much (in addition to solving big problems; one can enjoy both).
    - deleted 7mo ago
      [deleted]
- palmotea 7mo ago
  >> Another way to look at this is that AI coding agents take the fun out of a software engineer's job. > Completely backwards - the fun in the job should be to solve problems and come up with solutions. Aren't the coding agents supposed to be doing that too? You give them the problem, they code up a solution, then the engineer is left with the review it to see if it's good enough. > The fun in the job is not knowing where to place a semicolon. That's like such a minor and easy-to-do thing that I'm surprised you're even bringing it up.
dybber 7mo ago
I think it depends on what you find enjoyable. I think people who like the tinkering and the actual act of coding, debugging, etc. will find it less and less fun to be in this area, but people who like to look at the big picture, and solve problems, will see that they will now be better at both getting overview of larger and larger codebases and that technical debt that was never attainable to solve before can now be “outsourced” to LLM’s. I find that fun. I work in a 50 year old IT company, with lots of legacy code and technical debt which we have never been able to address - suddenly it’s within reach to really get us to a better place.
- maplethorpe 7mo ago
  The best way to have a big picture view of a project is to build a mental model of that project in your head. Coding with LLMs removes that ability, and replaces it with an illusion.
  - stavros 7mo ago
    Does the thing work like I want it in the end? Is it fast, reliable, enjoyable to use, maintainable, cheap, efficient, resilient, etc? If so, I don't care if I wrote it by hand or with an LLM. People who think that building something with an LLM somehow dooms the something to mediocrity are engaging in magical thinking. I can simply use as much or as little LLM as will allow me to meet my quality criteria.
    - frizlab 7mo ago
      You forgot maintainable.
      - stavros 7mo ago
        Added a few more adjectives and an "etc", to cover all pedantic bases that don't matter to my argument.
    - maplethorpe 7mo ago
      You listed "maintainable", but how do you know your project is maintainable, if you yourself have no understanding of the code base? Presumably the reason is that the AI has managed to maintain the project so far, so it follows that it will be able to do so in the future. But that's not a given. It's more of a prayer.
raw_anon_1111 7mo ago
The “fun” for me has never been “coding” and on the enterprise dev side that has been a commodity for a decade. If you look at the leveling guidelines for any tech company “codez real gud” will only get you to a mid level ticket taker.
- catgary 7mo ago
  And even then - I still read the code it generates, and if I see a better way of doing something I just step in, write a partial solution, and then sketch out how the complete solution should work.
  - raw_anon_1111 7mo ago
    Unless the solution is going to be more secure, faster, more stable etc, why does it matter? Will the end user care? “Does it make the beer taste better”?
    - dijksterhuis 7mo ago
      in a word, maintainability > maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something https://softwareengineering.stackexchange.com/a/134863 https://softwareengineering.stackexchange.com/a/134863 i could be wrong, but i'm pretty sure that end-users get upset when a change takes a long time or it ends up breaking something for them. just because people are finding that agents or whatever are speeding changes up now doesn't necessarily mean they won't encounter a slow-down later when the codebase becomes an un-maintainable mess. technical debt is always a thing, even with machines doing the work (the agent/machine still has to parse a codebase to make changes).
      - raw_anon_1111 7mo ago
        What makes you think that AI couldn’t make the same changes without breaking it whether you modify the code or not? And you do have automated unit tests don’t you? Right now I have a 5000 line monolithic vibe coded internal website that is at most going to be used by 3 people. It mixes Python, inline CSS and Javasript with the API. I haven’t looked at a line of code. My IAM permissions for the Lambda runtime has limited permissions (meaning the code can’t do anything that the permissions won’t allow it to). I used AWS Cognito for authorization and validated the security of the endpoints and I validated the permissions of the database user. Neither Claude nor Codex have any issues adding pages, features and API endpoints without breaking changes. By definition, coding agents are the worse they will be right now.
hax0ron3 7mo ago
I like programming for fun, but professional software engineering has never been more than very occasionally fun to me. I do it because it pays well. Most companies use some variant of the sprint/"agile" methodology, which means that you as the programmer are similar to an assembly line worker. You don't control the pace, you rarely get the chance to actually finish anything as much as you would like to so you don't get the satisfaction of a finished product, you get little downtime in between tickets or projects to feel a sense of satisfaction at what you have done before you move on to something else. I totally understand why businesses operate this way. It's simple: if you try not to operate this way, you increase the likelihood that your competitors will release more rapidly and take all your market share. It's the basic evolutionary logic. If you can release a decent but buggy product six months faster than the competitor can release a better and less buggy product, there is a good chance that you will drive them out of business. It all makes sense, but it doesn't result in a pleasant experience for me as a programmer. The job is also very sedentary and it puts stress on your eyes and your hands. Of course I'm not going to compare myself to a coal miner, but the fact remains that in its own ways the job is more rough on the body than some people might expect. Meanwhile the intellectual and constantly changing nature of the field means that you can never rest on your laurels - the job requires constant mental engagement. It's hard to do it well while multitasking and thinking about other interesting things at the same time. If jobs in this field did not pay so well, I don't think I'd ever even consider doing this as a career. It just doesn't have nearly enough upsides for me. The only upside I can think of besides the money is that you get to spend time interacting with intelligent people. But one can get that in other places. Coding with the help of AI is a big improvement for me because just automating away the boilerplate and greatly reducing the time that needs to be spent in doing reading, research and experimentation already takes away some of the main time-sinks of the job. And while I appreciate code's deterministic and logical elegance, I've written more than enough code in my life to not miss writing it directly. I also enjoy writing English, after all. It's refreshing for me to spend my time composing precise English instructions for the AI instead of writing in a programming language. My English skills are above average, so this also helps me to leverage one of my talents that had previously been underutilized. Well, my English skills always came in handy when I needed to talk to coworkers or managers, but I meant that they had been underutilized in the act of actually creating software.
linsys 7mo ago
But isn't that what Linux admins said when Cloud and Platform Engineering became a "thing". Puppet, Chef, Ansible they are taking the fun out of system administration, Cloud it's going to take away my job. But what happened is roles changed, SRE, Platform Engineering, dare I say DevOps engineers (whatever those are) all emerged. Software engineering is going through he same transformation with the same knee jerk reactions from both sides of the argument. Either AI run rampant with no guardrails like OpenClaw people burning 1000s in tokens, OpenClaw calling them randomly at 2am, etc.. then on the other side of the argument we have a petition asking the Node.js Technical Steering Committee to ban AI-assisted code from Node.js core. AI is here, it's here to stay, I believe that those of us that will be successful will find the middle ground.
az09mugen 7mo ago
That's exactly the feeling in this quotation : "I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do my laundry and dishes." -- Joanna Maciejewska, author and videogame enthusiast

jonah 7mo ago

Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". Same thing happens here, you get complacent and miss critical failures or problems. It's also similar in that it "take[s away] many of the fun parts". When I can focus on simply driving it can be engaging and enjoyable - no matter the road or traffic or whatever.

deleted 7mo ago
[deleted]
gruez 7mo ago
>Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". That might be an issue for supervised "self-driving" cars (eg. tesla FSD), but not really applicable to self driving cars as a whole. Waymo seems to be doing just fine for instance.
- jonah 7mo ago
  Exactly why I put "self-driving" in quotes. Right now AI assisted coding might generally be at the equivalent of Level-2 or -3 self-driving. Getting to autonomous coding agents will be like the step change that is Level-4 or -5 driving.
- teatro 7mo ago
  Aren’t Waymo‘s 5% covered by some people in the Philippines? [1] And aren’t they still failing occasionally? [2] [1](https://www.techspot.com/news/111233-waymo-admits-autopilot-often-guys-philippines.html https://www.techspot.com/news/111233-waymo-admits-autopilot-...) [2] (https://www.bloomberg.com/news/articles/2026-01-23/waymo-probed-by-us-safety-agency-over-austin-school-bus-mishaps https://www.bloomberg.com/news/articles/2026-01-23/waymo-pro...)
  - gruez 7mo ago
    >Aren’t Waymo‘s 5% covered by some people in the Philippines? [1] If you look at waymo's prior blog posts, you'll realize that the people in Philippines aren't making split second decisions that was implied by "you’re not going to pay as much attention as you should". https://waymo.com/blog/2024/05/fleet-response https://waymo.com/blog/2024/05/fleet-response >And aren’t they still failing occasionally? [2] What's the failure rate of humans? For both AI drivers and coders, if they make less mistakes than humans, that's still a win.
    - stavros 7mo ago
      > What's the failure rate of humans? 5x more than Waymos, last I saw.

mark242 7mo ago

> Another way to look at this is that AI coding agents take the fun out of a software engineer's job. Completely backwards - the fun in the job should be to solve problems and come up with solutions. The fun in the job is not knowing where to place a semicolon.

bluefirebrand 7mo ago
> the fun in the job should be to solve problems and come up with solutions Who are you to tell anyone what the fun "should" be? Personally, I find writing code very fun, because building the solution is also very gratifying. Besides which, in my experience until you actually write the code you haven't proven that you solved anything. It's so easy to think you have solved a problem when you haven't, but you won't figure that out until you actually try to apply your solution > The fun in the job is not knowing where to place a semicolon. This can be solved with simple linters, no need for LLMs
chris_money202 7mo ago
Exactly, the fun part is when the code works and does what you wanted it to do. Writing code itself is not fun. People forget this because they get small wins / dopamine hits along the way, a clever function, an elegant few lines of code, a bug fix, but the majority of that time coding is just a grind until the end where you get the big dopamine hit.
- HendrikHensen 7mo ago
  Fun is not measured objectively. Different people find different things fun. I enjoy writing code very much (in addition to solving big problems; one can enjoy both).
  - deleted 7mo ago
    [deleted]
palmotea 7mo ago
>> Another way to look at this is that AI coding agents take the fun out of a software engineer's job. > Completely backwards - the fun in the job should be to solve problems and come up with solutions. Aren't the coding agents supposed to be doing that too? You give them the problem, they code up a solution, then the engineer is left with the review it to see if it's good enough. > The fun in the job is not knowing where to place a semicolon. That's like such a minor and easy-to-do thing that I'm surprised you're even bringing it up.

dybber 7mo ago

I think it depends on what you find enjoyable. I think people who like the tinkering and the actual act of coding, debugging, etc. will find it less and less fun to be in this area, but people who like to look at the big picture, and solve problems, will see that they will now be better at both getting overview of larger and larger codebases and that technical debt that was never attainable to solve before can now be “outsourced” to LLM’s. I find that fun. I work in a 50 year old IT company, with lots of legacy code and technical debt which we have never been able to address - suddenly it’s within reach to really get us to a better place.

maplethorpe 7mo ago
The best way to have a big picture view of a project is to build a mental model of that project in your head. Coding with LLMs removes that ability, and replaces it with an illusion.
- stavros 7mo ago
  Does the thing work like I want it in the end? Is it fast, reliable, enjoyable to use, maintainable, cheap, efficient, resilient, etc? If so, I don't care if I wrote it by hand or with an LLM. People who think that building something with an LLM somehow dooms the something to mediocrity are engaging in magical thinking. I can simply use as much or as little LLM as will allow me to meet my quality criteria.
  - frizlab 7mo ago
    You forgot maintainable.
    - stavros 7mo ago
      Added a few more adjectives and an "etc", to cover all pedantic bases that don't matter to my argument.
  - maplethorpe 7mo ago
    You listed "maintainable", but how do you know your project is maintainable, if you yourself have no understanding of the code base? Presumably the reason is that the AI has managed to maintain the project so far, so it follows that it will be able to do so in the future. But that's not a given. It's more of a prayer.

raw_anon_1111 7mo ago

The “fun” for me has never been “coding” and on the enterprise dev side that has been a commodity for a decade. If you look at the leveling guidelines for any tech company “codez real gud” will only get you to a mid level ticket taker.

catgary 7mo ago
And even then - I still read the code it generates, and if I see a better way of doing something I just step in, write a partial solution, and then sketch out how the complete solution should work.
- raw_anon_1111 7mo ago
  Unless the solution is going to be more secure, faster, more stable etc, why does it matter? Will the end user care? “Does it make the beer taste better”?
  - dijksterhuis 7mo ago
    in a word, maintainability > maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something https://softwareengineering.stackexchange.com/a/134863 https://softwareengineering.stackexchange.com/a/134863 i could be wrong, but i'm pretty sure that end-users get upset when a change takes a long time or it ends up breaking something for them. just because people are finding that agents or whatever are speeding changes up now doesn't necessarily mean they won't encounter a slow-down later when the codebase becomes an un-maintainable mess. technical debt is always a thing, even with machines doing the work (the agent/machine still has to parse a codebase to make changes).
    - raw_anon_1111 7mo ago
      What makes you think that AI couldn’t make the same changes without breaking it whether you modify the code or not? And you do have automated unit tests don’t you? Right now I have a 5000 line monolithic vibe coded internal website that is at most going to be used by 3 people. It mixes Python, inline CSS and Javasript with the API. I haven’t looked at a line of code. My IAM permissions for the Lambda runtime has limited permissions (meaning the code can’t do anything that the permissions won’t allow it to). I used AWS Cognito for authorization and validated the security of the endpoints and I validated the permissions of the database user. Neither Claude nor Codex have any issues adding pages, features and API endpoints without breaking changes. By definition, coding agents are the worse they will be right now.

hax0ron3 7mo ago

I like programming for fun, but professional software engineering has never been more than very occasionally fun to me. I do it because it pays well. Most companies use some variant of the sprint/"agile" methodology, which means that you as the programmer are similar to an assembly line worker. You don't control the pace, you rarely get the chance to actually finish anything as much as you would like to so you don't get the satisfaction of a finished product, you get little downtime in between tickets or projects to feel a sense of satisfaction at what you have done before you move on to something else. I totally understand why businesses operate this way. It's simple: if you try not to operate this way, you increase the likelihood that your competitors will release more rapidly and take all your market share. It's the basic evolutionary logic. If you can release a decent but buggy product six months faster than the competitor can release a better and less buggy product, there is a good chance that you will drive them out of business. It all makes sense, but it doesn't result in a pleasant experience for me as a programmer. The job is also very sedentary and it puts stress on your eyes and your hands. Of course I'm not going to compare myself to a coal miner, but the fact remains that in its own ways the job is more rough on the body than some people might expect. Meanwhile the intellectual and constantly changing nature of the field means that you can never rest on your laurels - the job requires constant mental engagement. It's hard to do it well while multitasking and thinking about other interesting things at the same time. If jobs in this field did not pay so well, I don't think I'd ever even consider doing this as a career. It just doesn't have nearly enough upsides for me. The only upside I can think of besides the money is that you get to spend time interacting with intelligent people. But one can get that in other places. Coding with the help of AI is a big improvement for me because just automating away the boilerplate and greatly reducing the time that needs to be spent in doing reading, research and experimentation already takes away some of the main time-sinks of the job. And while I appreciate code's deterministic and logical elegance, I've written more than enough code in my life to not miss writing it directly. I also enjoy writing English, after all. It's refreshing for me to spend my time composing precise English instructions for the AI instead of writing in a programming language. My English skills are above average, so this also helps me to leverage one of my talents that had previously been underutilized. Well, my English skills always came in handy when I needed to talk to coworkers or managers, but I meant that they had been underutilized in the act of actually creating software.

linsys 7mo ago

But isn't that what Linux admins said when Cloud and Platform Engineering became a "thing". Puppet, Chef, Ansible they are taking the fun out of system administration, Cloud it's going to take away my job. But what happened is roles changed, SRE, Platform Engineering, dare I say DevOps engineers (whatever those are) all emerged. Software engineering is going through he same transformation with the same knee jerk reactions from both sides of the argument. Either AI run rampant with no guardrails like OpenClaw people burning 1000s in tokens, OpenClaw calling them randomly at 2am, etc.. then on the other side of the argument we have a petition asking the Node.js Technical Steering Committee to ban AI-assisted code from Node.js core. AI is here, it's here to stay, I believe that those of us that will be successful will find the middle ground.

az09mugen 7mo ago

That's exactly the feeling in this quotation : "I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do my laundry and dishes." -- Joanna Maciejewska, author and videogame enthusiast