Даниэль Лемир предложил «эфемерное тестирование» кода с помощью ИИ-агента
Даниэль Лемир в блоге от 5 октября 2026 года предлагает метод, который, по его словам, раньше был немыслим, «эфемерное тестирование». Слово «эфемерный» он поясняет как «одноразовый» или «временный».
Схема такая. Вы пишете код или программный компонент (или его пишет за вас ИИ-агент, автор считает, что это неважно). Затем просите ИИ-агента построить поверх него приложение, ещё один слой или даже несколько, и протестировать то, что он построил. Исходную работу напрямую вы не оцениваете: вы оцениваете, насколько хорошо работает программа, построенная на её основе.
Лемир называет это формой интеграционного тестирования, но с отличием: надстроенное ПО полностью одноразовое, по завершении его выбрасывают.
Главный довод автора: библиотека с чистым API, устойчивыми инвариантами и полезными сообщениями об ошибках позволяет агенту быстро получить работающий результат. Библиотека со скрытым состоянием, неожиданными значениями по умолчанию или неполной документацией порождает груду заплаток и сбоев. При этом, подчёркивает он, сбои, свидетельство о вашем коде, а не об агенте.
Тест можно повторять: другие агенты, другие задачи, тот же фундамент. По сути, вместо того чтобы строить ядро, пытаясь предугадать, что понадобится на других уровнях, вы имитируете эти уровни, реально их создавая.
Лемир предвидит возражение: с ИИ можно всё переписывать заново, когда нужно. Но, по его мнению, это непрактично, нужна некоторая стабильность.
Автор применяет приём в разных проектах: обдумывая новую функцию, просит своего ИИ быстро сделать прототип того, что потом, возможно, будет строить сам. По его словам, пока эфемерное тестирование у него работает. Других подтверждений, кроме личного опыта, в тексте нет; цифр и конкретных проектов или агентов автор не называет.
Ключевые факты
- Суть метода: ИИ-агент строит поверх вашего компонента одноразовое приложение или слой и сам его тестирует; оценивается качество этой надстройки, а не исходный код напрямую.
- Это форма интеграционного тестирования, где надстроенное ПО полностью одноразовое и выбрасывается после проверки.
- Чистый API, устойчивые инварианты и полезные ошибки позволяют агенту быстро получить рабочий результат; скрытое состояние, неожиданные значения по умолчанию и неполная документация дают груду заплаток и сбоев.
- Сбои в надстройке, свидетельство о коде под тестом, а не об агенте; проверку можно повторять с разными агентами и задачами.
- Автор применяет приём в разных проектах и пишет, что пока он работает; других доказательств в тексте нет.
Почему это важно
Лемир предлагает смотреть на качество библиотеки или компонента через то, насколько легко ИИ-агенту строить поверх них. Вместо попыток заранее угадать потребности других уровней их имитируют, реально создавая. Автор перечисляет привычные способы контроля качества, юнит-тесты, фаззинг, интеграционное тестирование, и предлагает ещё один метод.
Кому это важно
Разработчикам библиотек и программных компонентов, а также тем, кто проектирует API и документацию и уже работает с ИИ-агентами для написания кода.
Как это применить
По описанию автора: написать компонент (или поручить это агенту), затем попросить другого или того же агента построить поверх него приложение или несколько слоёв и протестировать результат. Если агент буксует, смотрите на API, инварианты, значения по умолчанию, сообщения об ошибках и документацию. Проверку можно повторять с другими агентами и задачами; построенное в итоге выбрасывают. Автор также использует приём при обдумывании новой функции: просит ИИ быстро сделать прототип того, что мог бы построить позже.
Можно ли доверять
Это короткая авторская заметка в блоге Даниэля Лемира. Единственное подтверждение, его слова «пока у меня работает». Измерений, цифр, названий проектов, библиотек, агентов или моделей в тексте нет, как и описания конкретных сбоев, найденных этим способом. Метод стоит воспринимать как идею, а не как проверенную практику.
Риски и подводные камни
Сам автор оговаривает, что перестраивать всё заново при каждой необходимости непрактично и нужна некоторая стабильность. Поскольку надстройка строится агентом, результат зависит и от выбора агента и задачи, поэтому автор советует повторять проверку с разными. Других ограничений в источнике не обсуждается.
«Исходную работу вы напрямую не оцениваете. Вы оцениваете, насколько хорошо работает программа, построенная поверх неё.»
— Даниэль Лемир