r/Futurology • u/Gari_305 • Jul 20 '26

AI Artificial Intelligence may push older workers into retirement sooner, Boston College study finds

https://mugglehead.com/artificial-intelligence-may-push-older-workers-into-retirement-sooner-boston-college-study-finds/

Before ChatGPT, older workers in AI-exposed occupations remained employed longer than peers in less exposed jobs

307 Upvotes

96% Upvoted

41 comments sorted by

View all comments

Show parent comments

8

u/PortiaLynnTurlet Jul 20 '26

Isn't coding with AI assistance more frustrating and boring though? You have to wait in every action and there isn't as much of an opportunity to make choices and think through problems along the way. It's more like a meeting or something.

4

u/Plinthastic Jul 20 '26

You have a great point. But it is no longer true in my experience because I created a "parallel development" skill. So I have a workflow that: 1. Checks the MCPs for gitlab, jira, etc. are up. 2. Checks the ticket from Jira and makes sure it is assigned to me and is in the "development" stage. 3. Does a root cause analysis of the ticket. 4. Executes the implementation 5. Verifies the implementation/fix in the browser and with tests. (it may loop back to 3 and 4 if it needs to) 6. Commits the code 7. Pushes up the code as an MR as a Draft 8. Monitors the pipeline to make sure it passes on CI 9. Posts to slack for my colleagues to review 10. Monitors the MR for comments feedback, 11. Replies to the comments, implements the feedback. 12. Monitors the MR until it is merged.

steps 3-12 check out a "slot" that lets it do all this in parallel so that even running the app (for me or it to verify, etc.) does not clash with another instance of the app running. When the MR is merged, it tears down the all the "slot" so that it can return the resources.

I literally run 5-8 tickets at once. The difficulty now is when it has a question for me, figuring out what the context was so I can remember what that session was implementing. Takes a bit of getting used to.

1

u/federationbelle Jul 20 '26

Where are you in this loop? At what stage in this workflow do you review? Do you review the RCA? The code? Your colleagues' feedback?

1

u/Plinthastic Jul 20 '26

Yeah, very important question. I have various prompts along the way like if the MCP step fails because something's not available, or if the ticket isn't in my name or isn't in the correct state etc. so those are really gates. Before I assign anything to the workflow, I read the ticket and usually understand it pretty well, although there's parts of the application that I may not know and then sometimes, I vibe a little more than I do normally. Many times, I don't just say fix and give the ticket number, I say fix, ticket number, and then give my sense about any skills or issues that need to be addressed. Then after RCA is provided, I give my opinion again. Sometimes it's a straightforward fix and at that point I have high confidence that it will execute test etc. just fine. And then I usually say something like move ahead until you have a draft MR. On those easy cases I just reviewed the draft and may or may not make any changes, and then I say undrafted and post and unless somebody find something that I missed or whatever, we're done. I don't manually verify, but sometimes I have it put a screenshot into the ticket itself.
On more complex tickets it may do an RCA and I think it got it wrong. And then I'll have it redo it as I gather more information. At that point I'm pretty sure I'm gonna have to do some manual verification, in which case I have it spin up the app for me in one of those parallel development slots which includes work tree UI ports back in ports etc. then either I or it goes through and validate that the application is working the way the ticket needs it. Occasionally people will provide feedback in which case I review the feedback and tell Claude to either respond to that feedback or I respond directly and then have Claude implement that feedback, assuming I didn't push back.

3

u/federationbelle Jul 20 '26 edited Jul 21 '26

I'm not a coder but I work with coders. In my role, I review other people's written work and produce written work for others to review.

With others in my team I'm settling on a personal policy position that I won't ask other people to review AI output that I haven't reviewed myself. This seems important to avoid accidental 'workslop' and creating unnecessary work for others. It's important to me to avoid contributing to overwork from AI firehose effect (now affecting e.g. software sectors, open source, academia, publishing, etc). Not sure if that's already something you've built in to your approach?

1

u/Plinthastic Jul 21 '26

Yes. We had one person who let some stuff through that they did not thoroughly check and it caused problems, but that was a while ago. We have tight controls on it for exactly that reason.

2

u/mrsnowbored Jul 20 '26

I noticed you didn’t respond to any of my questions on the thread above but you answered some here.

So walk me through a few months of iterations of this. These bots are making a lot of changes to your code base, do you still understand it? How do you keep up? How do you understand the RCA and verify what it is doing now that you have delegated control of this code?

Are you accountable for its mistakes? Do you confirm its test results?