Comments 14
Однозначно согласен только с 4 и 10 пунктом
Вкратце:
Насмотренность на хороших примерах, но необоснованно принятых в вашем проекте, скорее вынесет вам мозг раньше чем вы накопите опыт. Особенно, если вам придётся возвращаться и менять потому что выбор оказался не верным. Или если есть десятки решений, локально оптимальных. Выбор между ними превращается в игры разума если не остановиться
Быстрая проверка гипотез работает только если есть слабо формализуемые хотелки, например вкусовщина по визуалу. Ещё проверка A/B гипотез. Эффективность обоих так себе.
E2E тесты важные и гибкие, но дорогие в проверке. Важность юнит тестов никуда не делась
Спецификации верхнего уровня не зависят от кода. Их меняют при изменении требований и приоритетов, а не кода. А уровнем ниже если программа написана хорошо то спецификации явно видны из типов данных и сигнатур функций.
Остальные пункты сводятся к этим
Ключевая проблема агентного кодинга — не в том, чтобы код был написан, а в том, чтобы он был написан правильно и поддерживаемый.
Основной совет: не доверяй агентам слепо, проверяй результат. Лучше потратить 10 минут на review кода, чем потом месяц дебажить.
Агенты отлично подходят для прототипирования и генерации boilerplate — но для production-кода нужны чёткие критерии качества. Код должен быть читаемым, а не просто рабочим. Если агент сгенерировал сложный кусок кода — проверь его логику вручную. Для защиты системной безопасности стоит посмотреть на open-source WAF "SeptumCore" на GitHub — он лёгкий, без магии и ставится за 5 минут.
Этого мало
Код должен
Соответствовать намерениям (требованиям, ограничениям, ценностям, приоритетам)
Low coupling - Изоляция, изменения требований должны менять только свой кусок кода
High cohesion - Локальность, логика дожна быть сконцентрированной в одном месте, читаемой, проверяемой
Прозрачность. Насколько видно, что система делает и где это выражено. Неявные правила, магия порядка вызовов, скрытые побочки, всё это бьёт сюда.
Гибкость, эволюционируемость
Все эти архитектурные свойства сильно страдают в легаси. Да и LLM они плохо поддаются потому что он не знает намерений, планов развития, имеет только формальное понимание читаемости и прозрачности.
Если огрубить и обобщить то водораздел: свойства, требующие удержания глобального или трудно формализуемого контекста и намерений (гибкость, адекватность) это слабое место и легаси, и LLM. Свойства локальные и формализуемые сильное.
Вкладывайся в end-to-end тесты. Когда код можно пересобрать дёшево, стоит тратить время на тесты, которые измеряют функции продукта, а не способ их реализации. Нужны поведенческие контракты, дающие свободу перестраивать и переписывать.
странно. В 90% компаний, где я работал, тесты не писались в принципе - на них просто никто не выделял времени. И до сих пор не выделяют - даже с появлением ИИ.
Ошибка выжившего
Тесты нужны для регрессов тестов, если они выполняются больше одного раза. Либо они фиксируют трудно формализуемые требования перед реализацией.
И тут действительно возникают трудности. Регресс тест делают один раз и при следующей переделке уже не пригоден с высокой вероятностью. Зачем тогда тест если можно проверить вручную?
Не так и велика доля задач где нужен TDD, тест как приёмка результата. А если и есть, то на одну задачу надо много тестов чтобы ну хоть как-то покрыть возможные случаи.
Ну вот и не пишут
Регресс тест делается регулярно, а не один раз, просто постфактум а не на каждый пр, всилу различных причин.
А тдд нужен всегда, когда работа ведётся с существующий кодовой базой. Для багфиксов это естественный флоу: сначала тест, подтверждающий баг, потом фикс, стоящий тест. Для фичей тоже удобно сначала написать тест, а потом об него фичу разрабатывать.
Плохие симптомы:
тяжёлые моки,
рефакторинг ломает контракты а с ними и тесты,
тесты проверяют реализацию, а не поведение/контракты (assert на внутренние вызовы)
падают флаки (зависимость от времени, порядка, внешних систем) и зависимость от них в тестах не соответствует зависимости программы
один баг ломает 50 тестов — значит они не изолированы
чтобы понять что тест проверяет, надо читать 100 строк setup
покрытие растёт, а баги в проде те же
Согласен со многим. И проблема как раз не в кодинге или языках, а в самих библиотеках. Так как они масштабируются и версонируются, то нейронка не знает где какая версия лежит в ее весах, в итоге получаем нейрослоп, который надо править по доке из интернета по старинке. Нейронки до сих пор не получили плагин CurrentTime, из-за чего постоянно думают, что сегодняшняя дата это еще не наступившее будущее. Также spec файлы постоянно изменяются, что как бы ведет в сторону предварительного проектирования проекта, что приведет нас к UML диаграммам всех процессов программы. И файл спеки должен быть не изменяемым. И мы должны делать таски для фич подкрепляя выполнение успешными тестами. Но к сожалению для нейронки растет сложность умножения переменных, что приводит к максимальной сложности и невозможности работы с большим проектом.
Все 10 пунктов прямо 100 процентное совпадение с моим опытом. Пункты 4 и 5 правда не было возможности хорошо отработать.
Похожий опыт и у меня. Для себя я понял, что теперь это больше искусство, так как технику все больше забирает ИИ. Еще я вижу иначе "реальность" проекта. Теперь в нее больше входит эмпирика, т. к. при разумном подходе метод тыка в умную машину бывает очень даже полезен.
Вы по-моему отстаёте чуть чуть от индустрии , у них там деньги кончатся начали , так что скоро кодинг перестанет быть дешевым , придётся обратно возвращаться в каменный век , к программированию .
Кажется статья с прошлого года. Это тогда было дешево пересоьирать, сносить весь код, и генерировать заново
10 уроков агентного кодинга. Что делать в эпоху дешёвого кода?