Немного перепрофилировал канал. Тематика остается прежней, просто "ребрендинг" ))

Искусственный интеллект - это хорошо, но меры осторожности соблюдать нужно!

На домашнем ПК разогнался с кодингом, одобрил скрипт, который содержал ошибку, приводящую к очистке диска "D" ))) Было больно, неприятно, но поучительно ))

ИИ очень раскаивался 😂 А семейный фотоархив бесследно исчез. Не забывайте о безопасности )

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

Сейчас есть три типа "агентных систем":
- узкоспециализированные (навроде 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, а значит можно сделать, что гипотеза подтвердилась.

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