5 ms·

I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code t

I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code that was required to be written. This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This hand off is no longer necessary as that same senior can just kick off an agent and have it handle the implementation for them. I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.

throwayay4929 1mo ago
... And Django and React removed ("stole the jobs from under") the engineers handcrafting html and jQuery web pages/apps.
- jameshart 1mo ago
  Django? Django is older than jQuery…
- platevoltage 1mo ago
  If you stopped learning during JQuery's heyday, You deserved to have your job stolen. This is not the same as watching AI ruin software platforms.
sarchertech 1mo ago
>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice. What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM). Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project. If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.
- re-thc 1mo ago
  > but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice I've seen a twist - not juniors but just offshore engineers.
- _doctor_love 1mo ago
  > I’ve worked at a lot of places over 20 years Primarily in Silicon Valley or outside of it? I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.
- AppleBananaPie 1mo ago
  I've never thought about it this way before but this definitely mirrors my experience
- Aurornis 1mo ago
  > This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice. I would have said the same thing for the first 15 years of my career across several jobs and acquisitions. Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things. The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them. It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.
- 1mo ago
doctorwho42 1mo ago
Again, this ignores the second order effect of entirely gutting the personnel pipeline that is required to create new senior devs... So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....
- AnimalMuppet 1mo ago
  I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.
- applfanboysbgon 1mo ago
  The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.
  - a34729t 1mo ago
    They'll become managers and PMs and TPMs instead.
- Aurornis 1mo ago
  > Kind of like the fortran crisis of the last decade or so.... I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it. Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.
wetoastfood 1mo ago
I agree the time it takes to go from planning to deployed is condensing. I'm not sure the hand off is no longer necessary (though it admittedly often feels like it). Perhaps it means we need better ways of planning and collaborating faster and on larger features? So you still end up with a hand off, but it looks different, is maybe more detailed, or spans a wider implementation than we previously might?
a2ff6eeb0 1mo ago
I think AI is getting pretty good at generating the tickets as well. Not amazing, but it feels like ticket generation today is where code generation was a year ago. I wonder if there's an agent harness that would work well for requirements gathering.
- coffeebeqn 1mo ago
  Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop
  - a2ff6eeb0 1mo ago
    That assumes you're the one that's implementing it. If the agents get good enough at figuring out specs, I'd expect you could just pass it along to the next agent for implementation -- vibe coding today, vibe speccing tomorrow.
- SchemaLoad 1mo ago
  This is what the managers at my company think. But it ends up generating a wall of slop. I always end up scrolling to the bottom and looking for the original customer email or product request that was used to generate the ticket above.
dominotw 1mo ago
what is so 'hard thinking' about building a crud app
- florianherrengt 1mo ago
  Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.
  - graemep 1mo ago
    The complexity I have seen in supposedly simple CRUD apps is amazing, especially what some less experienced people do.
  - bossyTeacher 1mo ago
    [dead]
- SchemaLoad 1mo ago
  In my experience it's always the permissions system where messy real world business has to be translated in to SQL that doesn't lock up the system when some program admin added to 200 teams tries to load the index page. "What can this user see" has always been a very complex question in every crud app I've worked on.
SpacePortKnight 1mo ago
I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer. I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.
- shimman 1mo ago
  Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
- tayo42 1mo ago
  My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
- SoftTalker 1mo ago
  By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it). Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
- dzonga 1mo ago
  you're one of the lucky ones. usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc. very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.
StableAlkyne 1mo ago
> This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it. The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision. I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.
- unified101 1mo ago
  > ask Claude if it makes sense to do X This is a fantastic way of working with agents in my experience. It's like have a peer architect who can challenge you and help you improve. You're projecting your own feelings and fears by calling it infantalizing.
  - StableAlkyne 1mo ago
    There is a world of difference between using it as a "peer architect" and outsourcing your entire thought process to it.
    - unified101 1mo ago
      You're treating asking questions on everything as "outsourcing your entire thinking". It isn't.
      - StableAlkyne 1mo ago
        This engineer would not do anything without asking the AI first. This includes extremely basic activities type hinting a function that takes a string and returns a string, which I know he knew how to do. Sorry mate, but if that isn't outsourcing one's thinking then we live in different realities.
JeremyNT 1mo ago
> I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised. I feel like this is a bit of cope. Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.
DaveParkCity 1mo ago
While the picture painted here is viceral... I think the reality is closer to this.. Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it. With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".

throwayay4929 1mo ago

... And Django and React removed ("stole the jobs from under") the engineers handcrafting html and jQuery web pages/apps.

jameshart 1mo ago
Django? Django is older than jQuery…
platevoltage 1mo ago
If you stopped learning during JQuery's heyday, You deserved to have your job stolen. This is not the same as watching AI ruin software platforms.

sarchertech 1mo ago

>This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice. What tends to happen is that the EMs and PMs look at who’s free and give that person the task. This means that sometimes you get a senior leading a simple project and sometimes you get a junior leading/designing a complex project (usually with help from a very minorly technical PM). Then the senior/staff/principal (often on a different “special” team) gets pulled in at the last minute to rescue the project. If your company is highly product driven, you’ll often find that the juniors end up leaving projects more often than not because they will tell the PM exactly what they want to hear.

re-thc 1mo ago
> but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice I've seen a twist - not juniors but just offshore engineers.
_doctor_love 1mo ago
> I’ve worked at a lot of places over 20 years Primarily in Silicon Valley or outside of it? I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.
AppleBananaPie 1mo ago
I've never thought about it this way before but this definitely mirrors my experience
Aurornis 1mo ago
> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice. I would have said the same thing for the first 15 years of my career across several jobs and acquisitions. Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things. The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them. It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.
1mo ago

doctorwho42 1mo ago

Again, this ignores the second order effect of entirely gutting the personnel pipeline that is required to create new senior devs... So without a training pipeline to provide experience to jr. Devs, in 15 years we will be hurting for senior devs to replace all the graybeards. Kind of like the fortran crisis of the last decade or so.... Just across an entire industry that supports every other industry....

AnimalMuppet 1mo ago
I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.
applfanboysbgon 1mo ago
The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.
- a34729t 1mo ago
  They'll become managers and PMs and TPMs instead.
Aurornis 1mo ago
> Kind of like the fortran crisis of the last decade or so.... I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it. Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.

wetoastfood 1mo ago

I agree the time it takes to go from planning to deployed is condensing. I'm not sure the hand off is no longer necessary (though it admittedly often feels like it). Perhaps it means we need better ways of planning and collaborating faster and on larger features? So you still end up with a hand off, but it looks different, is maybe more detailed, or spans a wider implementation than we previously might?

a2ff6eeb0 1mo ago

I think AI is getting pretty good at generating the tickets as well. Not amazing, but it feels like ticket generation today is where code generation was a year ago. I wonder if there's an agent harness that would work well for requirements gathering.

coffeebeqn 1mo ago
Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop
- a2ff6eeb0 1mo ago
  That assumes you're the one that's implementing it. If the agents get good enough at figuring out specs, I'd expect you could just pass it along to the next agent for implementation -- vibe coding today, vibe speccing tomorrow.
SchemaLoad 1mo ago
This is what the managers at my company think. But it ends up generating a wall of slop. I always end up scrolling to the bottom and looking for the original customer email or product request that was used to generate the ticket above.

dominotw 1mo ago

what is so 'hard thinking' about building a crud app

florianherrengt 1mo ago
Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.
- graemep 1mo ago
  The complexity I have seen in supposedly simple CRUD apps is amazing, especially what some less experienced people do.
- bossyTeacher 1mo ago
  [dead]
SchemaLoad 1mo ago
In my experience it's always the permissions system where messy real world business has to be translated in to SQL that doesn't lock up the system when some program admin added to 200 teams tries to load the index page. "What can this user see" has always been a very complex question in every crud app I've worked on.

SpacePortKnight 1mo ago

I have been a software engineer for 8 years and not once I have had a jira ticket handed over to me by a senior engineer. I have worked in startups before and currently work at bkng, and have friends at uber. Everywhere it is expected that the engineers will create their own tickets and refine them with the team. If you are in a product facing team, your PM could even help you with a PRD but I have not seen one in the last few years.

shimman 1mo ago
Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).
tayo42 1mo ago
My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.
SoftTalker 1mo ago
By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it). Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.
dzonga 1mo ago
you're one of the lucky ones. usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc. very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.

StableAlkyne 1mo ago

> This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code I wish this were the extent of it nowadays. But for whatever reason, I've seen multiple really promising engineers get a hold of AI tools, and just outsource all of their thinking to it. The self-infantalization is so bad that I was pair programming with a guy one day (partly to see how he was using AI) and watched him ask Claude if it makes sense to do X for every single decision. I get using it as a form of linting... But you'll never learn how to be an independent developer if you constantly outsource your decision making. And it's disappointing too, because he was developing so rapidly as an engineer before Copilot came out.

unified101 1mo ago
> ask Claude if it makes sense to do X This is a fantastic way of working with agents in my experience. It's like have a peer architect who can challenge you and help you improve. You're projecting your own feelings and fears by calling it infantalizing.
- StableAlkyne 1mo ago
  There is a world of difference between using it as a "peer architect" and outsourcing your entire thought process to it.
  - unified101 1mo ago
    You're treating asking questions on everything as "outsourcing your entire thinking". It isn't.
    - StableAlkyne 1mo ago
      This engineer would not do anything without asking the AI first. This includes extremely basic activities type hinting a function that takes a string and returns a string, which I know he knew how to do. Sorry mate, but if that isn't outsourcing one's thinking then we live in different realities.

JeremyNT 1mo ago

> I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised. I feel like this is a bit of cope. Right now you still need to have some skill to guide these things correctly to produce cohesive and functional products, but at the rate we've seen them improve I question how long this will remain true.

DaveParkCity 1mo ago

While the picture painted here is viceral... I think the reality is closer to this.. Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it. With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".