Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 154
Столкнулся с такой проблемой, если агент не достаточно живёт архитектурой проекта, он выбирает самые простые локальные решения. Например сваливает всю логику в уже существующий мелкий файл и легко раздувает его до 5000 строк, потому что название файла было общее и позволяло это делать. Для себя вынес главное правило — разработчик отвечает за архитектуру. Отсюда уже и нормальный процесс — review, refactor, cleanup — без всякой магии и чёрных ящиков.
Я бы сказал иначе: если разработчик не достаточно живёт архитектурой проекта, то все вытекающие - почти стопроцентная вероятность. Агент живёт в тех рамках, что ему задаёт разраб, не более и не менее
Хорошая аналогия с авиацией. Заметил по себе: когда Cursor генерит код, всё равно построчно ревьюю — иначе через неделю не вспомню логику. AI как второй пилот, а не автопилот: решение всегда за разработчиком.
AI как второй пилот
>Copilot
А Майкрософт знали!
И все равно решение, которое придумал сам (особенно, если тяжело далось) запомнится лучше, чем то, которое увидел готовым. И понимание будет на более глубоком уровне.
Но Вы же не изучаете и не проверяете байткод после компилятора, вы ему доверяете и вообще даже не пытаетесь понять, что он там понаписал...
Потому что байт-код/машинный код не предназначен для чтения, редактирования, осмысления, не является объектом рефакторинга, проектирования, поддержки, в отличие от программного кода.
Если байт-код генерируется с помощью распределения вероятностей, аналогично тому, как работают llm, то стоило бы... Но обычно компиляторы таким не занимаются. Там вполне жестские правила заданные при создании компилятора. Однако, например таким занимается оптимизаторы некоторых баз данных и "внезапно" хорошим правилом является проверять план выполнения сложных запросов...
Народ пока ещё не привык к тому, что код можно не читать. Вообще. Работоспособность продукта можно и нужно проверять не чтением кода. Но это знают product owner'ы, а не девелоперы. Вот поэтому первых станет больше, а вторых - меньше.
Вайбованги подъехали всех увольнять. Прямо вижу разработчиков банка или ПО авиакомпании, которые не читают код
Работоспособность продукта - нет, она никогда не проверялась чтением кода. Надёжность, устойчивость, иногда отказоустойивость и отказобезопасность, а также минимизация проблем при последующей работе с кодовой базой - да. Но об этом знают девелоперы, а не product owner'ы. Вот поэтому первых станет больше, а вторых - меньше. Шучу, не станет, потому что если бы код изначально писался нормально, а не по принципу "ща mvp соберём из говна и палок запилим, парочку новых технологий в резюме добавим, а потом сделаем как надо, и рефакторим всё по 5 раз", столько девелоперов бы и не понадобилось. Хотя mvp изначально можно сделать нормально и потом постепенно развивать.
Вы считаете, что все случаи можно покрыть тестами? Или ИИ по коду и короткому промту выдаст заключение о полном соответствии кода и решаемой задачи?
Нет. Нет.
А как проверять работоспособность продукта?
На стенде, в песочнице или эмуляторе окружения испытывать как чёрный ящик. Если функционал не особо важный и не ударит по опыту пользователей, а мы контролируем окружение, то после можно устроить канареечное тестирование, если же нет, то кроме длительного прогона с различными вводными ничего не остаётся. Но это в идеальном мире. Вот как раз чтобы меньше делать прогонов и нужны юнит и интеграционные тесты, а если кодовая база устойчивая, ещё и с изменениями помогает. По крайней мере у меня так, потому что вместо QA есть ОТК и о тестах перед прогонами на стенде надо самому думать.
Вот бы ещё с QEMU разобраться чтобы запустить эмуляторы разом на два синхронизированных контроллера, я бы вообще как король зажил. Не пришлось бы столько возиться с проектами времён месопотамии.
Есть много других способов. Самый надёжный из которых - конечные пользователи. Я долгое время работал с Magento, строил на её базе магазины и интегрировал в них различные расширения сторонних производителей. Очень любопытный опыт, я вам скажу. Так вот, "Magento way" - это тестирование продукта на конечных пользователях. Ну, это я так его назвал - Magento way. Потому что как интегратор я видел, что типовые сценарии работают как часики, а вот шаг влево или вправо - болото. И тикетов в Magento висела гора, я сам поставил не один десяток. И висели тикеты годами, даже те, к которым PRы были с решениями на две строчки. А платформа, тем не менее жила и процветала, одно время была вообще самой популярной в e-commerce.
Так вот, Magento way - и есть самый надёжный способ проверки работоспособности продукта. Остальные лишь помогают минимизировать возможный ущерб от "проверки пользователем". Включая ваши варианты с тестами и анализом кода через ИИ.
Тогда думаю стоило бы делать уточняющую сноску - чем меньше риски тем больше можно забивать на безопасность, вплоть до того что не читать код. Потому что в моей сфере такая вот "проверка пользователем" которая случилась раз за пару лет может светить фирме многомиллионным штрафом, если попы не прикрыли кучей бумажек. Где после кучи объяснений написано что ликвидация последствий за время эксплуатации меньше по стоимости чем доработка.
Принцип называется ALARP если кому-то вдруг делать нечего, вы его кстати плюс-минус сформулировали в последнем абзаце. Жаль что теорию надёжности больше не преподают в вузах, хотя бы иметь представление что это было бы полезно. Ах да, точно, для программирования же вышка не нужна, посыпаю голову пеплом.
лол, тестирование на пользователях это бест практис, сразу видно квалифицированного человека
"бест" - это "лучший". А я писал про "надёжный". Это "рилайэбл".
И если вы немного пораскинете мозгами, то тоже придёте к такому выводу: "самый надёжный метод проверки работоспособности продукта - на конечных пользователях".
А если пользователь находит баг, который стоит миллионы для компании? От поломки системы (с долгим восстановлением или безвозвратных потерь в материльном мире) до прямых финансовых убытков от транзакций.
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод. Что лишь подтверждает тезис, что самое надёжная проверка - на конечных пользователях.
P.S.
bug bounty hunting - пример такого тестирования
Нет, это значит остальные способы проверки работоспособности оказались недостаточными. И говорит о том, что вы готовы пойти на определённую степень риска. На промке кстати для такого есть правильное название - опытная эксплуатация.
Всё придумали до нас (с)
И опять-таки, bug bounty hunting может хорошо сработать в публичном поле, но в закрытых контурах для такого нанимают специальные команды, которые проверяют всё ДО ввода в эксплуатацию.
Нет, это значит остальные способы проверки работоспособности оказались недостаточными.
А разве "оказались недостаточными" по факту не означает "не сработали"? IMHO, как раз именно это и означает.
На промке кстати для такого есть правильное название - опытная эксплуатация.
Да, опытная эксплуатация - как раз об этом. О проверке пользователями.
в закрытых контурах для такого нанимают специальные команды
Специальными пользователями!
Нет, не означает. Одно дело если вы это тестировали и баг просочился именно там, где должен был отловить тест (ложно положительный результат), и другое дело когда это даже не проверяли.
Нет, опытная эксплуатация на то и опытная, можете сами загуглить чем она от промышленной отличается. Это не проверка пользователями, а приближённая к реальным условиям работа, причём система зачастую работает вхолостую или с дублированием по сторого оговоренной методике.
Да, специальными пользователями со специальными бумажками (взрослые их вообще очень любят), где говорится что к мнению этих ребят надо бы прислушаться, и чтобы они работать начали подписывается бумажка где описаны все условия проверки. Это не рандомный албанец сидящий у родителей в подвале который делает это по приколу или ради денег.
А если пользователь находит баг, который стоит миллионы для компании?
Это значит, что остальные способы проверки работоспособности продукта не сработали и баг попал в прод.
Нет, это значит остальные способы проверки работоспособности оказались недостаточными.
А разве “оказались недостаточными” по факту не означает “не сработали”? IMHO, как раз именно это и означает.
Нет, не означает. Одно дело если вы это тестировали и баг просочился именно там, где должен был отловить тест (ложно положительный результат), и другое дело когда это даже не проверяли.
ОК, я вполне могу принять вашу точку зрения (если “ложно положительный” - то “не сработали”, если “не проверяли” - то “недостаточные”). Но у меня картина мира попроще: баг на проде - облажались при тестировании. Ну так мне и не нужно в куче бумажек расписывать откуда-куда-что. В e-commerce как-то всё попроще, чем на ж/д.
Да я вроде и не говорил что вам нужны бумажки и всякое такое. Я скорее за то, чтобы разработчики задумывались о целесообразности. У вас риск не такой большой, поэтому можно тестить и на проде, хотя как по мне практика сомнительная, если это не канареечное тестирование. У меня же малейшая ошибка может стоит фирме миллионов и поэтому мне приходится изворачиваться как только можно. То что работает у вас, не факт что сработает в другой сфере, не только моей.
Да, у вас такая сфера деятельности, где нужны работающие и проверенные практикой подходы. Вангую, что к вам ИИ-кодинг придёт позже других и в уже достаточно стабильном виде :) Ну а эксперименты с ИИ будут проводиться в других сферах.
То что работает у вас, не факт что сработает в другой сфере, не только моей.
Полностью согласен.
Я как раз об этом и говорил.
Полгода назад ситуация была - в прибор попала молния, прибор упал в отказ, из-за него встала линия, это показали логи на станции. За то что на час встала линия, фирме выкатили претензию насколько я помню миллионов эдак на 6, и это при том что там не было спецвагонов. И хорошо что у нас есть бумажка, где доказано что такая ситуация произойдёт с вероятностью 10^(-9) и для требуемого уровня безопасности считается несущественной. И то, хочу заметить - поезда просто встали, в лобовое никого не отправило.
Что русскому хорошо то немцу смерть (с)
Прям отрывок из Библии нейрослопера.
Его можно не читать, если плевать на сохранность навыков и качество выходного продукта (что есть явления взаимодополняемые). Пока машина не сможет детерминированно генерировать код, в который человеку даже смотреть смысла нет (а здесь самое время поднять вопрос безопасности полного контроля в руках машины), ибо нечитаемо, но работает, читать код будет важно. За исключением уже упомянутых случаев.
А вы-то сами можете "детерминированно генерировать код"? Не на уровне "Hello, World!" или "ToDo List", а на уровне приложения хотя бы на пару тысяч LOC? Каковы ваши собственные пределы детерминированности?
Я когда-то, в первой половине 90-х, изучал ассемблер и писал на нём работающие программы. Не то, чтобы я читал с листа машкоды, но разбирался с помощью справочника, что именно там написано. А потом мне как-то стало плевать на сохранность этого навыка и я ушёл в сторону ЯП высокого уровня - сначала C/Pascal, потом C++, потом Java, а потом вообще PHP и JS.
Буквально вчера вечером я попросил агента исправить одноразовое приложение на JS, которое такой же агент создавал 10 месяцев назад для мониторинга сайта объявлений и которое проработало несколько недель, пока не перестало быть нужным. Теперь надо было мониторить другую категорию объявлений с другой структурой. В этом приложении есть веб-сервер для регистрации пользователей на получение push-уведомлений и сервис, который опрашивает сервер объявлений на предмет появления новых, после чего отправляет push-уведомление всем зарегистрированным пользователям. Я ж говорю, чисто одноразовое приложение под текущую задачу.
Так вот, я полез читать код, который там нагенерён - не помню я через 10 месяцев, что там вообще. Потом плюнул и просто спросил агента - что это и как оно работает. Через минут 5 у меня в памяти была восстановлена картина в общих чертах. Ещё минут 10 мы с агентом переключались на новую категорию объявлений и обновляли библиотеки, после чего я минут 20 восстанавливал окружение, которое я снёс за ненадобностью - веб-сервер, DNS, systemd, ... Сейчас это приложение уже крутится и мониторит новую категорию.
В код я так больше и не заглядывал. Не пригодилось.
Я в курсе, что не во всех сферах человеческой деятельности такой подход применим. Я даже могу согласиться, что во многих сферах традиционного программирования такой подход не применим. Но такой подход открывает ниши, где неприменим уже традиционный подход "с чтением кода и написанием его вручную".
Кстати, буквально вчера стучал рекрутёр с вопросом, а могу ли я всё ещё работать с Lotus Notes? А я уже лет 15-20, как с ним не работаю никак. Не сохранил я этот навык, как и множество других, когда-то полезных - умение администрировать машины с MS-DOS и Windows for Workgroups, NT4, XP, Win2K, OS/2 Warp, Novell Netware, Solaris, Slackware, RedHat/Fedora, писать проги под MS Office и Lotus Notes/Domino, сервлеты под Tomcat, утратил навыки программирования портлетов для Liferay и их интеграции с Intalio BPMS, я больше не программирую на Clarion / C / LotusScript / VisualBasic / Java и почти уже не программирую на PHP и начал забывать Magento. У меня много утраченных навыков и много приобретённых. Одним больше, одним меньше...
В древние времена проверяли :-) Но разница в том, что компилятор, при всей сложности, машина детерминированная. А LLM - не совсем или совсем не.
А ведь когда-то код ревью как раз и предназначалось для разделения знаний о коде...
Пробовали https://graphify.net/ ?
Ну тут как говорится плохому танцору ноги мешают, но в целом если плохой программист научился Клод код на выходе у него результаты намного лучше чем раньше
Однозначно верная статья! И рецепт лечения надо брать из авиации - situational awareness: пилот должен мыслями "лететь" впереди самолета, вместо того, чтобы действовать реактивно.
То есть - команда (или разработчик) до запуска агента должна иметь видение того, что должно быть построено - и сверять то что делает агент - со своим видением. Это ставит жи-и-рный крест на всякой ереси типа spec-driven development, вайб-кодинге, code as secondary artifact - и заставляет проектировать agentic SDLC таким образом, чтобы человек сохранял ситуационную осведомленность! И при соблюдении этих условий, ИИ-инструменты будут безусловно полезны!
В текущей парадигме ии это не реально
В авиации тоже было не реально - когда все были влюблены в парадигму максимальной автоматизации на всех этапах полета. Потребовалось убить в этой парадигме несколько сотен человек чтобы получить общественный резонанс, и подумать еще раз!
Ну вы путаете тонкое с мягким, парадигм как программировать достаточно безопасно у нас полно, ну и в среднем ии генерит код сильно лучше чем программисты
Э-э, какие ? Есть класс программ с полным доказательством инвариантов - в свое время этим баловался Кнут и другие академические исследователи. Это безусловно работает - ибо математику не перешибешь - но не позволяет описывать сколько-нибудь сложные реальные системы. А все остальное так или иначе сводится к тестированию - которое может доказать что специфическое поведение есть, но никак не может показать что другого поведения вне тестов - нет...
С аргументом что ИИ генерирует код лучше программистов - не согласен. Любая спецификация на входе ИИ-агента - принципиальна неполна и/или противоречива. Смысл утверждения на естественном языке раскрывается только если источник и приемник разделяют контекст, в котором сделано высказывание. При этом - люди-программисты со временем согласуют свою голову с контекстом (отраслью, проектом) в котором они работают - а у LLM веса зафиксированы, и учиться она не собирается. Нет, можно пытаться подавать опыт через контекст - но там и так места немного, и несмотря на похвальбу в 1М токенов, после трети контекста, ИИ начинает писать как будто хлопнул стопарик водки... а потом еще один, и еще...
ИИ генерирует не лучше программистов, и, начиная с определённой степени сложности задачи, его заметно заносит не туда. Только что получил забавный опыт вайб-разработки планировщика передачи пакетов для некоторой синхронной системы связи (near-real-time), агента приходилось постоянно поправлять и подпинывать в нужную сторону. Совместными усилиями собрали предсказуемо работающий код, но сам процесс по сложности не сильно отличался от ручной разработки с нуля.
но не позволяет описывать сколько-нибудь сложные реальные системы
А можно вот с этого момента поподробнее? Понятное дело, что есть Idris и HOL4, на которых что-то практичное и прикладное написать, наверное, невозможно. Но есть же Dafny, который с его современной стандартной библиотекой, уже мало чем отличается от условного python, а также имеет .NET, JVM и python-бекены, позволяющие формально верифицированный код на Dafny встраивать в более сложные системы. Сам активно использую и в целом доволен: как раз направление, где LLM применимы действительно хорошо, так как если доказательство сгенерировано LLM, то в нём можно не то что не разбираться, а в целом не смотреть в силу характеристик SMT Z3, который гарантирует математическую корректность сгенерированных LLM доказательств.
Пока речь идет о куске кода целиком под вашим контролем - все относительно хорошо. Добавляем сеть и базу данных - и оно перестает описываться в формате доказуемых свойств. Ну или вы будете вынуждены описать БД так, что мат.модель ее будет очень далека от действительности - и фактически вы сможете доказать только happy-path (что дешевле проверить тестами - и все так и делают!).
Да, это больше для алгоритмов, библиотек и критической бизнес-логики подходит. Впрочем у меня сейчас проект-числодробилка вообще без БД, только с сетевым взаимодействием, так что использование Dafny с .NET-бекендом вполне себе покрывает большую часть проекта, а всё сетевое взаимодействие вынесено в обвязку на C#.
в среднем ии генерит код сильно лучше чем программисты
Это невозможно, образцы кода он списывает у программистов. И как при этом, пользуясь разными кусками, написанными разными программистами, он может написать лучше этих программистов?
увы уже проверенно и оно так и есть как я написал
А вот StackOverflow загнется из-за LLM, вот тогда и посмотрим, как он будет писать.
Так он уже загнулся
Должна быть некоторая пауза между загибанием SO и ухудшением кода LLM. В SO была очень хорошая база кода и оценки его качества. Причем это не только SO. Когда роботы будут только списывать друг у друга, ИМХО все это будет деградировать.
Ну хотите пауза уже давно прошла по сути со загнулся , я сказать честно не могу вспомнить даже когда последний раз ходил туда за последние три года
Мы двигаемся к усредненному, стандартному, безыдейному во всех отношениях коду... Откуда ИИ брать в дальнейшем эти самые правильные примеры, если все съест нейрослоп? Вопрос риторический
Он не загнулся. Он очистился от школоты. Ещё скажите, что форумы загнулись.
Самые лучшие программисты обучались на образцах кода "средних" программистов. Почему они стали лучше?
Оно учится на лучших программистах)
Потому, что у них есть сознание, цели, эмоции. Они хотели быть лучше. LLM ничего хотеть не может. Он лишь генерит наиболее вероятный ответ. Но наиболее вероятный ответ в любой сфере -- это говно.
Так же, как селекционеры получают организмы лучшего лучшего качества для сельского хозяйства из имеющихся менее качественных. Из яблони-дичок с мелкими кислыми яблоками получают обильное плодоношение сладкими.
Ученик может превосходить учителя, были исследования на эту тему - как отсеивает некачественное из обучающих данных, на основе выученных закономерностей в бигдате.
2) Не только на основе кода программистов обучены ЛЛМ, но и на основе огромного % синтетики, проверенной запусками на тысячах виртуалок.
ну и в среднем ии генерит код сильно лучше чем программисты...
Если "программисты" -- это вы, охотно верю.
Ну вот за spec driven dev буду стоять - если бы было время и силы, в идеале разработка так бы и выглядела даже без всяких LLMs. Отделить планирование от кодирования - совершенно разумная цель, и очень хорошо, что её стало проще добиться.
Только в реальной работе оно возможно только если делаешь то, что уже сто раз делал. Серьезная разработка состоит из кучи экспериментов, теорий и переделок, а не написал спеку и потом по ней просто код пишешь
Смотрите, даже если вы пишете небольшую функцию, которая у вас занимает 3 часа, всё равно вы отдельно её продумываете, и отдельно программируете, не так ли? И если что-то работает не так, у вас хотя бы в голове же есть картина -- проблема в постановке задачи или в реализации.
Соответственно, вы пишете спеку и по ней программируете задачу, потом следующую и так далее. Но на практике так никто не делает не потому, что это концептуально неправильно, а потому что нереально.
Но с появлением LLM это стало реально. Я сейчас почти все задачи для LLM прогоняю через OpenSpec, крому ну уж совсем мусорных на выброс. Я ему даю описание задачи (фактически github issue), дальше он генерирует несколько документов -- развёрнутое описание того, что надо сделать и чек-лист, он же "definition of done". Дальше запускается процесс, и если всё проходит хорошо, краткая выжимка этого всего (что конкретно сделано) становится частью документации проекта.
Как раз с небольшой функцией это реально. А когда надо написать целую оригинальную систему - все равно все идет через прототипирование, PoCи и так далее. Нельзя описать в задаче полное устройство системы - это будет по сложности примерно равно ее реализации
А для правки мелких багов и таких же задач - спеков особо и не нужно, агент сам разберётся, если база есть
Ну я не вижу тут больших противоречий. В openspec описания полного устройства и не ожидается, всё по канонам agile. В идеале есть документ, который описывает общие принципы (используется такой-то фреймворк, такие-то архитектурные решения), и есть описание требуемой задачи, по сути github issue. А по мере закрытия задач растёт проектная документация.
Проблема любых методов программирования, которые опираются на естественные языки (спецификации) - заключается в том, что между людьми спецификация объясняет главные идеи - а остальное люди сами достраивают исходя из логики, контекста и знания предметной области. Поэтому опытный разработчик ценится больше чем начинающий - из-за контекста в голове, а не потому что он знает слова языка программирования лучше. Любая попытка "улучшить" спецификации сделав их более подробными - на самом деле ухудшает дело, потому что примерами человеческих подробных спецификаций являются законы (которые хрен прочитаешь и поймешь без специального образования). Кроме того, удачи вам ловить противоречия в тоннах английского текста. Если мы достаточно упорны - то мы будем упрощать язык и ужесточать его правила, чтобы было легче анализировать спецификации не только LLM, но и формальными методами. И через несколько итераций мы придем к тому, что идеальная спецификация пишется на специально сконструированном языке с жесткими языковыми конструкциями и структурой. Дальше достаточно посмотреть вокруг, и убедиться что такие языки: Java, Python, C/C++, Бейсик прости господи - уже давно изобретены и используются.
Я бы сказал, что это разумная критика, но она сама по себе настолько в общих чертах сформулирована, что непонятно, соглашаться или спорить. Дьявол в деталях.
С одной стороны, если я даю абзац текста подчинённому, и он пишет целую подсистему, я по сути уповаю на то, что он достаточно опытен, и у него в голове "логика, контекст и знание предметной области" совпадают с моими. На практике это поучается методика plug and pray, ну ок, небесспорно.
С другой стороны, "более подробными" по сравнению с чем? Очевидно, что английский текст не должен приближаться к Питону по объёму, но точно так же очевидно, что какие-то технические решения должны быть либо частью постановки задачи, либо запротоколированы уже после реализации, чтобы было понятно, что вот эта штука оптимизирует память, а не скорость, или наоборот, и так оно задумано.
Для меня очевидно, что три строчки текста из issue в качестве описания подсистемы явно мало. С другой стороны, конечно, надо избегать крайностей.
Это немного отклонение от темы - но я лично вместо spec-driven и далее по списку - использую ИИ там, где он несомненно полезен: первый раз на этапе ideation/solutioning - чтобы получить доступ к широким знаниям модели. Второй раз - на этапе деталей реализации (ибо оно помнит конкретные методы spring batch или spring security сильно лучше чем я). Но в середине между этим: выбор способа реализации, обозначение границ - я предпочитаю работать сам. Чтобы ИИ у меня работал в режиме "спишите, расставляя пропущенные буквы" (C). Третий раз я его использую после того как написаны интеграционные тесты, чтобы он посмотрел на code coverage map, и сформулировал мне существенные бизнес-кейсы и edge-cases которые нами не покрыты - и дописал тестов на них.
SDD мы пробовали - но остались в задумчивости. Если не читать тонны текста которые он производит - то в чем смысл ?! Если читать - то кто это будет делать и за чьи деньги ? Если в процессе реализации спеки LLM все-таки налажала, то надо ли все сбросить, и пробовать еще раз улучшив спеки (а куда списать затраченные токены) ? Или пробовать делать корректирующую спеку (а кто потом будет разбираться в этой лапше) ?...
Возможно, ситуация будет лучше если проект с самого начала делается по SDD и спеки периодически грумятся. И то - у меня вопросики относительно того, не сожрет ли чтение спецификаций весь разумный контекст...
В нашем случае - мы делаем нечто сильно более легкое чем SDD - мы заставляем ИИ поддерживать онтологии разного функционала системы. Это позволяет ткнуть ИИ в готовую онтологию, и предотвратить постоянное шараханье по дереву исходников: "А давайте прочитаем build.gradle, а давайте прочитаем еще контроллеры, а давайте прочитаем то, а еще вот это...".
Да, ситуация понятна, ну мы все живём "в процессе", и у меня нет твёрдого мнения по этому вопросу. Моя интуиция состоит в том, что концептуально правильно разделять этапы планирования и разработки, а каждая задача должна оставлять за собой некие осязаемые артефакты -- код, документацию, юнит-тесты. Разделение на планирование и код -- это такое же разделение, как на "багфикс", "рефакторинг", "новая функциональность". Вроде нет сомнений, что нехорошо в одном коммите совмещать багфикс и новое, но при этом превратить два предложения текста в три страницы кода через "магию" в голове -- как бы ок.
В принципе, тут же нет ничего нового: скажем, в TDD вы тоже по идее заранее пишете тесты (они же спеки по сути), а потом уже код. С другой стороны, многие классические рекомендации даются не потому, что они оптимальны, а потому что иначе нереалистично. Скажем, вы можете просить LLM делать себе код ревью хоть три раза в день, но коллега этого делать не будет.
Кроме того, разные этапы можно делать разными системами с разной ценой, если хочется сэкономить.
Признаться, я не читаю всё, что генерирует openspec. Я читаю хотя бы tasks.md (то есть чеклист) и общее описание design.md. Выгода (как мне кажется, на истину не претендую опять же) в том, что 1) после завершения работы только небольшая часть этого текста становится проектной документацией, вы получаете её бесплатно, и дальше при решении других задач LLM может читать документацию, а не лопатить сразу код (что опять же по идее должно экономить токены); 2) иногда в процессе работы LLM начинает автоматически жаловаться, что какой-то кусок кода не соответствует спецификации, а это сигнал -- надо перепроверить и исправить либо документ, либо код.
Глобально, помню, в какой-то книге было сказано, что если вы говорите, что не используете какую-то "методологию программирования", то вы просто не знаете, как она называется. Можно подходить к процессу по-разному, но надо отдавать себе отчёт в том, что конкретно происходит. Если у вас немного людей, и вы все на одной волне, может, и вправду незачем разжёвывать -- и так каждый понимает друг друга с полуслова. Но надо чётко осознавать особенности сетапа -- у кого-то так, у кого-то не так.
Скажем, мне комфортно думать в процессе письма, вот как сейчас. У меня есть коллега, который с ChatGPT общается голосом. Для меня это нонсенс, я не могу говорить и при этом думать. Но для него комфортно, что ж.
Согласен с @rg_software SDD - это то, как должна выглядеть разработка в идеале. И не важно, кто там "под капотом" - "кожаные" или "силиконовые".
"План эксперимента", так-то, тоже можно считать своего рода спецификацией. А удачные бизнес-приложения сейчас вообще никогда писать не заканчивают (тот же Youtube, Facebook, Amazon, ...). Так что картинка "написал спеку, а по ней просто код пишешь" - это всего лишь маленький фрагмент жизненного цикла приложения.
И это... я сейчас так и делаю - пишу документацию (спецификации), а по ним агент код генерит. Потом меняю документацию и агент меняет код. Ну и т.д.
Но оно же так в реальности на проектах не работает! Это не улица с односторонним движением - от бизнеса через требования и спецификации к коду. Наоборот, если бизнес сумел нахреначить спецификаций без нашего ведома - значит скорее придется делать двойную работу - сначала отменять то что уже успели утвердить, а потом еще раз утверждать уже то, что нужно. Правильный подход - это когда бизнес вам намекает на проблему (или даже если это хороший бизнес - то прямо рассказывает в чем она заключается), а дальше вы с бизнесом делаете несколько итераций пытаясь найти такое решение, чтобы оно и в существующую реализацию хорошо легло, и бизнес устроило... Нет, понятно что все это можно сделать и на спецификациях - но я хочу понять какую проблему вы этим пытаетесь решить ? Из наших экспериментов с SDD - мы увидели выигрыш только в одном случае: у вас на проекте почему-то разбежались все люди которые умеют читать и писать код (разрабы), но остались люди которые умеют и любят читать английские тексты (аналитики). Тогда без SDD вы будете стоять пока девелоперы не вернутся - а с SDD вы будете криво-косо, но ехать практически без умения читать код. Но поскольку эксплуатировать дальше продукт без чтения кода нельзя - то движение это ограниченное, и потом придется технический долг вернуть...
Мы, наверное, разное вкладываем в понятие SDD. Я, например, вкладываю в это понятие то, что при хорошо написанной документации, код можно доверять (пере)генерировать агенту. Но "спеки" в этом случае должны описывать не только продукт с точки зрения бизнеса, но и используемые технологии, платформы, проектные соглашения и т.п.
Но поскольку эксплуатировать дальше продукт без чтения кода нельзя
Можно. И вы сами это делаете. У ИТ-сообщества богатый опыт использования сторонних библиотек (те же .dll в windows и .so в linux). Сборщики типа maven, composer, npm - это из этой же оперы. Вам необязательно лезть в код, чтобы использовать продукт. Достаточно контракта.
Ну как бы да - я пользуюсь maven не глядя в его код. Но maven - детерминированный тул, а агент на базе LLM - нет. Он пишет по одной и той же спеке немного разное. А один раз на N запусков может вообще все зафакапить...
В общем, на текущем уровне развития ИИ, я не готов объявить code - secondary артефактом который можно дешево регенерировать. Вне зависимости от того, какой harness мне дадут, и сколько текста в спеку оно напишет. Потому что оно нет нет, а напишет одно - а сделает другое...
Возможно, моя осторожность проистекает из отрасли в которой мы сидим. Если ошибка в проде никого серьезно не напрягает, и просто является сигналом перегенерировать код и попробовать снова - то можно и поиграть в игру 'spec is a source of truth, not the code". Я в это (пока!) играть не готов...
Это вообще лишает смысла применять LLM в разработке там, куда их пихают сейчас, а именно в основном в генерацию кода. Хотя применение им всё же есть, и очень полезное, и даже не одно.
Нет никакого автопилота. Чтобы добиться качества (архитектура, безопасность, производительность) нужно все вручную контролировать, собирать контекст, ревьюить и исправлять. Иначе будет лапша на дубликатах и тупости.
В отличии от авиации программирование с ИИ это уже ракета по объему кода в секунду. Пилот при старте ракеты все что может это молиться. Задача программиста в таких условиях это разработка инструментов (элементной базы)
Казалось бы, выход прост - надо ревьюить и тестить код который аи понаписал, на каждой итерации. Тогда скорость всё ещё в разы выше чем вручную, и ничего не атрофируется. Но людям просто лень
Так он сам и тестирует и ревью, с этим вообще нет проблем
ревьюить и тестить код который аи понаписал, на каждой итерации
С учётом его привычки на каждой итерации стрелять дробью / переписывать половину проекта - получается ад ревьювера
Да, но зависит от модели и правил разработки которые ей предоставили в системном промпте.
У меня нормально генерят локальные модели qwen3.6/3.5 - отдают только измененные строки по поставленной задаче.
Я использую свой набор правил разработки, можно попробовать его весь или только пункты [RULE_STYLE_CONSISTENCY] и [RULE_NAME_STABILITY].
Если подключить набор правил разработки целиком, то в первый раз может серьезно изменить код - для приведения в соответствие с правилами, но потом будет выдавать аккуратные точечные правки.
Все пункты правил составлены по фактическим кейсам из llm-разработки - если я видел что модель постоянно совершает одни и те же ошибки - я создавал правило для такого случая.
Наверно, нужен какой-то новый термин вместо "вайбкода" для контролируемой llm разработки, где она выполняется по строгим правилам, и проходит ручное код-ревью.
Но людям просто лень
Народ понаписал кучу комментов вместо того, чтобы честно признаться, что не только лень просматривать ИИ-портянки, но и самому писать код. К сожалению, мы так устроены - мозг экономит энергию при любой возможности, что неудивительно - холодильник с едой появился буквально “мгновение” назад по сравнению со временем эволюции нас как вида. ИИ - мощнейшая эксплуатация этого “бага”.
Процессы мышления при управлении самолётом и программировании значительно отличаются. В управлении самолетом исключен творческий подход, он даже запрещен. Управление самолетом - это зазубренные «до не могу» тысячи страниц определенных предписаний к действиям, их порядку и таймингу. К тому же, пилот не бывает «универсальным» и пересесть с 737 на 747 это не перейти с одного фреймворка на другой. Пройдя обучение и аттестацию на симуляторах пилоту достаточно поддерживать знания, а не развивать их. Поддерживать практически на уровне робота. У программиста-разработчика ПО совершенно другая история.
Поспорю - действительно, виды работ разные. Но творческий подход и у программистов ограничен - мы пишем на достаточно строгих языках, шаг вправо-влево - ошибка компиляции. Аналогию codebase awareness с situational awareness - считаю принципиально правильной: чрезмерное применение автоматизации вызывает деградацию человека в цикле управления - и когда происходит факап, выясняется что никто точно не понимает как оно случилось, и что делать. Последствия разные - это правда. Но тем ценнее перенимать опыт из индустрий где ошибки стоят дорого, и поэтому они раньше нас задумываются что с ними делать...
В программировании, как правило, существенно больше одного способа сделать что-то. И есть период тестирования, выявляющий критические ошибки. В авиации управление происходит в реальном времени (код в условиях таких ограничений не пишет никто), а цена ошибки чрезвычайно высока.
Таким образом - да, проблема деградации разработчиков в IT-индустрии есть, но "авиационными" методами она не решается, слишком разные предметные области.
Если бы в авиации был единственный способ все делать - то летчик точно был бы не нужен: запрограммируй этот способ (он же один!) - и профит! С другой стороны, если вы Cloudflare и оно упало - то чинить вы будете в таком же стрессе как пилот, у которого замигала лампа "пожар 1 двиг"... Я не говорю что надо механически переносить руководящие документы из авиации в ИТ - но их опыт (пере) автоматизации надо изучать, и свои документы писать с оглядкой на него...
Очень правильный комментарий. Ноги растут от ожидаемого % успешных завершения проекта (полёта или написанной фичи). Если б существовали методологии, при которых фича шиппится без багов с первой попытки с той же вероятностью, что успешно завершится регулярный полет в гражданской авиации, то программирование было бы совершенно другим (и, к слову, это бы понравилось пиджака, но превратио бы в ад работу инженера)
IMHO, самый правильный режим программирования с использованием ИИ-агента - это парное программирование. Сначала агент пишет код, ты проводишь ревью, потом - наоборот :)
В итоге, с разработчика снимается часть рутины, но у него возникает понимание того, как и что работает в проекте. А ещё, ИИ-агент - это идеальный "резиновый утёнок", об него удобно оттачивать разного рода идеи в режиме обсуждения.
Вы говорите "
Конкретно атрофируется несколько вещей:
Умение читать незнакомый код:когда агент объясняет что делает каждый метод, навык самостоятельного разбора не нарабатывается." А когда незнакомый код составляет несколько тысяч строк и чтобы понять в чём предназначение той или иной функции, чтобы в дальнейшем в нужном месте прикрутить свою фичу, при самостоятельном разборе займёт уйму времени, нежели если просто задать вопрос агенту, так и возникает вопрос, насколько оно вообще нужно самостоятельно разбираться в коде? До какого момента?
Одна цифра там не меняется уже несколько десятилетий: около 80% катастроф связаны исключительно с человеческим фактором.
100% катастроф связаны с человеческим фактором! Начиная от неудачных инженерных решений и заводского брака и заканчивая неудачным выбором эшелона при преодолении грозового фронта. В конце концов кто-то же отвечает за допуск конкретного лайнера и экипажа в рейс. Так что корреляция тут стопроцентная, вся суть лишь в длине этой корреляционной цепочки...
Главное отличии ИИ от автопилота в самолёте - первый вероятностная модель, второй алгоритм с чётко прописанными условиями. Это совершенно разный уровень надёжности, нельзя их в лоб сравнивать.
Также, конечно, проблемы с управлением на самолёте - это не то же самое, что проблема в коде. Большинство из нас не пишут код для настолько критических мест.
А те кто пишут, не имеют права не глядя деплоить что им сделал ИИ. Отвечает всё равно человек.
В общем, ИИ - это компромисс между ценой+скоростью и надёжностью. Люди решают идти на компромисс или нет, в зависимости от того какой риск их устраивает.
А почему вообще качество кода должно быть заботой программиста? Если сам владелец бизнеса ставит программистов в такие уловия- или вайбкодишь или идёшь на мороз. Всё развалитца через 5 релизов и пол года? Да наплевать. Я уже зарплату получил. Ты начальник, я дурак. Хочешь тонны вайбкода, их есть у меня.
Так не развалится же
Ну, так это же прекрастно. Всё получают, что хотят. Маск получает свои триллионы баксов инвесторов, программисты поучают прекрасного помощника, который пишет код, владельцы бизнеса получают снижение издержек и повышение прибыли. О чём тогда плакать то?
О том, что 80% программистов выгоняют на мороз, а оставшиеся 20% говтрят "да вы не понимаете, это просто проблема в экономике". Не, у тех, кто живет на дивиденты и управляет решением правительств разных стран проблем в экономике нет, как и войны и всего прочего, это есть только у тех, кто не в той семье родился.
Компетенции и опыт постепенно обесцениваются, а родственные связи и правильное детство - растут в цене, но, увы, я их не могу изменить.
О том, что программы теперь весят не 5 MB, а 500 MB. При том же функционале. Ещё и не работают без Сети.
Приложение Сбербанка перевалило за гиг еще до анонса ChatGPT (сейчас bigbeta откатилась к "скромным" 887 МБ). Приложение Яндекс.GO вынудило меня купить "геймерский" смартфон в 2021, потому что на старом 4 ядра 4 гига оно открывалось 25 секунд (я замерял с таймером).
Плохому танцору никакой ИИ не помешает, буквально НЕЛЬЗЯ написать приложение хуже, чем пишут некоторые специалисты. Давно пора их всех поменять на клод за 20 баксов.
программы теперь весят не 5 MB, а 500 MB. При том же функционале. Ещё и не работают без Сети.
Точно? Кмк наоборот, добавляются функции, о которых лично вы не просили, и не пользуетесь - вот вам и кажется что только размер поменялся.
Меня только пара моментов в этой истории смущает:
С тебя требуют наличие навыков, которые при таком подходе тяжело наращивать и поддерживать.
С тебя спрашивают больше output'a, но ничего не дают взамен. Что-то я не слышал, чтобы разработчики массово рапортовали, что внедрение AI повлекло за собой рост зарплат, ведь теперь они в хN быстрее!
Другая глобальная проблема - человек перестает понимать проект в целом. А без этого не может задавать правильные вопросы и ставить задачи для ИИ.
Классная мысль про “ручной налёт”. Мне кажется, это шире, чем разработка. Любая автоматизация опасна, если человек перестал понимать процесс, который она закрывает. В локальном бизнесе вижу похожее: хотят бота или CRM “Чтобы не терять заявки”, но до этого не описаны статусы, ответственный, следующий шаг и момент, когда клиент считается потерянным. В итоге автоматизируется не порядок, а хаос))
Интересно, нужен ли командам с AI-агентами свой регламент ручной практики - дебаг без агента, ревью до подсказки модели, небольшие задачи с нуля?
Еще пару лет и профессия "программист" встанет рядом с профессией "кучер" .
О я тот кто последнее время стал часто скидывать много задач агенту, начал замечать что когда меня спрашивает проджект типа "А что у нас в этом блоке, как считает?" , я часто сходу не могу ответить, хотя на старом проекте, который писал еще 2-3 года назад, без ИИ агента, частично могу хоть сейчас ответить как устроен тот или иной процесс, без сильной детализации но в целом. Деградация реально заметна, вопрос в другом, готов ли бизнес сегодня платить , если я буду лишнее время тратить на "антидеградацию"? Лишний раз прогонять код глазами? Что-то мне подсказывает что нет. В халвабанке, сверху активно агитируют чтобы старались больше скидывать кода на агента, локально уже каждый тимлид сам решает, но сверху идут "приказы" на глобальное ИИ-использование.
Забегает как-то чувак в опиумный притон и кричит «Пацаны, наркотики — зло!»…
А ему все в ответ «О дааа, даа, конечно же! Пф-пф-пф… Лютое зло! Пф!»
Boeing ведёт статистику авиационных происшествий с 1950-х. Одна цифра там не меняется уже несколько десятилетий: около 80% катастроф связаны исключительно с человеческим фактором.
Открыл ссылку. Полистал. Human Factor не увидел. Поискал. Не нашел.
Написал камент и закрыл статью не читая.
Вот почему в моей компании никогда не будет ни "generative AI", ни "agentic AI", ни прочей чуши.
PS: Тем двум, кто поставили минусы статье, желаю, чтобы хирургические операции по спасению их жизней выполнили вайб-хирурги.
Всё норм. Просто программисты-инженеры из кодеров становятся менеджерами своего раба - AI. Работа другая по содержанию, поэтому квалификцации в области кодирования утрачиваются - так же как утрачены квалификации телефонистки-коммутатора. Вся разница лишь в надежности - на том этапе у автоматического коммутатора была надежность намного выше 99%. А у AI она где-то процентов 80, может 70 - по моим ощущениям и по моим задачам. Но уже не 50, как было год назад.
В отличие от человека ИИ не учится на решаемой задаче. Новая версия условно "прослушала углубленный курс", но не получила опыт в вашем проекте. А вот опыт человека действительно теряется.
В отличие от человека ИИ не учится на решаемой задаче. Новая версия условно "прослушала углубленный курс", но не получила опыт в вашем проекте.
Смотря что вкладывать в понятие обучения. Новых навыков не приобретает, да – веса фиксированные для данной версии. А вот базу знаний по конкретному проекту очень даже накапливает, в различных формах: спеки, созданные в процессе решения отдельных задач, плюс история проекта в ~/.claude/projects/{project path}, правила и скиллы, созданные в процессе работы над проектом, тесты, в конце концов.
Я сейчас делаю небольшой (~30К строк кода) проект, изначально в паре с клодом. И самого начала по всем канонам: SDD, TDD. Сам не пишу практически ничего, иногда какие-то мелочи подправляю. И качество кода, и функционал вполне удовлетворительные, и в процессе добавления фич предыдущие решения он помнит прекрасно – порой лучше меня. На каждое решение в проекте есть два документа: спека и план реализации – к которым он при необходимости обращается. Тестов более 800, 77% покрытие. Это можно считать обучением? Новая версия модели эти знания будет использовать точно так же, как и предыдущая.
Аналогия с авиацией бьёт точно, но есть различие, которое делает ситуацию для разработчика даже хуже: у пилота отказ автопилота — событие редкое и заметное (приборы, тряска), а у нас «отказ» агента размазан тонким слоем по сотням мелких фрагментов и ничем не сигналит. То есть момента «бери управление на себя», который тренирует пилота, у нас просто нет — приходится назначать его себе искусственно. По-моему, рабочая практика — раз в неделю брать одну небольшую задачу и делать целиком руками, как «налёт вручную». И совет про code review до того, как просишь агента объяснить чужой код, — недооценённый, забираю себе.
1 июня 2009 года над Атлантикой ночью обледенели трубки Пито на Air France 447. Приборы скорости показали некорректные данные, автопилот отключился. Двое пилотов, которые находились в кабине, не имели подготовки к ручному управлению самолётом на большой высоте — и это было видно по их действиям: они потянули нос вверх вместо того, чтобы опустить. Самолёт вошёл в сваливание. Экипаж так и не понял, что находится в режиме сваливания, и не предпринял ни одного манёвра для выхода из него.
Наглядный пример почему в авиации еще долго будут нужны пилоты, если приборы дают некорректные показатели, то у автоматики просто нет шансов.
И зачем нужны такие пилоты, которые в совершенно безобидной ситуации угробили себя и самолёт со всеми пассажирами? К сожалению уних не только не было навыков пилотирования в данных условиях, но и с логикой большие проблемы. Если вы секунду назад находились на высоте 9000 и летели со скоростью 900, то в следующую секунду всё останется примерно так же, если самолёт вокруг вас не развалился на куски. А он не развалился, поэтому дёргать штурвал это крайне хреновая идея. Тут прямая аналогия с ослеплением водителя автомобиля встречным светом. Встречный свет никак не влияет на сам автомобиль, не меняет его скорости и направления, поэтому крутить рулём и жать на тормоза во время ослепления это прямая дорога, в лучшем случае в кювет, а в худшем на тот свет.
Так нет других вариантов, без пилотов автоматика бы все ровно разбила самолет из-за неверных показателей.
Тут прямая аналогия с ослеплением водителя автомобиля встречным светом. Встречный свет никак не влияет на сам автомобиль, не меняет его скорости и направления, поэтому крутить рулём и жать на тормоза во время ослепления это прямая дорога, в лучшем случае в кювет, а в худшем на тот свет.
С автомобилем проще, есть возможность плавно остановиться или даже резко и в 99% ни чего страшного не произойдет.
Эта логика работает только на прямой. Если водителя ослепило в момент, когда он входит в левый поворот, то отказ крутить рулем и жать на тормоза до момента когда получится проморгаться и сориентироваться как раз и будет прямой дорогой в кювет.
Это наглядный пример, что нужно делать резервирование, а не что нужны пилоты
Резервирование не гарантирует отсутствие ошибке в каждом узле, резервирование тоже имеет свой предел. Ни какая автоматика не смогла бы посадить самолет на Гудзон когда птицы повредили оба двигателя на малой высоте.
Резервирование не гарантирует отсутствие ошибке в каждом узле
Также, как наличие пилота не гарантирует, что он способен совершить правильный манёвр в той ситуации, где автоматика отказала. По сути это отдельный вид резервирования, когда резервирование осуществляется не одним прибором, а двумя разными (с разных партий, заводов или моделей). Людей, кстати, тоже можно резервировать
Оооо. Смотрю как некоторые програмиистишки в комментах распетушились, все еще надеятся, что их не заменят. Этот сериал никогда не утомит
Однажды у мастера сломалась дрель, а он настолько привык, что она работает, что не смог проковырять дырку сам.
У другого походника промокли спички и он не смог высечь огонь камнем.
Мораль у этой сказки - у использования любого инструмента есть цена - вы можете забыть, как работать при его отсутствии.
Осталось только выяснить кто это все оплатит. Оплатить может только потребитель. Готов ли потребитель накинуть условную десятки и подождать условную неделю пока программист развлекается? Не уверен. То есть уверен что нет. Так что звучит прекрасно, но не работает. Но это не мешает тем кто хочет делать это самостоятельно. Правда как я понимаю всем хочется что бы этим за бесплатно занимались другие.
это проблема, которая проявится позже, когда агент сгенерирует что-то нерабочее и нужно будет разобраться почему.
ИИ возможно допустит меньше ошибок, чем джун который пишет сложное приложение сам. Вопрос в том, должны ли джуны писать такое сами.
автор лукавит ... пишет всякую фигню вместо того чтобы пойти лошадь подковать, телегу смазать ... С бензом ведь уже известный дефицит, в магазин ничего не возят а где копьё - заточил? Бухгалтеры с появлением 1С разучились считать в уме, не говоря уж о счЁтах, не умеют закрыть 20ые, 90ые и 91 счета руками. Программисты не умеют заправить ленту в матричный принтер, перфокарты зарядить в ЕС-2032.
Некоторые навыки, дядя, становятся ненужными, это называется "эволюция". Я не верю что если программер пишет сам то это на 100% спасает от скрытых "угроз". Так не бывает. Тупых очень много
Вы сознательно, или несознательно игнорируете существенный момент - ВСЕ ранее перечисленные инструменты (счеты, 1С, etc) являлись детерминированными. А LLM - принципиально вероятностная система. Одно дело - заменять прошлую детерминированную систему - другой детерминированной системой. Другое - менять известный предсказуемый (!) тулсет на принципиально более производительный, но время от времени сходящий с ума. Первое - несомненно прогресс. Второе - сомневаюсь... :-(
Некоторые навыки, дядя, становятся ненужными
Да на здоровье. Как только придём к решению, что все эти ваши Python, Java, Go, Haskell можно в помойку отправить, ведь никто на них больше писать продакшн не будет — тогда можно говорить о ненужности. Когда и всё это одновременно нужно, и одновременно тебя хотят воткнуть в конвейер, на котором эти навыки теряются в обозримой перспективе — это харчок в лицо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем лучше Claude Code, тем хуже разработчик