Спасибо за развёрнутый комментарий, очень в точку.
Про DDD — полностью согласны, у нас похожие наблюдения: чем «человечнее» и семантически богаче код, тем лучше с ним работает LLM. По сути, хорошие имена и явные границы домена начинают играть роль дополнительного контекста, которого модели обычно не хватает.
Про риск-менеджмент тоже болезненно знакомо. Есть ощущение, что ИИ действительно убирает тот естественный “фильтр боли”, который раньше заставлял инвестировать в архитектуру — теперь многое «как будто работает», и это создаёт иллюзию, что можно не думать о последствиях.
А в случае с джунами наш прогноз оптимистичнее: думаем, что из-за «парадокса Джевонса» количество вакансий будет расти (софт начнут делать даже в тех компаниях, где раньше этим не занимались), а способные джуны с ИИ смогут быстрее прежнего осваивать технологии и сократить путь к сеньору, так что толковые люди понадобятся.
В общем, спасибо, что так подробно дополнили — как раз ради таких комментариев и писали пост.
Да, SDD у нас используется, но не как жёсткий формальный процесс, а как часть рабочего флоу. Перед задачами фиксируем ожидаемый результат, ограничения и инварианты, чтобы агент не «додумывал» и не уходил в лишние части системы, а дальше спокойно уточняем и обновляем спецификацию по ходу работы. По сути, это не «написали документ и забыли», а живой слой между задачей и кодом, который постоянно синхронизируется с реальностью. В связке с TDD и риск-менеджментом это даёт гораздо более предсказуемый результат, чем каждый из подходов по отдельности.
И отдельно добавим про часть «Если делаем что-то серьёзнее манки кодинга, удачи провести три цикла интеграции и анализа рисков...»
С этим сложно спорить. Если подходить к ИИ как к «манки кодингу», то в серьёзных системах это гарантированно ломается. Но по нашему опыту, происходит обратное: с ИИ требования к инженерной дисциплине не снижаются, а растут.
ИИ может быстро написать «что-то рабочее», но со скрытыми ошибками, нарушениями архитектуры и неочевидными рисками. Поэтому генерация — это не конечный результат, а самый дешёвый этап пайплайна. Дальше всё по классике (и это никуда не делось): ревью, тесты, интеграция, проверка крайних кейсов, анализ рисков. И во многих случаях мы делаем это жёстче, чем при ручной разработке, потому что ИИ «уверенно ошибается».
Подход «сделай 3 варианта, выберем лучший» может быть полезен на этапе быстрых гипотез и исследований — в этом смысле ИИ даёт сильную «аджайлность». Но как основной процесс в production он почти всегда не масштабируется: дорого по интеграции, дорого по верификации, дорого по рискам.
Поэтому рабочий вариант, который приживается конкретно у нас: чёткая спецификация → одна реализация → строгая проверка, а не «перегенерируем, пока не понравится».
ИИ в этом смысле — не способ упростить инженерку, а инструмент, который заставляет лучше формулировать задачи, строже проверять результат и быстрее находить слабые места.
Если этого не делать — да, получится ровно тот сценарий, о котором вы пишете.
Ну, фраза про водопад ведь даётся в тексте как реакция от гипотетического читателя, а не как наша позиция.
Возможно, не совсем точно получилось передать там мысль, она была вот в чём. Кто-то при виде слов «spec-driven» испугается, что отберут любую возможность влиять на исходный план по ходу дела, даже если очевидно понадобились изменения (например, в стартапе на ранней стадии, где всё часто меняется). Но если такая потребность есть, то её возможно и с SDD реализовывать.
А так да, всему своё место, не нужно везде ударяться в аджайл ради самого аджайла. С этим не спорим.
Не вполне. «Просто ТЗ» на практике часто означает, что есть какое-то ТЗ, но что-то будет доуточняться устно, что-то меняться в процессе и уже не фиксироваться в ТЗ. А в итоге «главный источник правды» — это код.
SDD подразумевает, что спецификация (точное и структурированное ТЗ) становится «главным источником правды». И разработчик, и ИИ ориентируются на неё, а не устные договорённости или ещё что-то. И если понадобилось что-то изменить, то эти изменения должны фиксироваться в спецификации до того, как будет сгенерирован новый код. ИИ всегда должен ориентироваться на актуальную версию спецификации.
Существуют ещё и сторонники более радикальной формы SDD, которые считают, что код вообще уже малозначим, потому что с ИИ его всегда можно перегенерировать из спецификации, как бинарники — из кода. Мол, теперь спецификация — это «новый код», а LLM — это такой своеобразный «компилятор». Но тут возникают вопросы вроде того, что ИИ по одной и той же спецификации может генерировать различающийся код. И конкретно мы в такое не ударяемся, для нас код по-прежнему важен.
К вашему вопросу. По сути, получается тот же класс проблем, что и в тексте, но на уровень выше: если в обычном reward hacking агент «обманывает тест», то здесь он «обманывает среду», потому что она для него упрощена.
Мы для себя это начали формулировать так: недостаточно проверять корректность кода, нужно проверять валидность предположений об окружении. Из практики: если понимаем, что сценарий упирается во внешние системы (антибот, rate limits, поведение CDN и т.п.), стараемся не ограничиваться тестами на уровне HTTP/скриптов.
Что делаем в таких кейсах:
Разводим synthetic и real environment Прогоняем сценарии в условиях, приближенных к реальным (IP, прокси, ограничения), а не только в «чистой» среде. Добавляем проверку фактического пользовательского состояния. Не «200 OK», а «пользователь действительно увидел нужный экран/контент». Фиксируем ограничения среды в спецификации.
Отдельно про Kodik: мы видим, что этого уровня проверок всё равно не хватает, поэтому сейчас двигаемся в сторону добавления vision-based проверок (анализ того, что реально отрендерилось в браузере), и агентов, которые могут взаимодействовать с браузером напрямую и проверять результат не только через API, но и через фактический UI.
Идея в том, чтобы агент ориентировался не только на «ответ сервера», а на «что реально видит пользователь», это как раз закрывает почти все кейсы с капчами/челленджами.
А раз вы с подобным сталкиваетесь, как вы у себя это обходите, особенно без ухода в полноценную гонку с антиботом?
Используем обширный ряд моделей — линейки GLM, GPT Codex, Anthropic (Opus, Sonnet, Haiku последних версий), Gemini и многие другие. Подробнее в документации: https://docs.kodik.ru/docs/intro
Спасибо за развёрнутый комментарий, очень в точку.
Про DDD — полностью согласны, у нас похожие наблюдения: чем «человечнее» и семантически богаче код, тем лучше с ним работает LLM. По сути, хорошие имена и явные границы домена начинают играть роль дополнительного контекста, которого модели обычно не хватает.
Про риск-менеджмент тоже болезненно знакомо. Есть ощущение, что ИИ действительно убирает тот естественный “фильтр боли”, который раньше заставлял инвестировать в архитектуру — теперь многое «как будто работает», и это создаёт иллюзию, что можно не думать о последствиях.
А в случае с джунами наш прогноз оптимистичнее: думаем, что из-за «парадокса Джевонса» количество вакансий будет расти (софт начнут делать даже в тех компаниях, где раньше этим не занимались), а способные джуны с ИИ смогут быстрее прежнего осваивать технологии и сократить путь к сеньору, так что толковые люди понадобятся.
В общем, спасибо, что так подробно дополнили — как раз ради таких комментариев и писали пост.
Да, SDD у нас используется, но не как жёсткий формальный процесс, а как часть рабочего флоу. Перед задачами фиксируем ожидаемый результат, ограничения и инварианты, чтобы агент не «додумывал» и не уходил в лишние части системы, а дальше спокойно уточняем и обновляем спецификацию по ходу работы. По сути, это не «написали документ и забыли», а живой слой между задачей и кодом, который постоянно синхронизируется с реальностью. В связке с TDD и риск-менеджментом это даёт гораздо более предсказуемый результат, чем каждый из подходов по отдельности.
И отдельно добавим про часть «Если делаем что-то серьёзнее манки кодинга, удачи провести три цикла интеграции и анализа рисков...»
С этим сложно спорить. Если подходить к ИИ как к «манки кодингу», то в серьёзных системах это гарантированно ломается. Но по нашему опыту, происходит обратное: с ИИ требования к инженерной дисциплине не снижаются, а растут.
ИИ может быстро написать «что-то рабочее», но со скрытыми ошибками, нарушениями архитектуры и неочевидными рисками. Поэтому генерация — это не конечный результат, а самый дешёвый этап пайплайна. Дальше всё по классике (и это никуда не делось): ревью, тесты, интеграция, проверка крайних кейсов, анализ рисков. И во многих случаях мы делаем это жёстче, чем при ручной разработке, потому что ИИ «уверенно ошибается».
Подход «сделай 3 варианта, выберем лучший» может быть полезен на этапе быстрых гипотез и исследований — в этом смысле ИИ даёт сильную «аджайлность». Но как основной процесс в production он почти всегда не масштабируется: дорого по интеграции, дорого по верификации, дорого по рискам.
Поэтому рабочий вариант, который приживается конкретно у нас:
чёткая спецификация → одна реализация → строгая проверка,
а не «перегенерируем, пока не понравится».
ИИ в этом смысле — не способ упростить инженерку, а инструмент, который заставляет лучше формулировать задачи, строже проверять результат и быстрее находить слабые места.
Если этого не делать — да, получится ровно тот сценарий, о котором вы пишете.
Ну, фраза про водопад ведь даётся в тексте как реакция от гипотетического читателя, а не как наша позиция.
Возможно, не совсем точно получилось передать там мысль, она была вот в чём. Кто-то при виде слов «spec-driven» испугается, что отберут любую возможность влиять на исходный план по ходу дела, даже если очевидно понадобились изменения (например, в стартапе на ранней стадии, где всё часто меняется). Но если такая потребность есть, то её возможно и с SDD реализовывать.
А так да, всему своё место, не нужно везде ударяться в аджайл ради самого аджайла. С этим не спорим.
Не вполне. «Просто ТЗ» на практике часто означает, что есть какое-то ТЗ, но что-то будет доуточняться устно, что-то меняться в процессе и уже не фиксироваться в ТЗ. А в итоге «главный источник правды» — это код.
SDD подразумевает, что спецификация (точное и структурированное ТЗ) становится «главным источником правды». И разработчик, и ИИ ориентируются на неё, а не устные договорённости или ещё что-то. И если понадобилось что-то изменить, то эти изменения должны фиксироваться в спецификации до того, как будет сгенерирован новый код. ИИ всегда должен ориентироваться на актуальную версию спецификации.
Существуют ещё и сторонники более радикальной формы SDD, которые считают, что код вообще уже малозначим, потому что с ИИ его всегда можно перегенерировать из спецификации, как бинарники — из кода. Мол, теперь спецификация — это «новый код», а LLM — это такой своеобразный «компилятор». Но тут возникают вопросы вроде того, что ИИ по одной и той же спецификации может генерировать различающийся код. И конкретно мы в такое не ударяемся, для нас код по-прежнему важен.
Спасибо! Да, хотя весь пост про использование ИИ, сам текст поста писал совершенно не ИИ :)
В сторону CloakBrowser пока что не смотрели, но подумаем об этом, спасибо!
Запомнили это как возможную тему для хабрапоста на будущее, спасибо!
Спасибо за такой вдумчивый комментарий!
К вашему вопросу. По сути, получается тот же класс проблем, что и в тексте, но на уровень выше: если в обычном reward hacking агент «обманывает тест», то здесь он «обманывает среду», потому что она для него упрощена.
Мы для себя это начали формулировать так: недостаточно проверять корректность кода, нужно проверять валидность предположений об окружении. Из практики: если понимаем, что сценарий упирается во внешние системы (антибот, rate limits, поведение CDN и т.п.), стараемся не ограничиваться тестами на уровне HTTP/скриптов.
Что делаем в таких кейсах:
Разводим synthetic и real environment
Прогоняем сценарии в условиях, приближенных к реальным (IP, прокси, ограничения), а не только в «чистой» среде.
Добавляем проверку фактического пользовательского состояния.
Не «200 OK», а «пользователь действительно увидел нужный экран/контент».
Фиксируем ограничения среды в спецификации.
Отдельно про Kodik: мы видим, что этого уровня проверок всё равно не хватает, поэтому сейчас двигаемся в сторону добавления vision-based проверок (анализ того, что реально отрендерилось в браузере), и агентов, которые могут взаимодействовать с браузером напрямую и проверять результат не только через API, но и через фактический UI.
Идея в том, чтобы агент ориентировался не только на «ответ сервера», а на «что реально видит пользователь», это как раз закрывает почти все кейсы с капчами/челленджами.
А раз вы с подобным сталкиваетесь, как вы у себя это обходите, особенно без ухода в полноценную гонку с антиботом?
Представитель Kodik на связи)
Используем обширный ряд моделей — линейки GLM, GPT Codex, Anthropic (Opus, Sonnet, Haiku последних версий), Gemini и многие другие. Подробнее в документации: https://docs.kodik.ru/docs/intro