DevForge picks up a labeled Jira ticket, reads the whole repo, writes code and tests, validates them, self-corrects on failure, enforces engineering policy as code β then opens a draft PR for a human to approve. It never merges on its own.
Read the ticket, understand the codebase, write tested code, check it against the rules, and hand a clean draft PR to a human. Six disciplines, one loop.
The full sandbox repository is cloned per run and injected into the prompt, so generated code matches the project's real files, conventions, and APIs.
Before anything is committed, generated code runs through syntax checks and the project's own test suite β node --check then node --test.
When validation fails, the exact errors are fed back to the LLM to fix its own output β iterating up to three attempts. This is what makes it agentic, not one-shot.
The LLM is asked to refuse policy-violating tickets (semantic), and a deterministic Python gate scans every generated file against pattern rules. Both must pass.
Engineering rules live in versioned YAML, auditable in git. Add, remove, or tighten a constraint by editing a file β no code change, no redeploy.
Output is always a draft PR with the agent's reasoning and validation summary. A reviewer approves every merge β the agent never ships on its own.
Every run is a closed loop: generate β enforce policy β validate against real tests. A failure isn't the end β the validator's errors become the next prompt, and the agent tries again, up to three times.
Each attempt runs in a clean clone of the repo β no state leaks between tries, so every retry is reproducible and honest.
The policy text is in the prompt. If a ticket asks for something forbidden, the model refuses to generate code and returns the rule it would have broken.
Every generated file is pattern-scanned against the YAML rules β catching anything the model might have slipped through. Both layers must pass before a commit.
Engineering rules are declared in versioned YAML and enforced twice. A ticket asking to hardcode an API key, disable a security check, or touch production config is refused before any code is written β the ticket moves to Blocked with a full audit trail.
Three deterministic outcomes β success Β· failed Β· blocked β drive the downstream Jira transition every time. No ambiguity for the reviewer.
A developer adds one label. About thirty seconds later, the work is done, validated, and waiting for review β or safely blocked.
Low-code (Jira Automation + Power Automate) handles the event-driven orchestration and Jira write-backs; a pro-code Python / FastAPI service runs the agentic reasoning, with deterministic validation and policy enforcement.
A clean draft PR for legitimate work β a blocked ticket with a full audit trail for anything risky. Exactly what enterprises need to adopt AI in the engineering loop.