Обновить

Комментарии 20

Resolved! )

Просто надо вычитать с зарплаты разработчика за каждое ревью его говно кода. Прямая почасовая оплата за ревью. А за инцидент на проде штрафовать. Это и будет ответственность

Ну, если такое случилось, тогда надо наказывать ревьювера и тестовый отдел за то, что они это пропустили.

А так обычно тестовый отдел дает обратную связь, что какие-то программисты выдают какую-то фигню и их задачи постоянно переоткрывают. Вот такие инциденты надо разбирать, и если программист не меняется, увольнять!

Тем более в эпоху ИИ-агентов программистов, которые могут вызвать ИИ-агента, сами прокликать то, что он сделал, и еще своими глазами просмотреть код коммита, пруд пруди...

Всегда так было. Если разработчик делает ерунду и не исправляется после пары указываний пальцем где именно он ерунду сделал и что надо делать по другому то его надо увольнять.

Сейчас таких просто больше стало.

Отличный набор принципов здорового инженера. Независимо от того, работает он с AI или нет. Уважение, очень правильно все описали !

Спасибо - новая реальность - новые подходы - но главные принципы не измены )

Главное правило - понимать код который ты пушишь в репозиторий. Не понимаешь - мучай аишку пока она тебе не разжуёт.

Появился тикет. Программист копирует ссылку, передает ее AI-кодинг-агенту и через какое-то время получает готовый Pull Request.

это не программист, а лишняя прослойка между агентом и создателем тикета

AI любит быстрые решения.

AI обычно пишет код так, будто база пустая

попросить AI добавить тесты

Подобное лечится правильным system prompt.

За код отвечает программист

Аминь.

А еще принцип "Готово - значит проверено".

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

Агенты часто, наоборот, пишут код, который должен быть обратно совместим, с различными миграциями и т.п. У меня в агентских инструкциях написано "don't maintain backwards compatibility" - так будет меньше визуального мусора и прочего техдолга.

В какой реальности вы все жили? Кто же вам сказал, что тесты всегда впереди. Вы ещё скажите, что ООП единственный жизнепригодный паттерн, а раст и питон единственные нормальные языки

TDD - не панацея. Зеленый тест != рабочий код

Ничего не понятно, но интересно

Как AI-кодинг-агенты используются в вашей команде?

Никак. А если и будут, то без меня.

Да. AI кодинг скорее менеджмент. То есть к умению писать код, добавляется ещё куча навыков обычно у разработчику несвойственных. Человек часто выбирает путь разработчика, сознательно отклоняет карьерные возможности в менеджменте. Тут вдруг вот такой вызов, когда эти навыки обязательны, а их человек сознательно избегал. С другой стороны идея менеджмента заменить людей на AI это как в столярке накупить кучу станков и удалить столяра. Возникает необходимость пересрбирать все (я про команды и управление проектами), а к этому ни готовности ни понимания.

Я не верю. Просто не верю. Я думал, что с Хабра ушли все авторы, мнение которых отличается от «грузи в агента, жми мерж, собирай профит»

Хорошая статья. Вполне понятные и обоснованные правила

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

Очень базовые вещи конечно, но и их нужно расписать иногда, спасибо.

Я говорю в подобных случаях про[махнувши]мся коллегам: зачем ты вообще нужен если тикет и так может улететь клоду на автомате, а потом сразу тестировщику? Неужели не боишься что только тестировщики и останутся, если можно так работать?

К сожалению, одним манифестом дело не наладить. Дисциплина хорошо, но нужны и внешние рамки. Соблазн отдать всё боту очень велик, ведь мы все в айти именно потому, что мы любим, чтобы машина делала за нас работу, правда?

У меня готового решения нет: кволити гейты и ревью лидом с последующей раздачей тем, кто решил побыть курьером у бота. Но это нелегко для лида и скорость убавляет. Как по-другому не знаю.

Я сделал себе скилл для работы со сложными задачами через pr loop, сначала вместе с агентом бьем задачу на шаги, потом он выполняет строго по одному шагу и делает pr на шаг, я отсматриваю эти небольшие pr и общаюсь с агентом через комментарии в них, когда шаги заканчиваются тестирую и отсматриваю финальный pr уже сам и отправляю на ревью. Состояние этого процесса разработки хранится в файле прямо в репозитории. Впринципе получается достаточно быстро перемалывать таски такой штукой. https://github.com/betine/dev-partner-skill

Только мне кажется что это не манифест, а скорее правила, может даже что то вроде best practics?

Рано. До бестпрактисов дожить надо. Пока все еще непонятно и изменчиво.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации