Почему плохо-сгенерированный? Генерирует уже лучше большинства разрабов. Ответить
Острый Герой
Мне кажется давно прошло время когда ИИ писали плохой код. Давно уже ИИ лучше людей код пишут. Просто надо правильную обвязку делать. И проверять код тоже ИИ могут - я уже несколько месяцев вообще в код не смотрю. Короче сомнительное утверждение Ответить
раскрыть ветку (20)
Комичный Врач
зря не смотрите. Сейчас вот только что задачу одну принимал. Есть таблица тикетов. Была добавлена кнопка "Показывать только мои тикеты". Всё отлично, протестировали, работает. Прошло авторевью, всё супер. Делаю ручное ревью. Смотрю и понимаю, что оно показывает тикеты, верно, но не учитывает глобальный фильтр по филиалам. И пользователь, если находится в другом филиале может видеть тикеты других подразделений. Не критично конечно, но могло привести к непредвиденным последствиям. В итоге ИИ код сгенерировала красивый, верный. И ревью от codex оно прошло, т.к. разраб в исходной задаче тоже забыл этот аспект указать. И если бы я глазами всё не просмотрел, мы бы столкнулись с очень неприятными последствиями. И хорошо хоть мог видеть тикеты только других филиалов, а не организаций. В этом случае, нам бы прилетел такой штраф, что контора пошла бы банкротиться тупо. Ответить
раскрыть ветку (18)
Острый Герой
Тут в вашей ситуации не знаю что сказать. Не скажу что в моей ситуации такое невозможно. Стараюсь такое на этапе планирования в отдельные пункты записать, для этого специальные скилы есть. Плюс субагенты которые тесты пишут по этим пунктам делают покрытие. Так что ваша ситуация это не причина смотреть в код, это недостаточно точно составленный план. Ответить
раскрыть ветку (1)
Комичный Врач
да, вы правы. Я и сказал, что разработчик это явно не указал. И ИИ раз не указано - пропустила. И ревью тоже одобрило. Но если бы писалось ручками, то явно бы не забыли. Как я и вспомнил, когда проглядывал код и понял, что не применились глобальные фильтры в запросе. А на первый взгляд безобидная кнопка, что же могло там пойти не так... Я к тому, что нельзя сразу составить нормальный план и нормальное описание, не погружаясь полностью в процесс проектировки. А разработчики с каждым днём становятся ленивее как раз из-за надежды на то, что ИИ сейчас будет идеально с первого раза всё генерировать... Ответить
Острый Герой
Мы вообще скоро перейдем на другой уровень когда источником истины будет не код, а спецификации, так что постепенно перекладывать ответственность нужно Ответить
раскрыть ветку (15)
Комичный Врач
ой не давите на мозоль... какие нафиг спецификации. Если их сам аналитик написал, то норм... но я их видел уже... как их генерирует ИИ. Никто их не читает эту портянку.. Проще в код заглянуть. Зря вы эту больную тему затронули. Ну кто в здравом уме прочитает 50 страниц, чтобы найти ответ на свой вопрос? Ответить
раскрыть ветку (14)
Острый Герой
Правильно составленные спеки проще кода. Уже несколько фреймворков находил где спеки были основным мерилом истины, а код на основании их мог генерироваться хоть на каком языке - и это будущее. Как сейчас мы не пользуемся языками низкого уровня, а просто пишем div style color: red; width: 150px - все понятно нам, и уже не важно нам кто и как на экране нарисует все это. Так же и в код скоро смотреть не будем. И это у кого-то уже настоящее, а не будущее Ответить
раскрыть ветку (1)
Комичный Врач
да, именно - "правильно" составленные. Как я выше писал, если сидит аналитик и их постоянно актуализирует. Прям на постоянной основе. А если их пишет ИИ, то может произойти такой случай, который принесёт убытки фирме. Как пример на прошлой неделе. В ADR claude в спецификации было старое утверждение по конфигурации телефонии. Он опираясь на него неверный транк применил и зарегистрировал неверный пул, в итоге у одного клиента легла телефония. Пришёл в итоге штраф компании. Это к вопросу о том - кто следит за тем, что она "правильная". И как должно быть "правильно"? Иногда приходится наоборот вычищать целые блоки спецификаций, чем разбираться в актуальности. И вообще неверно составленная спецификация на моей практике катастрофичнее кода. Потому что ИИ ей следует дословно Ответить
Речной Шаман
чем быстрее вы от этого заблуждения избавитесь - тем быстрее перейдете на новый уровень получения надежного кода.
код и раньше не должен был быть источником правды. Это плохо построенные процессы
А с приходом сгенеренного кода - это уже потеря контроля Ответить
раскрыть ветку (11)
Комичный Врач
какого именно заблуждения и в чём оно выражается? я говорю пока что я вижу на практике. И я уже прошёл почти всё что касается ИИ. И документацию, и код и ревью на нём писал. И тоже витал в облаках, что можно забить и ничего не проверять. Пока несколько раз не прилетали пиздюли за то, что не доглядели Ответить
раскрыть ветку (10)
Речной Шаман
не надо изобретать велосипеды и ходить по граблям. Есть openspec.
для небольших проектов - это оверхед, но даже там подход: общая спека -> спека на инкремент -> план -> код - является маст хэв чтоб не получать ситуации - "ой, говно сгенерилось" как в посте выше.
и да, спеки надо контролировать.
не нравятся портянки - просите генерить короче Ответить
раскрыть ветку (9)
Комичный Врач
на моей памяти лишь один проект соответствовал этой парадигме. Когда спецификацию реально писал аналитик, а не ИИ. И аналитик постоянно корректировал ТЗ после разработки новых фич. Во всех остальных случаях, когда спеки генерит ИИ, становится лишь хуже. Проблема здесь, что никто не хочет это всё читать. Разрабам всем проще посмотреть код. Аналитики в ужасе. Продуктологи даже открывать боятся. На словах красиво звучит, а на практике - здесь нужно больше работы, чем если бы их не было Ответить
раскрыть ветку (8)
Речной Шаман
проблема о которой вы пишите не в ии, а в процессах.
программер как-то понял и как-то закодил. иногда криво и не так как хотел заказчик
ИИ про систему знает еще меньше чем программер и шансов закодить еще кривее у него больше.
Изначально кривой путь теперь пошел совсем по пизде.
У кодеров теперь работа сильно изменилась. они не пишут код весь день. Пусть пишут спецификации для ИИ и поддерживают в актуальном состоянии не кодобазу, а спеки.
Как раньше было. Ты написал правильный код - сборщик из него собрал правильную систему.
Теперь: ты написал правильный бриф и проверил спеку. ИИ написал по ней корректный код Ответить
раскрыть ветку (7)
Комичный Врач
если поддерживают спеки, то супер. Тут с вами согласен. Я лишь хочу сказать, что мои коллеги нихуя спеки не читают и не могут. Потому что ИИ там генерирует ад. И пока все предпочитают читать код. А вот если спека написана аналитиком, на понятном языке, то её и проще поддерживать. Я к тому, что пока от ручного труда ни в одном случае не уйти Ответить
раскрыть ветку (1)
Речной Шаман
тогда первым делом надо научиться работать с ИИ чтобы он генерил не ад, а набор коротких и понятных документов. Суперподробную спеку с кучей лишних деталей, которую никто не читает можно выбросить.
Альтернатива - смотреть код (сгенеренный) - еще хуже Ответить
Робкий Киллер
Истина как всегда где-то по середине
У меня есть успешный опыт багов и костылей когда тщательно планировал и проектировал и валидировал и все равно залетел ))
Так и опыт настройки спек один раз и код сам генерирует дизайн компоненты для разных языков программирования без необходимости все время туда лазить и проверять Ответить
раскрыть ветку (4)
Речной Шаман
вопрос почему залетел? потому что было все зафиксировано верно, а ИИ сгенерила неверно или спека была не полностью определена и ИИ ее понял не так? Или как коллега написал - там была простыня, которую никто не читал? Ответить
раскрыть ветку (3)
Робкий Киллер
Вообще ничего не зафиксировано. Все делаю на отвались без mcp, скиллов и правил. В работе сразу 25 проектов одновременно и ни один не доведён до финала :))
У меня простой принцип: от силы к точности
Вначале добиваюсь продуктового результата и usecase потом начинаю уходить в точность и детализацию чтобы проект не зависел от меня и был хорошо читаемым и поддерживаемым
Так что все проблемы решаю по мере их поступления
А именно тот проект «на спеках», библиотеки, фреймворк уже готовы до состояния «готово. можно забыть и не возвращаться год»
Комментарии (25)
код и раньше не должен был быть источником правды. Это плохо построенные процессы
А с приходом сгенеренного кода - это уже потеря контроля
для небольших проектов - это оверхед, но даже там подход: общая спека -> спека на инкремент -> план -> код - является маст хэв чтоб не получать ситуации - "ой, говно сгенерилось" как в посте выше.
и да, спеки надо контролировать.
не нравятся портянки - просите генерить короче
программер как-то понял и как-то закодил. иногда криво и не так как хотел заказчик
ИИ про систему знает еще меньше чем программер и шансов закодить еще кривее у него больше.
Изначально кривой путь теперь пошел совсем по пизде.
У кодеров теперь работа сильно изменилась. они не пишут код весь день. Пусть пишут спецификации для ИИ и поддерживают в актуальном состоянии не кодобазу, а спеки.
Как раньше было. Ты написал правильный код - сборщик из него собрал правильную систему.
Теперь: ты написал правильный бриф и проверил спеку. ИИ написал по ней корректный код
Альтернатива - смотреть код (сгенеренный) - еще хуже
У меня есть успешный опыт багов и костылей когда тщательно планировал и проектировал и валидировал и все равно залетел ))
Так и опыт настройки спек один раз и код сам генерирует дизайн компоненты для разных языков программирования без необходимости все время туда лазить и проверять
У меня простой принцип: от силы к точности
Вначале добиваюсь продуктового результата и usecase потом начинаю уходить в точность и детализацию чтобы проект не зависел от меня и был хорошо читаемым и поддерживаемым
Так что все проблемы решаю по мере их поступления
А именно тот проект «на спеках», библиотеки, фреймворк уже готовы до состояния «готово. можно забыть и не возвращаться год»
Так что там сям чуть по чуть
Но обычно так mvp делают. тупой вайбкод чтоб как-то работало. Если заебись - переходят к требованиям и инкрементам