Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд

В сфере искусственного интеллекта произошло заметное событие. sproshchaev 10 минут назад Коллаборация человека и ИИ в Kotlin‑разработке: скрытые практики эффективных команд Уровень сложности Средний Время на прочтение 7 мин Охват и читатели 480 Блог компании OTUS Kotlin * Искусственный интеллект Карьера в IT-индустрии Туториал Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java / Kotlin разработки в FinTech, а также преподаю на курсах по архитектуре и бэкенд‑разработке в OTUS. В этой статье хочу разрушить один опасный миф: якобы скоро нейросети заменят разработчиков, и нам останется только пить кофе, пока ИИ пишет микросервисы.

Сегодня мы перейдем к практике создания функционального узла системы. Мы не будем полагаться только на магию ИИ — мы совместим инженерный опыт, готовые архитектурные шаблоны и возможности автономных агентов. Это демонстрация реального процесса, где разработчик выступает в роли дирижера сложной технологической системы.

Технические детали

Расскажу, как подготовить фундамент, как ставить задачи агентам и, что самое важное, где автоматика ошибается и требует твердой руки эксперта. Они решают задачи Когда я только начинал экспериментировать со связкой Kotlin + AI‑агенты, я думал, как и многие: «Сейчас объясню бизнес‑требование, и оно само превратится в Pull Request». На деле получил лапшу из классов, нарушающую все принципы SOLID .

Потому что ИИ, будь то Copilot, Cursor с агентами или самописные воркеры на базе LangChain4j , отлично решает задачу «в лоб». Но плохо понимает контекст всей системы, если этот контекст ему не дать. Можно потратить месяц, переписывая один модуль Ktor ‑приложения, где ИИ‑агент генерировал эндпоинты без спецификации OpenAPI .

Каждый новый метод будет работать, но вместе все это превращается в кашу. Именно тогда я и сформулировал правило: «Кодинг — это доставка. Архитектурный дизайн и контракты — рулевое управление».

Отраслевые последствия

И рулить должен разработчик (рис. 1 Иллюстрация концепции: разработчик как дирижер ИИ‑команды Благодаря этому у меня сформировалось понимание того, что подход Agent‑Oriented Programming имеет место быть, но с жестким контролем. Весь входящий поток бизнес‑требований необходимо сначала «упаковывать» в строгую архитектурную схему, используя проверенные шаблоны.

Только после этого даем волю ИИ‑команде. Подготовка фундамента: не дайте агенту сойти с рельсов Главная ошибка новичков — дать агенту промпт: «Создай CRUD для пользователей на Ktor с Exposed ». Но как потом это поддерживать?

Без абстракций, без Clean Architecture , без разделения на слои. Мой Best Practice теперь выглядит так: шаблон решает всё . Я не стартую проект с пустого main.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.