Шесть месяцев без ручного кода: как я перестал писать код и научил агентов работать параллельно
Six Months of Writing Code Exclusively with Agents
Инженер из exe.dev рассказывает, как он шесть месяцев писал код исключительно с помощью AI-агентов. Он описывает эволюцию от Copilot до Claude Code и создания собственного инструмента botd для управления десятками агентов в изолированных Linux VM. Главные выводы: агенты ускоряют работу, но требуют нового подхода к ревью и ответственности. Автор делится опытом настройки параллельной разработки, решения проблем с конфликтами и безопасности, а также признаёт, что не всё, что работает, стоит включать в продукт.
Инструменты могли сказать мне, что изменение работает. Они не могли сказать, стоит ли его добавлять в систему.
- greenowl
Я какое-то время полностью придерживался агентного подхода. Никакого ручного кода! Если отбросить «способности» инструментов, я понял, что это неправильное направление, уже через пару месяцев. Я особенно запомнил, как во время реализации крупной фичи у меня закончились токены на моё 5-часовое окно или что-то в этом роде, и я просто не мог продолжать сам. В основном из-за лени (подожду до завтра, когда лимит сбросится!), но я также уловил первый большой намёк на зарождающуюся деградацию навыков / атрофию, и это вызвало у меня дискомфорт. Я просто не вижу, чтобы этот полностью агентный подход хорошо работал в долгосрочной перспективе. Говорите об ultimate зависимости!! Если свет «погаснет» по какой-либо причине — сбои, рост цен, или агентная скорость наконец достигнет точки бифуркации сложности, и вы потеряете контроль и понимание своей системы до такой степени, что агенты будут делать только хуже, что бы это ни было — вы действительно ожидаете, что сможете повернуть время вспять и начать кодить на том уровне продуктивности и с тем результатом, что были раньше, когда вы... писали код?
- lostnfound8778
> Самой большой затратой был набор текста. Каждый раз, когда я хотел что-то создать, я видел код у себя в голове. Просто не мог печатать достаточно быстро. Факт. Для меня чем больше был разрыв между тем, что я видел в голове, и скоростью, с которой мои пальцы могли физически воплотить это в реальность, тем больше стресса я испытывал, и некоторые марафонские сессии кодинга заканчивались тем, что спина была вся перекошена просто от напряжения.
- thisisauserid
А до LLM он бы за обедом набросал bash-скрипт на двадцать строк и cron-задачу, и потратил бы шесть месяцев на что-то другое.
- redlewel
Как люди читают такие посты с этим AI-флёром? Я не смог прочитать больше пары предложений.
- mrothroc
Несколько комментариев здесь затрагивают основную проблему: агенты пишут больше кода, чем мы можем проверить. У сеньоров никогда не было достаточно времени на ревью, а плодовитый вывод от кодинг-агентов делает только хуже. Более того, код почти всегда хорош. Так что ты просматриваешь цунами довольно хорошего кода, что приводит к усталости от ревью, и всё это превращается в театр. Для меня это означает, что проверки должны быть чем-то большим, чем просто «я посмотрел». Есть две вещи, которые происходят до того, как я вообще это увижу: во-первых, как уже упоминали другие, у меня есть модель из другого семейства, которая просматривает код с чётко определёнными критериями. Ревьюеры из одного семейства имеют общие предубеждения, поэтому должна быть другая модель. Во-вторых, у меня есть базовый набор детерминированных гейтов (например, линтер, но также и юнит-тесты), которые должны выполняться. В любом случае, неудачи отправляются обратно кодинг-агенту. И только потом я утруждаюсь. Но я действительно не читаю всё. Если это стандартные CRUD-операции, агенты в этом довольно хороши, особенно если они используют зрелые пакеты. Я сосредотачиваюсь на критических вещах, например, на том, как код обеспечивает права доступа. Это хорошо работает для меня, хотя остаётся один главный вопрос: стоит ли это вообще строить. Агенты, как правило, слишком рьяны, поэтому мне приходится много работать заранее, чтобы убедиться, что результат принесёт пользу. Гейты могут проверить только артефакт, но не моё намерение.
- iamflimflam1
Писать код с LLM требует дисциплины и сложно. Нужно научиться это делать и извлекать из этого максимум. Инженерия ПО мертва, да здравствует инженерия ПО!
- rich_sasha
Я испытываю странный диссонанс от всех этих рассказов. У меня есть доступ к топовым моделям через Cursor на работе. Каждый раз я думаю: вот скучная, но чётко определённая задача с ясными критериями успеха, где можно добиться многого упорными итерациями. Я поручу её Клоду. Во-первых, мне требуется вечность, чтобы правильно описать задачу. Все эти ясные критерии успеха — вместо того чтобы писать код по чёткому ТЗ в голове, я пишу кучу прозы и пытаюсь сделать её однозначной. Я программирую на English++. Но затем, один раз из пяти, он выдаёт что-то, что вроде работает. Может, не идеально, но достаточно хорошо. Два раза из пяти это вроде как выглядит нормально, но на самом деле игнорирует 80% спецификации или отделывается минимальной имитацией в комментариях. А иногда, может, чуть меньше, чем в 2/5 случаев, он просто полностью скатывается в полное дерьмо. Начинает писать скрипты, которые загружают AST главного скрипта, пиклят его, а затем сериализуют в base64 без всякой причины. Кодируют что-то в строках, а затем проверяют ord(string[i]) повторно для сравнения строк. В конце концов заканчивается контекст, и у него развивается LLM-эквивалент тяжёлой деменции. Я совершенно не могу согласовать свой опыт с людьми, которые, кажется, говорят «эй, компьютер, напиши это», и это хорошее использование их времени.
- phildenhoff
Обидно видеть, что в целом хорошую статью разбавили AI-штампами («Но вот в чём поворот: тот поиск, о котором я говорил ранее, никогда не был отправлен в botd. Вся история была в SQLite, поэтому я направил на неё другого агента и всё равно получил анализ. Инструмент умер; данные — нет», среди прочих примеров). Мэйсем Али пишет о том, что они не перестали заниматься инженерией, несмотря на передачу производства кода ИИ. Я думаю, это интересная перспектива по ряду причин, но прежде всего, я не уверен, что согласен. Во-первых, мы видим яркий пример того, как это может взорваться. «botd умер в этом месяце. Он рухнул под собственным весом». Трудно представить, как агентская обвязка (или это оверлей поверх других обвязок?) может рухнуть под собственным весом из-за чисто технической сложности. Что заставляет такой инструмент «рухнуть»? Если он правильно спроектирован, кажется, что любое внешнее изменение можно адаптировать. Падающие тесты можно починить. Эта эволюция ИИ-кодинга дала нам возможность создавать прототипы, внутреннее устройство которых мы не понимаем, но я считаю, что для всего ценного (и, как я бы сказал, botd, судя по всему, имел ценность для Мэйсема) мы должны, по крайней мере, понимать и влиять на архитектуру и инженерию того, что мы строим. Если бы Мэйсем сделал это для botd, тот бы не «рухнул под собственным весом» и не _мог бы_ рухнуть. Любое внешнее влияние, требующее изменений внутри botd, было бы управляемым. Во-вторых, передача производства этой статьи на аутсорсинг указывает на м […]