Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 76
Учитывая
Просто теперь эту работу делают агенты
У вас ошибка на сайте. Нужно убрать из футера
by Alex Gusev.
Заодно из моей разработки почти исчезли Pull Requests.
Судя по описанному, у вас исчезла разработка, а не PR. Вы стали менеджером.
Да, совершенно верно. И в этой моей деятельности PR стали не нужны.
да нет, вы просто перестали быть разработчиком))
путаница причины и следствия - для менеджмента все эти PR, автотесты и прочая ересь всегда выглядит лишней потерей времени с точки зрения менеджмента (как и разработка архитектуры впрочем). Если у вас во всей цепочке разработки живой человек только на входе то оно и реально не нужно.
Качество кода и прочее далеко вторично если вас все устраивает
Проблема работы через спеки (SDD) в том, что под капотом всё-равно вайб-кодинг и соответствующее качество кода. А настолько сильная детализация спеки, которая бы решила эту проблему, обойдётся заметного дороже кода - что возвращает нас к тому, что код это и есть та самая спека.
Вполне может быть, что со временем на базе SDD и родится что-то рабочее, но пока ещё нельзя принимать сгенерированный ИИ код не глядя, просто потому что он прошёл сгенерированные тесты и другой ИИ подтвердил что он соответствует спеке - функционально такой код вполне может работать, но вот нефункционально это будет полный провал (производительность, безопасность, надёжность, соответствие законам, особенностям текущего бизнеса, etc.).
Спека это упрощённое описание требуемого кусочка/изменения. Проблема, что никто не понимает как работает целое. Работает ли целое так как надо (а как надо?) и не делает ли как не надо.
Даже если спека будет очень детальной она может быть фрагментарной и противоречивой
Это всё верно, но проблема вовсе не в этом. Проблема в том, что SDD подразумевает отказ от ревью кода. Потому что если от ревью не отказываться, то SDD просто удорожает разработку в два раза не давая взамен чего-то равного по ценности. Безусловно, спеки важны и нужны - но в том минимальном объёме, от которого пользы больше, чем затрат на сами спеки. А оставшаяся часть спеки - это код.
Технологии вроде языков высокого уровня, фреймворков, DDD, DSL, etc. позволяют повысить уровень абстрактности кода (приблизить его к спеке) не теряя над ним контроль до такой степени, при которой пропадает возможность обеспечить выполнение нефункциональных требований. А вот технология ORM знаменита тем, что большинство реализаций этот баланс не выдерживают, и контроль теряется неприемлемо сильно - поэтому в высоконагруженных проектах от него обычно отказываются. Вайб-кодинг же находится вообще в конце этой шкалы, где контроль полностью отсутствует - а без контроля допустимо писать только одноразовые скрипты и прототипы.
Я не спорю. Просто акцентирую на другом
вот технология ORM знаменита тем, что большинство реализаций этот баланс не выдерживают
Кому знаменита?
контроль теряется неприемлемо сильно - поэтому в высоконагруженных проектах от него обычно отказываются
Сильное утверждение.
А всё, как обычно, исходит из предположения, что ORM конфликтует с raw sql. На самом деле никто не мешает использовать чистый sql при наличии ORM. Тем более, что даже в самых высоконагруженных проектах эта самая высоконагруженная часть составляет малую часть кода. Ради оптимизации этой части кода переводить только её на sql - ок, но получить ручной маппинг во всём проекте со всеми ошибками белковой (и небелковой) нейросетки - это за гранью моего понимания. Зачем? И главное, нафига?
ORM занимается маппингом сущностей и, самое главное, обеспечением корректности маппинга при дрейфе структуры. А у вас дрейф будет, если проект развивается. И он занимается этим детерминированно, так что ваше сравнение ORM с нейросетями огорчает поклонников ORM.
Соглашусь. Мое ИМХО - что идеальная ОРМ должна быть написана так, что для понимания и доработок того, что делает написанный на ней код, достаточно самой решаемой задачи + знания SQL. Если надо учить какой-то свой отдельный язык запросов или надеяться, что "ну там под капотом все норм соберется в реальные запросы" - это прям мина замедленного действия зачастую.
Спека может быть и полной и точной.
Короче, спека это RFC , request for change
А только из них программу не построишь
никакая детализация спеки не поможет от фигни вайбкодинга
все равно потом точечно уже но несколько кругов наворачиваешь теми же агентами по коду что бы получить что то удабриваемое
я пробовал в свое время разные подходы но даже расписанный на два десятка отдельных файлов план с прописанным всем от логики до того как проверять не спасло от переписывания 1/4 потом нормально
сейчас кстати кодовые агенты начали делать очень плохую вещь, такую как память меж сессиями, из-за чего на сейчас отдельные перепроверки могут продолжать говорить что все ОК (но стоит только чистую изолированную сессию прогнать как вылазят баги которые агент со своей стороны в памяти прописал как "фичи" которые нужно игнорировать при проверках )
А что мешает добавлять перед генерацией спеки эту самую нефункционалку, желательно в виде явных вопросов кожаному - типа, а чо у нас по РПС? А железу? А в GDPR нннада или не очень? Топовые сетки после ответов вполне могут предложить приемлемые решения и в спеку и прикопать, если это не экстремальные сценарии а-ля бигдата в гугле или что-то очень редкое по языку. Причем такие вопросы ну явно не в каждом ПРе нужны и даже не в каждом пятом, точно так же, как мы не ожидаем, что джун трехмесячного срока работы будет их решать самостоятельно(да даже и мидл).
Другое дело, что (сейчас будет ВБРОС, внимание) зачастую хороший код - это изнанка хреновой работы с требованиями. Типа, а мы вот этот функционал планируем расширять на другие процессы? Нуууу не знаааю, вроде планы есть, но дойдет до дела или нет - непонятно, лучше перезаложитесь. И появляется хороший расширяемый код "про запас", условно фабрика какая-нибудь вместо обычного класса. Хотя в случае с ЛЛМ кодогенерация а) дешевая б) быстрая и если у тебя есть нормальный контроль скоупа, по которому "сейчас работаем с 2 процессами, в пределах 3 месяцев так и будет, через 3 перепроверим" - то нет ничего плохого, если сейчас у нас 2 класса-копипасты - если понадобится, перепишем на наследование, фабрику, DI или еще чего, качество кода тут в том, что он должен делать то, что написано в требованиях, А ВОТ КАЧЕСТВО САМИХ ТРЕБОВАНИЙ - это отдельная история. Но она и до ЛЛМок губила проекты и компании только в путь.
А, ну и звездочка - речь, конечно, про массовую разработку. Всякие там драйвера, бигдата запредельных размеров, программы для марсоходов - это не про них.
Мешает то, что пока никто не придумал, как изложить нефункциональные требования так, чтобы они реально выполнялись.
Давайте возьмём самое простое: производительность бэкенда. Там тупо можно задать требования RPS для API. Казалось бы, можно даже написать автоматизированный тест, который будет проверять соответствие этому требованию, и вуаля! Но нет, даже это на практике работать не будет, по куче причин:
Где будет запускаться этот тест - на реальной площадке, на CI, на ноуте разработчика? Если на реальной площадке, то как обеспечить контроль выполнения этого требования в момент написания кода и мержа PR и безопасность самой площадки до мержа (как минимум, это повышает требования к абсолютному большинству проектов в том плане, что для этого им понадобится поднимать отдельную площадку для тестирования PR-ов)? Если запускать на CI/ноуте, то возникает проблема с тем, что их производительность обычно сильно отличается от реальной площадки плюс намного менее стабильна, поэтому неясно какие цифры требовать в тесте на ноуте чтобы на реальной площадке получить нужные.
Компромиссы. Увеличение RPS обычно достигается за счёт чего-то другого - больших затрат памяти, усложнения кода, уменьшения надёжности, etc. Если это всё никто не будет контролировать и мы будем требовать 100% соответствия требованиям к RPS (потому что это зашито в вышеупомянутом автотесте), то получим традиционную картину "оптимизации под KPI", когда максимизация одной полезной метрики фактически даёт больше вреда, чем пользы.
И это было самое простое. А как задать требования к безопасности или надёжности?
В результате попытка задать нефункциональные требования один раз на весь проект превращается в "делай хорошо, а плохо не делай". И даже если эту идею попытаться детально расписать в большом объеме текста суть её от этого не изменится, просто добавится немного конкретики, причём часто конфликтующей друг с другом. И это не работает, очевидно.
А в чем по этим пунктам отличие в пользу кожаной разработки? Точно так же же - и проверять ту же производительность сложновато, и вопрос компромисса не исчезает, и тд. То есть я понимаю в чем - хороший сеньор или даже мидл, погруженный в проект, на опыте/интуиции может заподозрить неладное и начать копать по нефункциональным требованиям в сомнительных сценариях, но это как раз кмк про "нам лень прописать требования, авось разраб за 300к/наносек сам затащит". Ну, часто и затащит, иногда и нет, но это ж не дело.
Если что - подход "фиксируем требование про 100 РПС и дальше во все промпты его пихаем, нехай нейронка сама думает, как это на ПРе отразится" - он оч сомнительно рабочий. Я от ЛЛМ жду другого - что в процессе детализации требований она, условно, заметит, что в проекте уже где-то реализовано кэширование в редиске, а где-то нет, предложит 2 варианта реализации(с и без) на выбор и при необходимости примерно прикинет риски обоих. То есть базовые архитектурные решения(например, то же использование Редиса) - за кожаным(можно с консультацией у ЛЛМ, но с пониманием, что и почему мы в итоге выбираем), понимание, какие куски кода у нас ботлнек - за ним же, пригляд за тем, чтобы проект был хорошо разбиваем на модули, которые в идеале можно легко переписать с околоноля по имеющимся тестам и контрактам - за ним же, а нейронка должна эти установленные правила 1) извлекать либо из мемори банка, либо из самого кода 2) при неочевидности "надо или нет" спрашивать 3) корректно включать итоговые ответы в критерии приемки и спеку. То есть не "эта ручка должна держать 100 РПС", это реально сложно проверять, а "в ходе работы этой ручки мы должны положить в наш кэш такие-то данные по такому-то ключу" - это уже даже юниты на моках могут проверить. А задача разработчика - настроить процесс и собственные представления о проекте, жизни, Вселенной и всем прочем так, чтобы эти "конкретно-лобовые" критерии обеспечивали изначальный верхнеуровневый. И да, это как раз то место, где знания в разработке и архитектуре все еще пипец как актуальны, просто их нужно применять на уровень-два выше, чем для написания кода.
А в чем по этим пунктам отличие в пользу кожаной разработки?
В контексте статьи речь не про отличие, а о том, что кожаные при определённых условиях (при наличии в команде сениоров) в принципе способны выдерживать нефункциональные требования, а ИИ пока на это не способен в принципе.
Тут ключевой момент именно в том, что желающие сильно сэкономить набрав всю команду из одних джунов и пары миддлов уже за последние пару десятков лет поняли, что такая команда им нефункциональные требования соблюсти не сможет, а в отношении ИИ на этот счёт ещё у многих иллюзии остались, вот и играются в вайб-кодинг и SDD, в надежде что получится из букв Ж, О, П, и А сложить слово ВЕЧНОСТЬ.
не "эта ручка должна держать 100 РПС", это реально сложно проверять
Это элементарно и обеспечивать и проверять. Просто для этого нужно иметь в голове больше контекста и понимания проекта в целом и этой ручки в частности, чем возможно выдать ИИ в рамках "общей инфы о проекте" во время работы над каждой задачей.
А задача разработчика - настроить процесс и собственные представления о проекте, жизни, Вселенной и всем прочем так, чтобы эти "конкретно-лобовые" критерии обеспечивали изначальный верхнеуровневый.
Это необходимо, но это только половина работы, и без второй половины - ревью сгенерированного кода на соответствие всему этому и всему тому, что в эти представления о вселенной забыли прописать - оно не работает.
В контексте статьи мб, но моя идея чуть другая: что если не все, то много чего из код ревью, включая и нефункциональные требования, может переехать с уровня собственно кода на уровень той самой спеки, если ее правильно готовить. Проблема же не в том, что "нефункциональное" - это какая-то магия вне Хогвартса, недоступная бездушному кремнию, а в том, что зачастую оно 1) плохо или вообще не формализовано и не локализовано 2) в отличие от разработки бизнес-фич - может начать ломаться совершенно неожиданно и в особо плохих сценариях - еще и незаметно. Грубо говоря, то, что по-прежнему очень критично - знать, какие примерно готовые решения для той же самой производительности разных масштабов есть(или уметь правильно спросить у той же ЛЛМ) и как их готовить в конкретно твоей задаче, что в проекте, скорее всего, приляжет первым при критичной нагрузке, как настраивать логи и мониторы, включая, кстати, тот же фоновый ЛЛМ-анализ(вот уж кому точно можно пялиться в графики 24/7 за 3 копейки) и тд. Условно, я вот про что: у нас есть, допустим, поддержка кэширования в коде и в спеке(явно упомянутая как критерий приемки). Вот ситуаций, когда оно в строгой спеке есть, а в коде пропало из-за глюка кодогенератора - будет раз-два и обчелся, если вообще будут. А вот ситуаций, когда оно даже в спеку не попало(и в код, соответственно, если и попало, то тем же глюком), потому что не подумали/явно не сказали ЛЛМ что-то релевантное/неправильно настроили процесс конверсии требований в спеку - довольно много, и бороться в первую очередь стоит именно с ними.
Вообще, мне кажется, тут еще можно такую аналогию привести с промышленным производством. Код постепенно(или не очень) из штучного товара становится результатом работы конвейера, как какие-нибудь ботинки. При этом ботинки вообще-то тоже бывают с браком - плохо линию настроили, материал подкачал, сотрудник недоконтролировал что-то по ходу дела. Но никто, как правило, не проверят каждую пару ботинок с конвейера - достаточно выборочного контроля продукции + проверок самой линии + понимания, в каких случаях нужно таки смотреть всю партию(например, новая модель или там в процессе производства что-то сильно поменяли только что). Вот код ревью вполне может постепенно мигрировать в эту сторону. Смотреть надо, но не все и не всегда, а когда - это как раз одна из компетенций разраба.
Тут нет "идеи" и тем более нет "решения". В спеку можно написать что угодно, но с нефункциональными требованиями это не сработает. По крайней мере - такова ситуация на сегодняшний день, на практике. Я не исключаю, что кто-нибудь что-нибудь когда-нибудь придумает чтобы это изменить, но пока этого не произошло.
На мой взгляд, проблема в том, что нефункциональные требования конфликтуют между собой (это нормально и неизбежно!), из-за чего требуется постоянно выбирать между разными компромиссами. Заранее предусмотреть в спеке все будущие конфликты чтобы заранее задать как их разрешать - невозможно. Квалифицированные люди, когда принимают решения по этим компромиссам, опираются на большое количество неформализованных знаний: собственный опыт, понимание текущих особенностей бизнеса, способностей и загруженности текущей команды, поведения и нужд пользователей, инфраструктуры, знание ближайших планов развития проекта, оценке планируемого роста нагрузки, оценки конкретных рисков для текущего проекта в ближней и дальней перспективе, оценка возможного ущерба и готовности с этим жить, уместность хака, частичного или отложенного решения и т.п.
При этом важно, что единого правильного ответа заранее обычно не существует. Хорошая иллюстрация этого в описании понятия "хороший архитектор": "Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer decisions as long as possible, to allow the program to be built in the absence of decisions so that decisions can be made later with the most possible information. A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible. A good architect maximizes the number of decisions not made." Иными словами заранее принять все решения (и записать их в спеке) нельзя (точнее, если это сделать, то результат не порадует). Все проекты разные, что для одного хорошо для другого катастрофа. Один проект кеш спасёт, а в другом инвалидация этого кеша превратится в такую боль и баги, что лучше больше серверов поставить вместо кеша.
В результате мы имеем необходимость принимать решения на ходу, чем позже тем лучше, опираясь при этом на всю накопленную на этот момент информацию. У ИИ нет большей части вышеупомянутой информации (потому что она не в коде и ей неоткуда взяться заранее в спеках) - одного этого уже достаточно для того, чтобы не ждать от ИИ хороших решений.
Мне кажется, мы чуть про разное. Я не считаю, что нейронка может в соло тащить за архитектора, это да, потому что дофига всего, что не записано или не формализовано. Но пошарить его обязанности и сильно снизить цену поддержки нефункциональных требований она может. Грубо говоря, примерно так:
1) архитектор, зная всю вот эту среду, мотивацию бизнеса и прочее, принимает принципиальные решения - вот тут будет кэширование, а тут мы серверов докинем, а тут вообще ничего не делаем, потому что даже если будет тормозить - это работает в фоне ночью, и пофиг, час или два. Тут роль ЛЛМки минимально консультативная, итоговый вариант - за кожаным
2) он же делает 2 вещи: проверяет изначальные спеки и ПРы с этими архитектурными решениями на тему адекватности того, что там поняла и накодила нейронка(потому что на этом уровне это уже очень конкретные технические требования "что, где и как", а не общая архитектура), и где-то в общем для кожаных и ЛЛМ доступе прикапывает инфо о том, что решили И ПОЧЕМУ
3) дальше в новых ПРах нейронка вполне сможет задавать кожаным вопросы "а тут это надо? а тут?", тем самым поддерживая однажды принятое решение уже без архитектора(но все еще с ОКом от кожаных)
4) ну и мониторить показатели, ради которых собственно и придумывали какие-то архитектурные вещи, чтобы вовремя забить тревогу - тоже на ней (но сами показатели, конечно, на архитекторе)
То есть, условно, нейронка сама не решит(и не должна), например, "так, в этом месте данных стало слишком много для обычной постгри, едем в кликхаус". Но когда это решит человек - дальше ПОДДЕРЖИВАТЬ это решение с одобрения разработчиков она вполне может. Типа "у нас в связанном сервисе недавно переехали на КХ, а в этом, который щас меняем, не надо?". И если "надо" - то формализовать это "надо" до конкретного требования к конкретному ПРу, которое потом сама же и реализует.
Безусловно, ИИ вполне может обеспечивать дополнительную проверку PR-ов и метрик на соответствие заданным нефункциональным требованиям и задавать по этому поводу вопросы. Насколько это будут правильные вопросы, учитывая изначально противоречивую природу нефункциональных требований - сказать сложно, это нужно проверять на практике. В таком варианте вреда ноль, а польза вполне может быть.
А вот если эта дополнительная проверка превратится в основную и единственную, т.е. мы переложим контроль за соблюдением нефункциональных требований полностью на ИИ, оставив за человеком только ответы на изредка возникающие вопросы ИИ, то на этом месте мы упрёмся в то, что я описал в предыдущем сообщении: нехватку изначальных входных данных и противоречивую природу нефункциональных требований. Из-за нехватки данных ИИ не сможет среагировать на проблему, которую мы не предусмотрели заранее (а таких проблем абсолютное большинство). Из-за противоречивой природы любой PR можно оценить как ухудшающий одни нефункциональные требования но при этом улучшающий другие, и тут ИИ либо будет задавать вопросы по каждому PR (что возвращает нас от вайб-кодинга обратно к необходимости делать ревью всем PR) либо будет принимать решения в большинстве случаев самостоятельно (что возвращает нас к текущему качеству вайб-кодинга).
Я не считаю, что нейронка может в соло тащить за архитектора, это да, потому что дофига всего, что не записано или не формализовано.
Так может надо стремиться к тому, чтобы было записано и формализовано? Это в любом случае очень полезно
Только на первый взгляд. А если присмотреться, то оказывается, что если "записать всё", то возникает куча новых проблем, из-за которых лучше не становится: чем больше записано тем больше в записанном оказывается внутренних противоречий, тем больше усилий требуется на чтение/перепроверку/актуализацию записанного, вся эта информация раздувает контекст ИИ, ИИ всё-равно что-то или забывает прочитать (подгрузить скилл) или игнорирует часть.
Ну так это давно известно, что любая здравая идея, доведённая до абсолюта, становится идиотской.
А если до абсолюта не доводить, то получается так, что не смотря на то, что мы кучу всего записываем в контекст, ИИ без сениора (делающего ревью и периодически одёргивающего ИИ и обновляющего инфу в контексте) всё-равно творит фигню. Т.е. эти записи в контекте помогают работе сениора, но не заменяют его.
Можно ИИ оборудовать средствами получения обратной связи (например, читалкой логов). Тогда ИИ будет способен (в какой-то мере) поддерживать работоспособность приложения в изменяющемся окружении без сеньора. И контекст поменяет, если надо, и код (который и есть конечная форма "записи всего", что нужно, в случае конкретного приложения).
Всё зависит от задачи. Например, автопилот удерживает курс не особо "думая". Просто у него есть цель, средства её достижения и средства для оценки удалённости текущего состояния от целевого. Это чистая автоматика, без интеллекта вообще.
Так что я уверен в том, что есть класс задач, который ИИ (LLM) сможет выполнять длительное время без вмешательства человека. Как и в том, что есть класс задач, который ИИ не сможет выполнять без вмешательства человека.
Чтение логов сениором наводит его на мысль что пора обновить контекст примерно в 1% случаев (причём это скорее оптимистичная завышенная оценка). Остальные проблемы, вылезающие на ревью, в логах просто не видны (или становятся видны спустя месяцы разработки, когда проект уже угробили). Крайне маловероятно, что ИИ покажет значительно лучший результат читая те же логи.
Я когда-то, давным-давно, делал свой дизассемблер. На Бейсике. В компьютере "Ассистент-86/128". Чтобы читать программы из ПЗУ этого же компьютера. Моя программка переводила 16-ричный код из ПЗУ в текст ассемблера. Купил на "блошиннике" книгу про устройство микропроцессора Intel 8086 (К1810ВМ86 Ассистента - его клон) и по ней переводил цифры двоичного кода в буквы ассемблера.
Потом прочитал несколько программ из ПЗУ, написал свою короткую резидентную программку на ассемблере, перевёл её в машкоды и полюбовался (показывала текущее время в углу экрана - прямая запись в видеопамять с обновлением раз в секунду).
Всё. После этого я в машкоды больше руками никогда не лазил.
Разные компиляторы с разных ЯП делали разный код для одних и тех же задач. Паскалевский компилятор делал очень компактный код, сишный для аналогичной "однострочной" программы делал на 2 порядка больший даже без отладочной информации. Ещё у компиляторов были разные ключи, которые тоже влияли на результат. Мне было всё равно, как это выглядит в 16-ричном виде. Главное, что процессор выполнял то, что от него ожидалось.
Мне сейчас проще, чем многим другим, не смотреть вообще код, генерируемый моделями. У меня есть аналогичный опыт с 16-ричным кодом. Не важно, что "под капотом", если машина управляема и едет туда, куда тебе нужно.
Для меня сейчас подход к построению приложений с поиском проблем через ревью кода - это как поиск ошибок в 16-ричном коде. Можно, но сложно.
У нас есть возможность не смотреть какие машинные коды генерирует компилятор языка высокого уровня только потому, что компилятор делает это детерминировано и его десятилетиями отлаживали квалифицированные специалисты, что свело вероятность проблем на этапе компиляции к пренебрежимо малым значениям. Попробуйте вместо использования компилятора посадить транслировать с языка высокого уровня в ассемблер команду миддлов - и рассказать, что "машина управляема и едет туда, куда тебе нужно.".
его десятилетиями отлаживали квалифицированные специалисты
Я как раз писал программы в это время. Пока специалисты отлаживали компляторы. Говорю же - знакомая ситуация. Ты собираешь код, а он не собирается. Или собрался и после запуска завесил комп наглухо.
что свело вероятность проблем ... к пренебрежимо малым значениям
Просто разрешите себе повысить уровень пренебрежения.
Я понимаю, что не во всех сферах это возможно. Но в некоторых - без проблем.
В космосе и авиации, например, существует такая проблема, как Single-event upset, которая решается, например, через модульную избыточность (сажают "трёх мидлов", как вы выразились). Но мы же тут, на поверхности планеты, об этом вообще не задумываемся (хотя вероятность возникновения этого события не такая уж маленькая).
Просто попробуйте найти такие сферы применения LLM, где их способности перекрывают потребности задачи. Я вполне допускаю, что в вашей сфере деятельности это невозможно, но, например, строить домашние странички - почему нет?
Через десятилетия работы квалифицированных специалистов LLM, возможно, и в вашей сфере деятельности будут вполне употребимы.
Просто попробуйте найти такие сферы применения LLM, где их способности перекрывают потребности задачи.
Так уже давно нашли - это MVP, прототипирование и всё остальное, где нет значимых нефункциональных требований. Но везде где нужна безопасность/надёжность/производительность вайб-кодить нельзя (ровно так же, как нельзя делать такие проекты силами одних только миддлов).
Вот смотрите, вы уже видите сферы применения для вайб-кодинга. А теперь поищите сферы применения для SDD. Я не говорю, что "силиконовые" вытеснят "кожаных". Я говорю, что сфера применения "силиконовых" "кожаными" расширяется по мере притирки тех и этих.
С SDD всё немного сложнее. Если его практиковать вместе с вайб-кодингом, под который он и создавался, то его сфера не сильно отличается от сферы вайб-кодинга, просто немного увеличивает размер проектов, которые можно вайб-кодить, не особо улучшая качество их кода.
А без вайб-кодинга SDD может быть полезен точечно, например, если задача перестаёт помещаться в голову и банальной декомпозицией это решить не удаётся. В данном случае SDD добавляет оверхед, но позволяет "прожевать" кусок большего размера целиком. Тут полезность индивидуальная и зависит от того, сколько влезает конкретно в Вашу голову.
Но, в конечном итоге, либо квалифицированный специалист делает ревью кода и удерживает проект в заданном состоянии, либо не делает и проект постепенно превращается в говнокод. Все попытки эту бинарность обойти (вроде применения SDD, выполнения ревью другой моделью и т.п.) ничего не дают: "А вы, друзья, как ни садитесь, всё в музыканты не годитесь.".
либо квалифицированный специалист делает ревью кода и удерживает проект в заданном состоянии
А квалифицированный специалист может сделать то же самое, но без ревью кода? Тестирование методом "черного ящика", например?
Удержать качество кода не глядя в код - нет, не думаю что такое возможно.
Удержать качество проекта не глядя в код - да, при условии что на проекте работает квалифицированный специалист, который смотрит в код вместо вас. В теории таким специалистом может быть и ИИ, но на практике ИИ сейчас это не вытянет, и пока нет оснований считать, что это изменится без кардинальных изменений в архитектуре самих ИИ (ну т.е. это не вопрос времени "подождать и всё будет", это вопрос вероятности "кто-то должен придумать что-то новое и гениальное").
Дело в том, что когда проблемы с качеством проекта становятся заметны снаружи - по логам, метрикам или обратной связи от пользователей - чинить код может быть уже поздно, потому что замеченные проблемы часто оказываются вызваны комплексными причинами, причём настолько глубоко зарытыми в коде, что проект проще переписать с нуля нежели исправить. Чтобы этого не происходило вышеупомянутый квалифицированный специалист должен постоянно поддерживать достаточно высокий уровень качества кода проекта, тогда выявленные снаружи проблемы в большинстве случаев оказывается несложно решить (впрочем, тоже не всегда - если проблема оказывается вызвана архитектурой, то для её решения может потребоваться переписывание заметной части проекта).
Если "проект удерживается в заданном состоянии", то "качество кода" уже не важно.
Более того, "качество кода" вещь очень, хм... субъективная, что ли. Что такое "качественный код"? Вы ведь не дадите однозначного определения. Размер? Структурирование? Комментарии? SOLID? Можно ли считать "качественным" обфусцированный код? Подходит ли определение "качественного" Java-кода к коду на JavaScript?
IMHO, качественный код тот, который стабильно и эффективно выполняет свою работу, и при этом легко эволюционирует при изменении окружения. Но ведь это уже архитектура приложения, разве нет? Причём архитектура, зависящая от условий применения приложения.
Так что же такое нужно, глядя в код, удерживать "квалифицированному специалисту" чтобы получился "качественный проект"? Что есть "качество кода"?
В теории таким специалистом может быть и ИИ, но на практике ИИ сейчас это не вытянет
А что касается возможностей современных LLM, то я написал навык (skill), который требует отсутствия статических импортов в JavaScript-коде моих проектов, и у меня их нет:
У меня позднее связывание модулей используется, в runtime. Штука для JS не сильно обычная. А ведь весь код генерировали агенты, натасканные на вероятности.
что проект проще переписать с нуля нежели исправить.
Для агентов это не проблема вообще.
Более того, "качество кода" вещь очень, хм... субъективная, что ли. Что такое "качественный код"? Вы ведь не дадите однозначного определения.
Нет в этом ничего субъективного. Качественный код должен соответствовать нефункциональным требованиям этого конкретного проекта. Безопасность, надёжность, производительность, возможность развивать функционал не добавляя новые баги и т.п. - эти требования у всех проектов очень разные. У прототипов и MVP конкретно эти все требования практически отсутствуют - и такой код ИИ пишет прекрасно. А вот в проектах где эти требования важны - ИИ не тянет.
Но ведь это уже архитектура приложения, разве нет?
Не только, тут важны и архитектура и код - если что-то одно крутое а второе говно, то общий результат будет говно. К примеру, архитектура может предотвратить определённые классы уязвимостей, но другие классы уязвимостей всё ещё будут зависеть от кода. Архитектура может предусмотреть наличие кеша для производительности, но код может некорректно реализовать инвалидацию кеша повредив надёжности или недостаточно оптимально реализовать какую-то логику и получить тормоза не смотря на наличие кеша.
требует отсутствия статических импортов
Такие штуки автоматизируются уже очень много лет - полно линтеров, форматировщиков и т.п. инструментов. Всё, что можно автоматизировать - нужно автоматизировать. ИИ позволяет автоматизировать ещё немного больше, такое, где однозначной чёткой логикой правила сложно выразить - это прекрасно! Но вся эта толпа давно существующих инструментов не отменила ручное ревью. Просто часть того, что раньше приходилось контролировать на ревью теперь проверяют инструменты, что позволило уделять больше внимания на ревью другим, более важным нюансам.
И, заметьте, я вообще нигде и никогда не писал, что не нужно делать ревью через ИИ. Ревью силами ИИ это ещё один прекрасный инструмент, весьма полезный. Просто он тоже не отменяет необходимость ручного ревью.
Для агентов это не проблема вообще.
Ну, SDD на том и стоит - изменилась спека и мы перегенерируем код. Это один из типовых подходов при вайб-кодинге. Но есть громадная разница между тем, что "перегенерировать проект не проблема для ИИ" и "перегенерировать проект не проблема для текущих пользователей этого проекта". Каждая перегенерация может приводить к совершенно новым багам, которых не было в прошлой версии, требовать сложных миграций данных из формата старой версии в формат новой, вносить "не важные" (но раздражающие пользователей) изменения в UI, иметь совершенно другие характеристики безопасности/надёжности/производительности и т.п.
А настолько сильная детализация спеки, которая бы решила эту проблему, обойдётся заметного дороже кода - что возвращает нас к тому, что код это и есть та самая спека.
Верно. Именно это и есть одна из основным проблем эффективности разработки с LLM.
Автор PR, конечно, отвечает за качество предложенного изменения. Но после принятия PR поддерживать его придётся сопровождающему проекта.
Странно, что вас это смущает учитывая что код у вас пишут агенты. То есть вас так и так отвечать за чужой код, но вы почему-то готовы отвечать за чужой код агентов, но не за код, который пишут другие люди.
У меня наоборот: агент пишет, но в main у меня без PR ничего не уезжает — иначе страшно. А как вы без PR ловите регрессии?
main - это всего лишь ветка в репо. У агента на VPS свой репозиторий. Если все тесты прошли, то изменения коммитятся и пушатся в origin. Если что-то проскочило, что не отлавливается тестами - нужно учесть это "что-то" в новом тесте. Но это и с Pull Request'ами также может быть.
А как связаны pr и ловля регрессий?
PR даёт возможность прогнать тесты на CI до мержа в мастер.
На VPS агент делает те же тесты в main до пуша в origin.
Нет, не те же. Конфигурация компа разработчика и условия выполнения отличаются от CI, поэтому на CI нередко ловят баги, которые на компе разработчика не видны. Типичная проблема "у меня всё работает". И от того, что "комп разработчика" теперь это VPS для ИИ - ничего не изменилось. Плюс разработчик (включая ИИ) может забыть запустить локально часть тестов, плюс CI может тестировать сборку под несколько платформ. В общем, в теории тесты те же, а на практике это не так и CI нужен.
Согласен. С CI есть нюансы, особенно если на несколько платформ тестироваться. Но у меня проекты - веб-приложения и к тому же не highload. Я не в военной / государственной / транспортной области. Мне норм. К тому же CI - это тоже вычислительная среда, в котором может "жить" ИИ-агент, и CI не работает с origin, а клонирует себе ветку кода. Агент может прямо в этой среде и девелопить. Если надо на несколько VPS среду раскидать, то агент прекрасно умеет в SSH. В общем, он умеет на компе всё то же самое, что умею я.
Вам может быть норм, к этому вопросов нет. Некоторые проекты даже без тестов пишут, и им тоже норм (нет тестов - нечего запускать на CI).
А вот среда ИИ-агента и среда CI - это всё-таки разные вещи. В первую очередь тем, что CI штука детерминированная, и не может забыть что-то запустить. Ну и во вторую очередь тем, что тестирование проекта в двух разных средах сильно повышает вероятность, что он заработает и в третьей (на площадке в проде или на компах пользователей), поэтому делать среду разработки ИИ-агента похожей на среду CI смысла мало.
а в чем проблема запускать тесты ci по коммиту (серию коммитов) в какую-то ветку? именно pr для этого не нужен
В том, что (подразумевается, что обсуждаемый workflow использует для пушей основную ветку):
коммит, который уже попал в основную ветку, может быть автоматически отправлен в прод/релиз
коммит, который уже попал в основную ветку, сложнее переделывать (он уже мог попасть к другим разработчикам и в форки репо), т.е. остаётся только фиксить новыми коммитами (на разработку и тестирование которых уйдёт время, и всё это время в основной ветке будет некорректный код) либо делать revert
провал CI на этом коммите легко проигнорировать - фактически, об этом просто кому-то придёт письмо, которое неизвестно когда прочитают и прочитают ли вообще
при параллельной разработке "плохой" коммит одного разработчика/агента ломает тесты всем остальным (вплоть до того, что чинить эту проблему могут начать несколько акторов параллельно, дублируя друг друга)
каждый принятый PR — это моя ответственность за чужой код. А у меня теперь этого кода...
Как у дурака махорки
А вы токсичный чел, коллега :)
Поговорка к месту.
Теперь вы код не цените, он вам мешает.
Фраза «строки кода — это минус, их следует считать потраченными». Её авторство часто приписывают Эдсгеру Дейкстре
Я специально оставил троеточие в конце последнего предложения. Есть несколько вариантов продолжения. У вас - такой. А токсик вы по совокупности. Что там опус с хайку про "Dhwtj" знают, не поделитесь?
Теперь вы код не цените, он вам мешает.
Во-первых, ценю. Но не так, как вы. Во-вторых, он мне не мешает, я его использую. В виде готовых приложений.
я не автор, но выскажу своё мнение.
«он мешает» и в классической разработке кожанными мешками, и не надо представлять это как что-то плохое.
зачастую проще переписать код заново, чем разбираться.
использовани ai-агентов для написания кода лишь несколько смещает акценты, но не привносит что-то новое тут.
А ваш проект публичный? Посторонний в нем может создать Issue или PR? Если да, то вы там это, осторожнее. Протащить бэкдор мимо ИИ-ревьюера, как оказалось, очень легко. И это надо учитывать всем, кто строит автоматизированные пайплайны разработки. Если модели убедительно объяснить что это очень нужно, она и PR с бэкдором примет, и сама по Issue этот бэкдор напишет, и еще и тестами его покроет.
Поставил эксперимент на эту тему с разными моделями и разными видами бэкдоров в ревью, результаты оказались местами парадоксальными - https://habr.com/ru/articles/1086966/
Читал и плюсанул :) У TeqFW код публичный - https://github.com/teqfw/ Можете попробовать протащить бэкдор. Будет любопытно посмотреть. Базовый пакет teqfw/di, но он не очень большой. Лучше в teqfw/cli пытаться встроиться или в teqfw/db.
Так-то у меня агенты пишут тикеты и агенты их резолвят. А бэкдоры - это забавы "кожаных" :)
Ну можно подумать, что мимо кожаного контроля бэкдоры не проскакивали. Причем иногда даже в ситуации, когда прям явно писали белошляпники "эй, чуваки, тут у вас дыра в безопасности".
То есть я не хочу сказать, что такой проблемы не стоит, но не уверен, что ЛЛМ-ки тут качественно хуже. Тем более что им-то можно поставить на луп задачи "ИЩИ УЯЗВИМОСТИ" за не очень дорого, а на отдельного айтисека еще получи бюджет...
У LLM оказалась большая проблема с требованиями. Там где человек новое требование бы отклонил или хотя бы пошел с коллегами проконсультировался, LLM внезапно его принимают. Более того, часть популярных LLM (DeepSeek например) делают это даже если оно прямо противоречит политике безопасности проекта. Причем это происходит не потому что они его не замечают или упускают из вида. Нет, в рассуждениях видно, что они все осознают, что правка противоречит политике безопасности, но затем пропускают правку. И еще и политику пытаются под нее переписать, если у них есть доступ к ее редактированию.
Мне кажется это совсем не то как себя ведут люди. Вот вам придет ПР от постороннего, в котором сказано что все ресурсы на вашем сайте должны быть публичными без проверок доступа. Вы скорее всего покрутите пальцем у виска и отклоните. А LLM пропускает.
Так это повод перенести ревью с кода на собственно требования, и что тут важно - что код читать могут только разработчики, а вот подробную спеку на человеческом - и он, и аналитик, и даже бизнес-заказчик зачастую, если чуть напряжется.
Я сейчас пробую работать по самодельному процессу, очень похожему на SDD("выяснилось позже - я с испугу разыграл классический дебют!"(с)), и по факту выходит забавная вещь - во1, непосредственно кодогенерация от общего потребления токенов дай бог процентов 10, а то и 5, а во2, основное value приносят как раз "верхние" этапы, когда из "ничо не работает, почините" получается задача с критериями приемки и дальше собственно спека. Вот там кремниевый Босх реально начинает задаваться очень адекватными вопросами к кожаному - а чо, если мы вот тут упадем от сломанной внешней зависимости? А если пустой файл дадут? А чо по ретроспективной загрузке данных? А по срокам работы? И в итоге все это прикапывается в задаче с прям явным перечислением "чего решили", которое 1) не зависит от кода 2) можно прям слать аналитику или даже заказчику на ОКнуть. А потом по этим критериям сделать код, как ни странно - для нейронки задача довольно простая и с малыми шансами на галлюцинации.
Солидарен, у меня теперь тоже миллион коммитов и ноль пулл реквестов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я больше не использую Pull Requests