# Buff Development

> AI for the whole company: autonomous development, answers from documents for every department, Buff Code for engineers — a platform overview.

The company’s AI platform · runs within your perimeter

# AI for the whole company, *not just for developers*

Buff answers any department from the company’s documents — support, sales, legal, HR, finance. For development, it takes tasks from request to a finished code change ready for review; for engineers, it provides a development environment on the organisation’s models. A person approves the brief and accepts the result.

[Connect a repository](https://buff.systems/app) [Create a knowledge space](https://buff.systems/app) [See the demo](https://buff.systems/en/demo) [What each team gets](https://buff.systems/en#entrances) The connector — a small program in your network, outbound connections only by default — is installed once; the first question about your documents or code takes minutes after connecting

← scroll the diagram →

**2–8 h** to analyse a project, whatever the size of the codebase

**14** ready-made connections — Notion, Confluence, Google Drive, folders, Jira; Word, Excel, PowerPoint and PDF are read where they are

**10 million** lines in the largest project: environment and tests built from scratch

**0** access into your network: no service keys, no production database

One platform, three ways in

## Each department comes in from its own side — and works in one place

[Development For engineering leaders and their teams A task goes the whole way on its own: clarifying questions, a brief for your approval, development in separate environments with build and tests, an independent check — and a pull request to your repository. The engineer takes part twice: to approve and to accept. How a task runs](https://buff.systems/en/product) [Knowledge space For support, sales, legal, HR, finance, marketing and management A question about policies, contracts, price lists or reports gets an answer with a link to the document, and conflicts between documents are named. Research comes back as a finished document. Documents stay where they are: in Notion, Confluence, on Drive, in the department’s folders. What it gives a department: examples for support, sales, HR](https://buff.systems/en/business) [Buff Code For engineers who write the code themselves An agent in the project folder, under your control: every edit is visible and any step can be rolled back. Plans for large tasks, scheduled checks, reviews by several hands. On the organisation’s models, knowledge and connections, with no keys on laptops and every step recorded. How Buff Code works](https://buff.systems/en/buff-code)

**Shared by all three:** a connector in your network · the organisation’s knowledge base · an audit log · roles and SSO · one balance and plans. A system that is not in the connection catalogue can be connected by your IT specialist with a tool of their own — ready-made or written from our documentation — and the AI agent can use it straight away.

[All three are on your phone too: approve a task, ask about your documents, allow a command for the Buff Code agent from an iPhone or Android, with a notification when something is waiting for you. Mobile app](https://buff.systems/en/mobile)

Objection 01

## “We already use AI agents. Why another tool?”

The most common question. An agent does write code fast — and that is exactly why your review queue keeps growing.

### An agent speeds up one person. We take the person out of the loop

The difference is not the model, but who runs the task and who decides it is done.

|  | AI agent in the editor | Buff |
| --- | --- | --- |
| Who runs the task | A person: keeps the context, makes sure the model does not make things up, decides when it is done | Nobody. The engineer approves the brief and accepts the result |
| Project rules | Set up by hand, different for every developer | Built from your code, the same for every task and checked at acceptance |
| Who decides it is done | The model, by its own judgement | The build and the tests, then your engineer |
| A long task | The model forgets the requirements, oversteps the scope, bends the tests | Scope and acceptance are fixed by the algorithm; independent model roles carry out the steps |
| Parallel work | One task, one environment on the developer’s machine | An environment for each task is created and removed automatically |
| What remains afterwards | The session is closed and the context is lost | The brief and the reasoning behind decisions arrive with the pull request and stay in your git |
| Where it runs | Inside your network, with a developer’s permissions | Outside your network, with no access to your infrastructure |

Objection 02

## “A finished change is not a result. You are just shifting the review onto us”

A team’s bottleneck is not writing code but reviewing it. A tool that fills that queue faster makes things worse.

### You only read what was agreed

A change arrives already put through the build and tests, with the scope of edits agreed before the start, and with comments on the debatable places from a separate reviewer — a model role that did not write the code. **During the review itself, the engineer works together with the AI:** asks questions about the change, and accepts, rejects or edits each comment. Accepted ones go into the project rules and do not come up again.

**Change review** before your code

← scroll the frame →

**Comments with their status (highlighted).** Approve or send back for rework — nothing reaches the main branch without your decision.

Objection 03

## “The model will break what works and then tell you all is well”

On a long task an agent forgets the requirements, bends the tests to fit the result and edits things it should not along the way. We know this.

### A task is closed by the build and tests, not by the model’s say-so

Done is not the model’s opinion but the result of a check that cannot be bypassed.

#### Tests before and after the task

Whatever failed before is marked separately, and you decide what happens to those tests.

#### A test cannot be bent to fit the result

Work on tests is planned before the code is written and limited separately from it.

#### The scope of changes is known in advance

Which files a task will touch is agreed before the start. Going beyond that is blocked.

#### An independent check at every step

Development and review are done by different model roles, each in its own context, and acceptance by the build, the tests and you: a mistake by one does not go unnoticed.

#### The same rules on every run

The project rules are the same for every task, given to the implementer and checked at acceptance.

#### Conflicts are resolved automatically

Parallel changes are merged together with their tests, and a main branch that has moved on is merged into the task before it is merged back.

Objection 04

## “My code is different. An old project with no tests, no documentation and no author”

A fresh project with a clean structure proves nothing. The proof is the code people are afraid to touch.

### No tests? They will appear. No environment? It will be built

Before changing anything, the system analyses the project in ten areas, singles out the important parts, covers them with tests and records the current behaviour. The rules come from your code, not from our idea of what is right.

**20 projects** in our test fleet: 17 languages, including 1C

**7 years** without a human edit — the oldest project the system has handled

**2.5 days** to prepare the environment and tests for a 10-million-line project with no documented build

**Project analysis** 10 areas

← scroll the frame →

**Ten areas of analysis (highlighted)** — each section with its status and date; the project’s tests and rules are built from them.

**An answer about the code** in minutes

← scroll the frame →

**An answer about the code (highlighted)** — how FreeScout fetches mail, with links to files and lines, without touching the code.

Integrations

## Works where your team already works

An integration connects Buff to your system — a tracker, a service, an internal API — and stays inside your network. It installs into a running connector, without a rebuild or reinstall.

- [Bitbucket Cloud 1.1.0 Questions and answers right in bitbucket.org pull requests — where the review happens. 3 of 4 tools only read](https://buff.systems/en/marketplace/bitbucket-cloud)
- [Bitbucket Data Center 1.1.0 Questions and answers right in the pull requests of your Bitbucket Data Center or Server — where the review happens. 3 of 4 tools only read](https://buff.systems/en/marketplace/bitbucket-dc)
- [Confluence 1.1.0 The team’s knowledge base as context for answers — and questions right in the page discussion. Data Center, Server and Cloud. 3 of 4 tools only read](https://buff.systems/en/marketplace/confluence)
- [Figma 1.1.0 Designs as context: parameters, tokens and screen structure for any model, the picture for one that can see. Questions in design comments. 7 of 8 tools only read](https://buff.systems/en/marketplace/figma)
- [Files on disk 1.0.3 Folders on the server and SMB network folders as context: Word, Excel, PowerPoint — new and old formats — PDF and text. Read only, no index. 3 of 3 tools only read](https://buff.systems/en/marketplace/files)
- [Gitea 1.1.0 Questions and answers right in the issues and pull requests of your Gitea or Forgejo — where the team already discusses the code. 3 of 4 tools only read](https://buff.systems/en/marketplace/gitea)
- [GitHub 1.1.0 Questions and answers right in GitHub issues and pull requests — both in the github.com cloud and in Enterprise Server inside your network. 3 of 4 tools only read](https://buff.systems/en/marketplace/github)
- [GitLab 1.1.0 Questions and answers right in the issues and merge requests of your GitLab — your own installation or gitlab.com, either way. 3 of 4 tools only read](https://buff.systems/en/marketplace/gitlab)
- [Google Drive 1.1.0 Google Docs, Sheets and Slides as context for answers, and questions right in comments. The research report comes back as a document in the same folder. 5 of 7 tools only read](https://buff.systems/en/marketplace/google-drive)
- [Jira 1.5.0 Tasks, questions and answers right in Jira Data Center and self-hosted Server tickets — without leaving the tracker your team already works in. 2 of 3 tools only read](https://buff.systems/en/marketplace/jira)
- [Jira Cloud 1.1.0 Tasks, questions and answers right in Jira Cloud tickets — without leaving the tracker your team already works in. 2 of 3 tools only read](https://buff.systems/en/marketplace/jira-cloud)
- [Notion 1.1.0 Notion pages and databases as context for answers — and questions right in the page discussion. The research report comes back as a page. 6 of 8 tools only read](https://buff.systems/en/marketplace/notion)
- [Redmine 1.1.0 Questions and answers right in Redmine issues — in the tracker you already have, which is not going anywhere. 2 of 3 tools only read](https://buff.systems/en/marketplace/redmine)
- [Internet 1.0.3 Search and read public pages from your perimeter, within the admin’s allow and block lists. DuckDuckGo without a key, your own SearXNG, Brave with a key. 2 of 2 tools only read](https://buff.systems/en/marketplace/web)
- ### Not there yet? We curate the catalogue: only what we have built and signed gets into your network. New integrations appear on request — including for an internal service. And you can connect your own tools yourself: your administrator marks which of them the model is allowed to read. [Send a request](https://buff.systems/en/contact)

Before installing you can see where the integration will be able to go, which credentials it will ask for and which tools the model will see. Tokens stay in the connector — the integration does not see them; the one exception (the network folder password) is named on its page.

[The full integration catalogue](https://buff.systems/en/marketplace)

Objection 05

## “I will not let an outside service near my code”

Your security team will ask what exactly leaves the network and who sees it. The answer should be short.

### We need nothing critical to do the work

No access to your infrastructure, no service passwords or keys, no production database, no personal data of your users. A copy of the code is enough.

- The key to your git can stay in your network — a small agent on your side does the transfer
- No production database needed: test data is generated from its structure
- Our workers run outside your network, and they cannot be started with their restrictions lifted
- Copying is one-way, and nothing reaches the main branch without your decision
- Isolation by organisation, role-based access, two-factor sign-in or your SSO
- GitHub, GitLab, Bitbucket, Gitea — including servers inside your network

← scroll the diagram →

Objection 06

## “Pay-per-use is an open-ended meter. I have to protect the budget”

Especially now, when every new line of spending has to be justified.

### You pay for work done, not for licences and seats

You are billed for completed tasks. Adding people costs nothing, and there is no annual contract. **Only what you have paid in is charged: no new work starts on a zero balance.** A task can be stopped at any time and resumed later, and finished parts are not charged again.

**Spending by task and stage** with export to a file

← scroll the frame →

**You can see where the money went:** audit, research, questions, preparation — for every task and operation, with the amount and repository, exportable to CSV. Companies and sole traders can pay by bank transfer and receive closing documents.

Objection 07

## “I buy it, but the team has to use it. They won’t”

A tool that “does the developers’ job” meets quiet sabotage. Two months later the initiative is dead.

### Engineers do the work they want to do themselves. The rest gets done

Start with the tasks nobody takes on: small debt, upgrades, tests for old code. An engineer hands over what they have been putting off for three months and stays the one who sets and accepts the work. You can see who hands over how many tasks and how acceptance goes, so a fading initiative shows at once, not a quarter later.

*01*

#### Hand over a long-postponed task

One you cannot give to a newcomer and do not want to take a strong engineer off their work for.

*02*

#### Approve the brief

The system asks clarifying questions and shows the scope of edits and the acceptance criteria.

*03*

#### Accept the result

A finished change with comments from an independent check. Approve it or send it back.

Objection 08

## “What if you shut down in a year?”

A young vendor is a risk. What will I have left besides the code?

### Everything we produce stays with you

Every change arrives with its brief and the reasoning behind its decisions — not on request when we part ways, but on every task. Project analyses and research can be exported to your knowledge base at any time. You own the rights to the code.

**The task’s brief** travels with the code

← scroll the frame →

**Code written here is better documented than code written by people:** why it was done, what it touched, how it was checked.

Objection 09

## “We don’t write code — why would we need this?”

Support, sales, legal, HR and finance ask about policies, contracts and reports, not code. And they need an answer from the document, not from memory.

### In a knowledge space, questions are answered from your company’s documents

Policies, contracts, price lists, reports and FAQs stay in Notion, Confluence, Google Drive or the department’s folders, and designs in Figma — the AI agent reads them where they are, answers with a link to the document and names any conflicts between documents. No code is needed; developers keep working in their own projects in the same organisation.

[A knowledge space for the company’s departments](https://buff.systems/en/business)

**Ask in the space** from documents

← scroll the frame →

**The documents disagree** — and the answer says so itself: 4 hours in the contract and the policy, 8 in an outdated FAQ, each file named with its section.

Other questions

## In short: what people ask next

### What happens in the first half hour?

You connect a repository, and questions about the code work straight away, with answers in minutes. Project analysis is started separately and takes 2–8 hours, and preparing the environment and tests for a heavy project takes up to a few days. Questions about the code are available the whole time.

### The team keeps working in the same repository. Won’t things drift apart?

The copy is updated when you say so. If the main branch has moved on, the task merges it in before merging back and resolves the differences. Conflicts are resolved automatically.

### Won’t the project analysis be out of date in a month?

Each section shows how many commits ago it was made, and the system warns you when it is badly out of date. You can refresh a single section, and the rules change at once.

### What will you definitely not do?

We do not choose the architecture — that is for your engineers to decide; pass it on as a requirement. For now we advise against handing over large new product features: the result is unpredictable, and we say so up front.

### Who is responsible if a change breaks something?

A person makes the decision: a change reaches the main branch only after your engineer approves it. We are responsible for making sure that, by the time of approval, there is a brief, an automated check, a fixed scope and an explanation of the decisions.

### How many tasks at once?

Up to a hundred subtasks in parallel, and capacity grows with the load within a few hours — on request too. There is no limit on the number of tasks per project.

### Is there a mobile app?

Yes, for iPhone and Android. Approve a brief, answer the agent’s question, accept a review, ask about your documents, allow a command in Buff Code — from your phone, with notifications. A phone is connected from the workspace or Buff Code in a minute, and messages are encrypted so that the buff.systems gateway cannot read them. The app is free: usage is billed under the organisation’s plan.

The first step changes nothing in your code or your documents

## Start with a question about your project or your documents

Connect a repository and ask how your code works — or create a knowledge space and ask about a policy, a contract or a report: the AI agent reads and answers in minutes without changing anything. A starter balance is included so you can try it.

[Connect a repository](https://buff.systems/app) [Create a knowledge space](https://buff.systems/app) [Write to us](mailto:info@buff.systems)

Companies and sole traders can pay by bank transfer and receive closing documents