---
slug: raft-build-is-now-source-available
assetPath: /resources/blog/raft-build-is-now-source-available
title: Исходный код Raft.build теперь открыт
description: Почему Raft публикует только снимки релизов и какой новый способ совместной работы нужен открытой разработке теперь, когда агенты пишут так много кода.
metaDescription: Как работает open source, когда код пишут ИИ-агенты? Почему Raft публикует source-available-снимки релизов и как Pull Request уступает место Prompt Request.
categoryKey: engineering
tagKeys: engineering, opinion
publishedLabel: 24 сентября 2026 г.
author: Richard
heroImage: /resources/blog/raft-build-is-now-source-available/raft-source-available-cover-1200x630.png
socialImage: /resources/blog/raft-build-is-now-source-available/raft-source-available-cover-1200x630.png
heroAlt: Агенты Raft связывают снимки релизов в рабочем процессе софта с открытым исходным кодом
canonicalUrl: https://raft.build/ru/resources/blog/raft-build-is-now-source-available/
datePublished: 2026-09-24
dateModified: 2026-09-24
---

> Источник: официальный блог Raft · https://raft.build/ru/resources/blog/raft-build-is-now-source-available/

[https://github.com/botiverse/raft-source](https://github.com/botiverse/raft-source)

Мы только что открыли исходный код Raft (source-available) под лицензией FSL-1.1-ALv2.

Но внутреннюю историю коммитов Git мы не публикуем и пока не принимаем Pull Request. Публичный репозиторий — скорее зеркало релизов Raft: с каждым новым релизом мы выкладываем туда полный снимок кода.

Так задумано.

Нам всё больше кажется, что теперь, когда агенты уже пишут огромную долю кода, «открытой разработке» может понадобиться совсем другой способ совместной работы, чем прежде.

## Писать код когда-то было дорого

Раньше писать код было дорого.

Чтобы прислать действительно ценный Pull Request, контрибьютору нужно было сначала разобраться в проекте, найти проблему и потратить время на реализацию. К тому моменту, как код попадал к мейнтейнеру, контрибьютор уже вложил в него немало сил.

Эти затраты сами по себе работали как фильтр.

Агенты это изменили.

Сегодня сгенерировать правдоподобный патч почти ничего не стоит, а сгенерировать десять — ненамного дороже. Но мейнтейнеру вникнуть в десять патчей и внимательно их проверить дешевле не стало.

Поэтому сама отправка кода уже не отсеивает слабые правки так, как раньше.

Мы почувствовали это ещё во время работы над Kimi Code CLI. Когда мейнтейнеры знают кодовую базу, контекст продукта и направление развития лучше внешних контрибьюторов, часто проще отдать стоящую за изменением идею своему агенту и дать ему переписать всё заново, чем тратить время на чтение реализации, которую сгенерировал чужой агент.

> **Пул-реквестам в опенсорсе приходит конец**
>
> Реализация дешевеет, и мейнтейнеру может оказаться проще отдать идею своему агенту и реализовать её заново, чем проверять код, сгенерированный чужим агентом.
>
> xxchan (@xiaoxxchan) · Статья в X · [Читать статью в X](https://x.com/xiaoxxchan/status/2017152237689327784)

Так настоящее узкое место сместилось выше по течению.

Главный вопрос теперь не:

«Можно ли это написать?»

А:

«Стоит ли это вообще делать?»

## От Pull Request к Prompt Request

Peter Steinberger называет одну из возможных новых форм «Prompt Request».

Интересное направление.

> **Pull Request → Prompt Request**
>
> Peter Steinberger сказал мне, что хочет, чтобы PR означал «prompt request». Его агенты вполне способны реализовать большинство идей, так что незачем брать вашу идею, раздувать её в бесплатном ChatGPT до каши из вайб-кода и присылать это как PR — а сейчас так выглядит большинство PR.
>
> Andrej Karpathy (@karpathy) · Пост в X · [Читать пост в X](https://x.com/karpathy/status/2040473058834878662)

Если ваш агент написал код, а наш агент потом его читает, проверяет и, может быть, даже переписывает заново, — зачем двум агентам вообще общаться через код?

Возможно, разумнее передавать намерение напрямую.

Но Prompt Request не должен буквально означать «пришлите нам промпт».

Ведь промпт тоже легко сгенерировать.

Если в итоге спам из PR просто превратится в спам из промптов, ничего не будет решено.

По-настоящему ценный Prompt Request должен давать больше контекста: какую проблему вы хотите решить, в какой ситуации она возникает, почему её стоит решать, какие есть ограничения и компромиссы. А в идеале за ним должен стоять человек, готовый и дальше участвовать в обсуждении.

И что ещё важнее, отбор должен происходить до реализации.

Может быть, сигналом станет репутация контрибьютора; может быть, идею сначала нужно обсудить; может быть, мейнтейнеры будут прямо говорить, в каких задачах им сейчас действительно нужна помощь сообщества; может быть, агенты помогут людям оспаривать, объединять и дорабатывать множество предложений и отбирать те немногие, что действительно заслуживают внимания.

Центр тяжести вклада смещается от реализации к вопросам уровнем выше.

Раньше контрибьютор присылал конкретную реализацию.

Теперь, возможно, ценнее будет помочь всем определить:

«Что должно существовать и почему».

Когда с этим ясно, реализация часто оказывается самой простой частью.

## А как же история коммитов Git?

Мы начали заново присматриваться и к другой давно привычной вещи — истории коммитов.

В публичном репозитории Raft нет полной истории Git из внутренней разработки: мы публикуем только снимки кода для каждого релиза.

Это не значит, что история Git бесполезна.

Она по-прежнему полезна для отладки, bisect и аудита и помогает понять, как система шаг за шагом развивалась.

Но мы всё больше сомневаемся, что цепочка «что поменялось в коде» — по-прежнему лучший способ записывать историю разработки.

Действительно важный контекст всё чаще живёт за пределами кода:

Зачем тогда это поменяли?

Какую проблему мы изначально пытались решить?

Какие ещё варианты рассматривали?

О чём человек попросил агента?

Что агент обнаружил по ходу работы?

Какие попытки провалились?

И что в итоге заставило нас передумать?

В тысяче коммитов может оказаться меньше ценного, чем в разговоре, из которого эта тысяча коммитов появилась.

На деле даже внутри команды мы теперь всё реже разбираемся в системе только по истории Git. Агенты, конечно, по-прежнему заглядывают в коммиты, когда нужно, но коммиты постепенно становятся лишь одним из многих источников контекста.

Возможно, agent-native разработке нужна более богатая «история».

Не только история кода.

Но и история решений, история намерений, история разговоров.

Поэтому «открыть процесс разработки» в будущем не обязательно будет означать выложить все промежуточные изменения кода.

Возможно, важнее открыть то, что действительно объясняет, почему софт стал таким, какой он есть.

## Что значит открытая разработка, когда реализация достаётся почти даром?

Именно это мы и хотим исследовать на примере Raft.

Нас волнует не только то, как публиковать исходный код, но и другое: как людям участвовать в открытом проекте, когда сама реализация стала предельно дешёвой?

Что после Pull Request станет новым главным способом внести вклад?

Как находить и отбирать хорошие идеи?

Какой контекст должен быть публичным?

Что должна фиксировать по-настоящему осмысленная история разработки, когда большую часть реализации делают агенты?

Pull Request никогда не был законом природы в мире open source.

История коммитов Git — тоже.

Это просто механизмы, которые сложились под влиянием определённых инструментов, структуры затрат и способов совместной работы.

Теперь изменились инструменты, изменилась и структура затрат в разработке.

Мы хотим посмотреть, какими будут новые способы работать вместе.

---

Впервые опубликовано 24 сентября 2026 года в [X](https://x.com/istdrc/status/2103168507878011088).
