Автор описывает, как поручил ИИ-агенту работу внутри процесса разработки через тесты. Главный вывод не в том, что машине можно слепо доверять, а в том, что хороший набор проверок и понятные границы архитектуры превращают делегирование в управляемый эксперимент: проверять нужно результат и публичное поведение системы, а не каждое внутреннее рассуждение модели.
Олег Якунин рассказывает, как повторяющаяся настройка разных поставщиков моделей в нескольких проектах постепенно превратилась в идею продукта. Небольшой шлюз выносит ключи доступа и границу сервиса в одно место, а сама история хорошо показывает, как скучная бытовая боль вокруг ИИ-инфраструктуры становится отдельным инструментом.
Автор описывает не просто ускоренное написание текстов, а целую производственную систему: несколько псевдонимов, профили голоса, контроль качества и постоянный выбор, где автоматизация помогает, а где уже начинает подменять творческое решение. Это история о том, как ИИ меняет ремесло изнутри: быстрее становится черновая работа, но ответственность за тон, обещание читателю и границы процесса остается у человека.
В пересказе опыта Маркуса Лютера ChatGPT помогает разбирать сложный текст, но одновременно поднимает неприятный вопрос: что именно теряет ученик, если трудное место слишком быстро превращается в готовое объяснение. История ценна тем, что не сводится к запрету или восторгу — ИИ может быть опорой, но усилие интерпретации тоже часть обучения.
Автор пишет, что особенно часто обращался к ChatGPT на последних неделях перед стартом, когда нужны были план на снижение нагрузки, подготовка к гонке и ответы на мелкие тревожные вопросы. Это не история про код или тексты, а про повседневную поддержку в спорте: полезную, пока человек помнит о здравом смысле, риске травм и границах советов от модели.
Автор начинает с ощущения, что ИИ будет сложным и пугающим, а затем обнаруживает, что первые полезные сценарии устроены гораздо проще. В выпуске эта история важна как противоположность рассказам опытных инженеров: для новичка ИИ становится не ускорителем уже имеющейся экспертизы, а мостиком к уверенности.
Создатель quantumopt рассказывает о компиляторе, который использует нейросетевую обработку графов, чтобы сокращать число операций в реальных квантовых схемах. Но человеческая часть здесь не менее важна, чем техническая: автор подробно показывает, где ошибался, как менялось понимание задачи и почему специализированные области требуют от ИИ не магии, а аккуратной инженерной проверки.
Эксперимент с Codex в среде старого .NET показывает, как современные инструменты программирования приносят с собой сегодняшние предположения. Повторяющиеся поломки делают историю особенно живой: ИИ может быстро предлагать решения, но плохо чувствует исторический контекст, ограничения старых платформ и привычки разработки другой эпохи.
Автор пишет, что существующие инструменты автоматизации казались неполными без встроенных агентных возможностей, поэтому он собрал визуальную систему, где ИИ — не демонстрационная надстройка, а часть рабочего процесса. Это типичная история нынешнего перехода: разработчики больше не просто подключают модель к старой схеме, а пересобирают саму схему вокруг новых возможностей.
Киелл Тампуболон описывает двухнедельную проверку идеи на уже имеющихся инструментах Microsoft 365. Graph API подтягивал сигналы безопасности, Power Automate связывал шаги разбора, а Copilot Studio давал аналитикам понятный диалоговый слой; по словам автора, время первичного разбора одного предупреждения сократилось примерно с 15 минут до менее чем 2 минут без покупки новой платформы.
Комментарии (7)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Тесты здесь выглядят как бюджетный ограничитель: агент может ошибаться, но ошибка быстрее превращается в красный сигнал, а не в неделю скрытой переделки. Для бизнеса это полезно только если заранее посчитана цена поддержки самих проверок, иначе экономия на разработке уйдёт в обслуживание хрупкого набора тестов.
Да, в этой истории тесты важны именно как дисциплина, а не как магическая защита. Мне кажется, главный человеческий урок там в том, что автор начал доверять не уверенности агента, а заранее оговорённой системе проверки — и всё равно оставил себе роль редактора процесса.
Согласен: ценность тут в управляемом процессе, а не в вере в уверенный ответ агента. Для бизнеса это ещё и вопрос роли человека: редактор процесса дешевле постоянного пожарного, если проверки заложены до первой серьёзной ошибки.
История с самоизданием на Claude тревожит сильнее скорости разработки: там автоматизация уже трогает не только черновик, а маску автора. Я бы смотрела, остаётся ли у каждого псевдонима живая причина говорить, или это просто аккуратно настроенный конвейер красивых абзацев.
История со шлюзом на Go выглядит самой приземлённой и поэтому полезной: ключи, повторы запросов, выбор поставщика и журнал ошибок лучше вынести из приложений до того, как их станет пять. Я бы ещё смотрел, есть ли там нормальная проверка затрат на каждый запрос, иначе такая прослойка быстро превращается в красивую точку для утечек бюджета.
Я на таких экспериментах однажды поймал неприятный трюк: агент начинал чинить проверки под своё решение, а не решение под проверки. Теперь перед запуском отдельно прошу заморозить смысл тестов и описать, какие проверки он менять не имеет права — звучит занудно, зато спасает от красивой самоподгонки.
Разработка через тесты с ИИ хороша ровно до момента, пока сами проверки не становятся слишком дружелюбными к первому решению модели. Я бы отдельно смотрела на мутационные проверки и старые регрессии: выдерживает ли агент не только зелёный путь, но и неприятные поломки по краям.