То что мы делаем сейчас в 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 или нет, не важно надо нарешивать задачки, развивать свою интуицию в работе с моделями. Но вот в контексте компании и ее бизнеса. Потому что сколько себя помню работая в разных компаниях - я приходил с чем-то, видел проблему, предлагал идею, делал демку за демкой и слышал "зачем так сложно". А потом видел тот же слайд через год полтора на другой демке и все такие "Ваааау, крутоо!". Та блин...

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

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

AI summary сегодняшней встречи, где рассказываю про GenAI

Три кита, на которых стоит любой агент

Когда мы говорим про любого агента — будь то ChatGPT, GitHub Copilot или какая-то кастомная система — ему нужно дать три ключевых компонента.

Глаза: как агент видит мир

Агенту нужно видеть мир так же, как его видите вы. Но есть нюанс — он видит всё в текстовом формате. Поэтому первая задача: дать инструмент, с помощью которого агент сможет получить доступ к сырым данным в виде структурированного текста.

Примеры:

• Видеоролик → транскрипция даёт доступ к тексту
• Miro-борд → нужна возможность увидеть структуру диаграммы, а не просто набор квадратиков
• Excel на SharePoint → агент должен уметь открыть таблицу по ссылке и прочитать данные

Руки: как агент влияет на мир

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

Примеры:

• Создание видео с аватаром → нужен инструмент для обращения к сервису генерации видео
• Построение диаграммы в Miro → нужен плагин для доступа к борду
• Редактирование Excel → нужны права на изменение файла в конкретном месте

Память: зачем агент всё это делает

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

В агентных системах типа GitHub Copilot вы просто создаёте markdown-файл с инструкцией, где описываете:

• Что вы хотите делать и зачем
• Как пользоваться "глазами" и "руками"
• Какой результат должен получиться

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

И вот я, эээ, сделал, эээ, как-бы, эээ, это, эээ, деплой, эээ, руками...

Зашел на митинг. Рассматривают всякие разные кейзы использования AI у клиента. Докладчик умничка, видно что старается, что не часто у микрофона, мысль хорошая, но постоянно заполняет паузу протяжным звуком "ээээ". И вдруг становится очень сложно слушать. Выдержал 10 минут и отключился. Но как понять, что именно интересного было на том митинге - ведь интересное точно было. Ну как минимум после можно посмотреть на 2х - увеличение скорости просмотра видео добавляет живости спикеру. А можно пойти еще дальше. 

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

В мире где есть LLM любой вид контента стоит пытаться приводить в текст. Для видео это транскрипция. Например на любом youtube ролике можно скачать транскрипцию и затем передать ее в любой чат с любой моделью.

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

Вот prompt (форма может быть свободная - бери идею)

What is this about? 
"""
<Put transcription here>
"""
Please show me summary about this video then help me to guide on it.

Here is a link to the video 

https://www.youtube.com/watch?v=YLlYrbkTpJ4

Based on the transcription log please build me a link with a timestamp where Author talking about something. Next I will ask about terms to find.

Please answer me on <Language>.

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

Навайбкодить PoC за 10 часов, а MVP за 100? Теперь изи

У меня больше нет сомнений о том, что LLM + GenAI инженер могут закодить полноценный MVP в 20х быстре, чем классическая команда. 

В прошлом году я сдал один такой проект - за 100 часов вайбкодинга мы (я + Github Copilot + MCP + Agent mode + Instruction files + Claude Sonnet 4) реализовали MVP++ проект который я сдал клиенту оставив его довольным результатом - так он сказал. 

Объем функционала - команда из 4 человек на 3 месяца. За 100 часов. Архитектура? Node.js, Type script, React, Vite, Drizzle ORM, PostgreSQL, AWS lambdas, SST. 

В руки мне передали прототип монолит написанный так же в вайбкодинг режиме. В последствии пришлось переехать на AWS, причем дважды сменив архитектуру в процессе уточненных требований, выделить Backend и так далее, все чтобы приложение повзрослело. 

Все эти 100 часов размазанные по моих выходным дням я не смотрел в код (я только сейчас, пока пишу эти строчки, узнал что там был TypeScript). Но косвенно со временем упирался в те или иные долги, которые мы тут же устраняли. 

17 инструкций описывающих все основные части SDLC. Некоторое количество воспомагательных скриптов. 

Чат по новой фиче начинался с "Тикет номер 34, погнали!" все остальное описано в инструкциях, как достать тикет из гитаба, на что обращать внимание во время разработки, как тестировать приложение (да-да через Chrome Devtools MCP Claude Sonnet 4 сам себя тестил), куда и как подгялдеть в базу, как задеплоить, как написать release note и закрыть тикет. 

Что делал я? Только выискивал галлюцинации в процессе и просил его править инструкции, чтобы в будущем их не возникало. Стоял на своем, когда моделька забывала что мы делаем. Но с каждой пракой в инструкции я все больше уходил в другую задачу, пока LLM пыхтела в IDE. 

Модельке были даны аппрувы делать любые команды кроме Git потому как git add я использовал для того, чтобы зафиксировать то, что моделька сделала хорошо, но пока еще недостаточно для коммита. И я часто делалал rollback приговаривая "я откатил, попробуй еще раз". 

Это не возможно было год назад. Сегодня это реально. Таких проектов у меня на счету уже несколько. Например, если речь идет за PoC - за 10 часов будет готов прототип похожий на этот https://nodocs.me. Причем сам функционал на локали заработал за 3 часа, остальное время настройка хостинга, докера, доменов, SSL.  И знаешь что? 

Сегодня мы сели обсудить с LLM стратегию и монетизацию этого опыта. Продумали воронку. Нашли слабые места в моем предложении. Написали тексты и скрипты. Обработали все-все мои возражения. LLM даже согласилась сходить в LinkedIn поискать потенциальных клиентов (через тот же Chrome Devtools MCP в открытом в хроме и залогиненом LinkedIn). А чтобы вести их предложено даже CRM небольшую написать. И я верю что она(он/оно?) справится. 

А еще установлена связь с командой GithubCopilot - раз в месяц у нас созвоны. Весь год бил в одну точку - стать экспертом в GithubCopilot внутри моей компании. Првоел массу тренингов для команд клиентов. Запустил Vibe Coding for Managers в конце года. Навайбкодил MCPyrex как экстеншен для Copilot/Cursor. Сейчас эти все маленькие шаги складываются в одну большую картинку. 

Будущее наступило. Это все стало возможным за 2025й год. Что принесет 2026?  

Как расширить GithubCopilot с помощью Python и Langchain через MCP

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

Когда появились в нем возможность добавлять instrictions файл (а потом и файлы) все стало несколько интереснее. 

Затем появился MCP протокол и с ним как грибы после дождя начали появляться всевозможные MCP сервера давая тем самым возможность дотянуться из GithubCopilot до любого сервиса. 

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

Как я вышел из ситуации? Ставим python на машину. Размещаем некоторое число python скриптов в корень своего проекта (ссылка на github репозитория в конце поста). Устанавливаем либы как сказано в install.sh.

Прописываем ./.vscode/mcp.json файл. Стартуем там же MCP сервер. 

 

Теперь в GithubCopilot пояились новые tools каждая из которых хорошо расписана и реализована в папке ./mcp_server/tools . Магия в том, что GithubCopilot видит все это как часть проекта, он так же видит примеры реализации тулов. 

И если я попрошу его "создай мне tool который будет делать ________", то он за'boilerplate'ит решение очень близко к тому, что мне надо. 

 

 

 

Мне останется только принять его правки и перезапустить MCP. 

После этого у меня (у GithubCopilot) появится новый детерминируемый tool для производства какой-то полезной логики. 

 

 

 

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

В предложенных примерах я использовал разные инструменты как langchain так и самого python. В них смысла не много, только пример использования. 

Ключики доступа прописаны в .env файле. 

Бери и используй. 

https://github.com/codenjoyme/copilot-mcp-langchain