В разработке ИИ очень сильно увеличивает продуктивность. А что в других направлениях?
По сути не вижу, почему он не должен помочь и там. Ограничитель - "не айтишникам" сложнее формализовано описать свою работу. Но внедрять в работу надо, потому что особенность ФинТеха в том, что продукт/сервис может создавать и обслуживать маленькая команда. Это всегда было эффективно за счет высокого уровня автоматизации.
ИИ - новый вид автоматизации. Я могу "напилить" агентов под каждую задачу, но это время и привязка к программисту. Значит нужен инструмент, который сможет сам создавать воспроизводимые сценарии на основании успешных кейсов работы человека и ИИ.

Сейчас есть три типа "агентных систем":
- узкоспециализированные (навроде IDE для программистов)
- универсальные для локальной работы (по сути упрощенные программерские)
- универсальные для работы через телеграмм.

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

Хочу к этому инструменту приделать возможность анализа "чата" и формирования "дистиллята", который можно будет запустить как "мини-приложение". Специалист поработал с агентом, получил то, что было нужно. Завтра нужно повторить результат, заменив только "начальные данные" - система сама воспроизведет ключевые шаги.

ИИ очень быстро развивается, даже слишком быстро. Есть агенту, взаимодействующие с вами в телеграмм и управляющие вашими данными (Open Claw).
Однако существует порог "сложности восприятия": человеку сложно воспринять далекую для него идею, как следствие он от неё откажется (не согласится с ней). Но если провести его к этой же идее более маленькими шагами, которые будут человеку понятны - он сможет с ней согласиться, так как будет иметь достаточный базис. Внедрение новых инструментов - такая же история. Сперва даём то, что человек сможет освоить, а затем он сможет освоить более сложные или более "не привычные" инструменты

Ребята принесли хорошую хитрость, которая облегчает "вкатывание" в мир ИИ-агентов для Не-айтишников.

Не бойтесь экспериментировать - для начала в личных целях вам вполне хватит подписки за 20$. Просто спросите агента, может ли он вам помочь с [ваша любая задача, которую не можете сделать сами]

У агентов достаточно большая база знаний обо всём, а умение программировать позволяет выполнить очень многие задачи. Коллега-айтишник вчера поделился личным опытом, как через ИИ-агента он управляет рационом - с его слов даже анализ дефицита витаминов совпал с медицинскими анализами.

ИИ - это инструмент Учитесь им пользоваться.

Вот вы думали, что Вовка из мультика лентяй?
Нет, он - не опытный руководитель, не умеющий описать процесс и поставить задачи :)

Удивительно на сколько проще тимлидам и "всяким прочим айти-руководителям" вливаться в ИИ-разработку, чем рядовым разработчикам.

Помните говорил про доклад для INFOSTART про ИИ? Доклад приняли, Буду открывать секцию про разработку с ИИ
Москва, 12 марта, 10:40 😎

Собственно тезисы доклада, приходите, кому интересно :)

Пояснение к логике работы:

жамкаешь кнопку "сохранить как миниприлож" -> "выбираешь агента" -> он читает контекст переписки -> определяет что стало результатом -> какая была задача -> критерии валидации -> строит схему выполнения -> оптимизирует. Это llm-цикл.

А дальше запускается агентный цикл, где ревьювер - читает, смотрит, сверяет, пишет замечания.
Исправлятор - читает замечания и вносит правки в схему миниприложения.
Повторить Х-раз пока не останется замечаний.

Айтишники, активно работающие с ИИ переживают и шутят, что "Когда ИИ нас полностью заменит - пойдем выращивать огурцы или класть плитку, пора получать вторую профессию".

https://t.me/turboproject/3528 - вот только ИИ может заменить "кожаных" и там... 😅 Безусловно есть ограничения, есть вопросы себестоимости и "полной стоимости владения", НО это процессы развития.

Первый трактор изобрели в 1888 году. Я думаю он был достаточно дорог для того времени. И вряд ли был очень эффективен. Пахать землю Крестьянином + Лошадкой было проще. Но технология развивалась, улучшалась и ... дешевела. В 1920 (спустя 30 лет) трактора на гусеничном ходу производились серийно и даже целая деревня с табуном лошадок уже не могли за ним угнаться.

За ИИ будущее. Когда? - это открытый вопрос. Но развивается он очень быстро. Можно его подсознательно бояться, отрицать... Но еще один продукт фантастов обретает реализацию. Как будет выглядеть это будущее? - тоже открытый вопрос, у каждого своё видение. Кто точнее спрогнозирует и составит свою стратегию с этим учетом - вырвется в лидеры. Остальные... В дикой природе выживает наиболее приспособленный к изменениям индивид 🤷‍♂️

На Инфостарте 2026 была панельная дискуссия по секции «искусственного интеллекта». Меня «зацепило» два вопроса:
1. Роль Джуна в будущем (с учетом трансформации отрасли с внедрением агентной разработки)
2. Применение ИИ для бизнес-автоматизации

Первый вопрос достаточно сложный и глубокий. Попробую начать с него, а ответ на второй вопрос будет частично зависеть от первого.

В дискуссии несколько раз прозвучала мысль, что Джун будет бесполезным звеном в связке «работы с ИИ», а значит утрированно должен работать за еду, пока не наберет компетенций. НО так ли всё просто?

Что бы в этом разобраться аргументированно, а не на ощущениях попробуем рассмотреть несколько аспектов:
- Что есть "Вайбкодинг", а что есть "Агентная разработка" и где там нужны какие специалисты
- Сравним сильные и слабые стороны LLM-агентов и Людей-специалистов (что бы понять динамику замещения человека моделью)
- На основании этого проведем небольшой сценарный анализ и тогда уже предположим потенциальные роли/места джунов (а возможно и мидлов) в новой вселенной.

С одной стороны это страшно, и нам, как Айтишникам, не хочется думать о подобных сценариях, но закрывать глаза и жить в розовых очках не продуктивно. А поэтому давайте разбираться! Я еще целую неделю в отпуске и посвящу часть времени этим вопросам. Буду рад вашему участию и Аргументированным комментариям.

Вайбкодинг vs Агентной разработки.

Продолжаем эти размышления. Вся путаница в терминах. Вайбкодинг - это процесс генерации кода/приложения путем выставления кодинг-агенту бизнес-требований или фич.

Например: "Сделай мне сервис, который позволит "А", "Б" и "С". Сделай фичу "Х" и фичу "Y". При этом что и как он сделает не важно, если функционально задача решена (то есть что просили - то работает, а как это выглядит под капотом вообще без разницы).
При "чистом вайбкодинге" никакой документации не ведется, как только проект перестаёт "целиком умещаться в голову агента" - каждое новое решение агента может отличаться от предыдущего, всё будет зависеть от того, что он прочитал в проекте и какое впечатление у него "сложилось".
То есть при чистом вайбкодинге мы не управляем контекстом. Это не обязательно плохо - это быстрый прототип на коленке, что бы "пощупать рынок" или показать MVP. Но при таком подходе сделать серьезный и сложный ИТ-продукт - это будет опасно и плохо-управляемо.

Агентная разработка - это когда применяются классические инженерные подходы, но работы выполняются агентом. Архитектура, спецификации, технические задания, тесты, иная документация по проекту. Правила (отвечают на вопросы ЧТО и КОГДА) и Навыки (отвечают на вопрос КАК). Человек выступает дополнительным валидатором на ключевых этапах.
Результаты становятся более предсказуемыми, соблюдается архитектурный контроль. Следовательно подход работает и на крупных системах.

Сейчас популярна модель (прием), когда результаты одной llm проверяются через другую llm (llm-as-a-judge). Модели по‑разному обучены, по‑разному ранжируют ошибки и по‑разному проявляют слепые зоны. Если Опус-ревьювер поверит Опус-разработчика - то он найдет только те ошибки, которые опус-разработчик допустил по причине фокуса на процессе кодинга. При этом Кодекс-ревьювер может найти совершенно другие ошибки (по его мнению), на которые Опус не обратит внимания, сколько раз не выполняй ревью (потому что не считает их ошибками или не понимает "сам по себе" почему это ошибка).

💡 ИТОГО: Вайбкодинг — это про творчество и гипотезы, Агентная разработка — это про инженерию и надежность.

Теперь давайте посмотрим на процесс Агентной разработки и на роль человека в нем, как... LLM. Человек-LLM.

Продолжаем разбираться. Представить человека как еще одну llm-модель, которая при агентной разработке выполняет роль ревьювера и оркестратора "высшего порядка", что бы очень грубо оценить границы возможностей человека и прикинуть, далеко ли моделькам до таких показателей. Честно скажу, что я не llm-инженер, поэтому консультировался по цифрам с самими llm 😅

1. Оперативная память (аналог Фокуса контекстного окна) = 7 +/- 2 объекта (т.е. от 5 до 9 объектов). Автор исследования Джордж Миллер "Магическое число семь плюс минус два". В моделях рабочей памяти "ядро" часто считают ближе к 3–5 чанкам; остальное добирается за счёт группировки и репетиции (что справедливо для работы специалиста с его сферой и цикличным проходом по задаче).
Для LLM - это 50-100 токенов с максимальным весом. 100 токенов (на латинице) - это 2-3 абзаца текста или 15-20 строк кода. Для кириллицы - это будет 1 абзац и 8-12 строчек кода.
В процессе мышления/работы фокус постоянно смещается.

Если представить визуально (тут наверное у каждого по своему, говорю о себе), когда ты строишь в голове модель чего-то, Фокус - это то, что ты "видишь внутренним взором". Из-за того, что этот Фокус ограничен - мы Рисуем модели и схемы. Полный рисунок превращается в контекст, а наш фокус - это некое "пятно внимания" перед глазами.

2. Кратковременная память (Контекстное окно)
Для LLM:
1 мил контекстного окна - эффективное окно рассуждений в диапазоне 200 - 300 тысяч контекста.
200 000 контекстного окна - эффективное окно рассуждений до 50 - 100 тысяч. Дальше повышаются шансы, что модель не учтет часть имеющейся информации. И чем дальше, тем больше.

100 000 токенов - это порядка 250-300 страниц технического текста формата А4. А у человека всего ~7 объектов ? Но есть интересный нюанс, который является главным технологическим ограничителем (на текущий момент). Объекты, с которыми работает человек могут быть почти Любой сложности. Миллер ввел понятие "Чанк".
Условно мы берем 7 объектов, группируем и придаём им новый смысл.. и запоминаем теперь 1 объект (1 смысл). И так может происходить множество раз, зависит от способностей индивида "повышать уровень абстракций".

Приведу очень простой пример такого эффекта:
Не пиши Номенклатура.Наименование - это плохо для производительности.
Не пиши Номенклатура.Код - это...
Не пиши ЗаказКлиента.Сумма...
Таких правил может быть миллион и всё "наизусть не запомнишь", но мы повышаем уровень абстракции: не обращайся через точку к объекту, т.к. это вызывает полное чтение объекта. Профит. Мы агрегировали сотни разрозненных примеров в одну смысловую единицу.
Примерно также выглядит представление архитектора о системе - "мышление блоками" это тоже уровень абстракций.

Мышление абстракциями и моделями позволяет человеку запихнуть в один и тот же контекст больше информации, чем может модель. Компактизации - попытка "закостылить" недостающие возможности. И как часто агент при этом теряет важную информацию. Именно потому, что LLM не умеет формировать абстракции (обобщения).

3. Долговременная память - это "веса модели". Человек учится "онлайн" постоянно. Модель обычно не учится в рантайме (контекст — не обучение); чтобы менять "веса", нужны отдельные дорогие процессы. Зато при наличии ресурсов модели могут перерабатывать огромные объёмы данных очень быстро..

💡 Что мы имеем по итогу?
LLM быстрее, LLM не устаёт, но не умеет мыслить Абстрактно и Модельно. Для этого нужен человек-верификатор, который описывает правила, знания.
Фокус внимания модели больше, чем у человека, но только на первый взгляд (зависит от уровня натренированной абстракции человека).
Вот мы и пришли аргументированно к ситуации, когда в процессе агентной разработки нужен человек, но не любой, а с прокаченным уровнем абстракций и модельного мышления (сеньоры и архитекторы). И он будет нужен до тех пор, пока LLM не научится это делать как следует. Такие попытки есть, но результаты существенно уступают возможностям человека. На долго ли? Время покажет.

Агентный цикл разработки 1С: как масштабировать сеньора

Продолжу разбор. Пройдемся по ключевым ролям и определим для чего они. После этого будем смотреть, где узкие места и как их расшивать.

ИИ-Техлид (человек) выстраивает рабочий процесс агентного кодинга и развивает его. На текущий момент можно считать, что вся функциональность по работе с 1С, доступная человеку, технически доступна агенту. Проблемы еще будут вылезать, но уже с уверенностью можно сказать что все они решаемы (наработка правил, навыков, воркфло), да и llm не стоят на месте.

ИИ-Аналитик (человек) - работает с бизнес-заказчиком, валидирует ФТ. Ему ИИ помогает исследовать базу, работать с данными… да много чего еще, но никак не заменяет (можно экспериментировать, но я пока не уверен, что получится научить модель относиться к заказчику со скепсисом и не принимать любое требование как закон, помешает текущий стиль обучения.. слишком они привыкли стремиться выполнить любое требование).
В мире 1С чаще всего Аналитик выполняет функцию тестировщика, проводя сценарный анализ. Агент сам выполняет сценарный анализ, но человек его валидирует.

ИИ-Архитектор/Сеньор (человек) - определяет архитектуру приложения, валидирует Техническое задание, проводит код-ревью того, что напишет модель (валидирует результаты агентского ревью).

А отсюда вывод, что не только Джуны, но и мидлы будут не особо нужны, стоит немного подкачаться агентам и их llm.

Выходит те, у кого не хватает знаний и компетенций для работы с ИИ будут существенно уступать своим «ИИ-шнутым» коллегам.
Миф о том, что с ИИ может создавать продукт даже не айтишник - только миф. Но его мы уже рассмотрели отдельно на примере Вайбкодинг vs Агентной разработки (тут будет ссылка на предыдущий пост).

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

Какие задачи мы отдаем джуну? Не критичные, или те, которые нам не горят, понимая что потом их внимательно перепроверим (процесс обучения).
А какие задачи отдаём мидлу ? Которые не требуют сложных архитектурных решений. За джуном может проверить мидл, за мидлом - сеньор.
А даже если задача требует архитектуру - то Сеньор/Архитектор её обозначает в задаче, а код реализует Мидл.
Сеньор определил ТЗ - выполнил мидл. Сеньор проверил. Ничего не напоминает?
Сеньор утвердил спеку, агент выполнил, Сеньор проверил.

Задача не требует архитектуры? - пусть выполнит мидл или джун. Джун выполнил - мидл проверил.
Задача раскладывается по ролям? Да.

А теперь еще один интересный факт - личное наблюдение, среди 1С комьюнити на текущий момент основных успехов в работе с агентами достигли Тимлиды или Руководители отделов (или ребята, имеющие такой бекграунд). Это специальности, требующие умения формулировать, ставить и проверять задачи. И способные повысить уровень абстракции, описав Как должен выполняться этот процесс.

И мы настраиваем фреймворки, которые выполняют задачу "от и до" сами, либо с участием человека на "чек-поинтах". Мы сразу и в роли ии-аналитика, и в роли ии-сеньора (ведь ии-архитектор должен понимать их всех, что бы автоматизировать).

Как это снова разбить по ролям? Не нужно придумывать велосипед. Старый добрый канбан и очередь задач. Каждая задача выполняется своим сабагентом. Оркестратор обеспечивает её выполнение и первичную верификацию (силами llm). Дальше задача падает человеку и ждет его. Человек пишет замечания и возвращает задачу в очередь предыдущего шага... или "окает" и кладет в следующую очередь.

Это и есть агентный цикл. Агентный цикл разработки на 1С и способ его масштабирования.

А значит, в зависимости от класса задачи найдется место для мидла. Точно найдется.
А для Джуна ? А ведь также и для Джуна. Он сейчас пилит печатки? А будет Валидировать разработку Печаток.
Он сейчас пишет простые отчеты? Значит будет валидировать разработку простых отчетов. И учиться, и набираться опыта.

Идея была в том, что бы проверить влияет ли опыт декомпозиции и постановки задач на осваиваемость ИИ агентов (проще ли с ними работать с таким опытом).

Уберем тех, кто "Просто посмотреть", тогда получим такие доли тех, кто считает, что успешно освоил агентную разработку:
Разработчик: 54%
Архитектор: 11,4%
Тимлид: 1,4% (видимо у нас не очень распространена такая роль)
Руководитель: 18.5%
Не получилось / не понравилось - 10% из голосовавших (но надо понимать, что опрос проводился только в комьюнити про разработку с ИИ, поэтому ожидаемо, что большая часть тех, кто в них состоит и голосовал - справляются с агентной разработкой).

При этом охват был в районе 3000 человек, а проголосовало всего 110 (посмотреть ответы не в счет), т.е. в целом от всего комьюнити освоили агентную разработку около 3%... пусть кто-то поленился отметиться или помешал "синдром самозванца"... но даже 5% - это достаточно мало.

Вернемся к гипотезе про управленческий опыт - средний коэффициент Разрабов к "Управленцам" 5:1 (5 разрабов на одного с опытом декомпозиции и постановки задач). При естественном разделении мы должны были бы видеть 83% разработчиков.
Минимальный порог в районе 3:1, но даже так это дало бы 75% разработчиков.

Если мы возьмем только тех, кто отметился об успешном освоении агентной разработки, то разрабов там 63%, а это коэффициент 2:1, а значит можно сделать, что гипотеза подтвердилась.

Это означает только одно - учиться формулировать свои желания полезно )))

Агентный цикл разработки 1С. Джуны спасены?

Вы согласны с картиной из предыдущего поста? Если "ДА", то мне удалось осознанно завести вас в ловушку.

Мы решили, что джун будет валидировать печатки и простые отчёты. А теперь вспомним, что хорошо собранный агентный фреймворк при соблюдении SDD + TDD работает на уровне мидла, что делает участие джуна в них бессмысленным. В недалёком будущем за счёт развития самих LLM и дистилляции навыков технических специалистов, вполне вероятно, что станет как Middle+.

На чисто кодерских задачах джун проигрывает LLM по скорости и качеству. А задачи, где нужно модельное Мышление в коде (архитектура, сложная отладка, декомпозиция) — требуют уровня мидл+. Между этими двумя полюсами для джуна-кодера — пустота.

А может, сделать из джуна "оператора" агента — пусть формулирует задачи и принимает результат? Звучит красиво, но тут быстро упираемся в ограничения. Чтобы сформулировать задачу — нужно понимать требования (это аналитик). Чтобы принять результат — нужно понимать код (это разработчик). Без этих навыков "оператор" просто жмёт "принять", не понимая что принимает. А чтобы понимать код — нужно учиться его писать. И мы возвращаемся к исходной проблеме.

На этом месте напрашивается жёсткий вывод: джуны не нужны. Но и схема работать "за хлеб" на перспективу... вы уверены, что это будет интересно джунам и что они к вам пойдут? Вырасти из джуна в мидла — это при лучшем раскладе не меньше года, а в среднем два. Два года работать "за еду"?

💡 А может, и "фиг с ними, с джунами"? Будет рост спроса на сеньоров, у нас будут расти зарплаты, а остальное не наша боль? Давайте проведём сценарный анализ, чтобы ответить на этот вопрос.

Сценарный анализ: что будет с рынком 1С-разработки

Продолжим. Давайте посчитаем на пальцах. Берём два типа компаний:
- Тип А — агентная разработка (ИИ-сеньоры + ИИ-мидлы + агенты, ИИ-архитектор строит фреймворк)
- Тип Б — классический подход (сеньор + мидлы + джуны, ручной кодинг)

Считаем на одинаковый объём работ. Классическая команда: сеньор (325к) + 4 мидла (по 225к) + джун (85к) + пара-тройка аналитиков (по 225к) — набегает под ~1 870к/мес на ~9 человек. А теперь смотрите, что даёт агентный подход на ранних фазах (×2 продуктивность): 1 ИИ-сеньор (350к) + 2 ИИ-мидла (по 250к) + те же аналитики + инфра агентов (150к) + ИИ-архитектор (один на компанию, ~75к на команду) = ~6 человек, ~1 640к/мес. Тот же объём — на 12% дешевле и на 3 человека меньше.

Но подождите, 12% — это ерунда, кто ради этого будет перестраивать команду? А вот сроки — это уже другой разговор. Каждая отдельная задача выполняется в 2 раза быстрее. На тендере это звучит так: "Мы сделаем за 2 недели, а не за месяц". Для серьёзных проектов — это критично.

Фаза 1 (1-2 года): Тип А только формируется, подход сырой, экспериментальный. Тип Б стабилен. Джуны приходят, учатся, всё как раньше. Пока ничего страшного.

Фаза 2 (2-4 года): А вот тут начинается самое интересное. Агенты дозрели. Тип А побеждает не ценой, а скоростью + управляемостью. Начинается утечка: лучшие мидлы из Типа Б осваивают агентов и уходят в Тип А как ИИ-мидлы. Мотивация: +30-50% к зарплате (было 225к → стало 300-350к). Важный момент: ИИ — это не повышение грейда, а способ работы. Мидл остаётся мидлом по знаниям 1С, но с агентом его продуктивность ×2. Уходят именно лучшие — костяк команды. А в Типе Б остаются слабые мидлы, немотивированный сеньор, джуны. Качество падает, клиенты уходят.

Фаза 3 (4-7 лет): Тип Б сжимается. И тут парадокс: он всё это время был единственным местом, где выращивались джуны → мидлы → сеньоры. Тип А их не выращивал — переманивал. По сути Тип Б субсидировал обучение кадров для всего рынка за свой счёт. Классическая проблема "безбилетника" (free rider): одни вкладываются в людей, другие потом забирают готовых. Когда Тип Б сжимается — иссякает источник кадров для Типа А.

Фаза 4 (7+ лет): Кадровый кризис. Сеньоры стареют, выгорают, уходят в менеджмент. Новых неоткуда взять. Зарплаты ИИ-сеньоров (600-700к) и ИИ-архитекторов (1000к+) взлетают. Себестоимость Типа А растёт — преимущество тает.

А что с Типом Б? Он мог бы стать конкурентоспособным на этой фазе — ведь зарплаты в Типе А взлетели. Но нет — конвейер уже сломан: джуны не шли в отрасль 5-7 лет, мидлов мало, те что остались — слабые.

Похоже, что в итоге все дороги ведут к гибриду (назовём его Тип В):
- Тип А вынужден строить обучение → становится Типом В
- Тип Б вынужден внедрять агентов → становится Типом В

Кто из них придёт к гибриду раньше и с меньшими потерями — тот и выиграет.

Отдельно про спрос. Тут есть неприятный момент. Когда разработка становится быстрее и дешевле, бизнес "входит во вкус" — начинает заказывать больше доработок, которые раньше "не стоили того". Спрос растёт. Но узким местом станут аналитики: программист с агентом "съедает" задачи от двух аналитиков, а аналитик ускоряется слабо (бизнес-анализ агенту почти недоступен). Рынок перестроится: меньше программистов, больше аналитиков.

💡 Как вам такая картина? Какой сценарий кажется наиболее вероятным именно вам? Или видите иной?

Ручной кодинг как лётный тренажёр

Мы столько всего разобрали, но Главный вопрос так и остался: если гибрид неизбежен — как должно выглядеть обучение джуна?

Тут мы выходим на неприятный, но важный вывод: ручной кодинг всё-таки нужно сохранить. Но не как работу на проекте, а как учебную функцию.

Как лётный тренажёр. На нём не перевозят пассажиров, но без него не будет пилотов. Компания, которая убрала "тренажёр" ради экономии — через 5-7 лет обнаружит, что пилотов нет. И купить их будет в разы дороже, чем стоило содержать тренажёр.

Я к этому пришёл не сразу, но, кажется, вывод один: затраты на джунов в гибридной модели — это не "расход на неэффективного работника", а вложение в людей, которые через пару лет будут тянуть ваши проекты. Как R&D: не приносит прибыли сейчас, но без него нет будущего. И чем раньше компания это поймёт — тем дешевле обойдётся. Потому что потом мидлы и сеньоры будут стоить кратно дороже, а их будет кратно меньше.

Чтобы минимизировать потери на обучении, можно:
- Выделить задачи, где агент наименее эффективен (много итераций с платформой, работа с "грязными" данными, плохо формализуемые требования) — и отдавать их джунам. Разрыв в скорости там минимален, а обучающий эффект максимален.
- Но таких задач немного (10-20%) и с каждой фазой развития агентов их будет меньше.

Есть и другой ход, уже на уровне системы: коллаборация ВУЗов и работодателей. Схема: студент работает на учебных/демо-базах → выполняет задачи → ИИ-агент проверяет и даёт обратную связь → к выпуску студент на уровне мидл-.

Что это даёт:
- Снижение потерь для бизнеса — обучение вне коммерческих проектов
- ИИ-агент как преподаватель — масштабируется, даёт обратную связь мгновенно, не устаёт
- Студент пишет код руками — через набивание шишек формируется модельное и абстрактное мышление
- Компания получает мидл- и может быстро подтянуть его до "продуктивного уровня"

По сути: то, что раньше делала компания за свой счёт (обучение джуна), теперь должен делать ВУЗ + ИИ-агент. А компания доводит оставшиеся 20-30% — адаптацию к конкретным проектам.

💡 Итого. Старый формат джуна ("пишу простой код, учусь на ошибках") умирает. Но сам принцип обучения через написание кода — нет. Его нужно вынести из боевого контура в учебный. Ручной кодинг — это тренажёр, а не конвейер. Кто раньше включит голову — тот не будет потом бегать по рынку в поисках сеньоров за миллион (и это мы еще инфляцию не закладывали в модель).