Features
Autonomous development — from task to pull request
Project analysis, answers about code and documents, deep research, development with review and a pull request to your repository. All in the cloud, with no access to your infrastructure: you set the task and accept the result.
What the system does
Eleven tools around your code and documents
Task writing
Describe the task in words — the system clarifies the details and shows you a brief to approve.
Learn moreAutonomous pipeline
A task is broken into subtasks that run in parallel, each in its own environment; progress is shown on a diagram.
Learn moreReview
Changes are reviewed with comments; you approve them or send them back for rework.
Learn morePublishing
Once approved, a pull request to your repository on GitHub, GitLab, Bitbucket or Gitea.
Learn moreAsk
A question about the code, connected trackers and documents — an answer in minutes with links to the source, without changing anything.
Learn moreDeep research
A solution is worked out before the code: a checked document, exportable to PDF and Markdown.
Learn moreKnowledge space — no code
For departments without code: questions and research on policies, contracts and reports — answers with a link to the document.
Learn moreAudits
Project analysis in ten areas — the rules come from your code.
Learn moreProject onboarding
Connecting a repository, with build and tests as the project’s baseline.
Learn moreMembers and roles
Organisations, member roles and repository access.
Learn moreBuff Code — for developers
For those who write the code themselves: a terminal and an app on the organisation’s models, knowledge and connections.
Learn moreTool 01
First, it gets to know your code
Ten areas: architecture, testability, build, dependencies, data and security, development process, behaviour, interface, environment constraints, contracts.
The rules come from your code, not from our idea of what is right
Each section has a status and a date. When the code moves on, the system warns that a section is out of date; you can refresh a single section and the rules change at once. Analysis takes 2–8 hours whatever the size of the codebase.
Tool 02
An answer about the code in minutes, without changing anything
Works as soon as a repository is connected — before the project analysis and the first task.
Ask about any part — the answer links to the files
The system reads the source — and the connected trackers and documents — and answers to the point: where a response is built, how a query is escaped, where to make a change. You can follow its reasoning, and attach files to a question.
Tool 03
The solution is worked out before the code
For questions where options need comparing first and code comes later.
An analyst and a reviewer prepare a checked document
The document takes shape as the work goes, and you steer the research in a conversation. The result exports to PDF and Markdown — attach it to a decision or pass it to a task as a requirement.
Tool 04
From a description in words to a finished change
The engineer takes part twice — when setting the task and at acceptance. In between, the task runs on its own.
The brief is agreed before the start, and progress is visible by subtask
The system asks clarifying questions and shows the brief: what is in scope, what is out, the acceptance criteria. Once you approve it, the task is broken into subtasks that run in parallel, each in its own environment with build and tests.
Tool 05
A change is reviewed — before it reaches your code
You only read what was agreed: a change arrives already put through the build and tests.
Comments with their status, the decision is yours
A separate reviewer — a model role that did not write the code — comments on the debatable places; you accept, reject or edit each comment. Approve or send back for rework — once approved, the system opens a pull request in your repository on GitHub, GitLab, Bitbucket or Gitea. You do the merge.
A task’s path
One continuous flow — from words to a pull request
The forks are where the system checks details with you, merges parallel edits itself or waits for your decision.
Task description
In plain words, without a three-page specification.
Clarifying questions
If something is missing, the system asks you rather than guessing.
Brief and plan
The scope of edits and the acceptance criteria — you approve them before the start.
Development
Subtasks run in parallel, each in its own environment with build and tests.
Merging edits
Parallel changes are combined, and a main branch that has moved on is merged into the task.
Change review
A separate reviewer goes through the change and comments on the debatable places.
Your decision
Approve, or send back for rework with a comment.
Pull request
A finished change in your repository; you do the merge.
Forks along the way
Clarifying questions
If something is missing, the system asks you rather than guessing.
Overlapping edits
When changes run in parallel, the system merges them itself before review.
Comments → rework
Review and rework run in a loop until the change is clean.
You have the final say
Nothing goes into your repository without your explicit “yes”.
Connecting takes minutes
Connect a repository
Questions about the code work straight away, and project analysis takes hours. By the time you hand over the first task, you will know how the system reads your project. A starter balance is included so you can try it.
Companies and sole traders can pay by bank transfer and receive closing documents