Most engineering teams spent the last two years getting faster at writing code. Fewer noticed the constraint quietly moving upstream, out of the build and into the ticket.
Hand a developer a thin ticket, and nothing breaks. They can ask two questions and build the right thing. Hand the same ticket for an autonomous agent, and it reads what you wrote, fills the gaps on its own, and ships something that looks finished either way.
That’s what changes once agentic workflows reach real backlogs. Your output stops depending on how well your team codes and starts depending on how completely your team specifies. The job description shifted more than any tool did.
Summary
Teams running coding agents are finding that the fix isn’t better prompts, it’s acceptance criteria that pass or fail cleanly, test scenarios written before the code, and a check that interrogates the ticket before the build starts. Slingshot’s Doug Compton runs a pipeline where a ticket goes in and a review-ready pull request comes out, and the habits that keep it honest cost nothing but attention. What they protect you from are the decisions your software is quietly making without you.
1. Automation removes the conversation that used to catch your gaps
The traditional ticket works because it’s only half the requirement; the other half lives in a hallway, a Slack thread, or a five-minute call.
“When you submit a ticket, it can be kind of vague. The developer will call you and ask you what you’re talking about, and you can have this back-and-forth conversation,” said Doug Compton, Director of AI Engineering at Slingshot. “But if this is an automated factory, there is no back and forth. The ticket needs to include everything that it needs.”
Doug builds what he calls a dark factory for code: a manufacturing term for plants so automated they turned off the lights because nobody was left on the floor to need them. People still design the line and handle the exceptions, but the machines run it.
His software version takes in a ticket and hands out a review-ready pull request. An agent researches the problem, writes a plan, implements it, and validates its own work at every step. A human manages the ticket up front, and a human reviews the pull requests on the backend, so everything in between runs unattended.
That design is exactly why the front of the line carries so much weight now. Your developers have to answer every clarifying question in advance, in writing, by the person who opened the ticket, and for most teams that person is a business user who has never had to write a requirement that can stand on its own.
Doug is blunt about what that did to his week: “Most of my job went from typing code to typing tickets.”
2. A gap in the ticket doesn’t stop the work, so it becomes an invisible decision
This is what catches teams off guard: an incomplete ticket doesn’t produce an error. It produces a wrong answer.
“If there’s missing information, the AI will fill it in with something it makes up,” Doug said. “If it does something stupid, you can call it a hallucination, but if it does something smart, you might not even notice it.”
Sit with the second half of that. You catch the obvious failures, but you never catch the reasonable-sounding guesses that quietly became product behavior, because nobody watches the middle of the process to see the decision get made.
Doug gave an example of a ticket he broke on purpose. He asked AI for a move counter so players could see how many clicks it took them to finish a puzzle. “But once you figure out a puzzle, if you keep clicking, what should it do? We never told it that,” he said. “Should it stop once you solve it? Or if you click again, will the move counter increase?”
The factory never asked. “I’ve run this a couple of times, and it’s actually implemented both ways,” Doug said. Nothing failed either time. Every validator passed, every test went green, and the agent made a product decision on behalf of the business and recorded it as a fact.
Scale that across a quarter of backlog, and you’re no longer looking at a quality problem, because small, undocumented decisions start accumulating inside shipped software with no author and no paper trail.
3. Acceptance criteria are the contract, and “sort of” is not a valid result
When tickets are this load-bearing, they need structure, not just length. The test Doug recommends is whether another agent, with no context beyond the conversation history, could pick up the plan and build the right thing from it alone.
That standard produces two rules. Rule #1 protects what the business asked for: “The plan may also add more stuff to it, or find new acceptance criteria, but it should never drop or reword what was in the ticket,” Doug said. An agent can sharpen your requirement, but it cannot quietly trade it for an easier one.
Rule #2 governs how each criterion gets graded. Doug said: “Each one should have a pass or fail, but never a ‘sort of.’ There needs to be a definitive yes, this passed, or no, this didn’t pass.”
That one does more work than it looks like. A criterion you can only grade as mostly met is a criterion no automated validator can act on, so it falls back to human review at exactly the point where no human is present. Vague in, vague out.
Tests are where those criteria stop being prose. Every acceptance criterion includes at least one scenario naming concrete inputs and the exact result they should produce, and edge cases get scenarios too, since the empty string and the negative number are precisely where a confident guess does the most damage. Write each scenario before the fix, watch it fail, and only then let the agent change the code until it passes.
So run the handoff test on your own backlog. If a stranger with no one to ask couldn’t build it correctly, someone has to fill that gap. Because if nobody does, the agent will.
4. The fix is a validator on the ticket itself, not more discipline from your business users
The obvious response is to tell everyone to write better tickets, but that won’t work. What if the ticket could help improve itself instead?
Doug accomplished this with a check at the factory gate. “I created a skill that will look at the ticket, then at the source code, and it will ask me questions,” he said. “It will say things like, ‘I see that this wasn’t mentioned. What should it do?’”
The ticket gets interrogated before the build starts, so the gaps surface before anything gets built. What is missing or unanswered? What should happen at the edges, and on errors? What is explicitly out of scope? Put the answers in the ticket, not in a chat window where they evaporate.
Notice what this preserves. The AI surfaces the gaps because it reads the entire codebase in seconds and spots what the requirement doesn’t cover, but the human decides what fills them. Only the human knows what the business actually wants; a developer controls what makes it into the ticket.
That split explains why he stays in the loop, even though agents now write most of the code: “The AI is just as good at writing code as I am, but it still doesn’t know the context of your business process.”
The same logic extends to the codebase itself. Doug wrote another skill that generates documentation specifically for an AI to read, and it lands in a predictable structure and gets indexed where the agent will always see it. He spends more time on research and architecture than he used to, and he writes it down somewhere the machine can find it. The context that lives only in a senior developer’s head is context the factory can’t use.
One more guardrail belongs in this category, since it’s also a specification problem: bound the loop. Doug caps his factory at three rounds, and if it can’t converge, it writes an escalation file explaining why it stopped. A loop that never resolves doesn’t fail in any visible way, so it will keep spending your money until somebody notices, most likely too late.
What this actually changes
The factory works, and that’s exactly why this matters. Tickets go in, validated pull requests come out, and the tests catch regressions a human reviewer would’ve skimmed past. The machinery isn’t the weak link anymore.
What changes is where the leverage sits. When agents write the code, the quality ceiling of your software gets set by the clarity of your requirements, the completeness of your acceptance criteria, and the quality of the documentation your systems can genuinely read. Those aren’t developer problems, so they belong to the people who run the process.
The question for your org is not whether your team can use coding agents, because they probably already do. The question is whether your intake would survive losing the hallway conversation.
Pull your last ten tickets and read each one as if the person who wrote it has gone silent and will never answer another question about it. Every gap you find is a decision you have already delegated to something that will make it confidently, quietly, and without telling you.
Scope Before You Connect
Written by: Savannah Cherry
Savannah leads marketing and new business at Slingshot. She writes, posts, and creates all things Slingshot, and helps companies navigate working with a tech partner for the first time. While she isn’t developing software, her CIS minor and a tendency to tinker with AI tools to streamline her own work keep her up to speed on the team’s work. She co-organizes and hosts the Louisville AI Exchange, and she can’t rest until all her work is done.
Expert: Doug Compton
Born and raised in Louisville, Doug’s interest in technology started at 11 when he began writing computer games. What began as a hobby turned into his career. With broad interests that range anywhere from snorkeling, science, WWII history and real estate, Doug uses his “down time“ to create new technologies for mobile and web applications.
Frequently Asked Questions
A good ticket for an AI coding agent contains everything a developer would have asked about in person, because the agent won't ask. That means the requirement itself, what should happen at the edges and on errors, what's explicitly out of scope, and acceptance criteria that can each be graded pass or fail with no middle ground. The practical test is whether a stranger with no context and nobody to ask could build the right thing from the ticket alone. If they couldn't, the agent will fill that gap with a decision of its own.
It doesn't fail or stop to ask. It fills in the missing information and ships something that looks finished. As Slingshot's Doug Compton puts it, a bad guess reads as a hallucination you can catch, but a reasonable-sounding guess may never get noticed at all. The result is a product decision made on the business's behalf, recorded as fact, with no author and no paper trail. Across a quarter of backlog, those undocumented decisions accumulate inside shipped software.
Dark factory is a manufacturing term for plants automated to the point that nobody needs to be on the floor, so the lights stay off. Applied to software, it describes a pipeline where a ticket goes in and a review-ready pull request comes out, with an agent researching, planning, implementing, and validating its own work at each step. People still design the line and handle exceptions. A human writes the ticket at the front and reviews the pull request at the end, and everything in between runs unattended.
Because they're the only enforceable contract left once no human sits in the middle of the build. Each criterion has to resolve to a definitive pass or fail, never a "sort of," since a criterion you can only grade as mostly met is one no automated validator can act on. It then falls back to human judgment at exactly the point where no human is present. Every criterion should also carry at least one test scenario with concrete inputs and an exact expected result, written before the fix and watched as it fails.
Put a validator on the ticket itself rather than asking business users to write better requirements. Doug Compton built a skill that reads the ticket alongside the source code and asks what wasn't mentioned, surfacing gaps before the build starts. The AI finds what the requirement doesn't cover, because it can read the whole codebase in seconds, and the human decides what fills each gap, because only the human knows what the business wants. The answers go into the ticket, not into a chat window where they disappear.
Bound the loop and keep a human on both ends. Doug Compton caps his pipeline at three rounds, and if it can't converge, it writes an escalation file explaining why it stopped, because a loop that never resolves doesn't fail in any visible way and keeps spending money until somebody notices. Pair that with documentation written for an agent to read and indexed where it will always be seen, since context that lives only in a senior developer's head is context the pipeline can't use.
