Alfred has the same problem. Which is why we made it refuse to start until the ticket is worth reading.
What is Alfred?
Alfred is an AI-powered workflow that takes a Jira issue and turns it into a pull request, fully implemented, tested, and linked back to the ticket.
It lives as a GitHub Actions workflow, triggered automatically when a ticket gets labelled alfred.
Before it does anything, it checks.
- Is the description long enough to be useful?
- Does it contain actual direction, not just a title?
If the answer is no, it doesn’t run.
This isn’t a nice-to-have. It’s the first quality gate in a chain, and everything downstream depends on it.
Context before code
Most people building agentic coding workflows assume the bottleneck is code quality. It isn’t. The bottleneck is whether the agent understands what it’s supposed to build and why.
Alfred works through three distinct phases before touching a single file.
First, it reads the Jira issue in full, including every comment. It’s about building a picture of the requirements, constraints, and any specific concerns the team has raised: security, performance, and rollout order.
Second, it searches the team’s Confluence and Jira via MCP. It looks for existing architecture decisions, PRDs, API specs, and user stories that might be relevant. This step exists because Jira rarely tells the whole story. The real constraints usually live in documentation that nobody linked to the ticket.
Third, it inspects the repo: the languages in use, the dependency files, the existing CI/CD workflows, the test layout. It figures out which files are likely to change before writing anything.
Only after all three phases does Alfred start implementing.
A workflow that knows the rules
Two “personality” files are injected into every Alfred run.
The first is a project brief: a short document describing what the product is, what’s being built right now, what matters, and the engineering rules the team lives by. Things like “use the SDK, don’t duplicate it” and “version everything.”
The second is a humanizer: a detailed guide on how to write like a person. No significance inflation, no rule-of-three lists, no em dashes for emphasis. PR descriptions get reviewed by humans, and sloppy AI prose wastes reviewer attention. We’ve invested real time in this file and it shows in the review conversations.
The implementation loop
Once Alfred has enough context, it creates a branch, implements the changes, runs the test suite and any pre-commit hooks, adds tests if coverage is missing, creates a pull request, and comments on the original Jira ticket with a link and a summary of what changed.
The whole chain is traceable. An engineer can follow a thread from Jira comment to PR to a specific commit without having to reconstruct what the agent was thinking.
What this actually buys you
Alfred doesn’t replace engineers. It eats the setup tax.
The setup tax is: reading the ticket, finding the relevant docs, poking around the codebase to understand what already exists, scaffolding the branch, getting to the point where you can actually start thinking. That work takes time and mental energy. Most engineers would rather spend it on the actual problem.
Alfred handles the setup. The result is a PR that a senior engineer can review and either approve or push back on, with enough context already present in the description that they’re not starting from scratch.
Development cycles shorten when a machine pays the getting-started tax. Documentation gaps surface when the agent can’t find what it needs and has to say so. Requirements quality improves when the system refuses to proceed on vague tickets. These are real effects and they compound.
What Alfred cannot do
Alfred will produce code that compiles, passes linting, and satisfies the tests it knows about. It will not catch requirements that were never written down. It will not know that the approach is architecturally wrong for a reason that lives in someone’s head. It will not understand the organisational history that makes a technically correct solution a bad idea.
Every PR Alfred creates needs a real reviewer. Not a rubber stamp. Someone who understands the domain and is willing to push back.
The review conversation actually gets better when Alfred is in the loop, because the PR description is richer and reviewers spend less time asking “what does this even do?” and more time asking “should we do it this way?” That shift is worth more than it sounds.
Alfred is fast. It is not wise. The domain expert stays in the loop. That’s not a limitation we’re working to remove.
A few things we learned building this
Vague tickets lead to confident, incorrect implementations. The gate that refuses to run on bad tickets is not optional. Build it first.
The project brief, the documentation integration, the repo awareness: these take more time to build than wiring up the LLM call. They’re also what separates plausible code from correct code. Don’t skip them.
Agent-generated PRs that get rubber-stamped accumulate risk. The workflow is designed to accelerate review, not shortcut it. The value of the whole system depends on the quality of the humans reviewing the output.
Alfred is a good assistant. It does its homework before it starts. The final call is still yours.