I've started noticing at $WORK that a lot of systems, procedures, etc. that fall under SDLC or devX are being made ever more onerous or complex because "LLMs can do it."

Some examples include requiring that someone addresses every review comment separately, or that a PR description be formatted a specific way, or that support requests have existing JIRA numbers etc. All of these make the developer experience much worse and would never fly if generating text (that no one reads) wasn't cheap now. A lot of this is cargo culting to make vibe coding feel more serious and entreprise.

The teams that have gone full specs driven development are not AFAICT more productive but good luck getting any change in without 10$ of API usage, even for a one liner. In some cases development is now slower with LLM than it was before!

▲

RHSeeger 2 days ago | parent | next [-]

I've seen every one of the things you listed, sometimes all at the same company. None of them add much in the way of effort/time to do the work.

- JIRA ticket - audit trail

- PR format - easier for people to scan, and to make sure things aren't forgotten (you can even have the template inserted when it's created)

- address review comments separately - not sure what to say on this one because I don't understand how _else_ you would address them - I've always addressed each one individually

▲

xmcqdpt2 2 days ago | parent | next [-]

> JIRA ticket - audit trail

The team I'm on prides itself in providing great service to our clients (other devs in the company). This includes responding to support requests even if the client isn't entirely sure how to ask or who to ask.

> not sure what to say on this one because I don't understand how _else_ you would address them - I've always addressed each one individually

What I mean is that it used to be enough for you to address PR tasks by changing the code and pushing the updates and marking the tasks as "resolved". Now in some projects at work you also need to reply to the comment explaining how the change you made addressed the task. The idea obviously is to stop LLM from just ticking tasks without actually doing the work, but it's onerous and based on distrust. Not trusting LLMs is warranted but those rules get applied to everyone.

	▲	9dev 2 days ago \| parent [-]
		> The team I'm on prides itself in providing great service to our clients (other devs in the company). This includes responding to support requests even if the client isn't entirely sure how to ask or who to ask. So in that case, you would create the ticket on their behalf before getting to work, right? Because how would you track what you have been working on, if something has happened already in the past, if there is a pattern in support requests, or how well your team reacts to support requests?

▲

macintux 2 days ago | parent | prev [-]

> PR format - easier for people to scan, and to make sure things aren't forgotten (you can even have the template inserted when it's created)

The team I just left had a PR template that was probably 60 bullet points (never bothered to count, just grumbled). Certainly was not easy either to scan or to update manually.

▲

clivedup 2 days ago | parent | prev [-]

> A lot of this is cargo culting to make vibe coding feel more serious and entreprise.

Those examples sound like responses to being swamped with LLM PRs:

* "every review comment separately" [so the bot doesn't get a chance to miss it]

* "a PR description be formatted a specific way" [so the bot has guardrails]

* "support requests have existing JIRA numbers etc" [so we can have a chance of understanding the context]

> The teams that have gone full specs driven development are not AFAICT more productive

I suppose time will tell. It's difficult to generalise my experiences beyond my immediate team/company/industry.

> In some cases development is now slower with LLM than it was before!

Yes, pre-LLM I wouldn't sign up for formatted PR descriptions!