Buff Development

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 Create a knowledge space See the demoWhat each team getsThe 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
Tasksfrom your backlogBriefyouDevelopmentcode · rulesTestsbuild · runCheckchange reviewDevelopmentcode · rulesTestsbuild · runCheckchange reviewDevelopmentcode · rulesTestsbuild · runCheckchange reviewSign-offyouDoneto your branchthe engineer takes part twice — when setting the task and at acceptance; in between, tasks run in parallel, each in its own environment

← scroll the diagram →

2–8 hto analyse a project, whatever the size of the codebase
14ready-made connections — Notion, Confluence, Google Drive, folders, Jira; Word, Excel, PowerPoint and PDF are read where they are
10 millionlines in the largest project: environment and tests built from scratch
0access 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

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

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

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

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 editorBuff
Who runs the taskA person: keeps the context, makes sure the model does not make things up, decides when it is doneNobody. The engineer approves the brief and accepts the result
Project rulesSet up by hand, different for every developerBuilt from your code, the same for every task and checked at acceptance
Who decides it is doneThe model, by its own judgementThe build and the tests, then your engineer
A long taskThe model forgets the requirements, oversteps the scope, bends the testsScope and acceptance are fixed by the algorithm; independent model roles carry out the steps
Parallel workOne task, one environment on the developer’s machineAn environment for each task is created and removed automatically
What remains afterwardsThe session is closed and the context is lostThe brief and the reasoning behind decisions arrive with the pull request and stay in your git
Where it runsInside your network, with a developer’s permissionsOutside 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

← 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 projectsin our test fleet: 17 languages, including 1C
7 yearswithout a human edit — the oldest project the system has handled
2.5 daysto prepare the environment and tests for a 10-million-line project with no documented build
Project analysis

← 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

← 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.

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

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
YOUR NETWORKsource gitproduction databasekeys and passwordsserverspersonal datayour environmentsall of this stays with youcopy of the codeBuffenvironments, tests, checks — hereonly by your decision

← 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

← 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

← 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
Ask in the space

← 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 Create a knowledge space Write to us

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