🚧 Не дай AI свернуть не туда!
Когда много работаешь с AI-агентами, быстро появляется красивая мечта типо:
«А давайте агент сам напишет приложение, а мы просто посмотрим результат» 😅
Звучит классно. Но есть проблема. У нас, людей, очень много контекста живет где-то в голове:
• как правильно организовать модули
• какие зависимости можно, а какие нельзя
• где должен лежать код
• какие архитектурные правила у проекта
• что “и так понятно”, но нигде не написано
AI этого не знает. Поэтому у нас сейчас встает задача построить для AI жесткий коридор. Или выкопать ров, чтобы у агента просто не было шанса уйти не туда!
Сейчас это часто называют harness. Термин довольно растяжимый, и, кажется, все понимают его немного по-своему.
Мое текущее понимание (особенно для мобильной разработки) такое:
• все, на что можно ответить true / false, должно проверяться статически. Не AI. Не на ревью. Мы итак к этому стремились всегда. Но сейчас прямо супер надо. Что я сюда отношу:
• все виды тестов (прямо по всей пирамиде идем)
• линтеры
• статические чекеры
• архитектурные тесты
• тесты зависимостей между модулями
• любые скрипты, которые могут сказать: “так можно” или “так нельзя”
Потому что если правило можно формализовать, значит его нужно формализовать.
Особенно если мы говорим не про MVP, который хочется быстро навайбкодить и посмотреть, что будет, а про продукт, который должен жить, расти и развиваться.
Недавно мы добавили в проект архитектурные тесты через Konsist.
Пока накидали первый набор правил, но уже постепенно пополняем.
Ещё подключили проверки зависимостей между модулями через Module Graph Assert.
Чтобы модули зависели друг от друга только так, как мы договорились, а не как случайно получилось.
И это, кажется, прям очень важный сдвиг. Я сам попался на днях с архитектурной ошибкой 😅
Пусть AI думает, генерит, предлагает решения.
А все, что можно проверить тупо и однозначно, пусть проверяют статические анализаторы.
А вот там, где нужен reasoning:
• соответствует ли решение задаче
• не потеряли ли мы важный edge case
• не выглядит ли решение неоптимально
• не создали ли мы костыль
Вот там уже подключаются люди, AI code review.
В общем, мой текущий вывод такой:
AI-агентам нужны стены, рвы и автоматические ворота!
💬 А что вы уже добавляете в свой harness для мобильных приложений?
Какие тесты, линтеры, чекеры или правила реально помогают не дать AI и людям свернуть не туда? Навалите в комменты ваш опыт, мне реально очень интересно!
#android #ai #architecture #testing #kotlin #mobiledev
Когда много работаешь с AI-агентами, быстро появляется красивая мечта типо:
«А давайте агент сам напишет приложение, а мы просто посмотрим результат» 😅
Звучит классно. Но есть проблема. У нас, людей, очень много контекста живет где-то в голове:
• как правильно организовать модули
• какие зависимости можно, а какие нельзя
• где должен лежать код
• какие архитектурные правила у проекта
• что “и так понятно”, но нигде не написано
AI этого не знает. Поэтому у нас сейчас встает задача построить для AI жесткий коридор. Или выкопать ров, чтобы у агента просто не было шанса уйти не туда!
Сейчас это часто называют harness. Термин довольно растяжимый, и, кажется, все понимают его немного по-своему.
Мое текущее понимание (особенно для мобильной разработки) такое:
• все, на что можно ответить true / false, должно проверяться статически. Не AI. Не на ревью. Мы итак к этому стремились всегда. Но сейчас прямо супер надо. Что я сюда отношу:
• все виды тестов (прямо по всей пирамиде идем)
• линтеры
• статические чекеры
• архитектурные тесты
• тесты зависимостей между модулями
• любые скрипты, которые могут сказать: “так можно” или “так нельзя”
Потому что если правило можно формализовать, значит его нужно формализовать.
Особенно если мы говорим не про MVP, который хочется быстро навайбкодить и посмотреть, что будет, а про продукт, который должен жить, расти и развиваться.
Недавно мы добавили в проект архитектурные тесты через Konsist.
Пока накидали первый набор правил, но уже постепенно пополняем.
Ещё подключили проверки зависимостей между модулями через Module Graph Assert.
Чтобы модули зависели друг от друга только так, как мы договорились, а не как случайно получилось.
И это, кажется, прям очень важный сдвиг. Я сам попался на днях с архитектурной ошибкой 😅
Пусть AI думает, генерит, предлагает решения.
А все, что можно проверить тупо и однозначно, пусть проверяют статические анализаторы.
А вот там, где нужен reasoning:
• соответствует ли решение задаче
• не потеряли ли мы важный edge case
• не выглядит ли решение неоптимально
• не создали ли мы костыль
Вот там уже подключаются люди, AI code review.
В общем, мой текущий вывод такой:
AI-агентам нужны стены, рвы и автоматические ворота!
💬 А что вы уже добавляете в свой harness для мобильных приложений?
Какие тесты, линтеры, чекеры или правила реально помогают не дать AI и людям свернуть не туда? Навалите в комменты ваш опыт, мне реально очень интересно!
#android #ai #architecture #testing #kotlin #mobiledev