AI Product | Igor Akimov

Самый сейчас горячий вопрос - как внедрить ИИ-разработку больших систем и с учетом еще бОльшего улучшения качества работы ИИ каждый квартал 2026 год. Вот вам офигенная статья от OpenAI на эту тему: https://openai.com/index/harness-engineering/ Рассказали, как построили продукт на миллион строк кода. Ни одна строчка не написана человеком. Вот чему они научились. Абсолютно весь код – логика, тесты, CI, документация, observability, тулинг – написан агентами Codex на GPT-5. Люди не написали ни строчки. И это было осознанное ограничение. Первый коммит в пустой репозиторий – конец августа 2025 ~1 млн строк кода за 5 месяцев ~1,500 PR смержено Начинали с 3 инженеров, сейчас 7 3.5 PR на инженера в день (и скорость растёт с ростом команды!) Оценка: построили примерно в 10 раз быстрее, чем писали бы руками 1. Роль инженера полностью изменилась Инженеры больше не пишут код. Их работа – проектировать среду, формулировать intent и строить feedback loops, чтобы агенты могли делать полезную работу. На практике это подход от простого к сложному: разбиваешь большую цель на строительные блоки, промптишь агента собрать эти блоки, потом из них собираешь более сложные задачи. Ключевое: когда что-то ломалось, ответ никогда не был "попробуй ещё раз". Вместо этого инженер спрашивал: "какой возможности не хватает агенту и как сделать его понятным и управляемым?" 2. AGENTS.md как энциклопедия – провал Первый подход – один большой AGENTS.md файл со всеми инструкциями. Провалился предсказуемо: Контекст – дефицитный ресурс. Гигантский файл инструкций вытесняет саму задачу, код и релевантную документацию Когда всё "важно" – ничего не важно. Плюс монолитный мануал превращается в кладбище устаревших правил Решение: AGENTS.md ~100 строк работает как оглавление, не энциклопедия. Вся knowledge base живёт в структурированной docs/ директории как source of truth. Там же – архитектурная документация с картой доменов и пакетных слоёв, документ, который оценивает каждый домен и отслеживает деградацию. 3. Agent legibility – главная цель Всё знание должно быть внутри репозитория (вот это офигенный совет и я честно говоря к такому только подбирался) Агент не может погуглить, не может спросить коллегу. Всё, что ему нужно для работы, должно быть доступно в репозитории и понятно из контекста. То есть все ваши решения с созвонов и переписки по проекту в слак тоже должны быть в репо! Это меняет подход к архитектуре: код и документация пишутся не для людей, а для агентов (и людей заодно). Каждый дизайн-док, каждое архитектурное решение существует в repo и проверяется на актуальность. 4. Архитектура и "культура" закладываются с самого начала Как мы пишем код -фиксируется один раз, а потом требуется автоматически на каждую строчку кода. Архитектурные вариации проверяются не через code review, а через механические проверки – линтеры, CI, автоматические ревью. Это позволяет ловить плохие паттерны ежедневно, а не через недели, когда они уже расползлись по кодовой базе. Потому что потом этот кривой код уже будет считаться хорошим примером для последующих генераций 5. Скорость меняет философию merge Когда у тебя 3.5 PR в день на инженера, классический подход к code review не работает. Вместо ручного ревью каждого PR – Codex ревьюит свои собственные изменения, потом запрашивает дополнительные agent-ревью (локально и в cloud), отвечает на feedback и итерирует в цикле, пока все agent-ревьюеры не удовлетворены. Человек подключается к ревью по необходимости, а не по умолчанию. 6. Уровни автономии росли постепенно Не пытались сразу дать агенту полную автономию. Начинали с простых блоков, потом постепенно наращивали сложность. Каждый новый уровень автономии опирался на уже созданные абстрации и инструменты. 7. Техдолг и "сборка мусора" Техдолг – как кредит с высокой процентной ставкой. Лучше платить маленькими порциями постоянно, чем копить и разбираться болезненными спринтами. Команда запускает непрерывный автоматический рефакторинг каждую пятницу– это работает как garbage collection для кодовой базы.