As someone who maintains open source projects, I can assure you that this has been a problem for about a year or so. But I reckon it took a bit longer for people to start doing this at work as well.

Let me guess, it’s ok if they do it, but if you handed their crappy ticket to Claude and shipped whatever crud came out, you’d be held accountable? ;)

Funny how that works out.

I've heard a great thing recently, more or less - If all you're doing is writing prompts, maybe you're not needed anymore. Stay behind the intent, own the output and understand it and then maybe it makes sense. sloppy prompt + c/p doesn't bring value and will be treated as such. As with anything in life, outcome is usually proportional to the effort put in.

AI etiquette is a great term. AI is useful in general but some patterns of AI usage are annoying. Especially if the other side spent 10 seconds on something and expects you to treat it seriously.

Currently it's a bit of a wild west, but eventually we'll need to figure out the correct set of rules of how to use AI.

I'm hearing nightmare stories from my friends in retail and healthcare where someone walks in holding a phone and asks you talk to them through their chatbot on their phone. Friend had a person last week walk in and ask they explain what he does to Grok and then ask Grok what questions they should ask him.

What shocks me is the complete lack of self awareness of the person holding the phone. People have been incapable of independent thought for a while, but to hold up a flag and announce this to your surroundings is really something else.

Yes. My Jira tickets used to be almost empty, but all of it was useful info. Now, my Jira tickets are way too long. The amount of useful info has also gone down.

Talk about an AI induced productivity increase ...

Same thing with PR descriptions. The signal-to-noise ratio has completely flipped. Before, a short PR description meant the dev was lazy. Now, a long detailed one might just mean they hit generate description and didn't even read it. The length went up, the usefulness went down, and the reader has no way to tell which kind they're looking at.

My teammates hit the generate PR button. I'm not reading that, it's a summary of the changes that I am _already_ going to be looking at, wrapped in some flowery language about being "better architecture, cleaner code" etc.

So those PRs may as well not have a description at all as far as I'm concerned.

Right, better architecture, cleaner code is the AI equivalent of synergy in corporate emails. It sounds like it says something but it communicates nothing. The useful PR description is changed X because Y was breaking Z and that requires the author to actually think about what they did. If the tool is doing the thinking, the description is just decoration.

I'm taking a break from doing Clever Stuff and just working on the networks team at work, because there's a big infrastructure update happening and if you want a thing done right you have to do it yourself.

Anyway.

People are starting to log support tickets using Copilot. It's easily recognisable, and they just fire a Copilot-generated email into the Helldesk, which then means I have to pick through six paragraphs of scrool to find basic things like what's actually wrong and where. Apparently this is a great improvement for everyone over tickets that just say "John MacDonald's phone is crackling, extension number 2345" because that's somehow not informative enough for me to conf up a new one and throw it at the van driver to take to site next time he's passing, and then bring the broken one back for me to repair or scrap.

Progress, eh?

I do this quite often, but I also instruct Claude to limit its output to 2-3 sentences or paragraphs, depending on the context. Also "Write this for a team of software developers / MBA's" goes a long way too.

I also do the extra step of eliminating things that are not needed, or we review this during backlog refinement.

Sounds like a lot of work to ensure it's correct, without the guarantee that it's actually correct. Why not just do it oldschool? Is it really saving you that much time?

It's weird that there's little to no focus on making AI describe problems coherently for use-cases like this?

Our engineers deliver concise outputs because we have settled internally that that's what we want. Fluffy verbosity serves no one if there's little signal in there, so just give me the no-purple prose, no emojis, tight and concise bullet version without all the chaff.

We went from Jira tickets with one or two sentences, "Implement feature X. Here are some caveats: (simple bullet points, a few words each)" to literal _pages_ of full-on unreadable garbage.

This. In my case I do write from time to time tickets with an LLM but it's always after a long exploratory session with Claude Code, when I go back and forth checking possibilities and gathering data, and then I tell it to create a ticket with the info gathered so far. But even in that case I tend to edit it because I don't like the style or add some useless data that I want to remove.

It sounds like you'd save a lot of time if you just didn't use the LLM.

Not really, the exploratory phase is (probably) much faster with Claude Code that on my own. Writing a well specified ticket is very, very time consuming. With Claude Code for me it's way much easier to branch off and follow the "what if actually...?" and challenging some knowledge that - if I had to do it manually - I will just take for granted during ticket writing. Because if I'm "sure enough" that a fact is what I recall it to be, then I just don't check and trust my memory. When paired with an LLM, that threshold goes up, and if I'm not 101% sure about something, I will send Claude Code fetch that info in some internal artifact (i.e. code in a repository, actual state of the infra etc) and then take the next decision.

But that would mean they would have do a lot more work in the same amount of time.

Don't discount the value in rubberducking with an AI.

They write shit code, but but can be prompted to highlight common failures in certain proposals.

For example, I am planning a gateway now, and the ChatGPT correctly pointed out many common vulnerabilities that occur in such a product, all of which I knew but may not have remembered while coding, like request smuggling.

It missed a few, but that's okay too, because I have a more comprehensive list written down than I would have had if I rubber ducked with an actual rubber duck.

If I finally write this product, my product spec has a list of warnings.

Is tossing stuff over the fence considered ok now? Review the slop with the person that submitted it.

> Is tossing stuff over the fence considered ok now?

Has been for a long time unfortunately. AI didn't create this behaviour but certainly made it easier for the other side to do it.

> Review the slop with the person that submitted it.

Alternatively, mark them as "Needs Work" if you can. But yes, put the ball in their court by peppering them with questions. Maybe they will get the hint.

>Has been for a long time unfortunately.

Yea, this is so annoying and AI has only grown the problem.

On the support side of things I love when the customer says "your documentation doesn't work like the product".

That used to be my joke! Given that most large organization spend (much) more time with the administrative work around code changes than the actual changes themselves (planning, deciding, meetings) then before we let Claude write our code we should let it write our Jira tickets. It was a great joke because while it was obviously absurd to many people it also made them a bit uneasy.

Cue a similar joke about salary negotiation, and the annual dance around goals and performance indicators. Is it really programmers who should be afraid to become redundant, when you think about it?

I should know better than making jokes about reality. It has already one-upped me too many times.

Tried that last year and the problem was, the tickets themselves were broken down well enough to make sense to the naked eye. The second problem was that it was all for a legacy codebase where practically everybody who had built it over the years had left, so it was a real don't-know-what-you-don't-know situation.

The second problem was always going to be there, even with human written tickets, but the problem really is that someone who relies on AI gets into the habit of treating the LLM as a more trustworthy colleague than anybody on the team, and mistakes start slipping in.

This is equally problematic for the engineers using AI to implement the features because they are no longer learning the quirks of the codebase and they are very quickly putting a hard ceiling on their career growth by virtue of not working with the team, not communicating that well, and not learning.

Some people use AI as they use anything else. Careless, without putting the effort in, making things somebody else's problem. This existed before AI, it just accelerated the stupidity.

Careless people never used to be able to create such absolute volumes of garbage that flood the system. Open source projects used to be able to just have an open PRs system, because the effort to create and submit something is quite hard, it's a natural filter. Now automated agents can flood a project with hundreds of useless PRs that disguise themselves as being real.

I've had exactly the same feeling. Since the beginning of time, it has generally taken more effort to build something than to review it. This is no longer the case, and it completely breaks some processes.

The quick solution is to escalate the arms race, and start using AI to filter the AI slop, but I'm not sure that's a world I want to work in :)

AI review can’t properly review AI code.

If you think of it like filters, a human programmer does everything they know and test to avoid bugs, then the AI review catches some things that slip through to catch a larger total number of bugs. But if both sides are AI the same stuff slips through both stages and blows up on production. It makes more sense to just improve the models to make less mistakes than to have AI review itself.

Exactly my point.

Well said, carelessness of the user persists regardless of the tools they're using. The cracks may show in other ways though.

I think before, it was easier to spot. Before, the effort spent would often show in the volume or consistency of the writing. Now, one can create a big, wordy and convincing-sounding document (without any grammatical errors!) in mere seconds. It also provides for some convenient plausible deniability: you can always claim the LLM only helped you here and there with the wording.

So now, even figuring out that it was a careless or lazy job takes a lot more time, which drastically skews the economics in favor of the careless person.

I would much rather have my prose contain grammatical errors then have anyone mistake it for LLM output. I am absolutely shocked that anyone has the opposite preference.

In a lot of domains, carelessness used to be associated with incomplete, terse, or minimal output. Not so now.

Had a friend in a similar situation. She got a clearly LLM-generated ticket that didn't make any sense, and was directed to question anything about that ticket.

Apparently, asking "why it doesn't make any sense" wasn't !polite~

If I remember correctly, she came up with ~200 questions for a 2-paged ticket. I helped write some of them, because for parts of the word salad you had to come up with the meaning first and then question the meaning.

You know what happened after she presented it? Ticket got rewritten as a job requirement, and now they seeking some poor sod to make it make sense lol

One had to be very unqualified to even get through the interview for that job without asking questions about the job, I feel. Truly, an AI-generated job for anyone who is new to the field

The first question should have been "Was this ticket AI-generated?".

Oh, it was! But the guy that generated it insisted that he triple-checked the prose after, and it should be treated as typed by hand

I'm pretty sure it would be okay to stop at 5-10 questions, because it was clear he couldn't answer any. But my friend is from a hateful branch, and so she went for humiliation angle of asking for as much clarification as the ticket itself allowed

I have a very similar situation. Except it isn't even a ticket, just an export of a very long "conversation" with ChatGPT with a vague indication that this is what needs to be implemented. When questioned about it, the person insists they completely understood it before but just forgot after a few days. Sometimes the prompts are removed. Lots of contradictory material in it, some doesn't make sense even in context. Very difficult to figure out what is wanted.

> person insists they completely understood it before but just forgot after a few days.

I don't doubt this, to be honest.

I have the feeling of learning a lot when coding with agents. New features, patterns, entire languages... It's very satisfactory asking questions and getting answers in as much detail as you want, with examples, etc.

Except I forget it all soon after. Because I didn't put the effort. Easy come easy goes .

I'm continually flabbergasted that this is accepted and not immediate grounds for punitive action- plopping slop into a ticket (or having it generated directly) is straight-up disrespectful to the person on the other end. I'd rather have someone slap me in the face directly than get one of these tickets.

I ran into a similar case recently, there was a ticket describing what needed to be done in detail. I was written by a human and it was a well written spec. The problem is that it removed some access controls in the system, essentially given some users more access than they should have.

The ticket was given to an LLM, the code written. Luckily the engineer working on it noticed the discrepancy at some point and was able to call it out.

Scrutinizing specs is always needed, no matter what.

The manager of my team is like this. He LLMed a design doc and then whenever people have questions he's exasperated that people didn't read the design doc. Bro you didn't write it, why would we read it?

Or they are like - here, can you check over this LLM design and see if it makes sense?

This is even worse because you are working with clinical trials, which literally has impact on human lives

I work for a small SaaS company.

We’re getting prospective and existing clients emailing us what look like AI generated spreadsheets with features that are miles long that they want us to respond to. Like thousands of lines. And a lot of features that are “what does that even mean??”

We get on a call with them and they don’t even know what is on the spreadsheet or what it means…

Very much a “So you want us to make Facebook?” (Not actually asking for Facebook) feeling.

I fear these horror shows of spreadsheets are just AI fever dreams….

Oh boy, do I have a story about this.

I had a PM that was unable to work without AI. Everything he did had to include AI somehow.

His magnum opus was 30 extremely large tickets that had the exact same text minus two or three places with slight variations. He wanted us to create 30 website pages with the content.

The ticket went into details such as using a CDN, following the current design, writing a scalable backend, test coverage, about 3-4 pages per ticket, plus VERY DETAILED instructions for the QA. Yep: all in the same task.

In the end it was just about adding each of the 30 items to an array.

I don’t know if he knows, but in the end it was this specific AI slop that got him fired.

This is a perfect example of where the real work and challenges are in software development.

AI makes it worse. This is where people will lose tons of productivity with AI and many people are completely clueless. It'll hit them like a ton of bricks one day.