General Software Development
Engineering automation with a paper trail
Use PWR on the codebase you already have. Agents implement features, fix bugs, refactor and add tests on their own branches, and every change arrives as a pull request with validation output, an independent review and a human approval step.
Software engineers, SaaS companies and enterprise teams that want to automate well-scoped engineering work without lowering the bar for what merges.
How it works
General Software Development, step by step
- 01
Connect an existing repository
Install the GitHub App on the repository and set the project's validation command, for example your test and lint script.
- 02
Let PWR learn the project
PWR discovers your README, contribution guide and docs. You approve what agents may rely on.
- 03
Delegate scoped work
Launch templates for features, bug fixes, APIs, refactors, tests or a debt-reduction plan. Each produces tasks with acceptance criteria.
- 04
Approve pull requests
Review the diff, validation, CI status and the independent review on one page. Approve the exact commit and merge through the gate.
- Available
- Implemented and covered by automated tests in the current platform build.
- Beta
- Implemented; verification against the live external service is still pending.
- Upcoming
- Planned or in progress. Not usable yet.
Work on existing codebases
Analyze an Existing Repository
BetaA read-only run that returns an architecture summary to orient planning and onboarding.
Launch path is covered by automated tests; it reads a connected repository, which has only been verified against a simulated GitHub.
Features and bug fixes
AvailableTasks with acceptance criteria for the Software Engineer role. Bug fixes carry a regression-test-first criterion.
Task creation is available. Execution through to a pull request follows the beta GitHub workflow.
APIs and multi-step builds
BetaLarger work runs as a goal: a plan you approve, then tasks queued within a budget, each with its own pull request.
Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.
Refactoring and technical debt
BetaA planning run proposes a debt backlog. A refactor goal works through approved tasks with bounded retries when validation fails.
Controller logic is covered by automated tests with a stub agent and a simulated GitHub; live end-to-end verification is pending.
Approved project knowledge
BetaOnly knowledge entries a person approved are given to implementing and reviewing agents.
Knowledge is assembled by priority within a size budget. Retrieval-based selection is not built yet.
Delivery pipeline
Branch and pull request per task
BetaA fresh clone, a dedicated branch from a pinned base commit, a secret scan before the push and a pull request with evidence.
Verified end to end against a simulated GitHub; verification against live GitHub is pending.
Validation recorded by the platform
AvailableYour validation command runs after the agent and its output is stored with the run.
CI status as evidence
BetaCI results for the pull request head are recorded from webhooks or on refresh. Projects can require specific checks before merge.
Verified end to end against a simulated GitHub; verification against live GitHub is pending.
Independent review and human approval
BetaA separate read-only review job, then an approval bound to the commit. New commits invalidate both.
Verified end to end against a simulated GitHub; verification against live GitHub is pending.
Security review role
AvailableThe Security Engineer role reviews with read and shell tools and reports findings with severity, evidence and remediation. Disabling a control is declared forbidden for the role.
The role and its tool policy are available. Review runs on pull requests follow the beta GitHub workflow.
Quality and governance
Test Coverage Autopilot
BetaMeasured baselines, a ranked plan you approve, and tests-only pull requests. Python is verified end to end; Node and .NET are in beta.
End-to-end runs have been verified with pytest against a simulated GitHub; live verification is pending.
Roles, tenancy and audit
AvailableFive organization roles enforced on the server, tenant isolation and an append-only audit log.
Spend controls
AvailablePer-run cost caps, a monthly hard limit and low-balance notifications per organization.
Bring your own provider keys
BetaRun agents on your own provider account. A bound key never falls back to a PWR-managed key.
Verified against in-repo provider simulators; verification against the live provider is pending.
Questions
Does PWR work with an existing codebase or only new projects?
It is built for existing repositories. Most workflows require a connected repository, and the agent works from your code, your validation command and the project knowledge you approved.
Which languages does it support?
The implementation workflow is language-agnostic: the agent edits files and your validation command decides pass or fail. Coverage measurement is language-specific and currently verified for Python, with Node and .NET in beta.
Can it deploy what it builds?
No. PWR stops at a merged pull request, and merge needs a human approval. Deployment stays in your own pipeline.
How large a task can I hand over?
Tasks work best when they are scoped and have clear acceptance criteria. Larger work should run as a goal, which plans first, waits for approval, and then executes tasks within a budget and a task limit.
Is our code used to train models?
PWR does not train a foundation model. Runs send repository context to the third-party model provider selected for the run, so that provider's data terms apply. You can restrict which providers are approved and use your own keys.
Put an AI development team on your idea.
Describe what you want to build. PWR plans, builds, tests and reviews it, and you approve each step that matters.