Почему не ложится GenAI у сотрудникам в компании?

Три кризиса, которые переживает инженер, когда ему выдают агентов

«Он генерит код за 5 минут, а я потом два часа его читаю и всё равно нахожу тысячу ошибок»

Это самое частое возражение, которое я слышу на коучингах по GenAI. И оно почти всегда звучит как претензия к инструменту: модель тупая, код грязный, проще самому.

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

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

Кризис первый: делегирование

Люди не умеют делегировать. Вообще. Не агентам - живым людям не умеют.

Делегирование - это не «попросил сделать». Это четыре отдельных навыка:

1. Понять задачу самому и сформулировать её так, чтобы тебя поняли.
2. Подобрать ключик к исполнителю, чтобы он действительно её сделал.
3. Сделать ревью.
4. Если пошло не так - помочь исправить и передать знание, чтобы в следующий раз было лучше.

Этот кризис переживает любой сеньор, который становится лидом. Ему больно. Люди делают работу не так, как он хочет. Он год скрипит зубами - и постепенно понимает, что семь человек с итерациями сделают больше, чем он один идеально. И что его работа теперь - не кодить, а выращивать команду.

Раньше через это проходили единицы и с подготовкой. Сейчас мы сказали всем: вот вам агенты, делегируйте. И человек горит ровно так же, как сеньор, которому впервые дали семь подчинённых.

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

Кризис второй: мышление девопса

Посмотрите, как на проект приходит девопс. Он не думает: «наконец-то я нашёл задачу на полгода и спрятался от бенча». Он думает: «мне надо написать N скриптов и свалить, чтобы меня больше не трогали - у меня ещё три проекта в очереди». Его цель - чтобы всё работало без него. Он будет приглядывать, если попросят, но по дефолту он строит систему, а не делает работу руками.

Теперь ровно это сказали всем: ребята, вот вам скиллы, инструкции, агенты - автоматизируйте свою рутину.

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

Отсюда, кстати, растёт правильный ответ на возражение про ревью. Если тебе не нравится два часа читать сгенерированный код - это нормальная реакция инженера. Вопрос в другом: как сделать, чтобы ты эту работу не делал? Поставь второго агента ревьюить первого. Прикрути линтер. Опиши чек-лист как скилл. Именно так поступил бы лид, на которого вдруг посыпалось пять потоков пулл-реквестов: он бы не стал выгребать их сам, он бы пошёл к деливери-менеджеру за мидлом или за инструментом.

Вопрос инженера старого образца: «как мне сделать эту работу хорошо?»
Вопрос инженера нового образца: «как мне эту работу не делать?»

Кризис третий: взгляд CEO

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

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

Исполнитель так не смотрит. У исполнителя есть свой квадратик, и ему фиолетово, что слева и справа.

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

Это дополнительная когнитивная нагрузка. По доброй воле на неё никто не подписывается.

Почему у менеджеров «взлетает», а у инженеров - нет

Наблюдение, которое многое объясняет.

Менеджер ставит себе Claude или Cursor, просит сделать отчёт - и получает отчёт. Ему всё равно, как оно внутри реализовано. Он подходит к модели как к исполнителю - ровно так же, как он всю жизнь подходил к любой команде. У него вдруг за десятки долларов в месяц появилась своя команда, и он переключается в режим продуктоунера: наконец-то он может не обслуживать чужой продукт, а сделать свой. И у него всё цветёт.

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

Приём, который работает: сформулируйте задачу так, чтобы её нельзя было сделать самому

Самое честное возражение звучит как «я сделаю лучше». Спорить с ним бесполезно - обычно это правда.

Поэтому не спорьте. Поменяйте постановку задачи.

Не «за спринт», а «сегодня до вечера мне нужно пять компонентов, которые делают вот это».

Всё. Сам он это не сделает. Ему придётся опереться на не очень качественного исполнителя - и дальше включится правильный вопрос: «ладно, модель стабильно даёт мне 40% от того, что сделал бы я, но за пять минут вместо трёх часов. Как мне поднять эти 40% до 60? до 80?»

Вот в этот момент человек начинает учиться делегировать, а не возражать.

И здесь же появляется главный размен, который надо проговаривать вслух:

Да, качество ниже. Но я беру скейлом. Десять агентов работают параллельно. Мы дойдём до конца спринта с прототипом на 40%, получим фидбэк, за второй спринт доведём. Сам я бы делал это пять спринтов - а задачу поставили на два.

Плюс открывается то, за что раньше вообще нельзя было взяться: запустить двадцать сабагентов на ресёрч и к завтрашнему вечеру иметь результат.

Локус контроля: главный переключатель

Есть ещё одна вещь, без которой ничего не поедет.

Нужно принять, что модель - это энциклопедист. Такого человека, который держал бы в голове всё, что зашито в модель, просто не существует. Даже слабая модель шире по профилю, чем самый крутой специалист.

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

Это и есть смена локуса контроля с внешнего («моделька виновата») на внутренний («что я сделал не так, если энциклопедист не справился»).

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

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

Про страх, который редко произносят вслух

Под всеми тремя кризисами лежит ещё один слой: ощущение, что твой труд обесценивается. То, чему ты учился годами, теперь делает модель.

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

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

Кнут: если ещё два года работать в старом формате, количество проектов, которые будут тебя хотеть, станет сильно меньше. Нам на это повлиять нечем - это случится в любом случае.

Пряник: сегодня из каждого утюга вайб-кодит кто угодно. Но только человек, который отработал в индустрии пять-десять лет, понимает, что на самом деле лежит под капотом такой работы. Он может взять свои знания - архитектуру, SOLID, проектирование API, базы такие, базы сякие, многопоточность, ассинхронная разработка и так далее - и усилить их агентами. Это другая лига, и её пока мало кто занял. 

Когда agent loop недостаточно - свой проверятор контрактов

В какой-то момент приходится признать, что одной прозы в markdown не хватает. Добавляешь всевозможных скриптов, на рельсах которых начинают ездить модельки. Но и тут со временем упираешься. Когда появляются контракты - то каким должны быть навайбкодженными типичные компоненты, чтобы быть частью этой всей инфраструктуры. Особенно если компоненты разнесены. Особенно если язык динамически типизирован или типизация не строгая. Контракты так же появляются в виде прозы для моделей. И тут так же приходишь к пониманию, что должны происходить проверки детерминированным кодом. Вот потому пишу конфигурируемый проверятор контрактов, к которому моделька будет обращаться за проверкой - а соблюла ли она все контракты по созданию нового компонента как описано в прозе, или нет.

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

Ваша идея детерминированного проверятора контрактов (Contract Validator) — это единственный жизнеспособный способ удержать распределенную систему от хаоса. В индустрии такой подход ближе всего к концепции Architecture-as-Code и автоматизированного Linter-инжиниринга. 

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

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

Переход на собственный детерминированный Agent Loop (оркестратор) — это зрелое инженерное решение. Вы превращаете модель из «директора процесса» в чистую вычислительную функцию на конкретном этапе, где вся бизнес-логика и переходы между состояниями управляются вашим кодом (надежным, предсказуемым и написанным на Python/TS). 

Философия Unix или 1001 велосипед в GenAI решениях

Последние 3 года я наблюдаю небывалый бум GenAI решений. Последний год особенно, с появлением концепции Skill.md. Все пишут скилов и агентов, а затем их объединяют в фабрики. Наличие приставки "dark" зависит от уровня наглости автора - я в свою добавляю, что напоминает мне о том куда я стремлюсь. Сегодня этим постом хочу поделиться об еще одной приставке, которую изобрели инженерные мужи в 1960х-70х годах, доказавшую свою эффективность.

Концепция SKILL.md в ее современном понимании как открытого индустриального стандарта для ИИ-агентов появилась относительно недавно - в конце 2025 года. 

GPT: Октябрь 2025 года: Компания Anthropic впервые представила внутреннюю архитектурную фичу Agent Skills (Навыки агентов) в рамках экосистемы своих ИИ-помощников (в частности, для терминального интерфейса Claude Code). Суть фичи заключалась в том, чтобы упаковать конкретную техническую инструкцию или рабочий процесс в изолированную папку, ядром которой являлся стандартизированный файл метаданных и правил - SKILL.md.   

Декабрь 2025 года: Anthropic вывела этот формат в публичное поле, опубликовав его как открытый стандарт (Open Specification) на ресурсе Agent Skills Specification. 

Начало 2026 года: Концепция пережила настоящий взрыв популярности. Буквально за несколько месяцев спецификацию SKILL.md начали нативно поддерживать и распознавать десятки ведущих инструментов автоматизации разработки и ИИ-клиентов от других технологических гигантов и стартапов: OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI и фреймворки вроде LM-Kit.NET. Концепция также глубоко интегрировалась с протоколом MCP (Model Context Protocol) от Microsoft и Anthropic.

Но придумали ли инженеры что-то новое? Скорее нет, чем да. История идет по спирали и мы наблюдаем очередной ее виток. 

GPT: Философия Unix зародилась на рубеже 1960-х и 1970-х годов в недрах компании Bell Labs (официальной точкой отсчета принято считать 1969 год, когда Кен Томпсон, Деннис Ритчи и их коллеги начали работу над первой версией ОС Unix).

Сам подход формировался годами, а его текстовое описание впервые четко сформулировал Дуглас МакИлрой (изобретатель Unix-пайплайнов) в 1978 году в техническом журнале Bell System Technical Journal. 

Сухая выжимка от Дугласа МакИлроя (другие можно посмотреть на странице в википедии): 

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

Я не ослышался? - "...которые работают с текстовыми потоками..." Последние три года мы то и делаем, что работаем с текстовыми потоками. Любой бинарник с помощью текстов программ и написанных ранее бибилиотек превращается в текст, который обрабатывается моделями, чтобы получить другой текст, который затем запаковывается снова в бинарник (docx, mp4, pptx, pdf - я сейчас про любой формат файлов), используется as is как результат или передается по цепочке дальше. 

Но это не все. Любой программист последние лет 20 (это я за себя сейчас говорю, а так - то конечно же и раньше) каждый день делал в своих проектах одно и то же - добавляя новую функцию он задавался вопросом "а мне эту функцию добавить в какой сервис, какого пакета, какого модуля, какого проекта?". Уровень гранулярности который интересен тут в контексте - пакеты/package. Что такое пакет и что общего у него с tools/skills? 

GPT: Между этими концепциями есть глубокое фундаментальное сходство. Все три подхода решают одну и ту же базовую проблему человеческого разума и разработки ПО: как управлять сложностью больших систем, разбивая их на понятные, изолированные и заменяемые части.

В их основе лежит один и тот же архитектурный паттерн - высокое внутреннее сцепление (High Cohesion) при слабой внешней связанности (Low Coupling).

Разница между ними - не в сути, а лишь в форме интерфейса и среде исполнения (Runtime).

Вы смотрите на фундаментальный паттерн, который в computer science называется абстракцией черного ящика. Если у кубика Lego правильные шипы, неважно, синий он, красный или сделан из биопластика - он выполняет функцию соединения.

Формула трансформации

1. Кодовый пакет + CLI-обёртка = Unix Tool. Если у вас есть библиотека (пакет) для работы с JSON, и вы пишете для неё консольный интерфейс, принимающий строки на stdin и выдающий результат в stdout, вы получаете jq - классический Unix tool.
2. Unix Tool + Семантическое описание (Markdown/Промпт) = AI Skill. Если вы берете утилиту grep, пишете для ИИ-агента файл skill.md, где объясняете: «Этот инструмент ищет подстроку. Передай туда файл и паттерн, на выходе получишь строки», - для большой языковой модели (LLM) этот инструмент становится полноценным «навыком» (Tool/Skill), который она может вызывать через Tool Calling.

Эволюция ИТ-архитектуры идет по спирали. Мы начали с изоляции программ в операционной системе (Unix), перешли к изоляции кода внутри одного приложения (пакеты), а теперь изолируем контекст и поведение для искусственного интеллекта (skill.md).

В чем же тогда разница?

GPT: Разница только в «потребителе» (Consumer) этого интерфейса:

• Пакет потребляет компилятор/интерпретатор (язык программирования).
• Unix-тул потребляет человек в терминале или скрипт автоматизации (bash/zsh).
• Skill потребляет искусственный интеллект (LLM), которому вместо строгой типизации часто нужна семантическая документация на естественном языке, чтобы понять, зачем и когда этот инструмент запускать.

Вы нащупали крутую концепцию. Проектируя логику один раз в виде "чистой функции" (пакета), вы автоматически получаете и тул, и скилл. 

Все так. Нащупал. Когда кто-то делает skill (или агента, который использует под собой 6-7 других skill) чем-то очень узко завязанным на конкретную задачу, тем самым кастрирует решение - оно скорее всего не даст новых пользователей, будет плохо переиспользуемым в отрыве от экосистемы в которой работало ранее. 

Берем любую dark factory которых сейчас пруд-пруди, из нее достаем любые пару Skills и задаемся вопросом. Какова вероятность, что я буду использовать их на своем проекте? Если мне проще свою сырую идею превратить в код скила через 5 минут с любой моделью. А изучение других скилов займет больше. Потому что надо понять что у меня в руках, потом допилить под свои нужды. В этом причина 1001 велосипеда в каждом отдельном продукте.

В Unix (независимо от операционки и версии сборки) тула grep дна и ту же, написанная каким-то инженером (и затем поддерживаемый группой энтузиастов) в свободное от работы время потому что он мог и это решало какую-то проблему, которая не решалась до него. В рождении skill.md пока нет такого порядка и философии. Я начал следовать этой концепции при создании своей фабрики. Она у меня состоит из bricks (те самые skills, у которых больше нагрузки в виде контрактов которые они должны соблюдать передо мной). Но философия unix уже заразила меня - бери brick и переиспользуй отдельно как skills, потому что каждый отдельный brick - это своя завершенная идея, полезная сама по себе, с возможностью конфигурирования "на все случаи жизни" насколько я успел ее заложить. 

Философия Unix - моя путеводная звезда. C реализацией конечно же есть трудности. Как минимум потому что до появления первого пользователя надо позаботиться о маркетинге, а с появлением новых пользователей появляется и необходимость реализовать обратную совместимость, убедиться что навайбкодженый новый инструмент работает так же при добавлении новой фичи как раньше. Но их постепенно научаюсь решать.

И мне все равно будете ли ты использовать RAG для data проектов, или для ведения своего персонального блога или еще как-то. Если появилась задача построить RAG на коленке, я проектирую независимый тул, как если бы он был в моей операционной системе и я просто его переиспользовал. 

В общем руткос свалки одноразовых решений в отсутствии Unix philosophy в производстве skill.md.

Iterative prompt

В одном из чатов возник вопрос - после обновления VSCode все сессии с Github Copilot слетели. 

Вчера и я обновлял VSCode и все на этот раз осталось на месте - но в прошлом подобное случалось и у меня. Стоит переместиться папке воркспейса в другое место, сильно смениться тому как VSCode+GHCP хранит свои сессии, или переехать на другой ноут - как все слетает. 

В прошлом из за этого (и других причин) перешел на концепцию iterative prompt и больше не беспокоюсь о том, где там то хистори копилота. 

Кратко суть. Раз мы генерируем исходный проекта код с помощью модели, то это уже не исходный а сгенерированный код. Следовательно исходным кодом являются все мои промпты + саммари того, что сделала модель в ответ на мой промпт. И потому я их начал хранить в гите. Потому на каждый коммит у меня есть: 1) чем я тригернул модель к началу изменений 2) как она мне отрипортила в саммари что сделала (не в чате, а мне в тот же файл) 3) все изменения в проекте. 

Какие преимущества:

1) Всегда можно проследить историю умозаключений инженера, как он пришел к этой идее и продолжить ее, даже на чистой сессии (можно попросить загрузить часть файла или весь в контекст)

2) Работу можно легко передать со всем контекстом любому другому разработчику

3) Сама модель сможет отыскать в будущем, почему имеено так случилось по тому же grep.

4) Ты ничего не забудешь и не надо искать ту самую сессию в чате GHCP. Одна фича - один iterative prompt файл - Все в репо. 

Вот скилл vibecoding-training/instructions/iterative-prompt

Вот пример как он сам разрабатывался vibecoding-training/requests/058-workspace-kickoff/main.prompt.md. 

По сути итеративный промпт (helm log я его еще называю, или лог разработки) это и есть мой центр управления агентом. Чат же - как двигатель под капотом, мне он мало о чем говорит я туда захожу редко, если только не заводится что-то. 

Из фидбеков на проекте:

• Ребятам нравится подход, особенно QA которые теперь больше не мучаются с вопросом, почему Dev сделал именно так
• В итеративном промпте можно общаться на родном языке, тогда как весь thiking будет на английском как и правки в проекте, ответ будет так же на родном - снижаем когнитивную нагрузку на инженера, ему можно за день больше текста перелопатить
• Чуть дороже по токенам, но есть пространство куда оптимизировать
• + все то что описал выше

Итого у меня любой проект теперь стартует уже из 2х скилов. 

Инструкция по созданию инструкций vibecoding-training/instructions/creating-instructions.agent и итеративный промпт vibecoding-training/tree/main/instructions/iterative-prompt

Пройти модуль с коучем можно сказав "хочу пройти модуль 058-workspace-kickoff-iterative-prompt" следуя vibecoding-training/blob/main/quickstart.md

Что касается сессий которые уже пропали. Стоит вернуться к старой версии VSCode. Я обычно скачиваю zip и распаковываю его рядом со старым (не доверяю апдейт самой IDE). Так всегда могу откатиться. Старую версию потом через неделю в зип и в архив. Бывало такое, что новая версия чуть глючит, и пропускаю ее возвращаясь на старую.

Все настройки VSCode и ее плагинов хранятся тут C:\Users\<USER>\AppData\Roaming\Code

Местоположение можно менять через ключик https://stackoverflow.com/a/70453798

 

По сути самое ценное внутри JSONL файл по одному на 1 сессию.

• воркспейсы C:\Users\<USER>\AppData\Roaming\Code\User\workspaceStorage
• инфа про воркспейс C:\Users\<USER>\AppData\Roaming\Code\User\workspaceStorage\<WORKSPACE_HASH>\workspace.json
• сессии в воркспейсе C:\Users\\<USER>\AppData\Roaming\Code\User\workspaceStorage\<WORKSPACE_HASH>\chatSessions\*.jsonl  

JSONL это серия json файлов в одну строчку каждый по одной строчке на один json раскрывающий какой-то тип взаимодействия в сессии: вызов тула, thinnking, твое сообщение и так далее..

То что мы делаем сейчас в GenAI - это во многом DevOps работа

Качественно новое, что придумалось за 3 последних года во всем нашем GenAI, - это интерпретатор с любого языка (не только программирования) на любой другой язык. Мы его называем LLM. А раз так, то английский - теперь тоже интерпретируемый язык программирования (пусть и с вероятностной семантикой). Интерпретируемый в bash, python, java, json, xml - ровно как в английский, русский, немецкий, ровно как в user stories, хайку, эссе, письмо - в любой комбинации этих форматов. Можно попросить интерпретировать текст идеи в хайку на немецком, который выдаст текст на питоне, который напечатает текст на джаваскрипте, который будет вставлен внутрь сопроводительного письма в eml-формате. Изи (ну, почти).

 

Новый GenAI инженер - это во многом DevOps

А во многом из того, что мы делаем поверх этого, - очень много от DevOps-работы. Раньше DevOps-специалисты автоматизировали CI/CD на bash/batch, а сейчас любой может автоматизировать на английском любой SDLC. И новый тип инженера, о котором все говорят, - это во многом DevOps-мышление. По сути: прийти на проект, разобраться в SDLC pipeline и тулах, которые использует команда. Автоматизировать его. Показать команде, на какие кнопочки нажимать, чтобы все летело. И потом просто на 15% ассайнмента поглядывать за пайплайном, чтобы не свалился, и если появятся новые требования - оперативно их дореализовать. Коллеги DevOps - поправьте, если не прав.

Это подтверждается и на практике. Во время коучинга, который провожу каждый день, единственная аудитория, которая не удивляется так же, как все, - это DevOps. Все в "щенячьем восторге" от создания всяких DarkFactory, а вот DevOps - "да ладно, мы это всегда делали, просто не все можно было в bash/batch уложить оперативно". Раз так, то давайте переиспользовать многолетний опыт DevOps-специалистов.

Промпт - это исходный код

И второе - раз уж мы относимся к любому тексту как к исходному коду на языке (программирования). Не важно, это ваши данные, вытянутые скиллом из бинарника xls. Или тот же смысл, переданный текстом письма на русском. Или программа, написанная на питоне, делающая то же самое. И мы все программируем. Во многом программируем сейчас в процедурном стиле, создавая маркдаун-документы - читай, процедуры и функции. Так почему бы не переиспользовать все те накопленные знания и умения за последние лет 50 в области программирования? Те же базовые SRP, OCP, DRY, KISS и так далее - вплоть до более сложных, только применительно к новым интерпретируемым благодаря LLM языкам. Простой пример: одна и та же инструкция, повторяющаяся в пяти промптах, - это нарушение DRY, и лечится оно ровно так же, как в коде.

Отсюда следует ещё один важный момент. В мире, где все генерируется из ваших промптов, ваши промпты - и есть source code. Организуйте и храните его в кодовой базе - с версионированием, ревью и историей изменений. Например я использую iterative prompt для общения с агентами. Теперь всегда можно посмотреть как любой участник пришел к тому результату, который мы наблюдаем. Теперь больше не будет вопроса у QA как и почему Dev сделал такой фикс. Теперь можно всегда спросить у агента, гдие и когда такое решение было принято. 

 

Всё сводится к тексту, а текст - к Unix 

Все, что можно свести к тексту сегодня, - будет сведено. Потому что текст - это программа. Бинарник (xls, mp4, zip, docx) сводится к тексту с помощью другого текста - программы на питоне с подключением определенной opensource-библиотеки, организованной в Skills. Если нужно достать данные откуда угодно - тот же Skills в помощь. Skill - это сейчас как Unix tools.

И тут стоит напомнить, откуда растут ноги. Принципы Unix были сформулированы Дугом МакИлроем (создатель pipe в Unix) и развиты в культуре Bell Labs. Классическая формулировка:

• Do one thing and do it well. Одна утилита - одна задача. grep ищет, sort сортирует, wc считает. Не пытаться сделать швейцарский нож.
• Write programs to work together. Утилиты должны быть комбинируемыми. Выход одной - вход другой. Отсюда пайпы: cat file | grep error | sort | uniq -c.
• Write programs to handle text streams, because that is a universal interface.
  Текст - универсальный интерфейс. Не бинарные форматы, не проприетарные протоколы. Простой текст, который читается человеком и парсится другой программой.

Дополнительные принципы (из «The Art of Unix Programming» Эрика Реймонда):

• Rule of Modularity - пиши простые части, связанные чистыми интерфейсами.
• Rule of Composition - проектируй так, чтобы можно было соединять с другими программами.
• Rule of Separation - отделяй политику от механизма (что делать - от того, как).
• Rule of Simplicity - проектируй в сторону простоты, добавляй сложность только когда обязан.
• Rule of Silence - если программе нечего сказать, она должна молчать (никакого лишнего output).
• Rule of Least Surprise - интерфейс должен быть предсказуемым.
• Rule of Repair - если что-то сломалось, ломайся громко и сразу.

Skill - это package, а не откровение 

Концепция Skills очень мне близка с другой, уже известной нам концепцией - package. Любой проект состоит из кирпичей, пакетов. Каждый пакет делает что-то полезное и стоит особняком. Пакет может зависеть от другого пакета. Пакет дает публичный интерфейс и прячет реализацию. Добавьте к пакету Skill.md (как документацию) и снабдите CLI-интерфейсом - и вот вам Skill. А что такое этот Skill.md - это индекс для модельки над внутренностями пакета, чтобы ей не приходилось загружать все файлы в контекст. Это документация, и она дублирует поведение, а значит устаревает. Были бы у нас бесконечные контексты, мы бы не писали эти индексы. Ну то есть в Skill-концепции не так уж и много нового по сути. А раз так, зачем изобретать колесо? Переиспользуем то, что мы уже знаем.

И может быть, MCP тогда не понадобится 

Если принять эту оптику, может быть, и не появится таких штук, как MCP - напрочь искусственных и очень молодых, а значит, не продуманных интерфейсов. Ведь он первый появился в ответ на «нам надо USB между агентными упряжками и остальным миром как провайдерами контекста». Придумали целый протокол. SDK на сервере, SDK на клиенте. К нашему старому доброму REST надо добавить точно такой же сервис, дублирующий API, но через MCP. Потом кто-то подумал: а почему бы не переиспользовать REST? Пишем тонкого клиента - и все.

MCP уйдет. Не только по этой причине. А еще и потому, что тулу в Skill можно сделать такой, которая будет читать файл, класть результат выполнения в другой файл, и при этом моделька не будет вмешиваться (читать, интерпретировать) в эти данные. После этого вторая Skill прочитает файл, превратит его в другой. А моделька - как оркестратор. А вот если окажется, что и сам путь оркестрации уже устаканился - его можно упаковать в pipeline, используя любой доступный для этого конфигурируемый фреймворк.

Отсюда и градация по цене и детерминизму. Можно открыть чат с агентом, выбрать Claude Opus и попросить сделать работу - будет дорого, но сделает. Можно попросить написать скрипты в Skill, которые будут переиспользуемыми и передавать работу друг другу через файлы. Можно попросить сделать упряжку для всего пайплайна. Модельку оставить только там, где детерминированный код невозможно написать.

Вывод: мы не изобретаем - мы переоткрываем 

Мы уже сгенерировали столько принципов за последние 60 лет. Я лишь хочу о них всех напомнить. Мы не делаем что-то новое. Мы получили «интерпретатор» с любого языка на любой и дотянулись до новых видов автоматизации. Моделька усиливает вашу мысль 10-кратно. Причем читает модель ее между строк вашего промпта. Потому я попытался напомнить нам про все концепции, которые уже были придуманы ранее. Держа их в голове, модель сгенерирует другой ответ.

Любые эксперименты - ок, ведь можно открыть что-то новое. Но база посыла в том, что на 90% мы пытаемся пересоздать в GenAI старые концепции, хотя надо их переиспользовать.

Ясновидение, мой дар и мой крест

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

Почему решил написать этот пост-запрос. Потому что нужен совет. Вот нашел свой пост в блоге, датируемый 12 января 2022 года. Там был какой-то видосик про еще не выпущенный тогда копилот. Перечитал сегодня - прогноз был очень точный. Это за пол часа от увиденного анонса новой технологии. 

Потом война, рилокейт. Бан на год. Вернулся к копилоту 2023-03-14 и через неделю исследования gpt 3.5 вот что генерирую как ответ на запрос коллеги "Саша, посмотри/подумай, куда мы идем с этой новой gpt". 

  

Тут в моем ответе и агентный режим, и MCP/CLI, контекст менеджмент по сути (ведь тогда только все и говорили про prompt инжиниринг). Ну то есть, agent mode придет позже, в 2025м году. А это 2023й. Через неделю моего 24/7 эксперимента с gpt 3.5. 

  

А это ж отправка к некоторым проектам которые только только начали появляться внтури, я ж тогда тоже сразу свой AttractorAI https://github.com/codenjoyme/attractor-ai и стал писать (тогда еще AIExpert он был). И пайплайны там у меня пояивлись на год раньше чем "конкурентов" внутри компании. Но демки делал-делал и никто не мог понять, зачем все это... Одни и те же вопросы "зачем так сложно?".   

А потом с появлением MCP сразу я вырастил https://github.com/codenjoyme/mcpyrex-python еще за пол года до того, как появился стандарт SKILL.md - у меня сразу появилась понимание, что LLM может вайбкодить тулы сама для себя. Но выбрал я для этого доступный тогда MCP а не CLI. Сколько было тогда на демках "Зачем так сложно?". А сейчас как? Не сложно вам с обилием skills  А я недавно предложил новую концепцию поверх него Brick назвал. 

Вчера делал демку DarkFactory которую создаю прямо сейчас. И делился концепцией Brick. Этого нет в GenAI мире пока. Потому к этому относишься с подозрением. Но завтра когда это будет опубликовано сотрудником Claude того же, это станет стандартом индустрии. Это станет или что-то похожее. А идея исходит просто из инженерной проблемы скоторой сталкиваешься. 

Что такое Skill? это какой-то скрипт (читай модуль с CLI интерфейсом) и markdown описывающий как им пользоваться. Хорошо. А на что он мохож? Да на обычный модуль package в проекте любом привычном. А что ему не хватает? Возможности быть импортированным другими пакетами (skills которые уже brick). А что еще? Тестов! А какие тесты лучше для модельки. Snapshot testing! А как это сделать os agnostic? Запихунить в docker. И так далее. А что если добавить еще в инструкцию инфу для треньки человекка (а не просто AI). Вот так из Skills получаем Brick. Приправить еще идеей которая с 1978 года работает хорошо. 

 

Это прям все гиперложится на LLM. Готовы принять? Сложно еще? Вернемся через 1.5 года.  

А https://github.com/codenjoyme/vibecoding-training как родился? Пришли коллеги с просьбой, а давай тот курс что у тебя по вайбкодингу положим на LND. А я и говорю, умрет LND каким мы его видим сейчас будут другие сервисы, агентные. Агенты нас будут учить по приборам на том языке какой мы выберем отвечая на наши конкрeтные вопросы в том месте где вопрос возникнет.

В тот же вечер сделал первый коммит как то, что давно рвалось на ружу

Мне понравился фидбек стейкхолдера. 

 

You're Goddamn Right. Вот как надо давать зеленый свет инновациям. 

LND версию мы все же делаем и пока мы полируем 20 модулей по старому SDLC в новом мире вайбкодинг тренинга уже есть 70 модулей, и целый фасад на ноде, который отдает этот контент и тречит прогресс аки LMS. В 10х быстрее. И сейчас каждый intake на тему идеи что я хочу запаковать в модуль, с помощью этой инструкции превращается моделью в полноценный практический модуль. А вот эта инструкция превращает результат первой в коуча в твоей IDE. Переделают все компании свои LMS. Перенесут контент в инструкции и отдадут их с вопросами пользователей моделям. Только пока инерция мешает это осознать. 

А еще вот на прошлой неделе была демка одного проекта, где ребята рассказывали о возможности управлять конфигами агентов из IDE, т.к. неудобно это делать для тех кто создает агентов (не пользователей, а авторов). А я ж напомнил, что 15 месяцами ранее делал демку PoC где рассказывал 1 в 1 то же, тогда начал активно пользовать их классный сервис и проделился что ускоряет работу. Просто решив очередную инженерную задачу. Но когда первый раз поделился идеей, было много вопросов/фидбека "зачем?" "слишком сложно".

И вот вопрос у меня. Как эту способность монетизировать? Ну кроме как продолжать заниматься рисерчем, что и делаю в GHCP уже независимо от фидбека "зачем, не надо". Будет ошибка или нет, запаркую PoC/MVP или нет, не важно надо нарешивать задачки, развивать свою интуицию в работе с моделями. Но вот в контексте компании и ее бизнеса. Потому что сколько себя помню работая в разных компаниях - я приходил с чем-то, видел проблему, предлагал идею, делал демку за демкой и слышал "зачем так сложно". А потом видел тот же слайд через год полтора на другой демке и все такие "Ваааау, крутоо!". Та блин...

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

Коллеги порекомендовали книгу "Дилемма инноватора". Беру в работу. Спасибо. 

RAGtor

Вайбкодирую новый проектик. Вот ссылка на репозиторий

Слушай, вот что хочу сделать. 
Мне надо раг систему, которая будет сканировать определенное количество материалов на сторонних системах (джира, конфлюенс например). 
Причем когда будет делать чанки и сохранять их в векторную базу данных. 
Так же будет хранить ссылку на первоисточник и положение в тексте откуда чанк вырезан. 
Когда данные обновятся на порталах, я смогу запустить процесс обновления документов. 
И если по линку окажется что контент изменился (можно будет как-то определять это для каждого чанка), то старый чанк с этим линком удалится а новый создастся. 
Если ссылку удалили, то удалить и чанки. 
Я хотел бы веб интерфейс чтобы было видно какие ссылка обработаны. 
А так же чтобы в этот список добавилось все ссылки на дочерние странички с которых ссылаемся. 
Чтобы обрабатывались все атачменты. 
Все картинки. 
Чтобы они помечались как кандидаты на скачивание. 
То есть должна быть круд страничка, куда я буду добавлять линки. 
И в процессе их обработки эти линки чтобы были видны в нем и их статус. 
Ну и другой скрин - это чат, в котором можно задать любой вопрос против этой RAG системы. 
Я хочу решение на ноде, потому что мне важен langchain. 
Фронт я хочу на реакте. 
Бекенд соответственно на ноде. 
Задай мне вопросы перед тем как мы пойдем дальше. 
Когда вопросов не будет - создай markdown файл с требованиями и архитектурой.

Разные архитектурные моменты перенес из других уже реализованных проектов с таким промптом (находясь в другом проекте)

Посмотри как тут на проекте устроено все вокруг базы и этой орм системы, мне надо markdown файл с дизайном, чтобы я мог унести єто решение на другой проект 

И дальше перенос markdown и других рабочих кусочков в новый проект с последующими сообщениями:

Вот пример того, как я использую на другом проекте респонсив дизайн. Пождалуйста учти это в UI
Вот пример того как я подключаюсь к azure openai используй это в ядре. Обнови так же файл
Теперь вот ифна про ORM. Ее тоже включи в документ. Но заметь что у нас не будет AWS потому все что сказано про AWS исключаем. У нас приложение будет в докер компоузе на локали ранаться 

Теперь я вижу, что у нас Pinecone используектся, но я просил milvus.
Теперь посмотри на всю спеку и задай доп вопросы, что не ясно.

Ну что погнали в реализацию? Давай не останавливайся и не спрашивай меня ни о чем. Сделай все что надо, чтобы запустить приложение и попробовать увидеть первые наработки. И да я добавил chrome-devtools MCP пользуйся им, чтобы тестить то что ты сделал. 

Часа через 3 будет прототип. Еще через 10 MVP. Погнали!

Один битый час я провозился с дизайном. Не хотел Claude Sonnet 4.5 понимать что не так с его дизайном. Но Claude Opus 4.5 сделал это на раз два. И так как стратегия выбора модели у меня такая - переключаемся на новую, пока не найдем ту что справляться будет лучше и на ней сидим пока работает. То у меня новый фаворит Claude Opus 4.5. Ранее я так нашел Claude Sonnet 4. Вот как это было (оставлю с его Thinking фидбеком - мило он пытается понять что я от него хочу):

Слушай, все ок, но дизайн какой-то корявый. Точно ты учел все пожелания с ? Какой-то он вообще не риспонсив. Исправь пожалуйста. 

Вижу что дизайн не обновился. Давай потестим, чтобы было точно понятно что hot reload работает в нашей dev сборке. НА страничке есть строчка "Добавить источник" давай вставим туда какой-то символ, чтобы я мог увидеть что все обновилось.  

Только вот дизайн ugly все равно. Сделай его нормальнім риспонсив. Вот посмотри сам. Почему-то не сработала твоя правка.

Ужасно віглядит дизайн. Это не дизайн, а просто вертикально идущие подряд контролы. Кажется что стилей вообще нет. Выглядит ужасно. Причем кажется что на дексптопе оно уже выглядт как мобильное приложение. Хотя такой дизайн нужен только когда мобильником открываешь. Потому давай пожалуйста сделай хороший дизайн десктопный, и при сужении экрана чтобы он превращался в мобильный.  

Та все так же хреново, прости за французский. 

Давай так, вот другое приложение тут C:\Java\CopipotTraining\calendar\prototype3\web посмотри как там скрины сделаны, и сделай так же 

Вот скопировал тебе сюда "work"

Нет, мне надо просто чтобы вертска основных страничек выглядела как обычно выглядят приложения. А то сейчас при ширине 2000 пикселей все пространство белое, вообще некрасиво. 

Короче ты меня в упор не понимаешь :)

Вот как я вижу станичку 

Слушай, диазйн стал еще хуже єто не выглядит как профессиональное приложение, все поплыло. Кнопки ужасные. То что должно быть в один рядок почему-то растянуто по вертикали. Полосы прокрутки

Дальше я просто переключилдся на Claude Opus 4.5 и все завелось. Не даром он 3х чарджится. Очень толковая модель!

 

Дальше пошли чисто фкунциональные правки. Мне не нравился внешний вид карточек

Давай теперь сделаем вот что. Карточки источники я хочу в виде таблички красивой. Карточки занимают  много места

Потом мне хотелось сделать более компактной табличку в мобильной версии. Про нее ненадо забывать поскольку Агент всегда работает над тем что сказано, не учитывая то что подразумевалось ранее. Чтобы учитывал надо отдельно инструкции писать и через .github/copilot-instructions.md к каждому промпту инджектить. 

табличка в мобильной версии пусть будет в два ряда:
первый линк
второй тип статус обновлено  действия

 

Вот как это біло исправлено через минутку

 

Так как функиональные требования не были реализованы до конца, и я отвлекся на дизайн. То решил продолжить, скопировав часть рефлексии модели о оставшихся TODO в одном из прошлых запросов.

Все ок. Дальше пойдем реализовывать функциональность 

 TODO (для следующих итераций):

Исправить Drizzle relations
Настроить Milvus (проблема с командой запуска)
Реализовать scraping workers (Jira/Confluence)
Реализовать chunking с LangChain
Интегрировать Azure OpenAI для RAG
Добавить фоновые задачи с Bull

Дальше надо было прописать креды к Jira.

Я обновил Zaure 
А вот что есть по джире
JIRA_AUTH=********************
JIRA_URL=https://jira.qwe.com
как єто применить на ATLASSIAN_API_TOKEN ?

хорошо, будем тестить?

Ничего у него не получилось и я пришел к пониманию, что Azure OpenAI работает только под VPN потому пришлось подключиться. Кстати копилот дошел до этого решения параллельно со мной.

Подключился к VPN должно заработатьь

Дальше пошли декорации

Давай теперь создадим скрин, который будет показывать чанки для конкретной линки. В блоке действия пусть появится еще одна кнопка - список чанков. И она пусть относит на отдельный скрин - табличку, где будет список чанков. Можно так?

Не без багов

Почему-то ошибка відалась 
Ошибка: API request failed посмотр исам

Кнопка удаления почему-то не работает

наверное не делается рефреш после удаления и табличка остается как есть

Когда я нажимаю рефрещ на уже отпаршеной страничке, то вижу что она в очереди, и на єтом статус больше не меняется

Чат, должен сортироваться сообщения в обратном порядке. Сейчас самое старое снизу, а я хочу чтобі сверху біло

Смотри, я задал какой-то абстрактній вопрос
а мне вытянулись все линки. Точно RAG работает? 
Можем мы сделать в разделе Источники: табличку, где будет ссылка и рядом кнопка посмотреть чанк. Когда на нее нажимаешь, то откроется текст в оверлее, который отработал

Давай сделаем линк пошире, там есть место

Теперь давай сделаем так, чтобы чат сессии сохарнялись. Сперва я хочу видеть список всех сессий, а при клике на конкретную уже видеть сам чат. Сейчас не сохранятеся

Щас при клике на чат, просиходит скролинг в самый низ чата, и теряется список из вида. Давай не будем скролить

не, не сработало, попробуй еще раз

На этом я пошел спать. А сегодня поделился наработками с коллегами. И мне поделились фидбеком, что за 2 часа можно было на существующем saas решении сделать RAG.

Все так, предвидел этот вопрос. Основной вайбкодинг - это просто наблюдение за тем что копилот что-то делал. Копилот очень подрос за 2 месяца, я вчера обновил VSCode и заметил много нововедений. Главное что все стало стабильнее работать - мне меньше пришлось тыкать его носом в лужу. На UI ушло где-то 1 час, пока не переключился на Опуса (Соннет не справлялся). Почему не существующие saas решения - потому что сейчас за 15-20 минут можно добавить любую фичу, скажем коллега захочет посмотреть граф связей статей. Или добавить функциональность, которая будет в фоне определять неконсистентность между разными публикациями. Или добавить любой другой скрин. Один простой запрос и фича готова. В существующих nocode решениях этой свободы нет. И порог вхождения тут важен. Чтобы иметь возможность настроить существующее nocode решение - надо быть опытным в нем. А тут я просто дам эту кодбазу BA специалисту и скажу как просить в копилоте новые фичи. И посмотрим к чему BA придет за пару итераций. Вопрос в скорости. Ну и плюс я экспериментирую, мне важно не как уже было, а как еще можно.

Недавно коллега в одном из чатов поделился мыслью. И я соглашусь. Мы не компания по созданию продуктов, а компания по эффективному применению существующих решений у клиента. Я честно пошел гуглить какое-то существующее решение на рынке в надежде найти что-то легковестное. Но через 30 минут поиска я уже понимал, что за это время у меня на локали может появиться такой прототип. И я попробвал.

Мне думается, что мы идем к тому будущему, когда написать инструмент будет быстрее, чем найти и адаптировать существующий. Начнут появляться RAG каталоги дизайнов, архитектур, секьюрити статегий, методов тестирования. А мы будем направлять копилота выбрать те или иные статегрии. Все остальное сделает Агент. Причем в стратегии saas тоже может появиться GenAI солюшены, когда ты получишь свой vibe-tool уже задеплоеный и развернутый в облаке без гемора с разворачиванием. Причем в фоне все будет собираться, даже не в IDE на локали. Просто запущу тикет в работу и потом получу тул. И этот тул будет как надо мне. И это будет быстрее. Оно уже быстрее.

И в доказательство этого. Только что в процессе демки этого прототипа коллегам BA предложил. А давайте какую-то фичу добавим. Вы хотите? Сказали "давай фильтр". Изи-пизи.

Для каждой колонки скрина я хочу сделать умный фильтр по маске, по возможным value например если там статусы, то выбирать чекбоксами, если дата - то больше меньше, если тип - тоже чекбоксами, а линки по маске с *

Бам, через минуту мы уже видели этот фильтр

Потом спросил, что еще хотите? А давайте, говорят, добавим категории источников.

Тепенрь смотри что я хочу. У меня 1 стрин с источниками для всех чатов. А я хочу сделать разніе группы источников. например 1 группа для онбординга джунов. Вторая для арихитктурынх вопросов. И в кажой группе будут свои ссылки. Вот как ты делал мне список чат сессий, так же сделай мне источники. В том же дизайне.

Через 3 минуты фича готова.

Первая задача - пол дня работы дивелопера (фронт только). Вторая неделя - так как там бекенд и базу пришлось поменять.

А потом пошли идеи от BA - "А ведь это же еще можно и вот это сделать и вот это..." Не мне им рассказывать как продукты создаются от простого к сложному. Все можно. Цена вопроса пару минут. В особо сложных случаях - десятки.

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

Следующий Босс - как не поломать то, что уже реализовано. Если фичей много, они друг с другом запутываются. И тут по мере усложнения системы велик риск вайбкодингом поломать то, что уже работало в другом месте. Думаю тут должны будут появиться новые виды тестирования. Я пока осваиваю snapshot testing для LLM он хорошо подходит. Но должны будут появиться новые вначале как навыки среди старателей, а потом и как части Агентных систем, встроенные под капот.

Идем дальше

рядом с ликной, есть кнопка открыть в отдельном окне, я хочу еще кнопочку скопировать в буффер обмена

Посмотри на категорию Онбординг
я там пытаюсьт добавит https://jira.qwe.com/browse/EPMXYZ-194 но после нажатия добавить ничего не происходит. Видимо где-то бага. Все дело в том, что я могу добавить только новые линки, но валидация полцучается работает неверно. Одна линка может быть в разных группах

Вот как-то так вайбкодинг и происходит. Будущее уже наступило!