The article discusses the emerging shift in how engineers write bug tickets to be understood by AI agents, noting increased documentation rigor and workflow challenges.
Been thinking about this a lot lately and curious how others on this sub are handling it. A year ago I'd write a bug ticket like I was talking to a teammate. Something like "login is broken on staging, repro from the usual flow, prob related to yesterday's auth PR." My team knew the context, knew what "usual flow" meant, knew which PR I was referencing. Done in 30 seconds, ticket closed in an hour. Now half the time the first thing that touches my ticket is some AI agent, either Copilot Workspace, a Claude Code session a teammate kicks off, or whatever our PM has wired into Linear this week. And the agent doesn't know what "the usual flow" is. It doesn't know which PR I meant. It will confidently go off and "fix" something that wasn't broken, or open a PR that technically resolves the ticket as written but misses the actual issue entirely. So I've started writing tickets almost like mini specs. Explicit repro steps. Exact file paths. The expected vs actual behavior spelled out. Links to the relevant commits instead of vague references. Sometimes I even add a "what NOT to change" section because agents love to scope-creep into adjacent files. The weird part is I'm not sure if this is good or bad. On one hand, my tickets are now genuinely better documented and a new hire could pick them up cold. On the other hand, I'm spending 10 minutes writing a ticket that used to take 30 seconds, and I'm basically doing prompt engineering for a JIRA ticket which feels like a deeply cursed timeline. A few specific things I'm wrestling with: * Do you write tickets assuming an agent might pick it up, or do you tag tickets as "agent-eligible" vs "human-only"? * Has anyone built internal templates or linting for ticket quality now that LLMs read them? * Are your PMs writing tickets differently, or is this falling entirely on engineers to enforce? * For those of you on teams that have fully embraced agent-driven work, did ticket quality go up or did everyone just give up and let the agents flail? Genuinely curious what patterns are emerging. Feels like one of those quiet workflow shifts that nobody is really writing about but everyone is dealing with.
The article argues that AI agents are revealing how unstructured and chaotic many corporate workflows actually are, suggesting that successful automation depends more on clean systems and documentation than on advanced models.
The article explores how AI agent workflows are reintroducing software engineering challenges around reproducibility, auditability, and state management that were previously solved with version control, CI/CD, and static code practices, while noting emerging solutions like GitHub's Agentic Workflows and git-native approaches.
The author proposes Automation Engineering as a discipline for designing triggers, guardrails, and success checks to make AI agents safe and reliable without constant human oversight.
The article argues that designing APIs for AI agents requires different principles than for humans, emphasizing clarity, explicitness, and avoiding defaults, because agents can read entire docs and write extensive code.