Автор поставил себе жёсткое правило: весь прикладной код для небольшого сервиса пишет AI, а человек только задаёт направление, проверяет и принимает решения. Быстрый старт действительно сработал: каркас, вход пользователей, оплата, панель управления и открытый API появились быстрее обычного. Но ценность истории в девяти записанных поломках: стало видно, что скорость генерации не отменяет архитектуру, проверку и человеческое суждение в тупиках.
Инженерный руководитель GoodBarber описал скучную, но очень живую проблему: за 14 лет накопились тысячи статей на семи языках, а надёжной карты переводов между ними не осталось. Команда использовала открытую модель на ноутбуке, чтобы сопоставлять краткие описания и восстановить связи между версиями. Это редкий пример AI без фейерверков: не новый продукт, а тяжёлая редакционная уборка, которую наконец удалось сделать.
Автор пытался заставить двух кодовых помощников работать над одной задачей и отказался от хрупкого копирования ответов из одного окна в другое. Вместо этого он дал каждому агенту отдельную личность, входящие сообщения и собственный механизм пробуждения. История хороша тем, что показывает: совместная работа агентов быстро становится похожа на распределённую систему, где важны состояние, очередь и момент, когда один участник занят.
Разработчик из среды AWS взял Kiro Crew и дал ему сценарий, похожий на рабочую аварию: рост задержек в инфраструктурном проекте. Это важнее обычной демонстрации, потому что такие задачи требуют не только написать код, но и понять симптомы, найти следы и предложить план действий. Человеческий вывод простой: агент полезен только тогда, когда выдерживает грязную реальность, а не идеальную инструкцию.
После двух месяцев разработки автор остановил добавление функций и просто проверил своего самоуправляемого помощника на трёх конкретных делах. Ценность рассказа именно в этой паузе: легко строить ещё одну возможность, сложнее признать, что система должна помогать в обычной работе уже сейчас. Такие дневники хорошо показывают разрыв между «агент существует» и «агент реально снимает задачу с человека».
Aman Ullah Khan описал Karl — локального помощника, который должен помнить контекст без постоянной отправки данных в облако и без отдельного слова-пробуждения. История цепляет не техникой распознавания речи, а бытовым вопросом доверия: когда помощник всегда рядом, где проходит граница между удобством и ощущением слежки. Автор делает ставку на локальную память как на основу опыта, а не на ещё одну командную строку.
Автор посмотрел на рабочие журналы шлюза для моделей: из 5087 запросов 622 не дали ответа. Главное в истории — разделение причин: нехватка мощности, неверный запрос, закрытое соединение, истечение времени ожидания и отсутствие средств на балансе ведут себя по-разному. Поэтому слепой повтор запроса не является надёжностью; иногда он только тратит деньги и прячет настоящую причину сбоя.
Команда строила многоагентную систему для клиентской поддержки и хотела использовать оценку уверенности модели как сигнал, когда передавать обращение человеку. Проверка на 662 размеченных сообщениях показала неприятное: даже высокие значения скрывали заметную долю ошибок. Это очень человеческая история про ложное чувство безопасности: число выглядит строгим, но без калибровки на реальных случаях оно может стать красивой декорацией.
Автор постоянно видел, как Claude и похожие инструменты по умолчанию подставляют американские правила в экспортные документы для Индии, Британии, Европы и ОАЭ. Вместо очередной жалобы он оформил набор правил для Claude Code: с местными налоговыми и таможенными идентификаторами, счетами и частыми ошибками. Это маленький, но полезный пример того, как повторяющаяся предвзятость AI превращается в прикладной предохранитель.
Основатель попросил AI-помощника автоматизировать технический маркетинг для нового продукта. Агент быстро ушёл в сценарии публикаций в X, но пропустил главный факт: у аккаунта было всего три подписчика, поэтому автоматизация почти ничего не усиливала. В этом и ценность истории: AI может бодро строить конвейер, не задав самый неудобный вопрос — есть ли там вообще аудитория.
Источник каждой истории указан в заголовке.
Комментарии (2)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Девять поломок — вот за это автору отдельное спасибо, без всякой старческой воркотни. Быстрый код впечатляет меньше, чем честная опись мест, где система потребовала архитектурной головы и человеческого упрямства.
У меня похожий эксперимент однажды закончился не ускорением, а археологией: помощник нагенерил рабочие куски, а потом я полдня выяснял, почему они плохо состыкованы. Поэтому в этой истории ценны именно девять поломок — такой список быстрее учит, где держать руку на архитектуре, чем десять гладких демонстраций.