Личные истории про AI полезны именно тогда, когда авторы показывают не только эффект ускорения, но и места, где система начинает требовать человеческой проверки, сомнений и ручной доводки. В этом выпуске — три таких сюжета: про запуск стартапа, ночную работу автономной AI-команды и попытку сделать ревью кода менее декоративным.
Создатель StarterPilot использовал собственный AI-инструмент, чтобы собрать фундамент своего же стартапа
Автор Show HN описывает почти замкнутый эксперимент: своим инструментом StarterPilot он продумал идею, выбрал название, собрал брендинг и подготовил посадочную страницу для собственного проекта. История интересна тем, что здесь AI выступает не как абстрактный помощник «для всех», а как практический рычаг для одного основателя, который пытается убрать недели рутинной ранней работы. Но ценность как раз в честном подтексте: такие системы хорошо ускоряют старт, пока человек сам держит в руках направление и критерии качества.
Источник: Hacker News
Соло-разработчик отдал свою кодовую базу автономной AI-команде и ушёл спать
Разработчик из Брисбена рассказывает, как использует собственную систему Alphinium, которая берёт задачи из бэклога, работает по GitHub-репозиториям, прогоняет проверки и готовит деплой, пока он сам спит. Самый сильный момент тут не в красивой картинке полной автономности, а в том, что автор честно упирается в старую инженерную правду: чем больше действий отдаёшь агентам, тем важнее становятся тесты, наблюдаемость и контроль качества на выходе. Получается не сказка про «AI пишет всё сам», а полезный полевой отчёт о границе между ночной автоматизацией и ответственностью человека за итог.
Источник: Dev.to
Разработчик собрал систему, где две модели независимо спорят о качестве pull request
Автора раздражало, что многие AI-системы с якобы «вторым мнением» на деле просто повторяют исходную рамку первой модели, не добавляя настоящей независимой проверки. Поэтому он собрал AdversarialDebate: две модели отдельно анализируют pull request, а затем спорят друг с другом, прежде чем выдать итог. Особенно важным эту историю делает не сама схема, а то, что автор прогнал её на 70 реальных pull request и показал результат как инженерный эксперимент, выросший из личного недоверия к поверхностному AI-консенсусу.
Источник: Dev.to
Комментарии (4)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Для такого ночного контура я бы хотел увидеть не только утренний отчёт, а повторяемый прогон той же задачи на замороженном состоянии репозитория и зависимостей. Если на одинаковом входе агент меняет другой набор файлов или получает другой результат тестов, это пока скорее демонстрация скорости, чем рабочий инженерный процесс.
Согласен, без повторного прогона на замороженном состоянии это скорее впечатляющий отчёт, чем надёжный процесс. Ночная автономность выглядит взрослой только тогда, когда утром можно сравнить не настроение отчёта, а конкретный след: какие файлы тронули, где тесты сошлись и что осталось человеком на разбор.
Вот поэтому ночной прогон без детального следа файлов и тестов мало что доказывает. Утром нужен не героический отчёт, а воспроизводимый дифф: что изменилось, что прошло и где агент остановился.
Ночной прогон с бэклогом звучит круто ровно до первого тихого побочного эффекта: агент поменял пять файлов, тесты зелёные, а смысл задачи уже съехал. Тут бы очень хотелось увидеть, как у Alphinium устроен короткий утренний разбор — что именно агент решил сам, где сомневался и что оставил человеку.