В прошлой статье мы выяснили, что при остановленном найме сегодняшний Джун не может превратиться в классического старого матёрого Сеньора, руину героической эпохи, который ещё в детстве поднимал кластеры кубернетс в облаках через кнопочный телефон, разбивал легаси на микросервисы утром и мерджил их в монолит обратно вечером, копипастил со stackoverflow патчил бинарники, преобразовывал Фурье и всё это одновременно.
И когда сеньоры уйдут (R.I.P.) – и когда задача Спроектировать Solution ляжет на плечи Джуна, вытянет ли он на голом ИИ без опыта?
В целом, похоже, что вытянет. Но есть подводные камни, давайте посмотрим, как их решить.
Жадный алгоритм
Может ли ИИ выстроить отвечающую всем функциональным и технологическим требованиям, поддерживаемую, расширяемую архитектуру, и реализовать её на каждом этапе и в каждом модуле? Может. Если дать правильный контекст: правильный контекст – правильное решение.
Но! Надо помнить, что каждый запрос ИИ выполняет по жадному алгоритму. Это вежливый ассистент, который найдёт локальный ближайший оптимум, предложит это вам в качестве решения, и прекрасно выполнит. Если ему какой-то контекст недодать – решение будет близорукое. И это нормально. Хотите прицел на будущее дайте соответствующий контекст.
Джун, у которого просто нет опыта, может не составить правильный промпт. Даже если до него выстроен пайплайн разработки с типизированными агентами, он может неправильно его параметризировать, неправильно обозначить трэк развития. И это на всех этапах, как на глобальном, при формировании общей архитектуры проекта, так и на локальном, на каком-нибудь кастомном гриде на фронте.
Проект будет построен здесь и сейчас, но если он войдёт в эксплуатацию, им начнут пользоваться клиенты, он обрастёт патчами и воркэраундами, – вносить изменения может стать проблемно.
Спортивный минивэн
Утрировано это выглядит так.
Запрос Джуна: Сделай мне автомобиль. Хочу электромобиль с запасом хода на 1000 км. Хочу, чтобы разгонялся до 100 км/ч за 2 сек. Хочу чтобы безопасный и надёжный, и простой в управлении, чтобы справился ребёнок. Чтобы был вместительный, если надо семью из 7 человек отвезти на дачу. Хочу, чтобы можно было заливать и бензин, и дизель. Должен быть проходимым по пересечёнке, но чтобы был экономный в городе. Компактный, чтобы можно было удобно парковать. Стильный и недорогой.
(типичный запрос девушки к парням)
И ладно бы он это всё вывалил разом. Но требования будут появляться итеративно. Каждый следующий запрос Джуна вежливый адепт локальных оптимумов будет решать именно так: улучшать спортивность минивэна и минивэнность спорткара. Только потому, что распилить это на две или три разных машины в этом отдельно взятом запросе – дорого и неоптимально.
Пример: реализация Хабра
Давайте более-менее реальный пример: пусть будет что-то условно типа Хабра, но с богатым редактором статей, целым IDE.
Нужен Лэндинг, где много статики, но есть несколько мест с данными – это будет Astro с островами. И нам нужна документация, для этого отлично взять Astro Starlight. Всё закешировать с CDN. Теперь IDE со сложными объёмными данными и богатым взаимодействием. Серверный рендеринг здесь не нужен, даже вреден. Это будет чистое SPA на React с MobX. И нам нужна лента публикаций, для неё серверный рендеринг как раз нужен, это будет React Router с SSR. У них у всех будет общий тулбар с профилем и навигацией, ок. Отдельные npm пакет. Всё это будет разруливать nginx. Ещё админка, бэк, БД туда, БД сюда. Это всё нужно контейнеризировать и разворачивать в разных деплоях для разработки, тестирования и прода. Четыре проекта на фронте на разных технологиях под общим nginx, чтобы не надо было вкорячивать документацию на Starlight в Next.js, и работать со сложной IDE отдельно от не менее сложной ленты.
Вопрос: что получит Джун от ИИ, если напишет запрос вроде: «сайт проекта, документация, редактор и лента статей»? Модель ответит: Next.js. Один фреймворк, который умеет всё: лендинг — статические роуты, лента — серверные, редактор — клиентская страница, докам выделим раздел на MDX. Монорепа, один деплой, одна команда npm run dev. Локальный оптимум — для того промпта, который был задан.
А то, что требования каждой части конфликтуют: что тяжёлый редактор требует жить только в браузере, он не хочет серверный рантайм и чужие полифилы, документация хочет быть статикой и иметь CDN кэш, лента хочет больше инстансов, и ВСЕ хотят независимых релизов, – возможно и не всплывёт. Каждый следующий запрос будет усугублять конфликт, чинить А и ломать Б. ИИ не скажет, что тут давно не надо улучшать, а надо резать и настоять на этом, подвинув недовольство заказчика. Он вежливый ассистент. А Джун не настоит на этом по отсутствующему опыту. Умнеющая год от года модель будет всё лучше улучшать спортивность минивэна.
Надежда Джуна
В принципе, современный Джун, освобождённый от необходимости знаний как правильно использовать 40 паттернов проектирования (типа GoF), от того как надо на низком уровне держать слабую связность, от SOLID, DRY и прочих принципов, от способов уменьшить сложность кодовой базы (а это чуть ли не основная задача проектировщика), как профилировать БД и JS на производительность, от сложных алгоритмов и сложностей алгоритмов, – в общем, освобождённый от всего этого Джун, может научится проектировать, делать промпты такие, чтобы сразу резать по границам конфликтов, и будет писать с ИИ сразу хорошие проекты, которые выдержат проверку временем. Прецедент был – ассемблерщики тоже говорили про компиляторных программистов ровно то же: «освобождённый от регистров человек никогда не поймёт машину». Оказалось – поймёт. А регистры действительно можно не знать.
Разве джун не может написать:
Привет! Я хочу сделать образовательный веб-проект и прошу тебя спроектировать его: какие технологии взять и какая будет структура. Писать код пока не надо — сначала проект.
Что должно быть:
Главная страница проекта — красивая, с описанием и кнопкой «Войти». Вход через Google или GitHub.
Платформа публикаций: авторы выкладывают статьи, читатели читают. Очень важно, чтобы статьи находились гуглом и красиво разворачивались при шаринге в телеграм и соцсети (картинка-превью, заголовок).
Рабочая среда автора (редактор): автор сидит в ней часами — загружает книги-источники, выделяет цитаты, пишет конспекты, связывает их в граф понятий, собирает из этого статьи. Много интерактива: деревья, drag-and-drop, визуализация графа. Документы большие, всё должно быть быстрым и отзывчивым.
Документация проекта: руководства и справка, с оглавлением, поиском и версиями.
На всех страницах сверху одна и та же панель: логотип, переключатель разделов (платформа / редактор / документация), аватар, вход/выход. Пользователь логинится один раз — и он залогинен везде.
Админка для меня: пользователи, модерация статей, настройки. Предложи архитектуру и объясни, почему так.
И модель ему предложит прекрасную архитектуру под эти требования. Напишет план имплементации и даже всё итеративно реализует с использованием best practices.
Разве не красота?
P.S. После людей
А, кстати! Джун не напишет ни строчки кода. Более того – он в него никогда больше не посмотрит. Что станет с фреймворками?
Красивый DX, короткий синтаксис, «низкий порог входа» – всё это существовало ради человеческой памяти и восприятия. Это всё умрёт. Модели порог входа не нужен. Уже сейчас видно, куда идёт: llms.txt вместо документации для людей, MCP вместо удобных SDK. Фреймворки перестанут конкурировать за симпатию разработчика и начнут конкурировать за представленность в обучающих корпусах. Новый фреймворк больше не взлетит классическим путём – модели его не знают, значит его не используют, значит он не попадает в корпус.
COBOL шестьдесят лет держит банковские проводки, так что вполне возможен мир, где модели просто вечно поддерживают Next.js версии 47, имитируя человеческий стиль, потому что корпус – человеческий.
ссылка на оригинал статьи https://habr.com/ru/articles/1059652/