Тысяча строк кода за час. Потеря понимания системы за три дня.

Claude Code и Codex сильно изменили процесс разработки, еще год назад главным ограничением был код. Сегодня код стал самым дешевым ресурсом в процессе создания продукта.

За час можно сгенерировать тысячу строк, но если у вас в голове нет ясной модели того, что вы делаете, к третьему дню эти строки начнут противоречить друг другу. Понимание системы или сбор контекста сегодня главное в работе с агентами.

Раньше понимание системы было побочным продуктом работы: разработчик получал задачу, сам придумывал и писал решение, проверял его и обновлял документацию. Пока он писал код своими руками, понимание системы само оседало у него в голове.

Агенты этот побочный продукт убрали. Теперь от старого процесса осталось только одно — понять задачу и правильно объяснить её агенту. Дальше агент сам предлагает решение и сам пишет код, а разработчик может не углубляться в то, что именно получилось и, главное, почему так получилось. Код есть — понимания нет.

Принцип «пиши для людей» при этом теряется. Каждый следующий разработчик пишет точно так же — с помощью агента, поверх кода, который он не понимает, написанного коллегой тоже с помощью агента. В какой-то момент из команды понимание пропадает полностью. В конечном счете, почему в вашем продукте существуют какие-то куски кода знает только агент.

Код — точка истины продукта. Когда его понимает только агент, хаос в коде превращается в хаос в команде. Аналитик приходит к разработчику уточнить, как организована система под новую фичу, а тот не знает.

Сам цикл работы должен измениться. Понимание нужно вынести на уровень выше кода, в управляемый контекст.

Было:

Понял задачу → Написал код → Задокументировал

Стало:

Контекст → Генерация → Контекст

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

Контекст стал главным, он участвует и на входе, и на выходе. На входе агента нужно накормить: дать ему информацию о вашей системе, о задаче, о код-стайле и т.д. На выходе систему нужно дополнить новыми знаниями, иначе следующая итерация стартует вслепую.

Эта информация (артефакты), как правило разбросана и хранится в компании в разных системах: задачи в Jira, документация и спеки в Confluence, пулл реквесты и Issues в GitHub.

Если посмотреть на этот процесс со стороны, становится очевидно, проблема больше не в генерации кода. На поиск этого контекста и оформление результатов уходит большая часть рабочего дня, больше, чем сама генерация.

Резонный вопрос, зачем отдельный продукт? Агента ведь можно подключить к Jira напрямую, через MCP.

Если коротко, MCP — это способ соединить ИИ-агента (тот же Claude Code) с рабочим инструментом вроде Jira, чтобы агент сам вытягивал из него задачи и контекст. Звучит так, будто проблема уже решена.

Но есть нюанс. Такое подключение каждый разработчик настраивает себе сам. В итоге у каждого свой агент, подключённый к рабочим системам по-своему — без общих правил, доступов и контроля. У этой проблемы есть название: теневой ИИ — когда сотрудники сами, неконтролируемо тащат нейросети в рабочие процессы. И это уже происходит, с согласованием в компании или без.

Но популярные клиенты нейросетей на сегодня это не командный инструмент, а индивидуальный.

Даже если всё согласовано, подключив MCP, вы закрываете не весь процесс, а каждого человека по отдельности.

На инженерный процесс надо смотреть не сбоку, а сверху. В разработке участвует команда, а многим из команды даже не знаком термин MCP.

Поэтому в процесс придется внедрять человека, который будет всем настраивать Claude Code одинаково, как менеджеру, так и разработчику, плюс обслуживание.

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

После того как нам понадобилось только объяснять и проверять, мы стали упускать детали.

Если вы как и я ревьюете код после того как агент его генерирует, нет никакой гарантии в том, что ваш коллега легко и просто откроет и поймет все от строчки до строчки.

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

И здесь важны выходные данные. Мы с легкостью можем получать на выходе комментарии о проделанной работе для задачи в Jira, summary для пулл реквеста в GitHub или расширенный функционал для документации в Confluence.

Но снова столкнемся с той же проблемой — время.

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

Становится очевидно, что для автоматизации этих процессов требуется класс решений, который предоставит нам полную работу над контекстом: от поиска до оформления результатов, с историей — что, как и зачем менялось. И так, чтобы этот контекст был управляемым: доступами, правами и нужными инструментами.

Решение, которое мы используем для данной проблемы называется Laplace.

Laplace — это командная AI платформа для управления рабочим контекстом.

Воркспейс — это комната для определенного круга лиц, с определенными инструментами и правами. Вы сами определяете, какой контекст будет доступен всем участникам воркспейса и из каких инструментов.

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

Подключение к Jira, Confluence и GitHub не требует от вас никаких усилий: мы не храним контент из ваших систем, а синхронизация работает буквально по одной кнопке.

Задавайте любые вопросы касательно системы, с которой вы работаете, прямо из чата, получайте понимание, Laplace сам поймет из какого источника ему вытянуть контекст, без затраты вашего времени на поиск.

А затем сразу переходите к действию: создавайте/редактируйте или комментируйте задачи, документы или пулл реквесты.

Я убежден в том, что процесс работы изменился и изменится еще больше. В ближайшие годы команды будут работать не только с людьми, но и с десятками AI агентов.

И главной проблемой станет не скорость генерации кода, а удержание понимания над кодом — как и почему устроена система.

Именно вокруг этой идеи мы строим Laplace.