Профессиональный скептицизм разработчика снова вышел из разряда «приятно иметь» в базовую инженерную гигиену: 25 сентября Stack Overflow Blog посвятил этому выпуск подкаста с Дэвидом Бёрнсом из BrowserStack. Для русскоязычных команд, которые уже впускают ИИ-агентов в код, тесты и CI, тезис звучит просто: доверяй инструменту, но проверяй состояние приложения, предположения и результат.
В выпуске ведущий Ryan поговорил с David Burns, Head of Developer Advocacy and Open Source в BrowserStack, сообщает Stack Overflow Blog. BrowserStack известна как платформа для тестирования ПО, а Бёрнс в разговоре связывает три темы, которые сейчас болезненно знакомы многим разработчикам: ценность инженерного сомнения, применение test-driven development к agentic engineering и борьбу с flaky-тестами через управление состоянием приложения.
Главная мысль не в том, что ИИ плох или хорош. Она скучнее и полезнее: чем больше автоматизации появляется между разработчиком и продакшеном, тем дороже обходится привычка принимать вывод инструмента за истину. Автодополнение может предложить рабочий на вид код, агент может быстро собрать тесты, CI может то падать, то зеленеть без видимой причины. Но ответственность за систему всё равно остаётся у команды, а не у модели, браузерной фермы или пайплайна.
Профессиональный скептицизм в этом контексте — не токсичное «я никому не верю» и не вечное торможение релизов. Это рабочая привычка задавать неудобные вопросы до того, как баг станет инцидентом: какое состояние было у приложения перед тестом, что именно проверяет ассерт, не зависит ли сценарий от порядка запуска, не спряталась ли ошибка за ретраем, не принял ли агент желаемое поведение за фактическое. Для разработчика это такая же часть ремесла, как читать diff перед merge, а не просто радоваться зелёной галочке.
Отдельная линия разговора — test-driven development в мире agentic engineering. Если раньше TDD часто обсуждали как дисциплину для человека, который сначала формулирует ожидаемое поведение, а потом пишет реализацию, то с ИИ-агентами вопрос становится ещё острее. Агенту нужно давать не только задачу, но и проверяемую рамку: какие тесты должны подтвердить результат, какие регрессии недопустимы, какие состояния системы считаются валидными. Иначе он будет оптимизировать не качество, а убедительность ответа.
Для бизнеса это звучит менее романтично, чем презентации про рост скорости разработки, зато ближе к реальности. ИИ может ускорить написание кода, но ускорение без проверок быстро превращается в технический долг с красивым интерфейсом. Если команда не умеет формулировать ожидания в тестах, изолировать состояние и разбирать нестабильные падения, агентная разработка лишь увеличит шум. Больше pull request, больше автосгенерированных правок, больше уверенных объяснений — и всё та же старая проблема: никто не понимает, почему тест упал только в среду и только во втором раннере.
Flaky-тесты в обсуждении названы не просто раздражающим дефектом CI, а симптомом плохо управляемого состояния. Это важная практическая рамка. Нестабильный тест редко лечится одной магической паузой или увеличением таймаута. Чаще приходится разбирать, какие данные остались после предыдущего сценария, как инициализируется окружение, есть ли гонки, зависит ли тест от внешнего сервиса, времени, кэша или порядка выполнения. Чем больше в цепочке автоматизации ИИ, тем важнее, чтобы эти границы были описаны явно.
Для российских и русскоязычных IT-команд тема попадает в нерв 2026 года: многие уже пробуют ИИ-ассистентов в IDE, генерацию тестов, код-ревью с подсказками и агентные сценарии для задач вокруг репозитория. Но зрелость процесса всё ещё измеряется не числом подключённых инструментов, а тем, может ли команда объяснить, почему конкретный релиз безопасен. Профессиональный скептицизм здесь работает как страховка от «модель сказала, значит нормально» — фразы, которую лучше не слышать ни от джуна, ни от лида.
Есть и культурный слой. Скепсис часто путают с недоверием к коллегам или саботажем инициатив. В инженерной команде он должен быть устроен иначе: сомневаться не в человеке, а в предположении; проверять не авторитет, а поведение системы. Тогда ревью, тесты и постмортемы перестают быть ритуалами наказания и становятся способом удерживать сложность под контролем. Это особенно важно в командах, где ИИ уже пишет часть кода быстрее, чем люди успевают договориться о критериях качества.
Следующий этап агентной разработки, похоже, будет не про то, кто подключил больше моделей к репозиторию. Он будет про команды, которые научатся превращать сомнение в инфраструктуру: тесты, воспроизводимые окружения, наблюдаемость, понятные критерии готовности и честные разборы нестабильности. И если профессиональный скептицизм станет таким же привычным навыком, как работа с Git, ИИ-инструменты наконец будут усиливать инженеров, а не просто быстрее размножать их ошибки.