в общем, OpenAI добрались рассказать (февраль...

в общем, OpenAI добрались рассказать (февраль 2026...) как они научились писать весь код только через агентов. если вы ещё не в подобном режиме, то вам могут пригодиться их наблюдения, выделил самое сочное. кратко:

- в ai-only dev, вы больше не "пишите код", вы строите среду, где агент может писать код сам. ваша работа — ставить задачи, настраивать механики ревью, добавлять тулы/данные/правила, чтобы агент стабильно доезжал до именно того качества кода, какой вы хотите видеть. - репа — это единственный источник правды. всё, что живёт в головах/чатах/гуглодоках, для агента как будто не существует. поэтому знания нужно перетаскивать в репо: доки, решения, схемы, "как у нас принято", "как дебажим", "как релизим". - по мере ускорения разработки, узким местом стал QA. мы запарились над тем, чтобы дать агенту прямой доступ к UI, логам и всем метрикам приложения, чтобы он мог тестить всё сам (а если бы OpenAI читали мой канал, то давно бы заюзали скилл из этого поста) - наш агент видел логи/метрики/трейсы через локальный observability-стек, который поднимается под конкретный worktree. он работает в полностью изолированной копии приложения — со своими логами и метриками — и после завершения таски это всё просто сносится. агенты ходят в логи через LogQL, в метрики — через PromQL. и когда у агента есть этот контекст, задачи типа "startup сервиса должен быть < 800ms" или "в 4 ключевых user journey ни один span не должен быть > 2s" стали решаемы. - вместо одной большой "библии для агента" лучше делать короткую сводку "куда смотреть" и нормальную структуру docs/ с небольшими кусками, которые легко поддерживать. агентам обычно проще идти слоями, чем проглатывать мегатекст. - замечания типа "вкус/стиль/как принято" лучше переводить в исполняемые правила. сначала — зафиксировать в доке. если правило важное и повторяется — лучше поднимать его до кода: линтер, статанализ, codemod, check в CI. цель — чтобы агент сталкивался с правилом автоматически, а не только через комментарии людей. - "agent-generated" обычно лучше считать не только продуктовый код. туда же логично относить тесты, CI, релизный туллинг, внутренние скрипты, доки, дизайн-историю, eval/harness, даже ответы на ревью. людям остаётся judgement: приоритеты, acceptance criteria, риски. - по мере роста скорости разработки ожидание начинает стоить дороже фикса, поэтому шерховатости и мелкие косяки иногда выгоднее закрывать доп. запросом, чем ждать идеального результата — при условии, что есть страховка в виде тестов, метрик и алертов. - качество со временем почти неизбежно "плывёт": агент копирует паттерны, включая плохие, появляется энтропия/ai-slop. ручная чистка не масштабируется, поэтому лучше закладывать garbage collection руками агентов: поиск тех.долга, фиксы мелочей, апдейты доков, рефакторинги. - ключевая дисциплина в ai-only dev — скорее не "prompting engineering", а scaffolding + системы контроля: как устроен репо, какие есть тулы, какие проверки считаются истиной, как агент сам себя валидирует/останавливает/откатывает/эскалирует, и как системно снижать долю человеческого участия.