Аё>Попробуй пусть клод напишет, по мотивам тестов например. Потом можно попросить его написать код по спеке, но запретить изменять тесты.

Оно так работает только на маленьких изолированных репозиториях, а не на многогигабайтных монолитах.

Здравствуйте, SkyDance, Вы писали:

SD>Оно так работает только на маленьких изолированных репозиториях, а не на многогигабайтных монолитах.

а вы пробовали писать тесты при помощи AI ? если да, AI написал что то нормальное

Аё>Если провести аналогию с начатым 25 лет назад трендом TDD- типа главное покрыть тестами, тогда риск проблем от легиона говнокодеров можно свести к минимуму.

можно оффтоп по этой теме?..

наблюдал в одном крупном проекте, где было в соглашении с заказчиком условие, что код должен быть полностью покрыт юнит-тестами
при этом TDD не применялось, а тесты писались в основном на готовый код, чтобы просто во все ветки выполнения тесты заходили
зачастую по сути они ничего не проверяли, а лишь фиксировали имеющуюся реализацию

и я всё недоумевал что это за дичь, похожая на каргокульт
вопрос про это поднимал, но у одного меня было маловато веса чтобы это ниспровергнуть (а все остальные аморфно-инертно или даже склонялись к имевшейся политике)
мне говорили что это норм, что раз не TDD, то покрытие тестами должно быть такое
я говорил что тесты должны проверять правильность поведения в значимых use-case'ах, а не прибивать программу к текущей реализации гвоздями unit-testов


поясните правильную ситуацию...

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>я говорил что тесты должны проверять правильность поведения в значимых use-case'ах, а не прибивать программу к текущей реализации гвоздями unit-testов
МПИ>поясните правильную ситуацию...

по ходу не налетал ты на последствия "безобидного" изменения в коде

Здравствуйте, Артём, Вы писали:

Аё>Т.е. подписка на клод стоимостью как 1-2 программиста, 1 понимающий в промптах жнец и на дуде игрец, заменяюший бизнес аналиста, monkey-tester-а, и 5 программистов уровня "5 лет опыта в C++".

Аё>Можно с таким утверждением согласиться?

Нельзя конечно, зачем такая дорогая подписка? Да, крутой синьор с хорошей ИИ заменяет плохого БА, немного снимает нагрузку с тестера и делает фич как 5 программистов. О чем это говорит? О росте производительности труда программиста, которая со времен перфокарт идет постоянно. Если раньше добавить внутренний чат между пользователями в систему стоило от 1.5 миллионов рублей, то сейчас, 200-300к.

Аё>Я на прош неделе свёл (в Teams) прогера и техлида с внутренним заказчиком из др продукта. Они что-то там долго перетирали, что не так. По итогу, Teams сгенерил транскрипт, я затолкал этот транскрипт клоду в глотку, тот высрал требования для тикета по исправлению недочётов. На митингн во время звонка я утратил нить и скучал, однако клод за меня что-то высрал.

Манагерам вообще лафа, раньше надо было морщить лоб и пытаться понимать, что происходит, сейчас транскрипты встреч засунул и делай отчеты и задачи с помощью промптов.

Аё>Так вот, накой member опыт написания кода, если с должным навыком постановки задачи LLM, можно отдать ей работу педалить говнокод? Куда девать ммллионы кодеров в мире?

Отдать-то можно, что потом делать с этим говнокодом, который не работает как надо?

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>мне говорили что это норм, что раз не TDD, то покрытие тестами должно быть такое

А какое должно быть покрытие тестами, если это не TDD?

Здравствуйте, Ziaw, Вы писали:

Z>Манагерам вообще лафа, раньше надо было морщить лоб и пытаться понимать, что происходит, сейчас транскрипты встреч засунул и делай отчеты и задачи с помощью промптов.

теперь понятно почему последнии полгода мне дают задачи
слова вроде бы знакомые а смысл ускользает и менеджер не может объяснить что она имела ввиду (уже созналась что за нее пишет AI)

Здравствуйте, SkyDance, Вы писали:


SD>Оно так работает только на маленьких изолированных репозиториях, а не на многогигабайтных монолитах.

Нужно давать узкую конкретную задачу, и контролировать. Если попросить "сделай мне круто", оно нагенерит ai-slop бессмысленных изменений с дебильными комментами, которое будет "красиво, но не собирается".

Здравствуйте, sergey2b, Вы писали:

S>слова вроде бы знакомые а смысл ускользает и менеджер не может объяснить что она имела ввиду (уже созналась что за нее пишет AI)

Можно попросить llm объяснить смысл витиеватого развесистого слопа. Проблема реально имеет место с нагенерёнными требованиями без смысла. Раеьше так политики отвечали на вопрос- много букав, ноль ответа.

Здравствуйте, sergey2b, Вы писали:

S>теперь понятно почему последнии полгода мне дают задачи
S>слова вроде бы знакомые а смысл ускользает и менеджер не может объяснить что она имела ввиду (уже созналась что за нее пишет AI)

Ну да, она же сама тебе сказала. Поди еще и указала, что ты должен понимать что к чему если профессионал.

МПИ>>мне говорили что это норм, что раз не TDD, то покрытие тестами должно быть такое

Z>А какое должно быть покрытие тестами, если это не TDD?

я и спрашиваю

просто в таком виде как там было оно контрпродуктивно


в другом вот проекте требовались исключительно семантически значимые функциональные тесты
даже если они не покрывали все use-case'ы, а только часть, то от этой части есть заведомая польза
вот так правильно, я щетаю

МПИ>>я говорил что тесты должны проверять правильность поведения в значимых use-case'ах, а не прибивать программу к текущей реализации гвоздями unit-testов
МПИ>>поясните правильную ситуацию...

_>по ходу не налетал ты на последствия "безобидного" изменения в коде

я налетал на разные интересные последствия рукожопия, но видимо не на это

что имеется в виду?
полагаю что юнит тесты мало спасут — в том проекте после "безобидного изменения"
просто постфактум, чтобы коммит прошёл, сделают соответствующие правки в тестах и всё...

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>при этом TDD не применялось, а тесты писались в основном на готовый код, чтобы просто во все ветки выполнения тесты заходили
МПИ>зачастую по сути они ничего не проверяли, а лишь фиксировали имеющуюся реализацию

МПИ>я говорил что тесты должны проверять правильность поведения в значимых use-case'ах, а не прибивать программу к текущей реализации гвоздями unit-testов

Непонятно. Что-то же такие тесты проверяли? Или они всегда success, а смотрим на %% покрытия кода?

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>я и спрашиваю

Без понимания всех деталей сложно что-то советовать.

МПИ>просто в таком виде как там было оно контрпродуктивно

Кроме продуктивности есть целевая метрика, которую требует заказчик. Нужно покрыть все строки кода.

МПИ>в другом вот проекте требовались исключительно семантически значимые функциональные тесты
МПИ>даже если они не покрывали все use-case'ы, а только часть, то от этой части есть заведомая польза
МПИ>вот так правильно, я щетаю

Иногда достаточно покрывать несколько десятков топ сценариев интерфейсной автоматизацией и ловить ошибки на qa/юзерах в остальных.

МПИ>>при этом TDD не применялось, а тесты писались в основном на готовый код, чтобы просто во все ветки выполнения тесты заходили
МПИ>>зачастую по сути они ничего не проверяли, а лишь фиксировали имеющуюся реализацию

МПИ>>я говорил что тесты должны проверять правильность поведения в значимых use-case'ах, а не прибивать программу к текущей реализации гвоздями unit-testов

AA>Непонятно. Что-то же такие тесты проверяли? Или они всегда success, а смотрим на %% покрытия кода?

по большому счёту тесты проверяли что вот такой-то if нужен путём конфигурирования моками условий захода в него

тесты были бы не success если бы этот if был инвертирован или убран

процент покрытия проверялся автоматизированно (не запушить если меньше 95%)

Уже появилась новая профессия
Это крутые программисты с металическими бубенцами

https://youtube.com/shorts/nIJHqv8Kvqo?si=iDdZGTxcih0Owr-F

S>а вы пробовали писать тесты при помощи AI ? если да, AI написал что то нормальное

Да, вполне, — если задание выдать (и уточнять по мере необходимости), пишет на достаточном уровне. Иногда приходится разбираться, почему что-то сделано слегка иначе, чем принято, или упрощать написанный код. Примерно как за джуниором.

Здравствуйте, Министр Промышленности из Minecraft'а, Вы писали:

МПИ>что имеется в виду?
МПИ>полагаю что юнит тесты мало спасут — в том проекте после "безобидного изменения"
МПИ>просто постфактум, чтобы коммит прошёл, сделают соответствующие правки в тестах и всё...

был случай после которого я проникся уважением к юнит-тестам. давно правда это было... короче один метод был оптимизирован для скорости. только вот тот кто оптимизировал не знал всех деталей и метод работал корректно только для под множества входных данных (там был то пяток другой возможных значений). юнит тестов не было, ревью не было (давно это было). в общем поймали это наши QA товарищи перед самым релизом.

Здравствуйте, Ziaw, Вы писали:

Z>Ну да, она же сама тебе сказала. Поди еще и указала, что ты должен понимать что к чему если профессионал.

Это классическая проблема эпохи «ИИ-менеджмента» — галлюцинации или «корпоративный бред», сгенерированный ChatGPT или аналогичными моделями. Менеджер, не владеющий контекстом, становится просто «ретранслятором» красивого, но пустого текста.Ваша реакция абсолютно понятна. Вот план действий, как спастись от «Скайнета» и начать работать:

1. Как читать такие задачи (Алгоритм «Дешифратор»)Не пытайтесь понять весь текст целиком. ИИ любит лить воду.Ищите существительные и глаголы: Игнорируйте эпитеты («оптимизированный», «инновационный», «синергетический»).Ищите сущности: Какие объекты (базы данных, экраны, функции) упоминаются?Ищите действия: Что нужно сделать? (Создать, удалить, перенести, рассчитать).
2. Как «пытать» менеджера (Правильные вопросы)Если менеджер не может объяснить, вы должны задавать вопросы, которые заставят ИИ (и менеджера) вернуться к реальности:«Какой желаемый результат?» (Что должно измениться в системе после выполнения задачи?)«Как проверить, что задача выполнена?» (Критерии приемки — Acceptence Criteria).«Где примеры данных/экранов?»«Это MVP или технический долг?»
3. Ответный удар: используйте ИИ против ИИЕсли задача непонятна, скопируйте её в ChatGPT/Claude и напишите промпт:«Действуй как опытный IT-аналитик. Переведи этот текст на простой технический язык, убери корпоративную воду и напиши список конкретных задач для разработчика: [ВСТАВИТЬ ЗАДАЧУ]».
4. Сара Коннор стиль: «Нет ТЗ — нет задачи»Если менеджер продолжает присылать бред:Пишете в задачу: «Задача непонятна. Ожидаю конкретизации по критериям приемки».Ставите статус «Blocked» (Заблокировано).Не берете в работу, пока не будет описано, что именно нужно сделать.Итог: ИИ — хороший помощник, но плохой начальник. Менеджер обязан фильтровать то, что генерирует модель. Если он этого не делает — вы рискуете делать «не то, не знаю что».Присоединяюсь к вашему приветствию — Сара Коннор знала, что делает! 🦾

Здравствуйте, Артём, Вы писали:

Аё>Если провести аналогию с начатым 25 лет назад трендом TDD- типа главное покрыть тестами, тогда риск проблем от легиона говнокодеров можно свести к минимуму. Счас можно то же самое сказать про spec-driven development?

А от говнокодеров это самое покрытие тестами спасало?

По-моему, покрытие тестами делает комфортнее внесение изменений в уже существующий код. Поскольку помогает обнаружить, если вдруг чего сломал, раньше, чем это произойдёт у пользователя или в руках другой команды, зависящей от этого кода.

А так, говнокод не начинает пахнуть розами, если покрыть его тестами. Скорее, он начинает пахнуть говнотестами

Аё>Так вот, накой member опыт написания кода, если с должным навыком постановки задачи LLM, можно отдать ей работу педалить говнокод?

А навык откуда берётся? А говнокод точно нужен?

Аё>Куда девать ммллионы кодеров в мире?

Послать в африку бананы выращивать.