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!
- 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
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.
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?
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.
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!
Tractor breaks, you complain about shoveling again and someone says you’re in the wrong job.
It's asking a tractor why the ground is full of dirt, despite having tractors to move the dirt, and tractors to confirm there is absolutely no dirt left before all the tractors can rest.
The tractor informs me that my tractors don't have permission to clean the dirt, nor see whether there is dirt, nor even distinguish that from "no permission to see dirt".
It found that faulty ACL was a known issue, and is a high priority bug for a team I've never heard of, and thousands of tractors are waiting for this.
One tractor found a webcam that overlooks the dirt patch, which bypasses the ACL, but that is now overloaded. Another tractor has setup multicast streaming to broadcast that camera, with low latency, hardware acceleration, and no single point of failure.
We're back in business.
Bypassing ACLs, multicast streaming, and using image recognition APIs for coding usecases are all against company policy, but nobody wants to pull the plug on any of this.
"Tractor, please add the multicast address to my AGENTS.md, and check my tractors have resumed."
"I've updated your AGENTS.md. The tractors have already cleaned the dirt. Here are images from the camera over the past 5 minutes, correlated with logs of the reporter tractors that reviewed progressed, to demonstrate the reports are now accurate too. I found an integer division bug, now fixed. Shall I schedule a tractor to oversee this every hour, by checking the camera?"
"Yes. And raise a blocking bug to fix all this up when the high priority bug is resolved."
8 minutes have elapsed.