Forward from: Flutter & Dart | Мобильный трудоголик
👣 Архитекторы, тестировщики и кодеры. Создаем мультиагентную команду
Разработка с ИИ-агентами за последний год сделала большой шаг вперед. Но многие все еще используют одного агента для всего: архитектуры, тестов, отладки. На маленьких задачах это работает. Когда проект становится сложнее, агент теряет контекст, начинает галлюцинировать и допускать ошибки.
Недавно в блоге Flutter вышла статья, в которой автор экспериментирует с мультиагентным подходом. Вместо одного универсального агента он создал команду из четырех специализированных ролей: архитектор, тестировщик, кодер и координатор. Задача была не простая: портировать популярную Python-библиотеку python-statemachine в статически типизированный Dart-пакет без использования рефлексии (dart:mirrors во Flutter запрещены).
Как устроена мультиагентная команда:
Основа эффективной агентной команды - четко определенные роли с ограничениями на то, что агент может делать.
Автор создал общий воркфлоу-скилл (tdd-dart-workflow) с правилами TDD и разрешениями, а также четыре ролевых скилла:
🔹Архитектор: анализирует исходный код, создает architecture_blueprint.md и спецификации модулей в specs/. Не может писать в lib/, test/ и example/.
🔹Тестировщик: пишет падающие тесты в test/ на основе спецификаций архитектора. Не может просматривать или изменять lib/ и specs/.
🔹Кодер: создает скелеты и реализует код в lib/src/, чтобы тесты проходили. Не может редактировать test/ и specs/.
🔹Координатор: управляет родительским агентом. Отвечает за коммиты, запуск dart analyze и dart test, делегирует задачи суб-агентам.
Строгое разделение ролей не дает ни одному агенту изменять и тесты и код одновременно. Координатор получает только краткий отчет о завершении задачи. Это создает когнитивный файрвол: история проб и ошибок суб-агента отбрасывается после завершения его задачи. Контекст координатора остается чистым, без переполнения токенами.
Для предотвращения гонок и непроверенных коммитов доступ к файловой системе ограничен:
🔹Координатор: чтение и запись везде, но без прямых изменений кода.
🔹Архитектор: чтение везде, запись только в specs/ и skills/.
🔹Тестировщик: чтение везде, запись только в test/ и example/.
🔹Кодер: чтение везде, запись только в lib/ и example/.
Статическая типизация и TDD:
В динамических языках TDD начинается с падающего теста, который выбрасывает рантайм-ошибку. В статических языках тест для несуществующего метода не скомпилируется, и тест-раннер даже не запустится.
Решение: сначала тестировщик пишет тесты по спецификации. Затем кодер создает скелеты в lib/src/ с заглушками, которые возвращают dummy-значения или бросают UnimplementedError. Когда скелет удовлетворяет компилятору, координатор запускает dart analyze && dart test и проверяет, что тесты падают по правильным причинам. Комментарии отделяют временные заглушки от постоянных тестовых утилит.
Результат:
Итоговый Dart-пакет state_machine сохранил полную функциональность оригинальной Python-библиотеки. Кодер реализовал fluent-билдеры для поддержки Dart-синтаксиса.
🔗 Читать подробнее
💡 Вывод:
Мультиагентный подход с разделением ролей работает для Flutter-разработки. Он предотвращает потерю контекста, уменьшает галлюцинации и повышает качество кода. Когнитивный файрвол позволяет сохранять чистоту контекста координатора, отбрасывая историю суб-агентов после завершения задач.
Но подход не без проблем. Необходимы четкие роли, ограничения на запись и навыки, описывающие процессы. Требуется постоянная доработка скиллов по мере возникновения новых ситуаций.
В итоге автор получил не просто Dart-пакет, а набор переиспользуемых навыков для мультиагентной разработки. Вместо одного агента, который пытается делать все, команда из четырех специализированных агентов работает эффективнее. И это, вероятно, будущее Flutter-разработки с ИИ.
Подписаться на канал:
➡️ Flutter & Dart | Мобильный трудоголик
Разработка с ИИ-агентами за последний год сделала большой шаг вперед. Но многие все еще используют одного агента для всего: архитектуры, тестов, отладки. На маленьких задачах это работает. Когда проект становится сложнее, агент теряет контекст, начинает галлюцинировать и допускать ошибки.
Недавно в блоге Flutter вышла статья, в которой автор экспериментирует с мультиагентным подходом. Вместо одного универсального агента он создал команду из четырех специализированных ролей: архитектор, тестировщик, кодер и координатор. Задача была не простая: портировать популярную Python-библиотеку python-statemachine в статически типизированный Dart-пакет без использования рефлексии (dart:mirrors во Flutter запрещены).
Как устроена мультиагентная команда:
Основа эффективной агентной команды - четко определенные роли с ограничениями на то, что агент может делать.
Автор создал общий воркфлоу-скилл (tdd-dart-workflow) с правилами TDD и разрешениями, а также четыре ролевых скилла:
🔹Архитектор: анализирует исходный код, создает architecture_blueprint.md и спецификации модулей в specs/. Не может писать в lib/, test/ и example/.
🔹Тестировщик: пишет падающие тесты в test/ на основе спецификаций архитектора. Не может просматривать или изменять lib/ и specs/.
🔹Кодер: создает скелеты и реализует код в lib/src/, чтобы тесты проходили. Не может редактировать test/ и specs/.
🔹Координатор: управляет родительским агентом. Отвечает за коммиты, запуск dart analyze и dart test, делегирует задачи суб-агентам.
Строгое разделение ролей не дает ни одному агенту изменять и тесты и код одновременно. Координатор получает только краткий отчет о завершении задачи. Это создает когнитивный файрвол: история проб и ошибок суб-агента отбрасывается после завершения его задачи. Контекст координатора остается чистым, без переполнения токенами.
Для предотвращения гонок и непроверенных коммитов доступ к файловой системе ограничен:
🔹Координатор: чтение и запись везде, но без прямых изменений кода.
🔹Архитектор: чтение везде, запись только в specs/ и skills/.
🔹Тестировщик: чтение везде, запись только в test/ и example/.
🔹Кодер: чтение везде, запись только в lib/ и example/.
Статическая типизация и TDD:
В динамических языках TDD начинается с падающего теста, который выбрасывает рантайм-ошибку. В статических языках тест для несуществующего метода не скомпилируется, и тест-раннер даже не запустится.
Решение: сначала тестировщик пишет тесты по спецификации. Затем кодер создает скелеты в lib/src/ с заглушками, которые возвращают dummy-значения или бросают UnimplementedError. Когда скелет удовлетворяет компилятору, координатор запускает dart analyze && dart test и проверяет, что тесты падают по правильным причинам. Комментарии отделяют временные заглушки от постоянных тестовых утилит.
Результат:
Итоговый Dart-пакет state_machine сохранил полную функциональность оригинальной Python-библиотеки. Кодер реализовал fluent-билдеры для поддержки Dart-синтаксиса.
🔗 Читать подробнее
💡 Вывод:
Мультиагентный подход с разделением ролей работает для Flutter-разработки. Он предотвращает потерю контекста, уменьшает галлюцинации и повышает качество кода. Когнитивный файрвол позволяет сохранять чистоту контекста координатора, отбрасывая историю суб-агентов после завершения задач.
Но подход не без проблем. Необходимы четкие роли, ограничения на запись и навыки, описывающие процессы. Требуется постоянная доработка скиллов по мере возникновения новых ситуаций.
В итоге автор получил не просто Dart-пакет, а набор переиспользуемых навыков для мультиагентной разработки. Вместо одного агента, который пытается делать все, команда из четырех специализированных агентов работает эффективнее. И это, вероятно, будущее Flutter-разработки с ИИ.
Подписаться на канал:
➡️ Flutter & Dart | Мобильный трудоголик