Comments 36
Самое неприятное - я этот код одобрил не потому, что разобрался.
А давайте введём для вайб-кодеров материальную ответственность? Утвердил кривой код из-за которого возник ущерб - отвечай.
Так она и так есть по факту - замержил, значит твоё. Проблема в другом, когда CI зелёный и покрытие 91%, ты реально думаешь что разобрался. Я вот думал. А потом webhook лёг и оказалось что нет
Так она и так есть по факту - замержил, значит твоё.
Материальная ответственность есть?
У вас есть ложное убеждение, что покрытие 100% дает 100% надежность кода. Максимум, что оно может гарантировать, что код не в 100% случаев взрывается(runtime error), всё. Еще раз, не в 100% случаев - означает, что есть как минимум один кейс, когда он не взорвётся, об остальных кейсах ничего неизвестно. Вам бы по хорошему как-то осознать опыт:
Пописать код без тестов
Задолбаться делать фиксы на код без тестов, после того как задачу вам возвращают тестировщики или вылезают баги на проде
Вы начинаете сами вручную тестировать код
Понимаете, что задолбались тестировать каждый раз этот набор кейсов, плюс постоянно что-то забываете, опять приходится делать фиксы
Думаете как бы это автоматизировать - начинаете писать e2e тесты
Утонули во всех этих тестах, логика написания не прослеживается, рефакторинг вызывает миллион правок в тестах.
Изучаете что такое пирамида тестирования, начинаете писать unit-тесты, а также приходит понимание как писать гибкий и масштабируемый код, который легко протестировать.
P.S. Как будто бы по-моему посту можно понять, почему между вайбкодингом и качественным программированием пропасть.
Согласен с Вами. Внесу только небольшое дополнение.
Тесты помогаю, только тогда, когда они красные. Если обнаружен новый баг, которые не выявили тесты, то сначала пишется тест для выявление этого бага, тест красный. Затем фиксим баг, пока тест не станет зелёным. Это в идеальном случае, конечно.
Так в этом и главная проблема вайбкодеров - они не понимают, как должно быть, а ИИ пока не волшебная пилюля, а удобный инструмент. Я настроил себе Opencode с субагентами, с критиком, с оркестрацией, и на выходе получаю очень качественные и систематизированные тесты, но их сначала надо валидировать. И тогда вся пирамида начинает работать, потому что если тест что-то проверяет на реальном коде - это уже лучше, чем без теста, а если он проверяет много - то это отлично.
А если в ручную код писал и не работает, то уважительная причина!🤣
П.С. Так то ответственность тестировщики несут, если тестировщиков нет, то жизнь такая.
П.П.С. Если баг в виде отказа на 10 000 случаев из за которого ничего непоправимого не произошло. То вообще не сильно, то и проблема.
Ну так в статье про это и речь)) тесты были, CI зелёный, покрытие 91%. Тестировщик бы тоже пропустил, потому что кейс с дублем вебхука ни в одном тест-плане не был. Это знание из инцидентов, а не из спеки
Ну по идее, тестировщик бы знал про дубли и написал бы соотвествующий тест
Тест был но кривой, вернее было покрытие тестами 100% но тесты как всегда ничего не проверяли
AI не знает, что платёжка иногда присылает дубли. Я это знаю, потому что чинил это в два часа ночи в ноябре. AI не знает - и тест не проверяет.
Если вы знаете и чинили, то где тесты которые это покрывают? Если тестов нет- значит у вас про покрытие а не про тестирование функционала
Справедливо. Знание про дубли было у меня в голове, а не в тест-сьюте. Починил в ноябре - тест не написал, “и так помню”. Через полгода Claude генерит новый обработчик без этого знания, покрытие 91%, всё зелёное. Вот в этом и штука - покрытие считает строки, а доменное знание которое живёт только у тебя в голове в метриках не отражается. Хоть с AI, хоть без
а давайте не будем с больной головы на здоровую. если в компании внедряют "вайб программирование" что бы фигачить быстрее и больше - это политика компании а не разраба и дело тут в процессах. от такой логики как ваша и так половина мира страдает - это из разряда что в магазинах на продавцов недостачи товара вешают. жадность капиталистов не знает границ.
ИМХО при работе в тандеме с ИИ важно помнить две вещи. 1). Агент - идиот. Знает больше тебя, но клинический дибил. 2) Агент - читер. Он тебя обязятельно попытается на***ть. Ну и опционально, для моделей вроде OSS - агент убеждён, что знает лучше тебя, что тебе нужно.
А у этого текста автор есть? Или, в свою очередь, только нажиматель кнопки «публиковать»?
баг на проде. Webhook от платёжки возвращал 500 на определённой комбинации параметров
Доверять ИИ написание кода, ответственного за обработку платежей - это надо быть больным на голову человеком.
То-ли ещё будет. Ждём, когда автопилот самолёта будет кодить ИИ, управление реактором АЭС будет писать ИИ, код медицинского оборудования начнёт писать ИИ.
Ирония в том что AI-код хотя бы все подозревают и ревьюят. А код который сеньор написал три года назад мержат не глядя, потому что “ну он же знает”. Вопрос где больше сюрпризов в проде
ИИ - это не синьёр даже близко, и не мидл тоже. Он пишет код как джун и постоянно вытворяет лютую дичь. Над ним надо стоять с палкой и постоянно его заставлять делать по нормальному а не через *опу.
Никто в здравом уме не посадит джуна писать приём платежей (если конечно объём платежей критичен для компании).
Доверять ИИ написание кода, ответственного за обработку платежей - это надо быть больным на голову человеком.
Имхо, если в принципе возможно, что кто-то в платежах написал код, который уронит платежи (не важно, сеньор, ИИ, скайнет или кто-либо еще) и его вмержили и ничего не сломалось - то это косяк не ИИ, а косяк доступов и процессов релиза, ИМХО.
Ну и когда касается платежей и денег в целом - все должно быть покрыто тремя слоями тестов на каждый чих, косяк интерфейса люди еще относительно терпят, а вот лишние списания очень сильно злят.
Вопрос не в том кто код написал, а в том кто его проверяет
Баги в платежках писали и живые люди с 15-летним стажем
Доверять ИИ написание кода, ответственного за обработку платежей - это надо быть больным на голову человеком.
То-ли ещё будет. Ждём, когда автопилот самолёта будет кодить ИИ,
Здесь проблема не в том, кто/что писал/писало код, а в том, что на входе не было чёткой спеки и граничных условий. В таких условиях любой программист, получивший столь расплывчатое задание, мог бы написать то же самое. ИИ, пишущий автопилот самолёта -- не проблема, если задача грамотно декомпозирована и спека полна, потому что потом можно проверить соответствие. В предельном случае -- доказать математически, что сгенерированный ИИ код ей соответствует.
А потому, что он выглядел нормально. Тесты прошли. Линтер не ругался. Я решил, что этого достаточно. Не было.
этого никогда не было достаточно, ни в доИИшную эпоху, ни в ИИшную. И в постИИшную тоже так будет
LLM это поисковый движок. Необычный, да, но поисковый.
Если вы используете его для поиска и получения информации, объяснения, то он будет полезен для ваших навыков.
Если вы используете его для создания чего-то, что не сможете повторить самостоятельно, не понимаю дотошно что создано и как работает, то он будет вреден или бесполезен для ваших навыков.
Подходит ли это для вашего проекта (программист вы или нейрослоппер, как пример), решать вам.
Исследование Anthropic из статьи это подтверждает цифрами - кто использует как объяснялку, понимает на 65-86%. Кто как генератор - ниже 40%. Граница ровно там где вы её провели
Поисковиком все таки не назовешь. Поисковик индексирует факты, а LLM синтезирует вероятности, отсюда и галлюцинации, которых в классическом поиске просто не может быть
Поиск может быть как синтаксический, так и семантический, или комбо. В идеале поисковик не искажает, но всё же будь то человек, например, библиотекарь, который приносит не ту книгу, или Google, который выдаёт не ту ссылку или быстрый ответ, перепутав суть, ошибки есть. Вы привели вариант синтаксического, но даже просто склонение слова уже может изменить выдачу на ошибочную или избыточную и потребуется и семантический поиск.
Если тенденция сохранится, через пять лет на рынке появятся вакансии ии-археолога, который будет за огромные деньги раскапывать логику монолита, сгенерированного нейросетями предыдущего поколения)
Внутри payments.md - то, что Claude не может знать из кода: «Webhook от платёжки может прийти дважды - идемпотентность обязательна.» «Таймаут 30 секунд, fallback на повторную проверку.» «Ответ 200 только если заказ найден.»
А почему эту информацию нужно размещать в .claude/, а не непосредственно в коде, в комментариях? Это же часть контракта эндпоинта, такая же, как типы параметров и их допустимые значения.
Комментарии гниют - код меняется, комментарий остаётся. Uncle Bob про это целую главу написал в Clean Code. Контракт эндпоинта надёжнее жить в тесте который сломается если контракт нарушен, а не в строчке которую никто не обновит. А .claude/rules/ это не комментарий, это constraint на входе - комментарий говорит “тут должна быть идемпотентность”, а правило делает так что Claude сгенерит с идемпотентностью сразу, до того как ты увидишь код
Контракту эндпоинта надёжнее жить в тесте
Однако, не все контракты в принципе возможно подпереть тестом, а иные требуют для этого слишком много усилий или тестовой инфраструктуры. Как вы поступали с такими контрактами до появления Claude Code, вообще нигде их не фиксировали?
не в строчке, которую никто не обновит
А кто обновит строчку в .claude/rules, если контракт поменяется?
Uncle Bob про это целую главу написал
Ну написал и написал. Однако, емнип, смысл там бы не “комментарии и документация — это зло, потому что могут устареть”, а немного сложней:
комментировать нужно только то, что нельзя понять из кода,
комментарии должны находиться как можно ближе к тому коду, к которому они относятся, чтобы.
Как будто бы прям наш случай.
А
.claude/rules/это не комментарий
Точно такой же комментарий, если только у вас не в принципе запрещено лезть в код руками, без клодкода.
Меня очень удивляет, что люди с таким энтузиазмом носятся со всякими AGENTS.md, но в то же время не желают документировать всё то же самое для людей. Почему бы всему этому добру не лежать в docs/guidelines.md, docs/architecture/payments.md и т.д.? Или же прям рядом с исходниками: src/payments/CONTRACTS.md?
TDD через плагин Superpowers. Есть плагин Superpowers, который заставляет Claude работать по TDD-циклу: сначала пишет один тест, запускает - убеждается что красный, потом пишет минимальную реализацию, снова запускает - зелёный. Следующий тест. По одному. Если Claude пытается написать код до теста - плагин буквально удаляет его и заставляет начать с теста. Жёстко, но работает. Тест-тавтология исчезает, потому что тест пишется до реализации и проверяет намерение, а не обратную совместимость AI-кода с самим собой. И вот что я не ожидал: наблюдая red→green в терминале, я получаю уверенность без чтения каждой строки. Тест был красным. Стал зелёным. Claude его не менял. Значит, реализация соответствует спеке.
Не понял, какая уверенность? Откуда? Почему вы думаете, что данный подход при использовании ИИ действительно работает именно так?
Из текста следует, что заменили шило на мыло.
Изначально проблема была в том, что разработчик не был уверен в том, что тесты покрывают все критически важные моменты которые следуют из бизнес требований. Из чего в данном тексте следует, что пришедшие от бизнеса требования полностью проанализированы и из них выведены все необходимые и достаточные функциональные требования к системе?
Выглядит так, что вы заменили одну тест-тавтологию на целую группу тест-тавтологий.
Как был какой-то беззубый фетишизм в анализе готового кода так он никуда и не делся.
И тут щёлкнуло: comprehension debt существовал задолго до AI. Просто раньше мы писали мало и медленно, и не замечали. AI увеличил объём - и долг стал виден. Половина моего легаси - тоже код без автора. Автор был. Он забыл.
Всегда замечали. Эта проблема еще в середине 70 встала, когда начали писать большие программные системы. И на протяжении всего времени эту проблему всегда держали в голове. Наличие такой проблемы в разработке - это один из классических признаков производства говнокода.
Меня вообще поражает как сейчас с большими глазами "открывают" то, что уже по 100 раз открыто переоткрыто и давным-давно находится в фокусе.
Код без автора