Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 232
Вайбкодю третий день мессенджер для Docker контейнера в роутере Mikrotik. Я не понял из вашей статьи можно продолжать или нет?
Если готовы к тому, что добавлением новых фич будут ломаться старые, а в один прекрасный день вас хакнут и скажут, что так и було, то продолжайте. Мы никогда не откажемся от нового повода поржать.
«В геометрии программировании нет царских путей» ©
Ну да, ведь когда люди пишут оно всегда получается стабильным, нвдежным и безопасным, а вот если те же люди ллм для генерации используют, то все, сразу ломается и дырявый.
Это видимо те же советские великообразованные умы, которые банки перед телевизором заряжали?
Когда пишут люди, а оно ломается, люди знают, куда смотреть нужно, чтобы починить. И починить не абы как, а, возможно, пересмотрев подход к фиче в принципе. А когда тебе ллм нагенерила кучу мусора, то не починишь ты ничего. Даже понимать не будешь, где поломалось. Но вы продолжайте. Я с интересом наблюдаю, когда это всё взорвётся тем или иным образом! :)
Это вы сейчас про пет-проект говорите, в котором все понимаете?
Я в свое время насмотрелся на "ну, мы эту фичу 10 лет назад сделали, вроде в новых версиях работает, но разрабочтик давно уволился, добавлять то, что клиент хочет, мы не будем..."
Никто ничего не помнит. Все всегда по стектрейсам и прочим логам находят ошибки. Если у вас нет дебага, где можно нащупать баг - это ваша проблема. Если у вас такая лапша, что вы переписываете небольшую часть кода, и у вас все падает - это тоже ваша проблема. ИИ прекрасно умеет писать так, чтобы на любой косяк у вас был лог чтобы увидеть, где логика\результат отличается от того, что должно быть. А если вы вайбкодите с нуля, то попросите писать план так, чтобы вы вообще к коду не прикасались - оно и язык тогда подберет более подходящий для себя.
Просто напиши ей в промпт "почини этот мусор и сделай чтобы работало". Железная логика вайбкодеров сбоев не дает! :)
Это видимо те же советские великообразованные умы, которые банки перед телевизором заряжали?
А, это те же россиянские великообразованные умы, которые деньги на безопасный счёт переводят?
Ежели Вы ещё не в курсе, советские умы разные бывали. Заряжали банки те, кто за 40 лет привык, что ну ведь не могут же по телевизору врать!!! и не осознал, что теперь — могут.
(А в МММ деньги несли те, кто за 8 лет до этого не читал в «Советской России» статью про финансовые пирамиды в загнивающем капиталистическом мире. Я вот читал — и всех знакомых отговаривал.)
А те кто прочитал и понял правильно - вовремя соскочили, и купили жене сапоги (ц)
P. S. Я мечтаю найти номер с той самой статьёй и всем её показывать, но проблема в том, что оцифрованного архива «Советской России»
[лирическое отступление с уточнением]
Я точно знаю, что это было именно в «Советской России», так как моя семья только одну эту газету и выписывала — а я пацаном подшивки в шкафу временами перелистывал, где и прочитал. Как пошла реклама «МММ» — я ещё нашёл в шкафу тот конкретный номер и дал родителям перечитать.)
в сети нет (в отличие от архивов «Правды» и «Известий»).
Ну да, ну да, сейчас то люди поумнее, зачем думать своей головой, пусть л̶о̶ш̶а̶д̶ь̶ ллм думает у нее г̶о̶л̶о̶в̶а̶ контекст больше.
Так давайте вам операцию на позвоночник попросим запитого бомжа с улицы с провести, ведь профессиональные хирурги тоже ошибаются
Хахах, у меня аж изображение стало мутным на мониторе из-за обилия жЫра
Мысль простая: работа с ии-агентами значительно ускоряет и улучшает работу профессионала, который знает, что он делает. В ином же случае результат непредсказуемо плох: может и нормально будет, но только до определённой степени.
Шутки шутками, а это правда. Мы с другом решили не напрягаться на курсовой работе и попросить схему у старших курсов (там приёмник на микросхеме с обвязкой). Ну взяли, стали разбираться что там как и решили упростить задачу - попросили нейронку описать принцип работы некоторых узлов схемы и их назначение. Это была просто попа. Мы видим что оно генерит, говорим что это неправильно, полный бред и должно работать так и служит для N, а нейрогопота такая "Да, вы абсолютно правы, я допустил ошибку...". И так весь вечер, в итоге забили болт и сами за несколько часов разобрались в устройстве.
Шутки шутками, а это правда.
А я и не говорил, что это шутка.
Это ещё Шекли написал...
Вселенная? Жизнь? Смерть? Багрянец? Восемнадцать? Ответчик знал ответы на эти вопросы. Но ему требовался верно сформулированный вопрос. А чтобы верно сформулировать вопрос — нужно знать большую часть ответа.» ©
Выглядит как диссонанс между ее возможностями и вашими хотелками. Например выбрана неподходящая модель, мало инфы на входе, плохо составленный промпт, не сделана декомпозиция проблемы, отключен поиск из внешних источников и еще туча подобных моментов. В сумме они и дают похожий результат.
Нет волшебной кнопки "сделай мне хорошо".
выбрана неподходящая модель
«Ты просто не ставишь пять линий после вишни — вот и не выигрываешь!» ©
xxx: Пробовали вчера эти ваши электроинструменты, сверлили бетон, не вышло ни фига...
yyy: Вы же перфоратором сверлили, а не шуруповёртом?
Wesha: «Ты просто не ставишь пять линий после вишни — вот и не выигрываешь! ©
Кстати, я как-то бетон шуруповёртом сверлил. Просто ничего другого под рукой не было, а отверстие нужно было сегодня. Два раза заряжать пришлось, но просверлил, да.
P.S. Скажите как на духу — Вы часто в своей жизни менеджеру говорили «вы мне неправильный инструмент дали, я не буду этим пользоваться»? И куда он Вас посылал?
>Нет волшебной кнопки "сделай мне хорошо".
есть и уже очень много лет))
https://button.dekel.ru/
И когда вы будете нанимать разработчиков на доработку вашего продукта поверьте, ценник вас неприятно удивит.
Вы не учитываете важный ньюанс - эти самые разработчики в современности будут переделывать проект не "по старинке", а с использованием ИИ-агентов, что заметно сокращает время и ценник.
А вот вайбкодинг очень-преочень хочет казаться мега архитектором и синьором, которому и социальную сеть написать под силу, поэтому спустя n недель вайбкодинга, ваш проект станет утыкан такими конструкциями, от которых у разработчиков глаза не то, что на лоб полезут, я боюсь они просто вылезут.
У меня есть опыт работы с плохой архитектурой, переделкой, и как раз это - одна из задач, с которой ИИ справляется лучше всего (меньше всего ошибается). Это не "додумай систему по огрызку кода и пофикси баг, который физически не можешь воспроизвести", это не "напиши тысячу идеально верных строк кода на одну строку промпта". Тут вся нужная информация есть в контексте.
Да, старые инстинкты заставляют вздрагивать, когда видишь, например, SQL-запрос такого размера, что он не умещается на экране, или функцию-бога на тысячу строк. Да что там, даже
Вот такой вот regex
(?:[a-z0-9!#$%&'*+\x2f=?^_\x7b-\x7d~\x2d]+(?:\.[a-z0-9!#$%&'*+\x2f=?^_\x7b-\x7d~\x2d]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9\x2d]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9\x2d]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9\x2d]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
уже заставляет волосы шевелиться везде, при том что это всего лишь безобидная валидация email-адреса по RFC 5322.
"Ух, ё... Это ж сколько времени и головной боли займёт всё это переделывать по-нормальному?"
А потом ты просто пишешь промпт с точным описанием того, как это должно быть (потому что знаешь, как оно должно быть), и уходишь на обед, а возвращаешься уже к свежему коду, где всё уже в целом переделано и читаемо. Потестировал, доработал напильником и готово.
Такие задачи можно сравнить с переделкой всего кода большого проекта под полное соответствие какому-то строгому стандарту. На первый взгляд, без опыта, кажется - титанический труд, "да я выгорю быстрее, чем это всё доделаю". На деле - со знанием линтеров, инструментов и опытом - недолгая и ненапряжная задача.
Вот и с ИИ сейчас многие проблемы, которые раньше считались фатальными, переосмысляются и становятся менее пугающими.
это всего лишь безобидная валидация email‑адреса по RFC 5322.
И Вас вылечат научать читать RFC...
и с ИИ сейчас многие проблемы, которые раньше считались фатальными, переосмысляются и становятся менее пугающими.
...но есть нюанс...
Вы не учитываете важный ньюанс - эти самые разработчики в современности будут переделывать проект не "по старинке", а с использованием ИИ-агентов, что заметно сокращает время и ценник.
Боюсь, это вы не учитываете нюанс. Если б ценник зависел только от того, насколько тяжко исполнителю, то мы бы жили в принципиально другом мире. По факту насколько велика будет нужда - такой и будет ценник.
Давайте все же разделять, когда с ИИ работает профессионал и просто кто-то с улицы. Когда вы сами умете программировать, имеет опыт работы с разными архитектурами и т.д., вам нейронка отличный помощник, что при рефакторинге, что в отладке, что для написания с нуля. Когда вы вот вообще не из ИТ и просто отдаете полностью всю работу нейронки, то и результат будет соответствующий.
У меня в последнее время жопа горит ресентимент к "настоящим разработчикам" уже через край, признаюсь. Наверное, пора ловить свои минусы. Поехали:
Не вайбкод, а "настоящие разработчики" пишут приложения типа Яндекс.GO так, что оно на смартфоне 4 ядра 4 гига открывается (с таймером) 26 секунд. Да, все те ребята, что рассказывают от такие очешуительные истории, как они десятками часов фиксят баги и как они хорошо знают архитектуру - это у них приложение еле пердит на том, что вывозит целую ОС. Смеетесь над лагами винды, пишете одно обосранное приложение, которое лагает сильнее.
Не вайбкод, а "настоящие разработчики" или кто там - менеджеры, я хз, закладывают архитектуру, которая по определению нежизнеспособна. А чо, все 99.98% SLA пишут, и мы напишем. А? Че? Площадка нам 99.98% не обещала? Да кого ебтрогает? Почему один дебил (я) в чате с клодом в первые 5 минут получаю отлуп "не получится", а весь штат хостера галлюцинирует, что "получится"?
Не вайбкод, а "настоящие разработчики" тащат любое говно вроде калькулятора на электрон, и дуют его до 100+ мегабайт. А что, жуяк-жуяк и в продакшн (знакомо, а?), железом пользователя компенсируем, пущай апгрейдится, щас бы МЫ оптимизациями занялись, у нас БИЗНЕС, у нас ВРЕМЯ НЕ БЕСПЛАТНОЕ, у нас Design-Payoff Line давно позади, ПОСЛЕ НАС ХОТЬ ПОТОП.
Не вайбкод, а "настоящие разработчики" раздули приложение Сбера на Android до 1 гигабайта. Я перепроверил сейчас - bigbeta - 0.9ГБ само приложение. Ни одна нейронка такое не высрет, только кожаный мешок, которому "виднее", ведь он НА ОПЫТЕ, он АРХИТЕКТУРУ знает.
Не вайбкод, а "настоящие разработчики" наваливают какие-то мутные баги на проде, из-за которых старые аккаунты не могут пройти верификацию, и приправляют все щедро не информативными ошибками "попробуйте позже" (никогда). А самая мякотка - никто их никогда даже не подумает исправлять. "Настоящие разработчики" заняты разработкой очередной новой фичи, их НЕ КОЛЫШЕТ что у них там пользователи что-то не могут.
Стоят визги про баги вайбкода. Когда условный Claude одним проходом по коду "настоящего разработчика" вываливает список багов доком на 100+ пунктов и 1 мегабайт, поднимается вонь: "да не баг это, мы так и хотели, вообще у нас ВРЕМЕНИ НЕТ все это исправлять, мы просто глаза закроем и уши заткнем". Нет, ну ладно, у этих хотя бы хватает смелости сказать все как есть - НЕ ВОЛНУЮТ нас ваши баги, делайте с ними что хотите, мы вам ЗАПРЕЩАЕМ о них нам сообщать. Коммерсы еще и засудят.
Друзья. Я вот вас устал. Очень сильно устал. Я в основном поэтому и начал вайбкодить. Потому что добиться чего-то от кожаного либо невозможно (успехов достучаться до разработчиков Facebook, чтобы они свою сраную верификацию пофиксили, сколько там лет багу, 5 уже точно?), либо ПРОЩЕ навайбкодить самому. В Twitter добавили communities, забыли добавить туда отложенный постинг по таймеру. Думаете кто-то озаботился за год? Нет, забили, приходиться вайбкодить велосипед на АПИ, где такое возможно.
На каждый убогий навайбкоженный проект, который взломали, или который сделал под собой лужу из-за багов, я найду два написанных "настоящими разработчиками" (отмазки "не баг, а фича" не принимаются). И многие из кошмаров, вываленных "настоящими разработчиками", вайбкод просто не даст написать, потому что сразу ответит, что это какая-то херня (пример с SLA выше). Нет, ну даст конечно, но вонять и сопротивляться будет, видимо, больше ваших коллег.
Конечно, тут каждый "не такой", "да у меня ни одного бага нет", "да меня менеджер заставил, сроки горят", "да я только mission critical пишу", "мы пишем код так, что его легко поддерживать!" (поддерживать не будем, нахер идите, но поддерживать легко!), но по факту имеем что имеем. Не знаю куда вы там свой код пишете, в NASA может, но потребителю вроде меня уже не продохнуть от засилья "настоящих разработчиков", которые говнокодят вокруг и ничего по факту не поддерживают.
Возможно, "настоящим разработчикам" есть чему поучиться у вайбкодеров? Например, писать свой велосипед под задачу, а не обкладывать его потом 10 лет "фичами", чтобы получился Яндекс.GO. Меня искренне раздражает само существование аргумента "наш код легко поддерживать 10 лет" - ЧТО ВЫ ТУДА БЛ**Ь ПОСТОЯННО ДОПИСЫВАЕТЕ 10 ЛЕТ? ВЫ МОЖЕТЕ НАКОНЕЦ УСПОКОИТЬСЯ УЖЕ? МОЖНО В ЭТОМ ГОДУ БЕЗ НОВЫХ ФИЧ И СУПЕРАППОВ? Можно проект ЗАКОНЧИТЬ и просто сделать для другой задачи ДРУГОЙ? Я УСТАЛ!
Яндекс GO нельзя перестать дописывать - у команды лапки (KPI), а за поддержку приложения без правок кода много не дадут.
Предлагаю начать дописывать в приложение производительность. Время холодного старта даже проще померить, чем то, на что они там сейчас ориентируются.
Сдаётся мне, те жопоручки, которые пишут вот эту дрисню уровня Яндех Жо и прочих вичатов, и те, у кого бомбит — таки разные люди.
А вообще в последнее время начинает импонировать вычитанная где-то схема версионирования софта в реверс. Начинаем, например, приложение с версии 99. Обновили — декрементируем, стала версия 98. Как только версия достигла 0 — трогать код вообще никак больше нельзя, программа достигла своего идеала.
Неплохо, но как фиксить уязвимости, которые так или иначе всплывут в коде или зависимостях со временем? Ведь даже дырявый пакет не обновить, если версия 0.
Сдаётся мне, те жопоручки, которые пишут вот эту дрисню уровня Яндех Жо и прочих вичатов, и те, у кого бомбит — таки разные люди.
Именно. Меня от жопоручек бомит ешё больше, чем у предыдущего оратора. И я того и боюсь, что раньше у жопоручек было просто недержание кода — а теперь им ещё и брандспойт с той же субстанцией всучить пытаются.
Кажется имеется инфляция термина "настоящего разработчика" и путаница его с бизнесом, который генерирует миллион фич.
Не вайбкод, а "настоящие разработчики" тащат любое говно вроде калькулятора на электрон, и дуют его до 100+ мегабайт.
До появления вайбкода, разработчики на электроне не считались "настоящими разработчиками". Раздували калькулятор до 100МБ в первую очередь те, кто сейчас первым побежал в вайбкодинг. Но так исторически можно опуститься до настоящих разработчиков на перфокартах, машинных кодах и пайки микросхем.
Возможно, "настоящим разработчикам" есть чему поучиться у вайбкодеров? Например, писать свой велосипед под задачу, а не обкладывать его потом 10 лет "фичами"
10 лет фичами обкладывают задачу менеджеры, у "настоящих разработчиков" код 10 лет может переписываться/оптимизироваться/рефакториться без единого добавления функционала.
"Настоящие разработчики" могут получаться удовольствие не только (и не столько) от закрытия задачи, а от самого процесса написания кода.
Кажется имеется инфляция термина "настоящего разработчика" и путаница его с бизнесом, который генерирует миллион фич.
Послушайте, это отмазка. Бизнес - это не Мать Природа, это N людей. Среди них есть исполнители, есть исполнители поумнее (синьоры), и есть заказчики. Почему настоящий разработчик с 10 годами опыта не может сказать - НЕТ, ТАК НЕ ДЕЛАЕТСЯ, а покорно пишет говно?
До появления вайбкода, разработчики на электроне не считались "настоящими разработчиками".
Кем не считались?
Раздували калькулятор до 100МБ в первую очередь те, кто сейчас первым побежал в вайбкодинг.
И, что характерно, калькулятор после вайбкодинга будет весить меньше 100 мегабайт :)
"Настоящие разработчики" могут получаться удовольствие не только (и не столько) от закрытия задачи, а от самого процесса написания кода.
Я ненастоящий разработчик, но я получаю удовольствие от рефакторинга и оптимизаций.
За что платят, то и пишут. А там где бесплатно, получается, например linux или какой нибудь sqlite. Но платят за калькулятор размером в 100МБ.
И если кто забыл, то LLM написали как раз "настоящие разработчики", возможно как раз для того, что бы не мучаться с бесконечными хотелками бизнеса, багами, капризами пользователей и наконец начать писать код для себя.
Кем не считались?
Писатели на электроне не считались "настоящими разработчиками", теми, кто считал себя "настоящими разработчиками".
И, что характерно, калькулятор после вайбкодинга будет весить меньше 100 мегабайт :)
99 МБ?
Я ненастоящий разработчик, но я получаю удовольствие от рефакторинга и оптимизаций.
Невозможно заниматься рефакторингом и оптимизацией без знаний и опыта. А генерация кода с помощью LLM в этом случае ничем не отличается от ручного набора текста.
Бизнес - это не Мать Природа, это N людей. Среди них есть исполнители, есть исполнители поумнее (синьоры), и есть заказчики
Если вы не в курсе, то бизнес и разработка - это разные люди. В случае Яндуха скорее всего даже не знакомые.
Почему настоящий разработчик с 10 годами опыта не может сказать - НЕТ, ТАК НЕ ДЕЛАЕТСЯ, а покорно пишет говно?
Ну во-первых, может. Вы же не знаете, сколько кала не попало в релиз.
Во-вторых, ну скажет, ну уйдет, ну другого наймут. Все уйдут - наймут вайбкодера за еду. Принцип действия ради действия останется.
Вы, видно, плохо понимаете кухню бигтеха, но виноватого нашли очень быстро.
Тут явное не понимание: все проблемы которые вы описываете не имеют никакого отношения к программированию. Это исключительно - то как задачи формулируются менеджерами.
Если вы думаете, что с вайбкодингом будет лучше - ошибаетесь. Фич станет еще больше, работать они станут еще хуже, а места занимать еще больше.
Фич станет еще больше, работать они станут еще хуже, а места занимать еще больше.
В этом никто не сомневается, просто нету способов достучаться до менеджеров (и бизнеса, который над ним). Система так построена, что нужно изображать бурную деятельность, иначе премию не дадут, или вообще уволят. Если нечего в код дописать - давайте хоть иконку приложения поменяем, лишь бы отчитаться о выпущенном обновлении.
А ИИ кодинг усугубит эту проблему, ускорив процессы.
Справедливости ради, это не проблема менеджеров конкретной организации, это в принципе проблема роста.
Был прекрасный просмотрщик картинок ACDSee из него сделали неудобоваримый комбайн которым пользоваться стало невозможно. Был лекгик и удобный NeroBurnigRom - превратился в кошмарного монстра. Был winamp из него сделали медиа-монстра, благо позже хватило ума откатить до состояния медиаплеера. С Яндекс.Такси случилось то же самое. Из него появился уродливый монстр Яндекс.Го. Пользоватья которым омерзительно не удобно.
И таких примеров - масса.
Хабр о программистах Роскомнадзора: предатели, позор, могли бы найти другую работу.
Тот же Хабр о программистах, которые пишут дерьмо: это не мы, это менеджеры.
Ну это вы выдумываете. Проблемы роскомнадзора не в программистах и даже не в менеджерах. А в отсутствии понимания что такое интернет и как он работает у депутатов. Мало их и далеки они от народа.
Вас минусуют, но я согласен. Буквально так у меня в оригинальном комментарии и написано: "да меня менеджер заставил, сроки горят".
@roudakov Никто не заставляет писать неоптимизированное говно. Нет такого ТЗ, "сделайте чтобы еле ворочалось". Есть просто сроки и тотальный похеризм исполнителей. Кто-то в срачах вокруг размера АПКшки Сбера написал - "да там библиотеки дублируются". Не вникал. Верю. Каждый написал свои три строчки и плюнул что там дальше. ТЗ такого не было, я гарантирую это!
Если вы думаете, что с вайбкодингом будет лучше - ошибаетесь.
Когда Claude на xhigh effort пишешь "добавь фичу", оно сначала идет и смотрит что вообще есть в коде. И пишет: вот это реюзаем, это заменяем, итд итп. Поэтому у меня кастомная апшкшка это влесс+прокси+запрет в три режима с failover, а v2rayng сам по себе с одним только влесс-ом весит больше.
Сразу видно человека который никогда не работал на крупных проектах.
Когда ты пишешь для себя, небольшую программку, у которой в пользователях полторы калеки и которые запускаю ее раз в пол года - ты можешь заняться оптимизацией, можешь менять архитектуру по три раза на день и, вообще, ударится в эскапизм и написать весь код на brainfuck.
А когда ты работаешь на крупном проекте: есть сроки, легаси, которое надо учитывать и которое далеко не всегда оптимально работает на новых задачах, требования от заказчика которые могул ломать всю выстроенную архитектуру, ограничения в платформы и еще много всяких ограничений которые приходится учитывать.
Это не отменяет, того, что есть ленивые и неквалифицированные программисты. Но такие редко задерживаются в команде на долго.
Что до ИИ который "идет и смотрит, что есть в коде". Ну так это вообще смешно. Код с которым работаю я не влезет в контекст ни в одного современного ИИ. И я бы с большим любопытством посмотрел, как он его будет смотреть...
Сроки не дают подумать что хватит простейшего csv, давайте на всякий случай используем pandas просто файлик записать?
Запрещают посмотреть, какие библиотеки используются, и в одном модуле использовать urllib, в другом requests, в третьем еще что-то не потому что именно здесь это более эффективно, а потому что "некогда думать, копать надо"?
Я охотно верю, что действительно некогда, сроки и все такое. Только вот LLM в отличие от человека как раз таки посмотрит, что, где, всякие сonventions, графы. Если конечно, вы среду настроили, а не просите написать функцию через web-чат, как 3 года назад.
Код с которым работаю я не влезет в контекст ни в одного современного ИИ
Офигеть. А в ваш мозговой контекст весь влазит? Или все-таки на высоком уровне понимаете, куда, в какой файл смотреть, и там уже проверяете детали?
P.S. Очень поддерживаю вашу горечь про ACDSee, NeroBurningROM и т.п.
Я вот совершенно не в курсе о чем речь, но даже из написанного можно сделать выводы.
Записать csv файлик - просто. А если в этот файлик понадобиться писать больше информации? А если понадобится другой формат? Интеграция с другими системами? Ну то есть, как костыль, csv сойдет. Как долгосрочная стратегия - pandas - лучше.
По библиотекам: urllib — встроенная, нулевые зависимости, идеально для микромодулей. requests — высокоуровневый и читаемый, отлично подходит для основных API-клиентов. Не забываем, что в разных модулях могут быть разные требования. Где-то лучше одна, где-то другая. А где-то начинали разрабатывать с одними требованиями и взяли одну библиотеку, а потом появились другие требования и пришлось добавить еще одну библиотеку со схожим функционалом, просто потому что она подходит лучше. А, еще, модули могут разрабатываться параллельно двумя разными командами и каждая сделала независимый выбор по своим критериям.
Унификация хорошо, если ее внедрение тебе ничего не стоит. На реальных проектах, стоимость унификации может оказаться дороже стоимости всего проекта.
Утверждение, что “ИИ посмотрит, а человек нет” — красиво, но ложно. LLM не понимает проект, она видит токены. А человек: Знает историю проекта — почему принято то или иное решение (а решение почти всегда было осознанным, просто вы о нём не знаете). Понимает бизнес-контекст — какой модуль критичен, а какой — вспомогательный.
Человек не хранит весь код в голове — он хранит карту: где что искать, куда смотреть, на какие файлы обратить внимание. И это гораздо эффективнее, чем пытаться скормить всё ИИ.
Дедлайны — это причина для компромиссов. Прагматичных компромиссов. И если какой-то выбор кажется странным — вы просто не знаете всей истории вопроса.
Вот видите, ваши аргументы опять уровня "человек знает историю проекта". Это про пет-проект? Или про суперархитектора всея проекта?
Пришел чел, ему дали задание написать фичу в большой проект. Какую историю проекта он знает, о чем вы? На онбоардинге он анализирует код всего проекта?
Я же не просто так написал не потому что именно здесь это более эффективно, а потому что "некогда думать, копать надо"
Сами же пишете про компромиссы, трейдофы и прочие дедлайны. Ну не будет этот чел копаться в чужих модулях, не входящих в скоуп задачи, что ему поручили. Возьмет библиотеку, которую привык использовать, да и все.
Кстати, если попросить LLM проверить/поправить спецификацию прежде, чем выдать этому товаришу, она-то как раз напишет не просто "дернуть такую-то апишечку", а с указанием принятого стека, какую либу заюзать, какие модули посмотреть, ибо есть какая-то взаимосвязь. Не хочешь - не смотри, конечно :)
LLM не понимает проект, она видит токены
Истинно, действительно токены, но напомнило мне анекдот про воздушный шар, заканчивающийся фразой "ответил абсолютно верно, но совершенно бесполезно".
Что значит "понимать проект"? Вряд ли вы про цели проекта для бизнеса, правда?
Модули, их взаимосвязи, конвенции и прочие - как раз LLM понимает. Другое дело, что проанализировать проект, создать для себя заметки и т.п. - это отдельный шаг. Не надо заставлять ее анализировать проект целиком на какждый промт. И не надо представлять современные системы в виде "скопипастили в браузер кучу кода, вот только с ним LLM и работает".
Ваш аргумент «он не будет копаться в чужих модулях» — это не оправдание халтуры, это описание плохого инженера или плохой организации работы. В нормальных компаниях дают не только задачу, но и доступ к документации, описание какие библиотеки используются и после еще и проведут код-ревью, где укажут на несоответствие. Никто не даст взять «библиотеку, которую привык использовать», игнорируя существующие в проекте аналоги без достаточно веского обоснования. Дедлайны — это причина для компромиссов в деталях, но не в фундаменте.
Ваш пассаж про LLM — это классическая подмена понятий.
«Модули, их взаимосвязи, конвенции… — как раз LLM понимает». Нет. LLM не понимает. Она генерирует правдоподобную последовательность токенов, которая статистически часто совпадает с описанием взаимосвязей в обучающей выборке.
LLM видит, что модуль А импортирует модуль Б, но не знает, что Б — deprecated с прошлого года, а новый модуль В ещё не задокументирован. Она предложит использовать А+Б, потому что это чаще встречается в обучающих данных, а человек поймёт, что надо мигрировать на В.
Когда вы говорите «LLM проанализирует проект и создаст заметки» — вы переносите ответственность с инженера на статистическую модель. Это опасно.
Человек именно, что понимает цели и задачи бизнеса, архитектурные компромиссы, смежные требования, вектор развития и потенциальные вектора расширения функционала. ИИ этого НЕ понимает.
LLM видит, что модуль А импортирует модуль Б, но не знает, что Б — deprecated с прошлого года, а новый модуль В ещё не задокументирован.
А человек откуда должен знать, что Б deprecated, а В - правильный? Из code review? А почему LLM не должна получать code review?
Человек узнаёт о депрекации Б и появлении В не из магии и не только из код-ревью. Он узнаёт это из множества источников:
Он видел рассылку в Slack/Teams о миграции.
Он участвовал в совещании, где тимлид сказал: «С прошлого месяца Б не юзаем».
Он правил этот модуль полгода назад и помнит, как ставил @Deprecated в коде.
Он видит лог сборки (Warning: ‘Б’ is deprecated), который LLM в момент генерации кода не читает.
LLM получает статический срез репозитория в момент промпта. Она не видит историю коммитов, не видит тикеты в Jira и не слышала вчерашнего созвона.
Человек, увидев модуль Б, задаст вопрос: «Стоп, а Б же вроде устарел?» — и пойдёт проверять документацию или спросит у коллеги. LLM лишена этой рефлексии.
Иначе говоря, человек имеет кучу ненадёжных источников информации, которые он легко может забыть (и чаще забывает, чем вспоминает, по моему опыту). А чтобы хоть сколько-то нормально работать с LLM, проект нужно постоянно поддерживать хорошо задокументированным, явно проставлять @deprecated и TODO - это актуальная реализация, надо описать нормально, и тому подобное, - в общем, всё то, что облегчит задачу и человеку тоже. Может быть, если это решить, то вопрос “понимает ли LLM” будет уже не так актуален?
Человек имеет много источников информации. ИИ - только один. Да, информация бывает недостоверный и человек умеет с ней работать. Оценивать ее достоверность, искать уточнения, менять вводные и даже пересматривать ТЗ, если видит проблему в поступившей информации. ИИ будет тупо следовать инструкциям, даже если они неверный.
Конечно, полная документация это хорошо и прекрасно. Только в жизни оно так не работает. Документация может зависеть от внешних источников, она может обновляться с опозданием, она может быть неполной, она может содержать умолчания (которые известны всем участникам процесса, но не известны машине). Но и ключевой момент, скормить всю документацию LLM не означает, что LLM ее поймет. Не значит, что он всю ее запомнит и не потеряет середину. Даже не означает, что LLM будет строго ее придерживаться.
Сколько уже тут было статей на тему, "я написал та не делать, а ИИ сделал именно так".
Не далее чем вчера кое‑что работало неправильно. Коллега A вызвал меня на созвон и спросил «а почему тут у нас получилось 1812, хотя я 5 лет работаю и никогда не видел значения больше 150?». Я 10 лет назад писал тот модуль, который выдал значение 1812, и сказал «большие значения могут получаться, если на вход подаётся значение XYZ более 99 — так в бизнес‑логике сказано». Посмотрели по логам, и увидели, что хотя сейчас значение XYZ — 42, но по логам вчера оно было 234. Созвонились с коллегой B — тот сказал «точное значение A нам в каждом случае сообщает партнёр, но до того как он это сделает, нам приходится использовать какую‑то временную прикидку, копайте в этом направлении». Стали копать, и действительно, значение, которое берётся за «временную прикидку», есть константа, записанная в конфигурации партнёра, помноженная на коэффициент прикидочности — и конкретно для этого партнёра в этом конкретном случае реально получается 234.
Раскопай мне такое, ChatGPT.
У меня есть два подозрения, почему вы считаете поиск такого бага сложным:
Константа в другом файле (партнера).
баг - не crash, не "совсем неправильные данные", а ошибка, которая маскируется под нормальное поведение. На code review такие чсложно найти, поскольку код выглядит "правильно" на первый взгляд.
В первом случае LLM имеет даже преимущества, она по умолчанию проверяет связанное, когда готовит сама себе контекст для анализа
Во втором - ну вот мой пример. Как мне кажется, этот "котенок с дверцей" показывает, что LLM учитывает логику, реализуемую кодом.
Много букв
▎ SPI-TR3 is 01:00 start + 05:00 duration = active 01:00–06:00 UTC. At 12:15 it should be inactive. The bug is in the backend resolver. Let me read it.
---
▎ Found the bug. Line 52 + 119: DEFAULT_RANGE: str = “SPI-TR3” … return active_ranges or [cls.DEFAULT_RANGE] # ← fallback when nothing matches At 12:15 UTC, nothing is active (correct), but the code falls back to [“SPI-TR3”] — so the log is honest, it’s just reporting the fallback, not a real active range. The system then finds 0 locations for SPI-TR3 → 0 candidates, which is actually the right end result. But the log is very misleading. The fix: when no range is active, return [] and let the caller handle it as “nothing to do”:
---
▎ The full picture is clear. Three things to fix: 1. resolve_all line 119: stop falling back to DEFAULT_RANGE when nothing matches — return [] 2. resolve() line 133: guard against empty list 3. Caller line 1345: when list is empty, emit a clear “Outside all scheduled time ranges” message and stop — currently it only stops at step 2 (no locations) with a misleading path through the fallback
---
▎ The second caller handles [] naturally — get_codes_for_ranges([]) returns [] immediately (line 181 guard), then returns empty candidates. No change needed there.
---
▎ Clean. Now the log at 12:15 will show: Outside all scheduled time ranges — no push scheduled Found 0 candidates Instead of the misleading Active time ranges: SPI-TR3. Ready to commit whenever you are.
Причем что в дополнительный плюс записываю - он проверил другие вызовы, связанные с изменением. Возможно вы тоже проанализировали "где используется другие константы партнеров" (вряд ли она была единственной), но LLM в любом случае быстрее подсветила бы вам, куда еще глянуть.
Если честно, я бы в качестве примера скорее race conditions приводил. Брейкпойнты не особо помогут, даже логи дополнительные могут поведение изменить.
Был прикольный случай, когда я просил его задокументировать, что мой модуль делает. И он в процессе написания документа (когда анализировал, что в какой последловательности модуль делает) нашел:
There is no locking inside the plugin itself (no asyncio.Lock, no DB row locks, no unique-constraint-based guard) protecting a run from overlapping with another run. Two concurrent invocations (e.g. via CLI and API at the same time) can race on disk reads/writes and database commits.
The Scheduler plugin’s own single-concurrent-execution guard (per-job is_running flag) only prevents overlapping scheduled runs of the same job — it does nothing to stop a manually-triggered CLI or API run from overlapping with a scheduled run.
Да, запустить параллельно ту же задачу через cli - в жизни такое вряд ли произошло бы, поскольку это механизм скорее для отладки и исключительных ситуаций (доступен только через podman exec). Однако ж если можно поправить - надо поправить Спасибо, Клод.
Ну или вот: я пришел с запросом: "No spinner, I see “running” forever, even when completed".
Клод:
Two problems: the trigger call returns immediately (job runs async), so the spinner dies right away; and there’s no auto-refresh while a job is running. Fix: poll every 3s while any job shows running, and keep the Trigger button spinning while last_run.status === “running”.
---
Fix: auto-poll + persistent spinner
<кусок кода для фронтенда>
---
Я проверил - стало лучше, но не совсем
Interesting. I see a small spinner on “trigger” button now. And once in a few seconds a “flash” with a bigger spinner in the middle of the page.
---
The “flash” is the table’s loading spinner firing on each poll refresh. Easy fix — suppress it during background polls:
<добавил флаг...>
---
Как по мне, frontend/backend timing race (бэкенд запускает job асинхронно, фронтенд не знает когда он завершится, и без polling’а статус «running» застывает навсегда) - сложно тем, что две команды должны согласовано чинить. А Клод понимает код как фронтенда, так и бэкенда.
Понятно, что "своя рубашка ближе к телу", и ваш баг суперсложный, а мои - "сам дурак, что такое допустил". Однако ж, мне кажется, они демонстрируют, что ИИ может быть полезна в поиске багов в т.ч. "логических"
Не обязательно ведь просить ее править код. Но попросить подсветить несколько мест, куда стоит посмотреть - почему бы и да.
Это ни в коем случае не значит, что он лучше меня справляется. Сплошь и рядом я ему подсказываю "у меня две версии, почему так, проверь". И он уже говорит "вот эта вряд ли потому то и потому, а вот эта - да..." Правда это приходится делать редко, только когда вижу, что сам он никак найти не может.
Я, конечно, не настоящий сварщик, но
Он видит лог сборки (Warning: ‘Б’ is deprecated), который LLM в момент генерации кода не читает.
Разве для того, чтобы в логе появилось такое сообщение в коде, который LLM как раз таки читает, не должно быть @deprecated ?
Если принятые решения разбросаны где ни попадя, в старой переписке или вовсе "тим лид когда-то сказал, кто услышал - молодец", LLM действительно будет делать "не то, что от нее хотят, а то, что от нее требуют" (исходя из данных, которые ей скормили).
Если экспертные знания по проекту только в вашей голове, а у других только обрывки, вас LLM не заменит, согласен.
Ну увидел LLM depricate, и что он сделает? Согласует замену модуля? Перепишет весь код, все зависимости на новый модуль? А за одно протестирует на совместимость и пригодность? А за одно проверит все внешние связи, что они не поломались? Обновит всю документацию по проект? Сделает рассылку по внешникам, что API поменялось?
Вы мыслите уровнем хобби-проекта. По этому вам кажется, что LLM такой умный и все умеет.
А чего, к deprecated модулям прилагать инструкции, что использовать вместо них уже не модно?
И чем поможет инструкция LLM? Я чуть выше написал путь для замены одного модуля другим. Что из этого сможет сделать LLM? Даже если будет такая инструкция?
Возможно последует ей?
Ответили на то что вам удобно, а все остальное проигнорировали... Не удивлен.
Просто мы немного в разных реальностях живём. Я бизнес логикой не занимаюсь и попытки влезть грязными лапами в мои красивые алгоритмы разворачиваю с порога
Разные реальности — это удобная отмазка для тех, кто не хочет признавать, что его "красивые алгоритмы" решают не ту задачу. Бизнес-логика — это не грязь, это критерий истины. Если твой код не приносит деньги и не решает проблемы пользователя, это просто коллекция абстракций в вакууме.
Мой код - это ядро системы. То, благодаря чему работают слои, которые приносят деньги. Если хотите, чтобы система работала надёжно, бизнес логика в ядро проникать не должна. Ядро математично, а бизнес логика его разъедает.
Ох уж эти сказки, ох уж эти сказочники...
Это называется "архитектура". Имеет смысл такое иногда иметь
Это называется: бумага все стерпит. Вы можете писать о себе все что хотите. Что вы пинками дверь к директору открываете. Что он ГД во всем с вами советуется. Что личного шофера отправляет за вами, когда что-то не работает... Никто это все равно проверять не будет.
А реальност она совсем другая. Если ваше "ядро" не будет удовлетворять бизнес, на все ваши рассказы про математичность ядра, про грязые руки и прочее... никто не посмотрит. И будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен.
Но вы продолжайте в себя верить.
Это не так работает. Изменение в ядро вносятся. Но не всегда так, как проситься. А так как укладывается в ядро. Предметная специфика изгоняется за пределы ядра.
Бизнесу всё равно, на каком уровне реализована фича. От ядра требуется дать нужные ручки, чтобы фичу можно было прикрутить, а не идти на поводу у хотелок, которые изменяться через месяц
будете вы переписывать свое ядро не так, что бы было красиво, а так что бы бизнес был доволен
Это очень спорное заявление. Во-первых, бизнес не может быть недоволен ядром, поскольку он про него ничего не знает. Во-вторых, адекватный бизнес с технарями советуется, а если не советуется — всегда есть в-третьих, бизнесов дохерищща, а я такой один — я просто в тот же день положу заявление на стол (и делал так дважды).
Вы не поверите, но таки да! Именно что согласует!
Вот прям так человеческим языком и спросит "какой модуль использовать вместо deprecated для такой цели? Выберите: Вариант1, Вариант2, предложите свой". Еще до того, как начнет не то, что кодить, но даже спеку составлять.
И как раз нет, я не считаю, что LLM такой умный и все умеет. Наоборот, я считаю, что за ним нужен глаз да глаз. И на его вопросы и уточнения я отвечаю вдумчиво, а не просто кликаю на услужливо подсказанное recommended. И спеки (где он описывает, что надо сделать) проверяю прежде, чем передать дальше, на имплементацию.
И храню их как ценные артефакты, которые той же (или другой LLM) или даже мне самому потом помогут понять, а почему, собственно, так. А не пытаться вспомнить разговор с заказчиком годовой давности.
Вы когда-нибудь делали что-то больше хобби проекта?
Согласует, это не значит "спросит у оператора". Согласует это значит найти людей (отделы, модули, заказчики, клиенты, архитекторы), которых затронет это изменение, убедится что это изменение не поломает их код (процессы, интеграции и т.п.), скоординировать по времени, что бы ваши изменения вступили в силу одновременно. И т.д. и т.п.
Знаете, что делают мои агенты первым делом на практически любую задачу?
Ищут контекст на доске и сверяют историю коммитов.
Причём я их об этом не прошу...
Звучит красиво, но на практике это антипаттерн.
Контекст на доске часто устаревает через 2 дня после создания тикета. Сверять с ним текущую реальность — все равно что гадать на кофейной гуще.
История коммитов показывает путь, но не показывает намерение.
Если ваши агенты тратят первые 15 минут на “ковыряние” в git log вместо того, чтобы спросить посмотреть актуальную схему данных — это не профессионализм, это прокрастинация под видом анализа. Сначала надо сформулировать гипотезу, а уже потом проверять её в истории, а не наоборот.
Или моя инфраструктура лучше вашей.
Я слежу за тем, чтоб беклог отражал актуальное состояние проекта. Агенты тоже следят, чтобы цели на доске не расходились с тем, что хочет разработчик.
И это не 15 минут, а 15 секунд на всю разведку. И нет. Полезность доски сложно переоценить. После того, как я начал активно работать с доской - агенты стали вести себя гораздо увереннее. Входят в контекст задачи с полуслова. Во многом благодаря тому, что на доске много внимания уделяется зонтичным таскам, которые задают стратегическую рамку для возможных задач. Нет, нет. Доска - уберполезна.
Забавно. А я так никогда не делаю, например, но что из этого следует?
В нормальных компаниях дают не только задачу, но и доступ к документации, описание какие библиотеки используются
Именно! Человек будет смотреть документацию, конвенции, а не вникакть в каждую строчку чужого кода всего проекта. Только в нужные фрагменты.
Может и LLM стоит то же самое скормить? А не пытаться ей в контекст загрузить весь проект целиком, каждую строчку кода, а потом ругаться, мол не влезает и внимание теряется.
Да? А давно LLM умеет участвовать в совещаниях? В созвонах с заказчиком? Читать и понимать несвязанные пожелания заказчиков? Разбираться в предметной области?
И да, вы уже отказываетесь от концепции, что ИИ посмотрит весь код и все там поймет и разберется?
Простите, у вас правда обычные рядовые программисты перекраивают продукт исходя из созвонов с заказчиком?
Нет такого, что product manager побеседовал, подготовил документ с изменениями, передал разрабам в уже четком стурктурированном виде?
Или в тот проект, что в миллионный контекст ни разу не влезает, вы сами вносите изменения после разговора с клиентом?
И таки да, product manager (ну или кто там у вас) очень даже может скормить транскрипт беседы в [другую] LLM, которая поможет ему правильно обновление спецификации подготовить, уточнить не отраженные в ней вопросы из обсуждаемого - забыл или сознательно решил не делать...
Я не product manager, но flow у меня примерно так и выглядит: "Клиент вот выкатил список хотелок, давай обсудим, разобъем на задачи и напишем задания для последующего составления детальных спецификаций".
Она составляет задание в стиле
Ensure a previous Scheduler job run is never left stuck reporting "running" when it has actually stopped (app restart, crash, or kill during execution).
Confirmed in code:
- No startup reconciliation exists: grepped the scheduler plugin for ...
...
Needs a fix:
1. On app startup (before
run_job_looptasks are created), queryScheduleRunfor ...
А дальше уже "девелоперская" сначала по такому промпту пишет design/spec (уже со структурами данных, кусками кода), следующем этапом по этой спеке соствляет план. И уже по согласованному плану пишет код, где особо в сторону не уйти. Что попросил (заказал архитектурно), то и получил.
Если мы занимаемся обсуждением функционала конкретного модуля, мне проще пригласить человека который реализовывал и отвечает за это модуль. Он будет отвечать за детали реализации, я за общую архитектуру и взаимодействие модулей. Зачем играть в испорченный телефон?
То есть, и без того ограниченный контекст, вы хотите заполнить пересказом двух часового совещания? И не надо говорить про другую LLM. Ей все равно понадобится дополнительный контекст, который не был озвучен на совещании, но присутствует в головах участников.
При том, что этот контекст на вносить при каждом обращении к LLM.
Надо же как интересно вы меня не поняли :)
Мне казалось, я четко объяснил, что транскрипт анализируется ДРУГОЙ LLM и по результатам формируется "выжимка". Двухчасовая беседа, обсуждения в контекст не попадают. Только к "чем пришли"
И таки да, product manager (ну или кто там у вас) очень даже может скормить транскрипт беседы в [другую] LLM, которая поможет ему правильно обновление спецификации подготовить, уточнить не отраженные в ней вопросы из обсуждаемого - забыл или сознательно решил не делать...
...
А дальше уже "девелоперская"
Собственно поэтому я хоть и не идеализирую LLM, но считаю, что за людьми не меньше глаз да глаз нужен. Тоже надо присматривать, перепроверять.
Разве что LLM умеют как отставивать свою позицию, так и признавать ошибки, а вот люди чаще упираются рогом и приходится прибегать ко всяким манипуляциям, чтобы лишний раз не обидеть.
P.S. Везет вам, такой большой проект и никакой текучки кадров.
Видите ли, в чём дело. Вот наша маленькая командочка из десятка человек, например, поддерживает сайт электрической компании. И нас никто не дёргает «напишите на pandas». Нам просто говорят «наши продаваны хотят иметь возможность загружать CSV» — и мы делаем. Да, на элементарной потоковой библиотеке, которая не жрёт память, аки беременный слон.
Просто задачи надо ставить правильно. У нас менеджеры не до конца зажрались, и если программисты говорят, «не надо так» — то они таки задумываются: «а может, и правда не надо?»
Что до ИИ который "идет и смотрит, что есть в коде". Ну так это вообще смешно. Код с которым работаю я не влезет в контекст ни в одного современного ИИ. И я бы с большим любопытством посмотрел, как он его будет смотреть...
Смешно только то, что вы до сих пор думаете, что кодинг с ИИ оперирует контекстами, как будто последний раз щупали его в чате. Эту проблему решили уже с год назад, и не просто бесконечным раздуванием цифры контекста, а следующим образом,
показываю на багфиксе 1M+ строчек кода знакомого:
Сначала сильная модель смотрит на структуру вашего проекта и размечает ее. Это еще до того, как оно вообще начнет вникать в суть вашего вопроса:
Потом оно запустит поиск багов десятками агентов, каждый по своему набору (обсуждения и код кропаю, private repo):
На каждый найденный баг спавнится агент, задача которого доказать, что баг не важен или его не существует (red team):
Рано или поздно оно закончит:
...и запустит еще один проход по самым важным областям кода уже на сильных моделях:
В результате вам будет предоставлен документ, из которого вы по своему разумению можете выкинуть, что вас устраивает как баг, что-то добавить, обсудить. И только после этого он будет раздербанен на тестируемые фазы, с которыми можно вайбкодить.
«Эту проблему решили с год назад» — нет, не решили. Вы путаете инструменты анализа (статический анализ, линтеры, поиск по AST) с пониманием. Вы наняли армию муравьев (агентов), чтобы они оббежали муравейник (репозиторий) и доложили, где трещины. Это круто, но это не решает проблему контекста.
Проблема контекста в LLM — это проблема внимания и потери середины. Когда ваши агенты режут код на куски и анализируют изолированно, они теряют глобальные зависимости. Ваши 100 агентов на 1M строк будут бесполезны, если баг кроется во взаимодействии между двумя модулями. Синтез глобального вывода из роя локальных наблюдений — это нерешенная математическая проблема на таких объемах, и «год назад» её никто не решил.
«Сначала сильная модель смотрит на структуру» — Это делает любой современный IDE за 2 секунды. Построить граф зависимостей по импортам — это не ИИ. Вы путаете парсинг и семантику. Модель «смотрит» на имена файлов и папок, но она не читает при этом логику. Она составляет карту, по которой потом отправляет курьеров. Это администрирование, а не интеллект.
«Десятки агентов ищут баги» — это звучит красиво, но на практике — это спам. Запустить 10 агентов на 1M строк кода — значит получить 10 тысяч ложных срабатываний. Ваш “Red Team” агент, который доказывает, что баг не важен — это просто второй LLM вызов, который с вероятностью 50% скажет “это фича”, потому что у него нет контекста продакшена.
«Рано или поздно оно закончит» — и ключевая фраза. Это долго и ресурсоемко. Запустить такой пайплайн на OpenAI API стоит сотни долларов за одну сессию. Теперь представьте, что я, человек, открываю этот же код в IDE, ставлю брейкпоинт на ошибке и нахожу баг за 5 минут, потому что я знаю бизнес-логику, которой нет в вашем AST-графе. Ваши агенты ищут синтаксические и типизированные баги, но не логические.
Ваш пример — это CI/CD на стероидах с LLM-оберткой. Вы не приблизились к решению проблемы контекста; вы просто научились игнорировать её, делегируя поиск локальных аномалий роботам.
Смешно не то, что код не влезает в контекст. Смешно то, что вы продаете инженерный костыль как революцию, при этом финальное решение все равно принимает человек, читающий ваш документ. Значит, проблема “посмотреть и понять” по-прежнему лежит на плечах человека. ИИ лишь подсветил фонариком. Фонарик — полезный, но он не видит всей комнаты.
Я не говорю, что ваш пример бесполезен. Он отлично подходит для поиска утечек памяти, неинициализированных переменных или SQL-инъекций — т.е. для задач, где баг локален. Но ваш исходный тезис был про то, что ИИ “смотрит и понимает” большой код. Вы признаете, что финальный документ читает человек. Значит, понимание — за человеком. ИИ — это увеличительное стекло, а не глаз. И увеличительное стекло не решит проблему, если трещина в фундаменте, а не на стекле.
Такой ответ мне нравится. Желаю, чтобы все "настоящие программисты" относились к работе так, мир станет лучше.
UP:
«Рано или поздно оно закончит» — и ключевая фраза. Это долго и ресурсоемко. Запустить такой пайплайн на OpenAI API стоит сотни долларов за одну сессию. Теперь представьте, что я, человек, открываю этот же код в IDE, ставлю брейкпоинт на ошибке и нахожу баг за 5 минут, потому что я знаю бизнес-логику, которой нет в вашем AST-графе.
Долго? Отнюдь. Вникнуть в такую гору кода - это обязано быть долго. И дорого. Но мы тут уже в ветке перетекли от софта для полутора землекопов к коммерческому? Пусть ищут деньги.
Кроме того, прогон из моего примера - это абстрактный поиск багов. Если баги ищутся в конкретном месте, то и читать весь код не надо, и влезает тогда все подозрительное после прогона муравьев в один агент-синтезатор. Более того, архитектурные доки, как продукт такого прогона, позволят больше не шерстить весь код от начала и до конца.
В идеальном мире вайбкодинга, вы должны тонуть в доках, которые агенты пишут для себя. Вам остается только принять решения, где есть выбор.
Я не говорю, что ваш пример бесполезен. Он отлично подходит для поиска утечек памяти, неинициализированных переменных или SQL-инъекций — т.е. для задач, где баг локален.
Я, к сожалению, не могу вам показать итоговый мегабайтный док, но бОльшая часть багов из него была не локальными. А как раз связями между модулями.
UP2: вот так могу:
Run one phase per session/agent. Between phases: the owner walks the phase’s manual checklist and signs off in
PROGRESS.md. If a session dies mid-phase, the next agent resumes fromPROGRESS.md+ the ticked boxes inFINDINGS-CHECKLIST.md— both are updated in the same commit as each fix, so the repo is always the source of truth.Map of the package
STABILITY-AUDIT-2026-06-11.md(repo root) — the audit report, §-references everywhere point here.
STABILIZATION-PLAN.md(repo root) — master plan: constraints, phase table, protocol.
docs/stabilization/— AGENT-INSTRUCTIONS (rules), DECISIONS (binding owner answers D1–D17), FINDINGS-CHECKLIST (598 items, stable IDs), PROGRESS (live state), phase-00…11 (step-by-step), audit-data/ (raw JSON, see its README), architecture-current-vs-target.png/svg.
Не совсем понял, где вы собираетесь ставить брейкпойнт получив задачу "найди баги, в т.ч. связанные с безопасностью, во всем проекте".
ИИ — это увеличительное стекло, а не глаз.
Именно так. С чем вы спорите-то? "увеличительное стекло мне не нужно, у меня глаз есть"?
«Увеличительное стекло» не может работать без фокуса. Если я просто «посмотрю» на весь проект через лупу, я увижу только шум.
Вот поэтому LLM и позиционируется как инструмент, которым кто-то будет пользоваться. Желательно осознанно. А не "отправили LLM в свободное плавание, и он творит, что хочет" (Порфирия Петровича из "Путешествия в Элевсин" пока не обсуждаем).
Да, фокус надо уметь наводить. Даже простым микроскопом пользоваться и то надо хоть чуточку, да поучиться.
А я как раз и спорю с тем, что ИИ позиционируют как замену человеку.
ИИ как инструмент, да - это хорошо и удобно. Но со своими ограничениями.
Что вы понимаете под "замену человеку"?
Если "вместо 10 человек хватит 5 + LLM" - это замена или нет? Один водитель фуры вместо десятков кучеров. Фура заменила человека (и не одного).
Если же "вместо 10 человек просто LLM" - это из серии "не будет ни театра, ни кино, а только сплошное телевидение". Отношение к таким предсказателям, как к фрикам.
Фура заменила человека (и не одного).
И дала работу сотне других людей.
Все аналогии - ложны. Ваша - особенно. Фура не заменила человека. Фура заменила повозку. Просто кучера стали звать водителем и, кстати, водителей стало кратно больше чем кучеров.
«вместо 10 человек хватит 5 + LLM» — это не замена, а оптимизация. Вы путаете сокращение штата с отсутствием человека. 5+LLM — это гибрид. Гибрид не является «заменой человеку» по определению, потому что LLM без этих 5 человек ничего не производит.
Вот это я и хотел у вас выяснить. Потому что для меня " «вместо 10 человек хватит 5 + LLM» " означает, что LLM заменила 5 человек.
Если для вас термин "оптимизировала" 5 человек звучит приятнее уху, ОК. Главное, что вы с этим согласны, и тогда и спорить-то не о чем.
P.S. Ну давайте скажем, что вместо программистов появятся операторы LLM.
Вот вы занимаетесь передергиванием, а в суть сказанного не вникаете.
Если вместо 10 программистов будут работать 5 - это оптимизация. А если вместо 10 программистов будет работать 5 операторов - это замена. Потому что квалификация программиста несоизмерима выше квалификации оператора.
Потому, что программист сможет "надавать по рукам LLM", когда она сморозит глупость. А оператор даже не поймет, то она сморозила глупость.
программист сможет "надавать по рукам LLM", когда она сморозит глупость.
И в очередной раз встаёт вопрос: вот прям интересно, что легче делать: писать свой код или читать чужой?
Ваши агенты ищут синтаксические и типизированные баги, но не логические.
Баги бизнес-логики агенты не умеют искать? Или всё же бывают такие агенты и SKILL?
Бизнес-логика не формализуема. И не унифицируема. Её нет в коде, она в головах заказчиков и в опыте разработчиков. Агент не может проверить, что “скидка 10% не должна суммироваться с промо”, если это явно не прописано в спеке. А если прописано — это уже обычный юнит-тест.
Всё, что есть на рынке — это помощники для регресса или обфускации, но не замена аналитику.
Агент не может проверить, что “скидка 10% не должна суммироваться с промо”
Т.е. ваши программисты сами такие условия добавляют? Не потому что им кто-то сказал?
А если он уволится, и другой на его место придет, он как про такую бизнес-логику узнает?
Во время онбоардинга ему расскажут или в коде увидит? Если последнее, то как должен отреагировать? Решить "здесь так заведено" (и пропустить баг в бизнес логике) или требовать от руководства каждую строчку обосновать?
P.S. Один из способов, как использую LLM - прошу ее разобрать мой код и нарисовать mermaid диаграммы состояний. И смотрю, а то ли я накодил, что бизнес логика ожидает.
Если ОК - остается артефакт, объясняющий бизнес-логику следующим поколениям.
А причем тут программисты? Речь шла об умении ИИ проверять бизнес логику.
Но, вообще-то, для человека разбирающегося в предметной области, это повод задать вопрос бизнесу, нет ли тут ошибки. ИИ на это внимания не обратит.
Вы писали, мол агент не может проверить, соответствует ли код бизнес-логике. Соответственно у меня вопрос: кто у вас это проверяет? Кто проверяет код, если не программист? Аналитик, знающий бизнес-требования, когда какие скидкы суммируются, а какие нет?
И так-то ИИ разбирается в предментной области, скорее всего, лучше рядового программиста. И с гораздо большей вероятностью уточнит. что обычно так не делается.
Кого вы имели ввиду, упоминая "для человека разбирающегося в предметной области, это повод задать вопрос бизнесу"?
Код и бизнес логика это хоть и связанные, но разные задачи. Код это ответственность программиста. Бизнес-логика - архитектора(аналитика) и заказчика. Но это именно зона ответственности.
У меня программисты вполне себе разбираются в бизнес логике которую реализуют. Умеют критически оценивать запросы пользователей и задавать вопросы.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой. Он знает некоторые шаблонные решения, да и то, если они опубликованы в интернете. Но не более.
Если человек видит и задает вопросы, когда что-то не укладывается в его знание процесса. То, ИИ не будет ничего "уточнять". Он просто реализует. И даже если его попросить проанализировать, он не найдет ошибок бизнес-логики. Он сможет найти только отличия от известных ему шаблонов.
Вообще-то агент не самодостаточен. К нему прилагается программист, задача которого ровно в том, чтобы дать нейронке достаточный контекст... И если программист контекст имеет, то почему агент его не получает? У вас, такое впечатление, что агенты сами неспросясь код правят.
Это общее правило - от армии, до стройки и грузоперевозок. Если конечный исполнитель находится “по колпаком” и не понимает общей задачи и роли в ней той подзадачи, которую он непосредственно делает - то он обязательно будте творить хрень. Потому что понимание у него всё равно будет, но в корне неправильное.
К ИИ - это, очевидно, тоже относится.
ИИ же, в принципе, не разбирается в предметной области. Ни в какой.
"Хоть горшком назови, только в печку не ставь"
ИИ не будет ничего "уточнять". Он просто реализует.
Если вы про веб-интерфейс - возможно. Хотя пока я опыта в составлении промптов не набрался, он даже там умудрялся уточнящие вопросы задавать, когда я "кофе черный с молоком" просил.
А в нормальной системе он именно что сначала задает кучу уточняющих вопросов, чтобы лучше "понять" задачу. Потом предлагает варианты, объясняя их поюсы и минусы. Потом пишет спеки/планы. И приступает к реализации только когда они меня полностью устроили.
Причем изредка бывает, что я даже при таком подходе чего-то пропустил, и тогда даже на этапе реализации система может остановиться и сказать "вот тут написано надо сделать так-то, но так не получится....".
А в нормальной системе он именно что сначала задает кучу уточняющих вопросов, чтобы лучше "понять" задачу.
Я уже третий день план пишу с Fable... Уже 60% 200-долларовой недельки убил только на вопросах и обсуждениях, без написания кода.
ИИ не задает вопросы, потому что ему непонятно. Он задает их, потому что в его настройках прописано: «Если энтропия запроса выше X%, возьми три наиболее частых неоднозначности из обучающей выборки и сформулируй их как вопросы».
ИИ может остановиться и указать на ошибку. Но не потому, что понял логику, а потому что:
В обучающей выборке были похожие баги, и он запомнил паттерн ошибки.
У него есть встроенный валидатор.
Он сопоставил ваш код с известной проблемой.
Если вы дадите ему уникальную архитектурную задачу, которой нет в интернете, он не остановится. Он спокойно напишет красивый код, который упадет в рантайме, потому что он не просчитывает последствия на 10 шагов вперед.
Мне, конечно, интересно узнать, чем "непонятно" отличается от "энтропия выше", ну да ладно.
Вы же в курсе, что так-то он еще и тестами код покрывает, как минимум, unit test? Причем генерирует больше edge cases, чем я сам бы напилил. И это все по согласованию со мной. Если я считаю, что может еще подводный камень быть - я ему подскажу, что еще протестировать, это и есть моя задача :)
Разумеется, даже с интеграционными тестами все еще возможны рантайм ошибки. И я слабо верю, что вы настолько хорошо просчитываете на 10 шагов вперед, что сразу написаный код оправляете в прод, и он там без багов работает.
Если же даже ваш код проверяется, зачем вы постоянно пытаетесь ограничить LLM? То дать ей меньше данных, чем программисту (пусть сама решает, какие скидки суммировать, а какие нет), то отправить код на выполнение без проверок...
А вы знаете, это прекрасный вопрос. Для меня он полностью закрывает необходимость дальнейшей дискусси.
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый. По этому LLM оперирует энтропией, а не "понятностью".
Юнит тесты для проверки ИИ, которые пишет сам ИИ? Это способ самоуспокоения и к проверке кода имеет весьма касательное отношение. И даже 100% покрытие тестами написанными ИИ не даст гарантии, что код правильный.
Проблема ИИ, не в том, что ИИ ошибается. Проблема в том, что ИИ прячет ошибку за правдоподобным кодом. И на синтетических тестах (даже написанных вручную) все может работать, а продавшее - ломаться.
Почему я пытаюсь ограничить LLM? Да потому, что контекст LLM, даже со всеми ухищрениями, сильно меньше контекста человека. Если ИИ скормить слишком много информации, он начинает ее сжимать. А это чревато тем, что важные требования могут оказаться потеряны, а ИИ сосредоточится на второстепенных. Примеров этому достаточно много даже здесь.
Вы не можете знать, какая информация нужна агенту для решения задачи. Ему нужна не сжатая выжимка, а доступ к базе и удобные ручки, чтобы брать нужное
"Непонятно" - это неизмеримое абстрактное понятие. Энтропия - это вполне конкретный параметр LLM, и, что самое главное, - измеримый.
Ну так это же прекрасно! У человека "ничего не понял", "не совсем понял" и т.п. Субъективно. У ЛЛМ все гораздо четче, ее на мякине не проведешь. "42%, надо уточнять". Никаких "вдруг если спрошу, подумают, что я плохой специалист, лучше промолчу"...
Почему, кстати, вас беспокоит, кем написан тест?
Меня лично больше волнует полнота условий для проверки, чтобы один и тот же тест гонялся с десятками разных комбинаций параметров перебирая и "нормальные" случаи из "серединки", и нормальные "на границах" допустимого, и "за границами. Причем в рзаных комбинациях (несколько граничных и т.п.)
Ну т.е. тест написать не сложно, вот они ассерты, глазами смотри, точно так же, как после коллеги. А вот набрать немеряную кучу условий... И опять же - само собой, потом надо их посмотреть, искусственно "испортить", чтобы убедиться, что это приводит к фейлам....
Причем код, который пишет LLM - отдельно. А входящие исходящие параметры для тестов (где она должна зафейлиться, а где должна в соответствии с задачей выдать нечто конкретное) LLM (возможно другая) пишет именно исходя из задачи. Т.е. код теста отнюдь не "подтягивается" под функцию.
А про контекст... Вы точно понимаете разницу, к примеру, между вызовом агента и скиллза?
Вкратце: И то и это вызывается при необходимости. Но в случае скиллза он остается в основном контексте. Вызван единожды, больше не потребуется в той сессии, но в конексте место занимает. А агенту "основной контекст" дает задачу и всю необходимую информацию. Агент "шуршит", возможно получает кучу "мусора", выбирает именно то, что требуется, и возвращает только это. Он выполняется в отдельном контексте, возвращшет только нужное, безо всяких промежуточных этапов. В основном конексте появляется только минимально необходимый результат.
Не надо тупо скармливать в контекст всю вашу кодовую базу. Человек, кстати, тоже вряд ли помнит каждую строчку.
LLM не обладает пониманием инженера — она обладает статистической уверенностью, которая может быть катастрофически ошибочной. Человеческое «ничего не понял, надо уточнить» — это не баг, а важнейший механизм верификации, основанный на реальном понимании предметной области. LLM же с абсолютно одинаковой уверенностью сгенерирует и гениальный краевой кейс, и тест, проверяющий деление на ноль через сакральный смысл числа 42, если это коррелирует с её обучающей выборкой.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели. И то, что написание тестов вы отдадите другому ИИ ровным счетом ничего не меняет.
Утверждение, что агент «возвращает только нужное, безо всяких промежуточных этапов», выдает непонимание природы LLM-агентов в продакшене. Вы называете «мусором» ту самую цепочку рассуждений, которая, является единственным способом для LLM решать сложные задачи с приемлемой точностью. Агент не «шуршит», фильтруя мусор, — он галлюцинирует на каждом промежуточном шаге. Проблема «основного контекста» никуда не исчезает: она просто переносится в контекст агента, где, благодаря многоагентности, ошибки накапливаются, а возможность человека проконтролировать логику стремиться к нулю.
Ну и главное: сравнение с человеком, который «не помнит каждую строчку кодовой базы», некорректно. Человек не помнит код, но он хранит ментальную модель системы. Он знает, почему модуль А не должен вызывать модуль Б напрямую, потому что полгода назад это приводило к гонке состояний. LLM не помнит синтаксис и не строит ментальную модель. Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Проблема не в том, кем написан тест, а в том, что вы делегируете машине верификацию истинности, на которую у машины нет ни права, ни способностей.
LLM напишет не тесты исходя из задачи, а статистически правдоподобную мешанину из всех похожих тестов, которые она видела в интернете. Она не проведет анализ граничных значений, основанный на понимании архитектуры. Она сгенерирует «немереную кучу» параметров, но их релевантность будет стремиться к нулю. Вы получите кучу юнитестов, которые тестирует не написанный код, а фантазийный мир языковой модели.
Такое впечатление, что вы ни разу не видели тестов, написанных LLM, просто пишете штампы, не попытавшись хотя бы просто посмотреть, как она напишет тесты какой-нибудь вашей функции.
Вы предлагаете заменить архитектора, который забыл пару строительных норм, но знает, почему нельзя убирать несущую стену, на прораба, который помнит ГОСТ наизусть, но совершенно искренне считает, что несущая стена тут лишняя, потому что в 42% похожих проектов этой стены не было.
Вы точно со мной сейчас разговариваете?
Не надо мне приписывать свои страхи (галлюцинации, фантазии) про "заменить архитектора"
Я тут всю дорогу распинаюсь, что специалист (архитектор) необходим. LLM - помощник ему при планировании и написании детальных формальных спецификаций. И на следущем этапе - "строитель", который делает "грязную работу", следуя качественной детальной спецификации.
«Код, который вы не можете объяснить — это не ваш код» ©
Код с которым работаю я не влезет в контекст ни в одного современного ИИ. И я бы с большим любопытством посмотрел, как он его будет смотреть...
Я не занимаю ничью сторону в этой дискуссии, но замечу, что RAG и запросы инструментов в MCP придумали неглупые люди, и мне удаётся упаковывать в контекстное окно 200К (1М/2М использовать не нужно, они не работают, вопреки обещаниям) весь относящийся к делу граф зависимостей.
Но этот RAG, разумеется, нужно сделать самому, то, что есть из коробки у флагманов — стыдно даже стажёрам показывать.
RAG не снимает ограничения ИИ. Он обходит некоторые, но не всегда успешно.
Я где-то сказал, что «RAG снимает ограничения ИИ»? Где?
Я сказал, что он «всегда успешно обходит все ограничения»? Где?
Мысль выше и так проще некуда, но могу переформулировать: RAG, правильно сделанный специально для проекта, обходит ограничение на размер контекстного окна. Всегда, потому что в MCP должен быть инструмент «приблизить»/«вглубь», а «R» из аббревиатуры должно оперировать абстрактным синтаксическим деревом, а не стеной текста.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем. Это решает лишь проблему поиска и анализа небольшого объема данных на большом объеме кодовой базы. Да инструмент полезный, но очень ограниченный.
Это не решает те ограничения о которых говорилось выше. Это не решает проблему потери середины. Это не решает проблему контекста. Это не решает много других проблем.
Предлагаю аккуратнее относиться к формулировкам, например так: «Я всё еще не понимаю, как это решает проблемы потери середины и контекста, хотя мне и два раза разжевали».
"да меня менеджер заставил, сроки горят"
Я просто выполнял приказ (с)
Потому что в реальной работе огромное количество переменных, которые ограничивают эту работу и не дают сделать "просто хорошо". Любой дурак и до ИИ мог написать полезных для себя пет-проект с нуля методом Ctrl+C, Ctrl+V и кучей говнокода, сейчас этот процесс просто улучшился и ускорился, но принципиально это ничего не меняет.
Я бы вообще сказал, что разработка сама по себе вещь довольно простая, особенно когда делаешь для себя любимого в комфортных условиях. Этот как сравнивать локальную установку и настройку Linux под себя и на домашнем компьютере и на рабочих машинах крупного предприятия
Отличный текст!
Распечатать и на стену!
Подписываюсь под каждым словом
ЧТО ВЫ ТУДА БЛ**Ь ПОСТОЯННО ДОПИСЫВАЕТЕ 10 ЛЕТ? ВЫ МОЖЕТЕ НАКОНЕЦ УСПОКОИТЬСЯ УЖЕ? МОЖНО В ЭТОМ ГОДУ БЕЗ НОВЫХ ФИЧ И СУПЕРАППОВ? Можно проект ЗАКОНЧИТЬ и просто сделать для другой задачи ДРУГОЙ? Я УСТАЛ!
Я понимаю попу-боль и разделяю, особенно в части оптимизации и размера приложений. Кстати, за Яндекс GO, случай, который произошел буквально вчера. Вызвали доставку по адресу, чтобы забрыть одну вещь в городе и передать другому человеку в этом же городе. Назначали курьера на машине, курьер приехал, забрал вещь и уехал. Спустя пару минут приходит отбивка, вам назначен курьер - и в мою строну движется какой-то новый курьер, чтобы забрать эту же вещь. При этом прошлый курьер в системе не виден, позвонить / написать ему невозможно, заказ отменить нельзя. Вещи нет, курьера нет, 3 часа долбили чать поддержки чтобы отменить / закрыть заказ и выяснить куда пропал первый курьер, так как вещь он так и не отдал получателю. Вот такой вот классный сервис.
А касаемо тезиса, ну вы же понимаете что есть бизнес, который оплачивает весь этот банкет. Хотите пилить супер фичи, вылизывать все до последнего байтика – да пожалуйста, но этому не место в корпоративной разработке, увы. В лучшем случае, от вашего времени отделять процентов 10-20 на тех долг, чтобы что-то улучшить или переписать, до чего не доходили руки. А все остальное время вы будете пилить новые фичи, ибо да, бизнес, метрики, EBITDA должна расти и все такое. И вспоминаю старую шутку с баша, которая вообще не разу не шута.
А касаемо тезиса, ну вы же понимаете что есть бизнес, который оплачивает весь этот банкет. Хотите пилить супер фичи, вылизывать все до последнего байтика – да пожалуйста, но этому не место в корпоративной разработке, увы.
Так где же тогда работают все топовые программисты? В Linux Foundation?
И вспоминаю старую шутку с баша, которая вообще не разу не шута.
Тут все понятно, но продукту уже 10 лет. Может пару раз лизнуть его надо было за это время?
Так где же тогда работают все топовые программисты? В Linux Foundation?
Смотря что вы считаете "топом". Если это крутые скиллы, большая сложность, высокие стандарты и кода и требования их строго соблюдать, то да - это все опенсорс. Если топом счиать тех, кто решает сложные бизнес задачи в ограниченных условиях и сроках, то там хорошо платят и требуют быть немного менее придирчивым, лишь бы влезать в человеко-часы и успеть двигать фичи в релиз.
Тут все понятно, но продукту уже 10 лет. Может пару раз лизнуть его надо было за это время?
А как вы это представляете? Ну вот есть монолит, написанный 10-15 лет назад. Он же не писался в стол, он в проде, активный и работающий. Он как-то поддерживается. Поддерживается, потому что он уже вдоль и поперек протестирован и предсказуем. Вы предлагаете скормить его в ИИ, чтобы она выплюнула улучшенную версию?
Такие проекты не переписываются ровно потому, что там слишком сильные зависимости внутри. Он работает с БД, в него ходит много сервисов уже новых за данными. Что относительно просто, то выпиливают в какой-то микросервис и ходят по API / шине. Распилить его непонятно как, как разделить БД тоже не понятно, такое разделение приведет к переделке многих внешних клиентов / потребителей, а на все это нужно время переделывать, переаналитить и протетсировать.
Вы предлагаете скормить его в ИИ, чтобы она выплюнула улучшенную версию?
Да, именно так, я чуть выше по ветке кидал пример того, как я бы это сделал. Не скажу за Яндекс, но у Сбера есть бета-программы, в которой я и состою - выкатывайте на меня вайбкоженный клиент на 100 мегабайт вместо 1000, с удовольствием потестирую.
Судя по некоторым всплывающим статьям, некоторые компании так и попробовали, сожгли тысячи долларов и престали.
Вы же понимаете, у бизнеса есть приоритеты. Бизнес всегда будет стараться больше и больше добавлять фич, чтобы конкуририровать, повышать ценность и маржинальность, выходить на новые рынки и сферы и т.д. И какое там качество и легаси, бизнесу глубоко насрать. Не насрать становится, когда падают метрики, когда всплывает больше багов и уязвимостей, когда фичей меньше в релиз заявляется, или стоимость их в часах увеличивается.
Если взять абстрактный мир, когда появятся нейронки и агенты, которые могут переварить миллионы строк кода и что-то выплюнуть работающее, не поломав ничего, знаете что будет? Бизнес будет клепать фич еще больше и быстрее. И того самого говнокода, которые генерируют люди станет просто кратно больше.
Окей, у людей разная эспертиза, у нейронок понятное дело возможностей писать лучше на порядок больше, но проблема не в экспертизе или не в знании каких-то вещей. Проблема говнокода в том, что в какой-то момент не адаптировали архитектуру, не заложили чего-то, не обмазали сервис интерфейсами, декораторами и прочими прелестями, не вынесли функционал в какой-то выделенный сервис и т.д. У людей на эту тему есть встречи, тедолги, арх. синки и прочее, и все равно люди ошибаются и допускают ошибки. Нейронка таких проблем не испытывает и не будет запариваться, она не предложит ничего из этого. Ее главная задача сделать так, чтобы оно работало - сбилдилось и прошло тесты, котоыре сама и напишет в лучшем случае. Если вы явно ей не скажете - выдели хэндлер, обобщи функционал в какой-то базовый класс и т.д., она это и не сделает, потому что нейронке пофигу на 3000 тысячи строк в файле, ей пофигу на конструктор с 50 зависимостями и т.д. И как это потом распутывать – открытый вопрос, но святая вера что нейронка просто посидит и подумает и найдет проблему, если не с первого раза, то с десятого иногда изумляет.
У людей на эту тему есть встречи, тедолги, арх. синки и прочее, и все равно люди ошибаются и допускают ошибки. Нейронка таких проблем не испытывает и не будет запариваться, она не предложит ничего из этого.
Вот тут вы правы, я считаю что вайбкодеры делятся на тех, кто регулярно останавливается и говорит сделай ревью, поищи баги, задай вопросы. И на тех, кто этого не делает. Именно в умении поставить нормальную задачу и вовремя выловить не оптимальные решения и состоит, так сказать, секрет вайбкодинга, на мой взгляд.
У меня почти на каждую пачку "фич" идет прогон на баги, дедупликацию и прочий рефакторинг. Причем не конкретно по новой пачке - с этим справляется сам ultracode в claude, а именно по всему коду.
Если вы явно ей не скажете - выдели хэндлер, обобщи функционал в какой-то базовый класс и т.д., она это и не сделает, потому что нейронке пофигу на 3000 тысячи строк в файле
Не согласен. В процессе прогона из примера выше таких примеров много. От них на самом деле иногда устаешь отмахиваться.
Например, вот:
helpers.pydecomposition — defer on cost is fine, but ⚑ "function-local imports = circular-import tell" is false:helpers.pytop-imports only stdlib +lib.log+config+discord; the function-locallib.models/lib.pause_managerimports are one-directional with no cycle. The decomposition is not gated by an import knot. ⏸️ Reviewed 2026-06-23 and kept deferred — 548 lines / 31 functions across ~7 concerns; pure cosmetic refactor with wide import churn and zero functional value. Do only as an isolated, test-backed commit ifhelpers.pybecomes a maintenance drag.
Так где же тогда работают все топовые программисты? В Linux Foundation?
В своем стремлении пнуть погромистов, вы уже дошли до клоунады.
В коммерческой компании не погромист решает, что будет в продукте. Хоть он трижды ТОПОВЫЙ. Он или кодит, как скажут, или идет лесом. Если идет лесом - берут нового, и он кодит, как скажут. Если дядя с деньгами решил, что Яндекс GO это комбайн всего на свете - значит это комбайн всего на свете. И ТОПОВЫЙ Вася Пупкин и Claude Code будут кодить комбайн всего на свете. Всё ещё сложная мысль?
В коммерческой компании не погромист решает, что будет в продукте. Хоть он трижды ТОПОВЫЙ. Он или кодит, как скажут, или идет лесом.
Опять хороших программистов заставляют писать говнокод! Заставляют либы по 4 раза включать, заставляют какие-то тормозные циклы вхерачивать на холодный запуск, чтобы оно еле включалось - все явно в ТЗ прописано сеньором, который писал под диктовку от заказчика. Ну и у кого тут клоунада?
Ну и у кого тут клоунада?
У вас. Вы видели исходники Яндекс GO, чтобы утверждать что-то про их либы и циклы?
Ну просто напишите в Яндекс, чтобы больше вайбкодили, а всех ТОПОВЫХ уволили. Делов-то.
Нет, я только производительность вижу. У меня винда на ПК быстрее грузится, чем у них приложение для заказа такси и жрачки.
Это либо саботаж, либо кривые руки. ТЗ такого не было.
Тут все понятно, но продукту уже 10 лет. Может пару раз лизнуть его надо было за это время?
Вот представьте, я — единоличный владелец этого продукта, а вы — новый программист в команде. Вы увидели продукт и предлагаете его "лизнуть". Вместо того, чтобы добавить фичу. Я спрошу вас, на сколько больше денег продукт начнёт приносить, если его "лизнуть". Если вы честный человек, вы скажете, что-то типа: "не на сколько, но нам будет приятнее с ним работать. А ещё нас похвалят три программиста с хабра." Я, как тоже честный человек, скажу вам: "мы все тут не для приятности, и не для похвал, а для того, чтобы делать деньги инвесторам."
Ми таки слышим звуки ваших слов, но и ви включите ушибленную калькулятором извилину.
Рефакторинг - это не вопрос красоты. Рефакторинг устраивается с целью. Цель - сделать так, чтобы в репозитории было удобно работать агентам, потому что когда агенту удобно - скорость внедрения фич и качество этого внедрения возрастает кратно, что прямо отражается на довольстве инвестора.
Есть рефакторинг - есть агентская разработка. Нет рефакторинга - нет агентской разработки.
Теперь можно доставать калькулятор
Цель - сделать так, чтобы в репозитории было удобно работать агентам, потому что когда агенту удобно - скорость внедрения фич и качество этого внедрения возрастает кратно
То есть, на простой вопрос: "сколько мы на этом заработаем?" ответа нет.
Допустим, мне не нужно увеличивать скорость внедрения фич, потому что бизнес работает хорошо при текущей скорости. Все при деле, все счастливы. Вы же предлагаете всё переделать, внедрить каких-то дорогих агентов, потратить кучу бабла с непрогнозируемым результатом.
Я спрошу вас, на сколько больше денег продукт начнёт приносить, если его "лизнуть".
Извечная проблема краткосрочной vs. долгосрочной перспективы.
У Вас есть два варианта на выбор, условно:
Вариант 1:
— В этом году потратить на вайбкоженье 100 убитых енотов, заработать 1000 и порадоваться;
— В следующем году на добавление фич и исправление вязанных с ними багов потратить 200 и заработать 1000;
— Через 2 года потратить 400 и заработать 1000;
— Через 3 года потратить 800 и заработать 1000;
— Понять, что долго так жить нельзя.
Вариант 2:
— В этом году заплатить человеку-архитектору 600 убитых енотов, заработать 800 и поплакать;
— В следующем году на добавление фич и поддержку 200 и заработать 1000;
— Через 2 года потратить 200 и заработать 1000;
— Через 3 года потратить 200 и заработать 1000
— ну и т.д.
(Все числа вымышленные, совпадения с реальными чисто случайные.)
Дак г̶о̶в̶н̶о̶к̶о̶д̶и̶н̶г̶ вайбкодинг был и до ллм, не все программисты - вайбкодеры, есть нормальные ребята-натуралы.
А ещё эти самые 'настоящие разработчики ' хер поделятся своим опытом и тебе при незнакомой технологии тупо приходится идти в qwen и почитать выжимку что об этом знает человечество
Проблема таких приложений в огромном количестве SDK для аналитики, рекламы и трекинга, которые требует бизнес. Разработчики просто реализуют спущенное сверху ТЗ
Когда в XIX веке появилась фотография художники придумали импрессинизм. А что сделают кодеры оказавшись в такой же ситуации? Начните уже резать себе уши, иначе вам хана, это очевидно.
У нас один из клиентов навайбкодил с помощью верстальщика(!) систему и внес смуту в голову другому клиенту, который теперь стал придираться к цене любых задач.
Система как раз вводится в эксплуатацию, поэтому наблюдаем в прямом эфире чистый эксперимент. Если не забуду, то через год напишу, как у них проходит полет.
Вот! Как раз написал статью о своем эксперименте с вайбкодингом! Спойлер: выводы неутешительные...
Хз, конечно, как остальные, но я пришел в профессию из-за любви к этому делу. Мне по душе это ремесло. Мне нравится собирать из маленьких кирпичиков большую систему, создавать эти же самые кирпичики, смотреть на их работу и получать даже эстетическое удовлетворение от взгляда на код на экране.
Я делаю это уже 8 лет. Да, иногда у меня подкашиваются ноги от усталости. Иногда эта усталость физическая, иногда психологическая. Иногда хочется выбросить комп в окно от всего это. Но это проходит и я опять полон сил, продолжаю писать код.
И как только меня заставят писать ллмками, я просто уйду. Это не потому, что моё дело обесценили или еще как-то обидели. Нет. Это потому, что я люблю своё ремесло. Если меня захотят лишить этого ремесла, что ж, так тому и быть, но я не стану делать то, от чего меня тошнит. Я не хочу превратиться из ремесленника, в обезьяну "уга-уга-сделай-мне-приложение".
Если кто-то считает себя музыкантом, делая промпт в суно, если кто-то считает себя художником, обращаясь к еще какому-то там генератору, если кто-то считает себя программистом, обложившись неронками, ребят, вы себя-то хоть не обманывайте.
Согласен! Я не пользуюсь ИИ, потому что мне интересно писать программы, но еще и потому, что я им не доверяю. И моя статья вчерашняя как раз об этом. Но я не понимаю, как могут ЗАСТАВИТЬ ими пользоваться?
Некоторые конторы по слухам вводят KPI по использованию нейросеток.
И как только меня заставят писать ллмками, я просто уйду.
Почему? Нет ценности писать очередную простейшую конструкцию, которые ЛЛМ щелкают, как орешки. Пишите то, на что у ллм не хватает фантазии или ума, и используйте ллм для всего простого, вроде тестов.
Вон там в соседнем топике парсинг джоса в десятки раз ускоряют. ЛЛМ так еще долго не смогут.
Разве это вайбкодеры называют себя супер-программистами? IMHO у них как раз самообмана нет. Они - вайбкодеры.
Я прекрасно понимаю, что может нравиться работать пилой, рубанком и т.п. (сам такой). Но убей не понимаю, почему "пользуешься торцовкой вместо теплой ламповой ручной пилы - фуу, не обманывай себя..."
Нравится вручную пилой каждую досочку подгонять - ОК. Но хорошей торцовкой вы достигнете результата быстрее. Потеряете фан? Да. Но итоговый результат вряд ли будет хуже (если потренируетесь, привыкнете к новому инструменту и не будете специально вредить).
Другое дело, что торцовка в руках неумехи ни разу не гарантирует супер-результат на выходе. Но что-то мне подсказывает, что он будет таки лучше, чем тот же неумеха вручную напилит.
Если вас интересует не результат, а исключительно процесс (фан) - это другой вопрос. "Мне нравится делать самому, не хочу бездушный инструментов" не означает "инструмент плохой".
Для меня также является фаном скормить в obra:superpowers/brainstorm документ с описанием, что я подготовил, и выявить дополнительные узкие места. Я такое воспринимаю как помощь, а не как обиду "будет еще тупая железка меня уму-разуму учить".
IMHO LLM в руках профессионала облегчает и ускоряет его работу. LLM в руках ламера тоже улучшит результат, убережет от явных глупостей, хотя и не сделает синьором. Это инструмент, весьма полезный, если уметь им пользоваться. Но не волшебная кнопка "сделай мне хорошо, сам я думать не хочу".
Если менеджеры этого не понимают и считают "ламер + LLM = дешевый синьор" - это про менеджера, а не про LLM. Собственно в этом треде уже много на менеджеров вылили :)
Да ладно, все это нудеж пустой. ЛЛМки сейчас на том же уровне, что первые самолеты и автомобили. То есть летающие тряпичные этажерки и чадящие самобеглые коляски.
Ну и как это выглядит сейчас? Да даже Форд-Т появился всего через 25 лет после авто Бенца, а когда появились первые ЛЛМ?
Вот когда было сгенерен этот шедевр? И сравнить с нынешними. Оно ведь теперь правильно рисует пальцы рук, да?
"Пять причин, по которым автомобили никогда не вытеснят лошадей"
3. Автомобили опасны. Онѣ ѣдутъ сами по себѣ: тамъ, гдѣ лошадь остановится или перешагнетъ упавшаго человѣка, автомобиль безъ колебаній собъетъ и задавитъ несчастнаго. Шоферъ же въ такомъ случаѣ только разведетъ руками: "Моей вины тутъ нѣтъ, автомобиль ѣхалъ самъ".
Оно ведь теперь правильно рисует пальцы рук, да?
Не всегда :)
Первые нейросети-“этажерки” ещё в 20м веке появились. Т.е. мы сейчас как раз на уровне Форда-Т (тот ещё автомобильный “франкенштейн” с переключением передач ногами!) и автомобилей 20х. Но чтобы развиваться дальше - нужна энергия, причём экспоненциально. У автомобилей это решалось массовой нефтеразведкой и освоением большого количества “лёгких” месторождений, которые тогда ещё были.
А вот где взять энергию для датацентров и чипов для датацентров и энергию для производства чипов для датацентров и т.п.?
Маск, вон, предлагает - в космос …
Многие топовые программисты уверяют что уже больше года весь код за них пишут агенты.
Я не топовый и не программист, у меня проектик на питоне, в контекст джемини(1млн токенов то есть >3млн символов) он давно не помещается, весь код за меня уже давно пишет джемини, приходится загружать по частям и он отлично в нем ориентируется, лучше, глубже, намного быстрее меня. И это не специализированный агент для кодинга, а обычный чат в аи студио, и даже модель не топовая в своей линейке, из инструментов у него есть только гугл поиск и прием текстовых файлов.
Иногда джемини делает глупые и опасные ошибки, но кто их не делает?
Ничего, скоро корпорации всё же затащат всех в концепцию “все ваши данные в облаке” (следующий логичный шаг - что токены по сети гонять туда-сюда?) - и программировыать (точнее “программировать”) - станет ещё легче и ещё проще (объективно, кстати). Вообще о контекстах и строках думать не придётся!
Многие топовые программисты уверяют что уже больше года весь код за них пишут агенты.
«Ну и вы говорите...» ©
Топовые инженеры используют агентов для написания регулярных выражений или базовых тестов, чтобы сэкономить время. Архитектурные решения и сложные интеграции все еще остаются за человеком
Но если твою работу может полностью заменить обертка над API чат-гпт, то скорее всего твоя работа с самого начала не стоила тех денег, что тебе платили
ЛЛМки сейчас на том же уровне, что первые самолеты и автомобили
Чем, концептуально, отличаются современные авто и самолеты от самых первых? Ничем. То есть по вышей логике, ничего не измениться, просто станет удобнее и дороже. А если посмотреть на этапы развития автомобиле и авиастроения, то получится что обе отрасли в глубокой стагнации, а все ноухау были в начале и середине развития отраслей.
Чем концептуально пещерный человек отличается от современного айтишника? Концептуально - ничем! Просто стало дороже. )
Дак я и не спорю) Еще чуть чуть и снова будем издавать звуки, вместо членораздельной речи
Да как бы почти уже там
Чем, концептуально, отличаются современные авто и самолеты от самых первых
Примерно всем. Другой двигатель, другая подвеска, другая система управления, другие скорости, другая грузоподъёмность. Общего только то, что на первых были двигатель, 4 колеса и диваны, и сейчас они есть.
когда появились первые ЛЛМ?Вот когда было сгенерен этот шедевр?
Простите за занудство, но БЯМы не генерят картинок. Это делают с помощью диффузионных нейронок.
Все верно и очевидно каждому разумному человеку.
Но, к сожалению, такие увещевания и объяснения бесполезны, если имеешь дело с определенным типом людей. Они непробиваемые, только время и нервы потеряешь.
Единственное, что остается - это отойти в сторону и тупо ждать, когда эти все люди сами воочию увидят все проблемы. Иного пути нет.
Народ начал вдупляться...это радует. Но говнокодить, конечно же, никто не перестанет.
Они просто создают для нас рабочие места
Ловлю флешбэки при ремонте тачки, когда надо было отремонтировать то, что было недавно отремонтированно. Короче, куда ты денешся с подводной лодки, если все вокруг вайбкодеры)
Меня сейчас самого удивило, что хотя скриншот был вроде бы как приколом, но ссылка — это уже не прикол, а реально продаваемый конторой сервис!
Моя подруга преподаёт в юридическом институте. Студент сдал ей курсовик, в котором она обнаружила ссылку на свою же работу, которую она НЕ ПИСАЛА. Но ссылка оформлена по всем правилам.
В целом есть несколько замечаний:
"нейронка становится все лучше и лучше," - согласен, но нужно уточнение - "лучше" это в чем?
поддерживаемое развитие систем разработки идет не "монолитно", а "микросервисно" с целью снижения сложности. Если мы пишем такие "реальные коммерческие системы имеют такую сложность, что она не умещается ни в головы целой команды разработчиков, не помещается в сотни статей кофлюенса", то чем мы отличается от нейронок?
«исправь баг, что мне пользователи голову имеют» - это вчерашний подход, поскольку контур обратной связи должен быть замкнут изначально при разработке проекта и никаких "лишних" посредников которым нужно писать промт быть не должно.
Завтрашний подход это функциональная система (забавно, но все эти HARNESS, AI агенты и т.п. это постепенное приближение к ней).
В целом ключевое слово для разработчика, менеджера и т.п. на сегодня - адаптация. Да, сегодня вчерашние знания и подходы еще работают, да сегодня нейронка тупит и "не заменяет" разработчиков технологий, но уже заменяет разработчиков кода.
Вы пишете, что везде ИИ, а порог критического мышления снижается. Ок.
Но дальше вы пишете про вопросы индустрии, которые "уже тысячу раз обсуждались", ссылаетесь на статью (предположительно прочитанную вами) по одному из тех самых вопросов и просите ИИ расшифровать вместо вас простую схему оттуда? Какой-то несостыковки тут не видите?
Да Gemini еще и плохо расшифровал, нет там "кривой сложности, улетающей в космос" - это либо другая схема, либо просто придумано.
Читаю не могу понять о чем спор. Раньше считали на счетах, и когда появились первые биг машины, бухгалтеры все еще считали на счетах потому, что так быстрее и понятней, и потом на много позже начали считать на ПК. То что сейчас только до 1 млн токенов это не говорит что потом их не станет 10 млрд. Спор не о чем. Индустрия развивается, ИИ уже находит дыры которым по 20 лет и профессиональные бухгалтеры их не видели, и это нормально. Но то что код обесценивается это точно, на низкоуровневом программировании ИИ уже делает всех оптимизируя драйвера и ускоряя их в 3-10 раз и быстрее в сотни раз ,чем это сделают люди. Ломай копья в другую сторону лучше.
потом на много позже начали считать на ПК
Ну вы почитайте историю получше, там говорят, что нейросевое хрючево еще в 50-60-х появилось, дальше были экспертные системы, потом явился ПэКа и все про ии резко забыли, так как ПэКа намного дешевле. Есть подозрение, что мы в один момент не туда повернули, сейчас опять чет не туда идем, точнее в тупик.
Но то что код обесценивается это точно, на низкоуровневом программировании ИИ уже делает всех оптимизируя драйвера и ускоряя их в 3-10 раз и быстрее в сотни раз ,чем это сделают люди
То то, я смотрю, все вокруг вдруг резко стало лучше, быстрее и стабильнее работать, при этом снижая нагрузку на железо и расход электроэнергии, также все это очень легко поддерживать.
оптимизируя драйвера и ускоряя их в 3-10 раз
Где такое увидеть?
ПРи чем тут счеты, калькулятор и нейронка? Счет, калькулятор и нейронка не думают за тебя, не делают за тебя работу. Они упрощают атомарную операцию умножения. Это всегда детерменировано. НЕйронка же за тебя пишет логику. Ты перестаёшь даже вникать, че там происходит. Ты ж сказал нейронке, чтобы она написала фичу, она и написала. Рассказал, какие тесты нужно написать? Ну она и написала. Тесты проходят? Проходят. ОТлично. А что там за тесты, что там в коде, да какая разница. При всём при этом, попроси ее сделать эту же задачу завтра, она сделает ее совершенно по-другому. Но вы продолжайте. Делайте всё в сотни раз быстрее.
Правильно ли я вас понял, что программисты пишут код детерминировано?
Попросил одного - он написал. Попросил другого - он написал в точности так же (ну может разве что переменные по другому назвал).
Ты перестаёшь даже вникать, че там происходит
А это на любителя. Некоторые умудряются со стековерфлоу куски кода тупо копировать не понимая, что они делают. Тест проходит - отлично.
ШОК! Молотком можно не только забивать гвозди, но и отбивать пальцы! /s
Эволюция все расставит на свои места. Первые самолеты были дендрофекальные, реально из бытовых стройматериалов и на честном слове. Кто-то разбивался, кто-то выживал, и эти Михалычи-кустари положили начало вполне себе нормальной авиационной отрасли. Автомобили начинались так же. Атомная отрась вообще с колдовских практик начиналась, когда радий в конфеты добавляли... Так и здесь - вайбкодеры без понимания матчасти какое-то время будут кодить неэффективное дерьмо, их бизнес медленно начнет разрушатся, будучи раздавлен теми, кто использует ИИ разумно, с пониманием дела, эффективно. К КИ говноделов не допускают уже, а в бытовом сегменте пусть развлекаются сколько хотят - идет строительство новой отрасли, и эксперименты надо делать именно сейчас, чтобы понять допустимые границы технологий и области применения.
Пережили моду на нокод, зерокод и блокчейн - переживем и этот хайп с промпт-инженерами. Технологии меняются, а легаси остается вечным
Я бы не был так уверен, учитывая то, с какой скоростью нейронки разбирают легаси
Проблема в обьеме этого легаси. У нас вот один проект почти 500 метров чистых исходников на java, огромный монолитище. Там куча бизнесовой логики, которая не описана нигде, куча флагов в базе типа is_order, is_ordered, _ordered, которые имеют при почти одинаковом названии полярно разную функциональность - ну исторически так сложилось. Это и рады бы сплавить железному болвану, но нет, пока только кожаный может разгребать это. Плюс нужен локальный железный болван, чтобы его дообучить на своем гите и нормативной базе, но это отдельная мега-задача...
Главное, не пытаться разгребать это за один раз. Раздевайте его как луковицу. Маленькими слоями.
Раздевайте его как луковицу.
Ой, наплачетесь...
Это нудно, но не более.
У меня весьма богатый опыт пересборки легаси кода агентами. С тех пор, как мне дали в руки агентов, мну распилил уже столько годобжектов, что перестал испытывать перед ними какой-либо трепет.
Сдаётся мне, никогда Вы не раздевали луковицу. Особенно российскую, а не американскую, которые с пониженным содержанием сульфинилпропана.
Главное, не пытаться разгребать это за один раз
Что делать в случае, когда для принятия архитектурных решений нужен анализ 20.000 строк возможно связанного кода и минимальный MR 2000 строк? Но если делать минимальными MR, то вам понадобятся ещё адаптеры на +50% кода.
флагов в базе типа is_order, is_ordered, _ordered, которые имеют при почти одинаковом названии полярно разную функциональность
В пределах одного ограниченного контекста должен быть только один уникальный и понятный бизнес термин.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как же залюбил меня вайбкодинг и вот почему