Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
У меня совершенно другой опыт после попытки жить с spec-driven development. Во-первых, в какой-то момент объем английского текста для вычитки - совершенно точно превысил объем кода, который мы собрались нагенерировать.
Во-вторых, человеческие языки специально сделаны контекстно-зависимыми, в отличие от ЯП (которые обеднены выразительными средствами, и максимально затрудняют выражать мысли неполно или противоречиво). Соответственно, я могу оценить только то что написано, но не могу сказать - что НЕ написано. Или другими словами - спецификация на английском языке одновременно и правильная, и нет - в зависимости от того, кто будет ее интерпретировать.
В третьих - в большинстве реальных задач, требования по-определению неполны, и раскрываются по ходу реализации. Как spec-driven development решает ситуацию когда на 81% выполнения задачи, я понял что стоило бы вот этот функционал вытащить в отдельный класс ? Мне сделать git reset --hard, поправить спеку и начать заново ? А потерянно время ? А сожженные токены ?
В целом все идеи "программировать на человеческом языке" у меня вызывают ассоциацию с музыкантом, которому вместо нот - дают талмуд текста, который вроде бы тоже описывает как ему теперь играть. Можно ли вложив достаточно сил и времени сыграть произведение в таком виде ? Скорее да, чем нет. Стоит ли это делать - чего-то я сомневаюсь...
В итоге, я пришел к выводу что SDD - это опять реинкарнация вайбкодинга, но с попыткой внедрить какую-то структуру. А значит, по прежнему - это актуально если:
Вы не знаете языка программирования, но делать надо. Действительно, перемещаться на костылях неудобно и долго - но бесконечно лучше чем беспомощно лежать на одном месте. Так же и вайб-кодинг в этом случае...
...или вам абсолютно наплевать на то, что случится с кодом в будущем, и ваш критерий приемки - главное чтобы оно "прямщас" заработало.
...или вы можете переложить боль вычитки спек на кого-то другого (например, рядом валяется никому не нужный бизнес-аналитик).
В противном случае (если вы знаете ЯП, и хотите поддерживать архитектурную целостность проекта) - чем SDD лучше напрямую работы с агентом ? Тут вы по шагам его контролируете, можете поправить решение или попросить оперативно что-то поменять, и т.д. Имхо это гораздо продуктивнее чтения сотен килобайт сгенерированных спецификаций...
ну я тут только две вещи могу сказать
я хоть и владею языком, прошу агента все требования переписывать по-русски. как минимум на случай, если она нужны кому то еще (добавлю это в статью) и чтобы не тратить лишнюю конитивную энергию на таком важном этапе.
как бы мы ни относились к конвертации естественного языка в яп, к этому прогресс пришел не просто так. это тоже алгоритмизируется, как ни странно. и как яп это уровень абстракции над байт-кодом, байт-код над машинным языком или как оно там, так и с тем как мы мысли выражаем и как это ложится в яп происходит, и дальше больше
По п.1 - я требую от AI-агента поддерживать консистентный файл AI-ONTOLOGY.md в котором описывать дистиллированную информацию о проекте. В первую очередь - чтобы в новой сессии не начинать опять читать 100500 файлов в контекст "ой, давайте посмотрим какой фреймвокр использовать, ой давайте посмотрим как тут сделан service layer, и т.д.". Пусть бы читал отнологию, и потом зачитывал дополнительно только что что нужно для конкретной задачи. То что там агенты пишут - вполне человекочитаемо и понятно - та же документация..
По п.2 - все предыдущие переходы: ассемблер вместо машинных кодов, C вместо ассемблера, С++ вместо C, и т.д - имели одно важное свойство: они были детерминированными. Я до сих пор знаю, какой ассемблерный код генерирует компилятор C... А переход "человеческий язык - ЯП" (при помощи LLM) - это уже вероятностная процедура. Поэтому я хочу чтобы ее нужность (или выгодность) была обоснованна отдельно. Особенно в ситуации, когда я ЯП уже так или иначе выучил...
все правильно, но есть нюанс
код детерминирован по абстракциям ниже, когда он уже написан. но перед этим его надо написать.
процесс написания кода — НЕ детерминистичен. на проектах и для людей есть все эти бесконечные «так не делай, так делай, запускай тесты»
дайте задачу на CRUD двум-трем разным людям и получите три разные реализации. нейронки в этом плане ничем не отличаются от людей и выдают ровно такой же ответ на опыте из вероятностей, промтов и датасетов.
если бы люди писали детерминистично код на ЯП, не было бы собеседований, брали бы первого же кандидата. результат то один
я понимаю, о чем вы пишите, просто это не симптом ии.
думаю, дальше появится какой-то протокол ввода в ide, либо у нейронок механизм изменят, либо и то и то будет ненужным для решения задач.
С этим я согласен. Но людей мы учим, и в конце-концов научаем (или увольняем - если оказались необучаемы). И за последние 10 лет читая чужие коды - я ловил себя на мысли что "... хорошие программисты все думают одинаково!". А с ИИ в этом смысле проблема - что он не учится на своих ошибках. Единственный способ организовать сейчас передачу знаний из одной сессии в другую - это через контекст. А его не сказать бы что слишком много! После израсходования 25-30% контекста, модель явно начинает терять когнитивные способности...
на ошибках его учат корпорации и венчурные капиталисты. эта работа на аутсорсе. а дальше ии надо воспринимать как инструмент все таки, и использовать там, где подходит
ну и про рост со временем: 10 лет назад у ии была настолько уже сфера применения, что тот факт что мы сейчас обсуждаем его возможности против хороших разработчиков должно нам говорить, что еще далеко не потолок
В этом и проблема - его учат "на ошибках вообще". А в конкретном проекте/отрасли нужно нарабатывать знания и опыт по мере работы. Текущий ИИ с его разделением на "цикл обучения" - "цикл коммерческого применения" имеет с этим проблемы... Развитие - да, согласен, только оно свернуло куда-то не туда. Вместо того чтобы стремиться уменьшить ИИ до размера футбольного мяча и энергопотребления 100-150 вт (мы такое на плечах носим) - ударились в гигантоманию с дата-центрами и новыми электростанциями... :-(
Если статья понравилась, плюсаните карму
Плюсанул (чтобы вывести вашу карму из минуса), но ваша просьба нарушает правила Хабра: здесь за такое обычно минусуют.
Вопрос по сути статьи: вы вычитываете весь сгенерированный код, или выборочно?
апдейт: добавил пару параграфов про модификацию вызываемых команд. вероятно, еще дополню позже.
Мой никому ненужный опыт вайбкодинга такой. Это хороший инструмент для поиска причины ошибки, написания тестов и документации, написания фрагментов кода примера работы новой технологии, написания утильных методов. Но. Для написания кода необходимо самому знать что и как писать и двигать агента по шагам. Самостоятельно агент код писать не умеет.
самому кодить надо уметь — факт. поэтому на рынке спрос на сеньоров помидоров как никогда высокий, чтобы их захватить и с агентом за тот же прайс получить х2 выгоды
Дело даже не в умении кодить, а в том что нужно заранее знать решение. И по шагам его расписать. Короче если там не однотипный бойлерплейт быстрее самому сделать. А обычно в работе время уходит на решение задачи, а не на бойлерплейт.
Не обязательно прямо вот знать решение - важно иметь опыт. Я пришел к выводу, что ИИ эффективен на двух концах спектра сложности задач. Первое - это дискавери и брейн-шторм: от описания проблемы перейти к причине, и нащупать пути решения. Условно - там где требуется широкий кругозор и интуиция (ИИ ее заменяет кластеризацией понятий в пространстве высокой размерности и гигантской обучающей выборкой). Второе - это "механическая память", когда воспроизводятся с незначительными вариациями куски кода, многократно раз присутствовавшие в обучающей выборке. Проблема в том, что в середине между этими крайностями - текущий ИИ работает очень плохо. Нет "клея" который бы связал "могу описать пути решения" и "могу сложить типовые куски кода вместе". У человека этот клей называется "опыт": попытки применения знаний для решения конкретных задач, наблюдение последствий и их запоминание для учета в следующих попытках. А текущий ИИ ни на своих успехах, ни на своих ошибках в режиме коммерческой эксплуатации - не учится...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подсушенный флоу вайб-кодинга с Claude Code + speckit