Managed AI engineering that ships your roadmap without a hiring round
Your roadmap is longer than your team, and another hiring round will not close that gap soon. I set up and run my software factory in your repositories, and your roadmap arrives as reviewed pull requests.
- 1
Workflow review: I find where AI and my factory move your team faster
I look at how work moves through your team today, from ticket to production: where AI helps, what my software factory can take on, how to configure it for your codebase, and the security issues I find along the way. You leave with a plan either way. From you: access to your repositories and CI, and a walkthrough of how your team ships.
- 2
Onboarding: one to two weeks setting the factory up with your team
I set the factory up in your repositories and tune it to your architecture, conventions and review rules. This is when I work most closely with your team, agreeing how work reaches the factory and how its changes come back for review. From you: your conventions, your review rules, and the people who know them.
- 3
Steady state: your roadmap arrives as reviewed pull requests
The factory plans, builds and reviews work from your roadmap, and each change reaches you as a reviewed pull request. You get architecture direction from me. From you: priorities, and sign-off where your approval workflows ask for it.
The managed factory is a set of agents I run, taking each ticket to a pull request
The factory is a set of AI agents I run on a machine I operate. It takes each of your tickets through research, a plan, the build, an independent review and its fixes, on a branch of its own.
Each ticket is sized first, so a small change skips research and goes straight to a plan, and a large one is researched before anything is built.
The factory builds and reviews on its own, and I own the decisions around it
Without me, the factory builds each change, has it reviewed by models that did not write it, runs the fix rounds and opens the pull request.
I own the workflow review and onboarding, read the plans that matter, set the architecture, answer the questions the factory raises at its gates, and step in when something sticks. Your approval workflows say which changes need your sign-off before they merge.
In a month you order tickets and sign off where you choose
You add and order tickets, and reviewed pull requests arrive in your repositories. You sign off where your workflows ask, and usage reporting shows what the inference and compute went on.
Each engagement covers onboarding and integration, the managed engineering itself, the model inference, infrastructure and compute the work needs, and more repositories as you need them.
When review finds the plan is wrong, the fix goes to the plan, not the code
A fix round may edit code and may not edit the approved plan. So when review finds that the plan itself is wrong, a fix round cannot converge: it can only patch around the plan until the round limit stops it.
A finding that cites the plan instead of the code now goes back to a plan revision. The build restarts from the first part of the plan that changed, code findings from the same review still get their fix round, and a plan still wrong after one revision comes to me.
Start with a workflow review of how a change moves through your team today.
How a change reaches your repository
- Your ticketYou write and order the work
- Research and planAs much as the ticket’s size calls for
- Built on its own branch
- Independent reviewA finding against the plan revises the plan
- Each fix reviewed again
- Pull request in your repo
- Your sign-off, then mergeWhere your approval workflows ask
Capabilities
Engagement
- Workflow review
- Integration with GitHub or GitLab
- Custom agent skills and checks
Oversight
- Senior engineering ownership of architecture and quality
- Usage reporting
- Approval workflows
Stack
- Go
- Python
- Kubernetes
- Terraform
- AI agents and orchestration
- MCP