AI beats us at coding.
But it surely’s additionally higher and sooner at almost every part else: planning, QA, working with all of the instruments in your SDLC.
So why aren’t we letting brokers take options and bugs all the way in which, from ticket to manufacturing?
All we must always must do is resolve what to construct and let brokers do what they do greatest.
However they’ll’t.
As a result of everybody’s SDLC is handbook at the moment.
Approvals, evaluations, handoffs. All issues that make us really feel snug however are largely pointless.
“Everybody’s SDLC is handbook at the moment. Approvals, evaluations, handoffs. That every one seems to be like theater to brokers as a result of they simply need to run ahead.”
That every one seems to be like theater to brokers as a result of they simply need to run ahead.
So we have to redesign software program supply to serve brokers first.
Which means 3 issues must be in place: context, guardrails, and visibility.
- Context so the agent begins from a whole image of the work, not only a ticket title.
- Guardrails so it is aware of what’s in scope, what to go away alone, and when to cease and ask.
- Visibility so engineers can see what’s occurring with out having to observe agent logs all day.
Let’s construct the infrastructure to assist it, from the second a ticket lands to the second it ships.
What we’re constructing
Earlier than moving into the main points, right here’s the form of the entire thing.
It’s 5 phases that alternate between agent work and human gates.
Part 1: Planning – Flip a uncooked ticket into one thing an agent can truly work on with wealthy context, an in depth PRD, and a complete tech spec.
Part 2: In evaluate – A scorecard validates that the work is secure and scoped sufficient for an agent. A PM indicators off on the PRD, and the engineer indicators off on the tech spec. They go it on to a coding agent.
Part 3: In Improvement – A Cursor or Claude Code agent works on the ticket and retains the entity up to date because the agent works.
Part 4: Preview – As soon as the PR is open and working in a cloud setting, an engineer and PM can preview it. Then they’ll hand it off to a deploy stream.
Part 5: Deploy – Dwell checks in opposition to present incidents and freeze home windows, generates launch notes, and deploys it.
The remainder of this submit walks by means of every section, beginning with what you want in place earlier than any of it really works.
Stipulations: your context lake
For brokers to do their greatest work, they want the very best context — a stay mannequin of your engineering programs that each workflow and agent can learn from.
Particularly for this information, you’ll want three issues to be of their context:
- Providers, with tier (T1/T2/T3), proudly owning crew, repo hyperlinks
- GitHub information synced by way of Port’s native integration: repos, open PRs, current commits, CODEOWNERS
- Work gadgets from Jira, Linear, or GitHub Points, linked to the companies they contact
The workflows we’re about to construct can even pull information by way of MCP as they want.
For instance, if brokers need to write correct tech specs, they could need to learn previous ADRs, runbooks, or previous specs in Notion or Confluence.
To enhance the PRD, we’ll hook up with actual buyer issues, so you may also need to join MCPs for Zendesk or Intercom.
Part 1: planning
The entire workflow is triggered when a ticket is created. It might be in Jira, Linear, or simply in Port.
We advocate making a generic blueprint like work_item so each step reads from and writes to those fields:
service → linked to service entity in catalog
crew → from catalog possession
tier → T1 / T2 / T3
blast_radius → low / medium / excessive (calculated)
open_prs → rely in opposition to linked repo
active_incidents → boolean from incident tracker
prd → markdown, written by workflow
tech_spec → markdown, written by workflow
stage → incoming / enriched / prd_draft / prd_ready / spec_draft / spec_ready / prepared
Step 1: Enrich the tickets with particulars from the context lake
The workflow queries the context lake to resolve any lacking particulars within the work merchandise, corresponding to its element or label. It may additionally add the service tier, proprietor, and repo from the catalog, calculate the blast radius from the dependency graph, fetch open PRs, and verify for lively incidents. Every little thing will get written to the entity, and the ticket strikes on to the following stage.
Step 2: Draft the PRD primarily based on a PRD ability
Port AI runs a PRD ability in opposition to the ticket, the enriched entity, and related PRDs out of your data base. Draft lands on the entity; the stage strikes to prd_draft; PM will get a Slack ping.
The ability you write defines the construction.
Step 3: Pause for PM evaluate
If the primary draft is structurally full however skinny on proof. The PM can open Port AI chat from the entity and query the gaps:
“What number of prospects have requested for this within the final 6 months?”
“Which companies would this have an effect on? What’s been touched not too long ago?
“Why shouldn’t we construct this?”
Port AI will then replace the PRD primarily based on this dialog.
As soon as they’re proud of the PRD, the PM marks it prepared, and it strikes alongside.
Step 4: Draft the tech spec primarily based on a tech spec ability
Identical sample as earlier than however completely different inputs. Port AI runs a tech spec ability in opposition to the PRD, codebase information within the catalog or MCPs, and ADRs out of your data base. The draft lands on the entity, and the engineer will get pinged.
Step 5: Pause for engineer evaluate
The engineer can then open Port chat and iterate on the tech spec:
“What’s modified on this space within the final 30 days? Who’s been lively there?”
“Are there current patterns we must always comply with? Something we’re duplicating?”
“What may go incorrect? What recordsdata have precipitated incidents not too long ago?”
Primarily based on the chat, the tech spec will get up to date.
As soon as the engineer marks it prepared, it strikes to the following stage.
Part 2: in evaluate
Earlier than a ticket will be handed off to an agent, two issues must occur: it has to clear an automatic scorecard, and an engineer has to truly decide it up off the board.
The scorecard verify
The scorecard is your governance layer (it could actually additionally work as a situation within the workflow). It asks two questions on each work merchandise leaving Part 1:
- Is it scoped sufficient for an agent to do?
- Is it secure to automate proper now?
If any rule fails, the entity is marked as blocked with the explanation.
If every part passes, then it strikes to prepared and continues.
An inexpensive beginning algorithm:
The Kanban dashboard
One factor that breaks down quick with agentic workflows is that the work turns into invisible. You delegate one thing, the agent runs, and except you’re watching the agent’s logs, you don’t have any concept the place it’s. Multiply that by ten parallel brokers, and also you’ve misplaced monitor of your work.
“One factor that breaks down quick with agentic workflows is that the work turns into invisible. Multiply that by ten parallel brokers, and also you’ve misplaced monitor of your work.”
The repair is a dashboard in Port that places all work gadgets on one web page, grouped by pipeline stage.
I made a decision to indicate work in a customized widget that renders a Kanban board off the work merchandise entities, with columns working on statuses: Incoming → Planning → For evaluate → Able to Delegate → In Improvement → Preview → Deployed.
Part 3: In Improvement
At this level, your work merchandise or ticket needs to be enriched with ample context, a PRD, a tech spec, and approval from a PM and an engineer.
It’s time to go it to a coding agent to implement.
Let’s construct a delegation motion
Construct a self-service motion in Port known as “Delegate to Claude Code/Cursor.” It lives on the work merchandise entity and reveals up as a button on the Kanban card. Once you click on it, the motion constructs a immediate primarily based on the work merchandise and kicks off the agent.
The purpose is that the coding agent begins with a whole image of the work: what to construct, tips on how to construct it, which recordsdata are in scope, and the architectural choices already in place. It will possibly nonetheless reference Port whereas it’s working, however it’s higher to have as a lot data up entrance as potential.
Conserving the board sincere whereas the agent runs. Keep in mind the “ten parallel brokers, and also you’ve misplaced the plot” downside from Part 2? That is the place we clear up it.
3 Port automations take heed to GitHub occasions and replace the entity in actual time:
- PR opened → write the PR hyperlink to the entity, transfer stage to delegated
- PR merged → set stage to achieved, document the timestamp
- CI fails → flag the entity and transfer it to needs_attention
Engineers can see which tickets have lively PRs, that are caught in CI, and that are achieved, with out opening agent logs or GitHub notifications.
If you would like the agent to diagnose and retry CI failures quite than simply flagging them, that’s a separate sample lined within the auto-healing CI article.
As soon as the agent’s PR is open and prepared for human eyes, the work strikes to Part 4.
Part 4: preview
As soon as the agent’s PR is open, the work strikes into the preview section.
I received’t go into an excessive amount of element right here, however simply provide you with some concept of issues you may add to Port, every one independently helpful.
Choose what solves your present bottleneck.
AI as decide
Earlier than human evaluate, run a Port AI verify that compares the diff in opposition to the tech spec and flags any deviations, corresponding to modifications to “don’t contact” recordsdata or missed acceptance standards.
Spin up a preview setting
Add a self-service motion or automation that provisions a cloud setting for the PR department and posts the hyperlink on the PR.
See your PR queue
Construct a private dashboard for every engineer exhibiting each PR assigned to them, the preview setting to verify it, and the way lengthy it’s been pending.
Nudge reviewers
Add an automation or workflow on the work merchandise entity that pings the assigned reviewer in Slack with the PR hyperlink and work merchandise context.
Part 5: Deploy
This section is triggered when the reviewer from the preview section is proud of the agent’s work. It will possibly occur with a standing change or a self-service motion.
Earlier than something ships, the workflow runs stay checks in opposition to the present state.
Right here’s the final stream:
- Gate verify in opposition to stay state:
- Energetic incident on any service within the blast radius? Question PagerDuty. Maintain if sure
- Open freeze window, or one other deploy already in progress? Maintain
- Blast radius excessive? Require express engineer approval on the entity
- Deploy. The work will get deployed by means of a self-service motion in Port
- Generate launch notes. Port AI builds them from the entity: what was constructed (from the PRD), what modified (from the PR diff), what was examined. (Optionally, you may push it to your launch notes system)
If one thing goes incorrect, rollback is one click on (for you or an agent). It’s an motion on the entity, pre-loaded with the deployment reference so that you don’t waste any time.
If you wish to go additional, you may run a full launch threat evaluation earlier than the deployment even begins by routinely scoring change quantity, blast radius, and rollout technique. That’s a separate sample lined within the release risk assessment information.
Measure how briskly work flows
When investing in a workflow like this one, it is advisable see how properly it’s working. So let’s measure lead time: how lengthy it takes to go from ticket creation to manufacturing.
Each stage on this workflow writes again to the work merchandise: the stage transitions, who acted, when, so the information is already within the ticket.
So what you find yourself with is:
Lead time per service: how lengthy the typical ticket takes from “Prepared for ATR” to deployed, damaged down by service. Tells you which of them companies are genuinely autonomous and that are nonetheless bottlenecked on people.
Time spent per stage: the place work truly sits. If every part is piling up at “Able to Delegate,” your scorecard is simply too strict. If it’s piling up at “Preview,” reviewers are overloaded.
Delegation fee: what proportion of labor gadgets truly obtained delegated to an agent versus dealt with manually. The one quantity that tells you whether or not the system is in use.
Human intervention factors: which phases wanted somebody to step in. Buildup factors on this workflow present that brokers may want extra context, higher guardrails, or a special scorecard rule.
These numbers inform you one thing cycle time by no means will: the place within the supply course of your crew is definitely bottlenecked, and which steps are saving time versus including friction.
That’s the total workflow. We began with a two-line ticket and ended up with a monitored manufacturing deploy. And we had a human within the loop at each gate that wanted one.
If you happen to construct any agentic workflow, I hope you construct this one to see what agentic engineering is all about.
YOUTUBE.COM/THENEWSTACK
Tech moves fast, don’t miss an episode. Subscribe to our YouTube
channel to stream all our podcasts, interviews, demos, and more.
