Claude Code у ваших кодеров — это еще не автоматизация разработки
Прикинь: в команду взяли бодрого мидла. Трекер ему не открыли, базу знаний не показали, а про архитектурные решения рассказали один раз — на онбординге, и все. Дальше его изредка дергают: «погугли вон то». Иногда подкидывают мелкую фичу — в полном отрыве от общей картины. А потом прилетает за то, что он не въехал ни в таску, ни в то, как у вас тут все заведено. Вот примерно так я и вижу внедрение нейронок в разработку.
Дальше — про грабли, которые вылезают при вкатывании агентской разработки в процессы, и неважно, сколько у вас людей и какого размера контора. Плюс про то, что я наработал сам и подсмотрел у других за годы парного программирования с компьютерами.
Как тестировать API с 202 Accepted и не пропускать сбои фоновой обработки
Прилетел 202, автотест зелёный, все выдохнули. А через несколько дней выясняется: часть операций так и не дошла до успешного финала. Знакомо? Причина банальная — ты смотришь только на ответ HTTP-обработчика, а вся асинхронная цепочка при этом висит без контроля.
Ниже — как собрать нормальный тест для API с polling: старт операции, проверка статуса, валидация финального результата и аккуратный повторный запрос.
Тестирование API: 20 проверок, которые обязан уметь каждый QA
Чаще всего «тестирование API» — это кинуть запрос и порадоваться, что прилетело 200. На собесе такой подход живёт минуты две. А вот на проде вылезает то, чего код ответа в упор не видит: в ответе чужой заказ, вместо ошибки валидации — тихий 500, товар со склада так и не списался.
Дальше — 20 базовых проверок. Именно они отделяют того, кто реально тестит API, от того, кто просто дёргает ручки: успешный ответ, входные данные, ошибки, доступ и состояние системы. И всё это на одном сквозном сценарии, с примерами на curl и в Postman.
Новичок соберёт себе порядок действий, опытный — сверится и поймёт, куда расширять набор тестов.
Completion gate для локальных моделей: как отделить завершённый ответ от оценки качества
Три маршрута выполнили по десять сценариев из десяти, но выбирать модель по этой таблице рано. Completion gate отделяет целый артефакт, который вообще можно оценивать, от проверки качества и человеческой приёмки.
Можно ли поймать breaking change REST API до интеграционных тестов?
Breaking change в REST API часто обнаруживают слишком поздно — уже на интеграционном стенде. Разберём, какие риски можно поймать раньше, где помогают OpenAPI и consumer contracts и почему зелёные проверки ещё не гарантируют совместимость со старым клиентом.