Agentic coding notes from Galapagos Island: когда ИИ врет, но это круто

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

Агент сделает то, за что вы бы немедленно уволили человека, а моя реакция — сделать вид, что это прекрасно, и запустить тысячу агентов, чтобы они делали еще больше такого же.
  1. duckmysick

    Хочу выделить другую часть статьи:

    > В целом, когда я говорю с программистами о тестировании, я исхожу из совершенно иной позиции, и они сразу смотрят на меня как на инопланетянина. Поэтому давайте обсудим, как мы тестировали в той аппаратной компании, где я работал — Centaur. Это сформировало мои взгляды на то, как мне нравится работать. Некоторые из наших практик, которые были или остаются нетрадиционными в мире софта:

    > — Найм专职 QA-инженеров, где тестирование стало полноценной карьерной траекторией, равноправной с разработкой.

    > — По умолчанию нет code review.

    > — Практически нет вручную написанных тестов.

    > — Постоянное тестирование через то, что программисты иногда называли property-based testing, рандомизированным тестированием, фаззингом и т.д., хотя мы просто называли это «тестами» (вручную написанные тесты назывались «hand tests»).

    > — Огромный набор регрессионных тестов (3 месяца в реальном времени на вычислительном кластере).

    > — Нет unit-тестов.

    Кто-нибудь из вас пробовал такой подход (или похожий)? Особенно полный переход на property-based testing и фаззинг без unit-тестов.

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

  2. bob1029

    Многие безумные идеи, похоже, растаяли перед лицом огромных размеров контекста. Сегодня я могу поместить в свой системный промпт примерно мегабайт текста в UTF-8, прежде чем начнутся странные вещи.

    Это огромное количество информации, даже если мы используем её небрежно. Можно прочитать «Хоббита» и первую книгу о Гарри Поттере от корки до корки и всё равно останется место. Мне было бы крайне сложно разработать такую детализированную модель мира для любого бизнеса. Всё, что требует большей специфичности, чем эти повествования, может быть реализовано через SQL-запросы к хранилищу данных, grep по кодовой базе, поиск через MS Graph API и т.д.

    Предоставление бизнесу сбалансированного способа совместной работы над этой единой моделью мира — это новый вызов, с которым я только начинаю сталкиваться. Я также заметил, что модель мира начинает накапливаться сама в себе в плане самодетекции возможностей обновления. Чем больше ограничений, тем вероятнее, что мы их нарушим.

  3. nasretdinov

    Я могу согласиться с Дэнном в двух вещах: LLM действительно часто выдают неверные результаты, и при умеренном использовании они всё ещё полезны для продуктивности. Для меня неверные результаты вызывают某种 реакцию в стиле ragebait, и я становлюсь гораздо более мотивированным, чтобы глубже изучить предмет и действительно получить правильный ответ. После того как я достаточно изучил область, я обнаруживаю, что лучше, чтобы LLM проверял мой код, а не писал его.

    Я даже не начал пытаться понять, как использовать фаззинг-тестирование для улучшения способности находить баги, но это звучит очень интересно. Я видел, что мутационное тестирование очень полезно для выявления пробелов в тестах, поэтому могу только представить, что фаззинг + LLM могут дать безумные результаты.

Ещё за этот день

2026-07-07