Forwarded from Книжный куб (Alexander Polomodov)
From Vibe Coding To Vibe Engineering (Рубрика #AI)
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они
1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.
2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.
3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.
Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.
Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
for loop, а системному дизайну и проверке качества.- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
YouTube
From Vibe Coding To Vibe Engineering – Kitze, Sizzy
Web development has always moved in cycles of hype, from frameworks to tooling. With the rise of large language models, we're entering a new era of "vibe coding," where developers shape software through collaboration with Al rather than syntax. This talk…
👍7❤1
Вот только ты подумал что JetBrains наконец то выпустили BYOK, слили junie в ai, и Claudе начнет отставать, и тут на тебе - Claude Code получил нативную поддержку LSP - это замашка на один из основных "доводов против claude code" - не было хорошего понимания кода по сравнению с IDE и даже редакторами вроде cursor. Борьба за лучший инструмент в enterprise сегменте в разгаре.
BYOK JetBrains кстати хорошо ладит с litellm proxy и свежей GLM-4.7 – по бенчмаркам чуть ли не opus. Выглядит потенциально неплохо, проверяем.
Пока закрытость и кастомный api anthropic имхо наоборот бьют скорее ей в минус, т.к. в enterprise борьба за ИБ зачастую актуальнее.
И работает это ровно до тех пор пока к claude моделям в действительности (а не в бенчмарках) достоточно плотно не подберутся китайцы.
BYOK JetBrains кстати хорошо ладит с litellm proxy и свежей GLM-4.7 – по бенчмаркам чуть ли не opus. Выглядит потенциально неплохо, проверяем.
Пока закрытость и кастомный api anthropic имхо наоборот бьют скорее ей в минус, т.к. в enterprise борьба за ИБ зачастую актуальнее.
И работает это ровно до тех пор пока к claude моделям в действительности (а не в бенчмарках) достоточно плотно не подберутся китайцы.
The JetBrains Blog
Bring Your Own Key (BYOK) Is Now Live in JetBrains IDEs | The JetBrains AI Blog
Bring Your Own Key (BYOK) is now available in the AI chat inside JetBrains IDEs as well as for AI agents, including JetBrains’ Junie and Claude Agent. Whether you’re looking to use cutting-edge fronti
👍6
Ваша работа — выпускать код, который доказанно работает https://habr.com/p/980006/
Habr
Ваша работа — выпускать код, который доказанно работает
Во всех обсуждениях ценности ИИ-помощников в разработке ПО мне встречается одна печальная история: разработчик-джун, вооружившийся каким-нибудь LLM-инструментом, создаёт для своих коллег или...
💯6❤1🔥1
Кстати пропустил новость что TypeScript вышел на 1-е место среди языков на github.
TypeScript cтал самым используемым языком на платформе.
Я в отпуске перебрал несколько сотен новых open source проектов (развлечение у меня такое), большая часть из них была на node/ts.
Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным.
TypeScript cтал самым используемым языком на платформе.
Я в отпуске перебрал несколько сотен новых open source проектов (развлечение у меня такое), большая часть из них была на node/ts.
Команды всё чаще предпочитают строго типизированный код при использовании ИИ: развитая типизация TypeScript делает автосгенерированный AI-код более надежным.
Хабр
TypeScript стал самым популярным языком на GitHub, впервые обогнав Python и JavaScript
GitHub представил ежегодный отчёт Octoverse 2025, и впервые за всю историю рейтинг возглавил TypeScript. Ещё недавно язык воспринимался как надстройка над JavaScript, но теперь он стал новым...
👍6🤔1
Forwarded from Книжный куб (Alexander Polomodov)
How Claude Code Works - Как устроен Claude Code изнутри: разбор архитектуры от основателя PromptLayer, Jared Zoneraich (Рубрика #Agents)
Посмотрел интересный доклад с конференции AI Engineer Conference в Нью-Йорке, который сделал Джаред Зонерайх, основатель PromptLayer и человек, который видит тысячи промптов в день. Его платформа обрабатывает миллионы запросов к LLM, а команда переписала свою инженерную организацию вокруг Claude Code. Джаред не из Anthropic, но его инсайты - это результат dogfooding и анализа работы тысяч разработчиков. Главная мысль Джареда в том, что кодинг-агенты заработали не из-за сложной архитектуры, а благодаря её упрощению. Вместо RAG, векторных баз и сложных оркестраторов Anthropic пошли по пути "дайте модели инструменты и не мешайте". Если подробнее, то тезисы автора выглядят так3,
✈️ Архитектура = один while-цикл + инструменты
Всё. Больше никаких ветвлений, подграфов и state machines. Модель сама решает, что делать дальше. Это N0-цикл внутри Claude Code.
🤖 Инструменты копируют поведение разработчика в терминале
- Bash - король всех инструментов. Модель может создать Python-скрипт, запустить его, посмотреть вывод, удалить. Это даёт гибкость тысяч утилит без кастомной разработки.
- Read/Grep/Glob - поиск как вы бы искали сами. Без векторных баз, просто grep и glob-паттерны.
- Edit - диффы вместо перезаписи файлов. Быстрее, дешевле по токенам, меньше ошибок.
- Todos - структурированное планирование через промпт, а не детерминированный код.
🗒 Todo-листы работают на честном слове
Система не форсит выполнение задач детерминированно. Вместо этого в системный промпт вставляется инструкция "одна задача за раз, отмечай выполненные". Модель просто следует инструкции — и это работает, потому что современные LLM хорошо понимают контекст.
🍬 Контекст-менеджмент через H2A и Compressor
- H2A (Half-to-Half Async) - двойной буфер для паузы/возобновления работы. Можете вмешаться mid-task без перезапуска.
- Compressor wU2 - срабатывает на ~92% заполнения контекста, суммирует середину, оставляя начало и конец. Это дает модели "место для размышлений" перед кризисом.
💯 Простота > сложности
Джаред цитирует Zen of Python: "Simple is better than complex. Complex is better than complicated". Все попытки защитить модель от галлюцинаций через сложный scaffolding - это технический долг. Лучше дождаться улучшения модели и удалить лишний код.
В итоге, это все можно свести к простым советам:
1. Перестаньте over-оптимизировать. Если вы строите агентов и пишете костыли для работы с текущими моделями - вы тратите время. Лучше инвестировать в чистые промпты и простую архитектуру.
2. Bash как универсальный адаптер. Вместо написания кастомных инструментов для каждой задачи - дайте агенту доступ к shell. Все утилиты (ffmpeg, git, grep) уже есть в системе.
3. Prompt engineering > сложные системы. Файл CLAUDE.md с инструкциями эффективнее локальных векторных баз. Модель сама исследует репозиторий, если знает, что искать.
4. Готовьтесь к следующей волне. Если ваша команда еще не переписала workflow вокруг кодинг-агентов - вы отстаете. PromptLayer сделали правило: "если задача < 1 часа - делай через Claude Code, не планируй".
В общем, как говорит Джаред: "Less scaffolding, more model".
P.S.
Примерно про это же говорил Nik Pash, Head of AI в Cline в докладе "Hard Won Lessons from Building Effective AI Coding Agents", о котором я уже рассказывал
#AI #ML #Agents #Software #Engineering #Architecture
Посмотрел интересный доклад с конференции AI Engineer Conference в Нью-Йорке, который сделал Джаред Зонерайх, основатель PromptLayer и человек, который видит тысячи промптов в день. Его платформа обрабатывает миллионы запросов к LLM, а команда переписала свою инженерную организацию вокруг Claude Code. Джаред не из Anthropic, но его инсайты - это результат dogfooding и анализа работы тысяч разработчиков. Главная мысль Джареда в том, что кодинг-агенты заработали не из-за сложной архитектуры, а благодаря её упрощению. Вместо RAG, векторных баз и сложных оркестраторов Anthropic пошли по пути "дайте модели инструменты и не мешайте". Если подробнее, то тезисы автора выглядят так3,
# n0 master loop
while (tool_call):
execute_tool()
feed_results_to_model()
Всё. Больше никаких ветвлений, подграфов и state machines. Модель сама решает, что делать дальше. Это N0-цикл внутри Claude Code.
- Bash - король всех инструментов. Модель может создать Python-скрипт, запустить его, посмотреть вывод, удалить. Это даёт гибкость тысяч утилит без кастомной разработки.
- Read/Grep/Glob - поиск как вы бы искали сами. Без векторных баз, просто grep и glob-паттерны.
- Edit - диффы вместо перезаписи файлов. Быстрее, дешевле по токенам, меньше ошибок.
- Todos - структурированное планирование через промпт, а не детерминированный код.
🗒 Todo-листы работают на честном слове
Система не форсит выполнение задач детерминированно. Вместо этого в системный промпт вставляется инструкция "одна задача за раз, отмечай выполненные". Модель просто следует инструкции — и это работает, потому что современные LLM хорошо понимают контекст.
- H2A (Half-to-Half Async) - двойной буфер для паузы/возобновления работы. Можете вмешаться mid-task без перезапуска.
- Compressor wU2 - срабатывает на ~92% заполнения контекста, суммирует середину, оставляя начало и конец. Это дает модели "место для размышлений" перед кризисом.
Джаред цитирует Zen of Python: "Simple is better than complex. Complex is better than complicated". Все попытки защитить модель от галлюцинаций через сложный scaffolding - это технический долг. Лучше дождаться улучшения модели и удалить лишний код.
В итоге, это все можно свести к простым советам:
1. Перестаньте over-оптимизировать. Если вы строите агентов и пишете костыли для работы с текущими моделями - вы тратите время. Лучше инвестировать в чистые промпты и простую архитектуру.
2. Bash как универсальный адаптер. Вместо написания кастомных инструментов для каждой задачи - дайте агенту доступ к shell. Все утилиты (ffmpeg, git, grep) уже есть в системе.
3. Prompt engineering > сложные системы. Файл CLAUDE.md с инструкциями эффективнее локальных векторных баз. Модель сама исследует репозиторий, если знает, что искать.
4. Готовьтесь к следующей волне. Если ваша команда еще не переписала workflow вокруг кодинг-агентов - вы отстаете. PromptLayer сделали правило: "если задача < 1 часа - делай через Claude Code, не планируй".
В общем, как говорит Джаред: "Less scaffolding, more model".
P.S.
Примерно про это же говорил Nik Pash, Head of AI в Cline в докладе "Hard Won Lessons from Building Effective AI Coding Agents", о котором я уже рассказывал
#AI #ML #Agents #Software #Engineering #Architecture
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
How Claude Code Works - Jared Zoneraich, PromptLayer
Deep dive into what we have independently figured out about the architecture and implementation of Claude's code generation capabilities. Not officially endorsed by Anthropic.
Speaker: Jared Zoneraich | Founder & CEO, PromptLayer
https://x.com/imjaredz…
Speaker: Jared Zoneraich | Founder & CEO, PromptLayer
https://x.com/imjaredz…
👍6🔥2
Forwarded from Смоллтех Сообщество
Второй доклад в программе на митап о внедрении AI и лидерстве в смоллтехе.
🎤"Уровни зрелости внедрения AI в процессы" - Иван Поддубный, СТО в Вебпрактик
Во многих компаниях AI вводят на уровне "внедрите какую-нибудь иишку и отчитайтесь". Заканчивается такое внедрение транскрибацией звонков и мнением "мы современные и с AI”. Как не попасться и действительно внедрять инновации, поэтапно и с оглядкой на зрелость вашей компании?
Расскажу:
- По каким моделям оценки по внедрению AI определить уровень зрелости компании
- Как пользоваться ими для аудита вашей компании
- Куда двигаться, когда картина прояснилась, чтобы идти в ногу с рынком
С доклада можно унести: понимание, где вы с компанией сейчас и какие шаги нужно делать дальше.
Успевайте зарегистрироваться до 26 января!
#доклад_small_tech
🎤"Уровни зрелости внедрения AI в процессы" - Иван Поддубный, СТО в Вебпрактик
Во многих компаниях AI вводят на уровне "внедрите какую-нибудь иишку и отчитайтесь". Заканчивается такое внедрение транскрибацией звонков и мнением "мы современные и с AI”. Как не попасться и действительно внедрять инновации, поэтапно и с оглядкой на зрелость вашей компании?
Расскажу:
- По каким моделям оценки по внедрению AI определить уровень зрелости компании
- Как пользоваться ими для аудита вашей компании
- Куда двигаться, когда картина прояснилась, чтобы идти в ногу с рынком
С доклада можно унести: понимание, где вы с компанией сейчас и какие шаги нужно делать дальше.
Успевайте зарегистрироваться до 26 января!
#доклад_small_tech
👍8
Сначала Торвальдс, теперь Мартин выпустили обзоры на AI кодинг, и все в целом оценивают его положительно.
Это хорошие персоны и статьи, на которых можно ссылаться при разговоре с AI-скептиками. Те кто внедряет AI в SDLC практически неизбежно сталкивается с сопротивлением изменениям отрасли.
Мне кажется, что солидная часть осознанных AI-скептиков больше сосредоточена среди поклонников "базы" и основ, а также почитании основных классических авторитетов мира разработки ПО.
Тему не обошел и Макконелл в своем относительно свежем интервью.
В общем берем подспорье на вооружение для аргументации с теми, кто все еще считает что это AI еще рано использовать в написании кода.
Это хорошие персоны и статьи, на которых можно ссылаться при разговоре с AI-скептиками. Те кто внедряет AI в SDLC практически неизбежно сталкивается с сопротивлением изменениям отрасли.
Мне кажется, что солидная часть осознанных AI-скептиков больше сосредоточена среди поклонников "базы" и основ, а также почитании основных классических авторитетов мира разработки ПО.
Тему не обошел и Макконелл в своем относительно свежем интервью.
В общем берем подспорье на вооружение для аргументации с теми, кто все еще считает что это AI еще рано использовать в написании кода.
Хабр
Какие выводы сделал Роберт Мартин, поработав с AI Coding?
Автор «Чистого Кода» и «Чистой Архитектуры» всегда славился консерватизмом. С ноября 2025 по январь 2026 в своём X он начал документировать освоение AI coding. Я проанализировал его записи....
👍6
Кстати замечаю что те кто серьезно занимается AI Coding не очень любят когда их называют "вайб кодерами".
В этом есть резон, ведь вайб кодинг как термин в первую очередь ассоциируется с greenfield проектами — нагенерить болванку простого проекта "с нуля" в т.ч. зачастую без навыков.
А работа с текущей кодовой базой требует определенных навыков, архитектурных паттернов, более глубокой и системной работой с контекстом, и, что самое важное, без хороших скилов разработчика это работает плохо.
В этом есть резон, ведь вайб кодинг как термин в первую очередь ассоциируется с greenfield проектами — нагенерить болванку простого проекта "с нуля" в т.ч. зачастую без навыков.
А работа с текущей кодовой базой требует определенных навыков, архитектурных паттернов, более глубокой и системной работой с контекстом, и, что самое важное, без хороших скилов разработчика это работает плохо.
👍6💯6
В пятницу прошел неплохой круглый стол на мероприятии SmallTech.
Вообще термин клевый, мне заходит.
Он позволяет отделять себя от BigTech не "от обратного". И сопоставлять процессы с таким же SmallTech. Построение карьеры в SmallTech для многих — осознанный выбор.
Говорили про AI в SDLC и сложности внедрения в SmallTech.
1. Уровни внедрения
Из присутствующих большая часть аудитории была на 0-2 уровне, на 3ем уровне было всего нескольно человек (подробнее про уровни тут)
2. Окно возможностей SmallTech
Мой коллега очень хорошо отметил: сейчас для смоллтеха отличное окно. Мы более гибкие и можем достигать большего по сравнению с неповоротливым бигтехом. И можем добиться большого технологического прогресса благодаря гибкости.
Хотя в бигтехе есть очень достойные весьма поворотливые 2 исключения, о которых я знаю: Яндекс и Tbank которые говорят о 60% adoption.
3. Размещение
Где размещать AI: сейчас инференс по подпискам сильно выгоднее чем размещать на своем или арендованном железе. По мнению коллег — кратно. Это окно возможностей.
Есть разнонаправленные прогнозы:
а) Инференс дешевеет
б) Вендоры понемногу закручивают гайки
Но точно что именно сейчас — экономически целесообразнее использовать внешние. Особенно для SmallTech.
4. Вопрос ИБ неплохо закрывается:
а) litellmproxy + presido контролирует утечку секретов. Политики работы с персданными должны закрываться классическими приемами вроде базы что у разработчиков не должны быть локально доступа к реальными немаскированным перс данным
б) Примером Тбанка который разрешает через свой proxy ходить во внешние модели. Если Тбанк понимает отсутствие критичности в том, чтобы пускать агентов в бизнес код (говорят они разрешают наружу ходить всем проектам кроме КИ), какой свой рокет саенс вы пытаетесь скрыть от Anthropic? Отличный тезис для безопасников. Конечно, если вы КИ - это другой вопрос.
5. Измерять эффективность?
А очередной раз пришли к тому, что мерить эффективность внедрения ai в sdlc крайне сложно: разработка слишком недетерменированный процесс. Мы не научились качественно измерять разработку, измерять разработку + ai не проще.
ВсеИнструменты говорят: мы смогли измерить и показать бизнесу цифры. Но ключевой момент в этом: этот замер они сделали на изолированных командах с абсолютно типовыми задачами. Таких команд мало у кого есть.
Хотя коллеги из Яндекса говорили что тестирование (в отличии от разработки) изолированно померить удалось и там кратный эффект роста перфоманса.
6. С какого этапа начинать?
Со всех сразу, в особенности выделяя наибольшие процессы. Зачастую это будет разработка и аналитика.
Важно понимать что точка сшивания одна, в любом случае на 4+ этапе вам нужно сливать изменения в один AI пайплайн.
7. Немало затронули и тему с shadow it
а) Есть компании где голова против AI изменений. И тогда выгодоприобретаталем становится сотрудник. Это он может работать на части задач кратно быстрее, а оценки оставляя такие же как раньше, выделяя оставшееся время себе на отдых, развитие или подработки.
б) shadow it также несет в себе риски по ИБ, когда бесконтрольно сливают секреты без ИБ политики.
Одна из ключевых мыслей: практически никто не отрицает что SDLC процессы трансформируются, все спикеры и активно участвующий в беседе зал больше задаются вопросом как проводить эти трансформации у себя в компании, нежели вопросом "зачем" или "надо ли".
Вообще термин клевый, мне заходит.
Он позволяет отделять себя от BigTech не "от обратного". И сопоставлять процессы с таким же SmallTech. Построение карьеры в SmallTech для многих — осознанный выбор.
Говорили про AI в SDLC и сложности внедрения в SmallTech.
1. Уровни внедрения
Из присутствующих большая часть аудитории была на 0-2 уровне, на 3ем уровне было всего нескольно человек (подробнее про уровни тут)
2. Окно возможностей SmallTech
Мой коллега очень хорошо отметил: сейчас для смоллтеха отличное окно. Мы более гибкие и можем достигать большего по сравнению с неповоротливым бигтехом. И можем добиться большого технологического прогресса благодаря гибкости.
Хотя в бигтехе есть очень достойные весьма поворотливые 2 исключения, о которых я знаю: Яндекс и Tbank которые говорят о 60% adoption.
3. Размещение
Где размещать AI: сейчас инференс по подпискам сильно выгоднее чем размещать на своем или арендованном железе. По мнению коллег — кратно. Это окно возможностей.
Есть разнонаправленные прогнозы:
а) Инференс дешевеет
б) Вендоры понемногу закручивают гайки
Но точно что именно сейчас — экономически целесообразнее использовать внешние. Особенно для SmallTech.
4. Вопрос ИБ неплохо закрывается:
а) litellmproxy + presido контролирует утечку секретов. Политики работы с персданными должны закрываться классическими приемами вроде базы что у разработчиков не должны быть локально доступа к реальными немаскированным перс данным
б) Примером Тбанка который разрешает через свой proxy ходить во внешние модели. Если Тбанк понимает отсутствие критичности в том, чтобы пускать агентов в бизнес код (говорят они разрешают наружу ходить всем проектам кроме КИ), какой свой рокет саенс вы пытаетесь скрыть от Anthropic? Отличный тезис для безопасников. Конечно, если вы КИ - это другой вопрос.
5. Измерять эффективность?
А очередной раз пришли к тому, что мерить эффективность внедрения ai в sdlc крайне сложно: разработка слишком недетерменированный процесс. Мы не научились качественно измерять разработку, измерять разработку + ai не проще.
ВсеИнструменты говорят: мы смогли измерить и показать бизнесу цифры. Но ключевой момент в этом: этот замер они сделали на изолированных командах с абсолютно типовыми задачами. Таких команд мало у кого есть.
Хотя коллеги из Яндекса говорили что тестирование (в отличии от разработки) изолированно померить удалось и там кратный эффект роста перфоманса.
6. С какого этапа начинать?
Со всех сразу, в особенности выделяя наибольшие процессы. Зачастую это будет разработка и аналитика.
Важно понимать что точка сшивания одна, в любом случае на 4+ этапе вам нужно сливать изменения в один AI пайплайн.
7. Немало затронули и тему с shadow it
а) Есть компании где голова против AI изменений. И тогда выгодоприобретаталем становится сотрудник. Это он может работать на части задач кратно быстрее, а оценки оставляя такие же как раньше, выделяя оставшееся время себе на отдых, развитие или подработки.
б) shadow it также несет в себе риски по ИБ, когда бесконтрольно сливают секреты без ИБ политики.
Одна из ключевых мыслей: практически никто не отрицает что SDLC процессы трансформируются, все спикеры и активно участвующий в беседе зал больше задаются вопросом как проводить эти трансформации у себя в компании, нежели вопросом "зачем" или "надо ли".
👍10🔥5❤3
WebMCP: протокол взаимодействия AI агентов с сайтами.
В статье наглядный пример как это будет работать.
Теперь будем декларатаивно описываем сценарии взаимодействия агентов с нашими веб-сервисами, вместо попытки агента спарсить происходящее на сайте.
В статье наглядный пример как это будет работать.
Теперь будем декларатаивно описываем сценарии взаимодействия агентов с нашими веб-сервисами, вместо попытки агента спарсить происходящее на сайте.
Хабр
WebMCP: Революция в интеграции ИИ прямо в браузере
Google и Microsoft представили в ограниченном превью новую технологию — WebMCP . Это стандарт, который обещает кардинально изменить взаимодействие ИИ-агентов с веб-приложениями. Если вы уже знакомы с...
👍7
Forwarded from AI for Devs
🤓 SkillsBench: скиллы дают реальный буст, но только если их писал человек
Вышел первый бенчмарк, который проверяет, дают ли «скиллы» реальный прирост ИИ-агентам. Назвали SkillsBench.
Для тех, кто в танке, Skill — папка с инструкциями и подсказками, которую агент читает перед выполнением задачи. Скиллы уже встроены в Claude Code, Gemini CLI и Codex CLI, но до сих пор никто не замерял, помогают ли они на самом деле.
86 задач, 11 доменов, 105 экспертов, 7 308 прогонов на 7 моделях. Каждую задачу тестировали в трёх режимах: без скиллов, со скиллами от человека и со скиллами, которые модель написала себе сама.
🟣 Скиллы от людей дали +16.2 п.п. к pass rate
🟣 На 16 из 84 задач результат ухудшился
🟣 Самогенерированные скиллы не помогли вообще (-1.3 п.п.). Модели не умеют писать инструкции, которые потом сами же используют
🟣 Компактные скиллы из 2-3 модулей работают лучше подробных документаций
Самый удивительный инсайт из исследования – Haiku 4.5 со скиллами обошла Opus 4.5 без них!
Полностью исследование можно прочитать тут.
@ai_for_devs
Вышел первый бенчмарк, который проверяет, дают ли «скиллы» реальный прирост ИИ-агентам. Назвали SkillsBench.
Для тех, кто в танке, Skill — папка с инструкциями и подсказками, которую агент читает перед выполнением задачи. Скиллы уже встроены в Claude Code, Gemini CLI и Codex CLI, но до сих пор никто не замерял, помогают ли они на самом деле.
86 задач, 11 доменов, 105 экспертов, 7 308 прогонов на 7 моделях. Каждую задачу тестировали в трёх режимах: без скиллов, со скиллами от человека и со скиллами, которые модель написала себе сама.
Самый удивительный инсайт из исследования – Haiku 4.5 со скиллами обошла Opus 4.5 без них!
Полностью исследование можно прочитать тут.
@ai_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Я хоть и не являюсь членом ПК конкретно стрима техлидов в Podlodka, с удовольствием и бесплатно их порекламлю как коллег по цеху (я в ПК Podlodka PHP Crew).
Новый сезон посвящен архитектуре данных.
В эпоху AI — контекст наше все. И то как строить архитектуру данных становится даже важнее чем раньше.
Техлидам нужно все больше в этом разбираться.
Затронется вся основная база: от выбора тип хранилищ (SQL, NoSQL, NewSQL), до построения OLAP хранилищ, проектирования DWH, Data Lake, и конечно как делать ETL пайплайны. Причем это не дата конференция для датасаентистов, а доклады будут сфокусированны для техлидов.
Обычно вся стримы подлодки про максимально практические знания, думаю этот тоже будет не исключением.
🗓 Когда: 2 - 6 марта
🔗 Посмотреть подробную программу → (https://podlodka.io/techcrew)
Скидка для подписчиков по промокоду: techlead_stream10
Новый сезон посвящен архитектуре данных.
В эпоху AI — контекст наше все. И то как строить архитектуру данных становится даже важнее чем раньше.
Техлидам нужно все больше в этом разбираться.
Затронется вся основная база: от выбора тип хранилищ (SQL, NoSQL, NewSQL), до построения OLAP хранилищ, проектирования DWH, Data Lake, и конечно как делать ETL пайплайны. Причем это не дата конференция для датасаентистов, а доклады будут сфокусированны для техлидов.
Обычно вся стримы подлодки про максимально практические знания, думаю этот тоже будет не исключением.
🗓 Когда: 2 - 6 марта
🔗 Посмотреть подробную программу → (https://podlodka.io/techcrew)
Скидка для подписчиков по промокоду: techlead_stream10
👍4
Часто думаю об образе базы знаний будущего: как личной, так и корпоративной.
Я любитель концепции docs as code, у меня даже пачка выступлений на эту тему. Но все же, ранее я считал это удел технарей, и применим не для всех проектов. Например сам я использую obisidan, а для семейной вики поднял affine.
Но в последние дни сталкиваюсь с примерами когда его используют уже сильно за пределами технарей т.к. это крайне удобный контекст для AI.
- Мой знакомый коллега рассказал как они внедрили это в юридическую фирму, для улучшения UX в качестве интерфейса используя obsidian.
- Я понимаю что большую часть документации и спецификации можно генерировать кодовыми агентами. Ты можешь попросить кодового агента внести изменения шотганом сразу во все связанные элементы, а самому заниматься ревью этих изменений.
Да, есть новые базы знаний которые априори строятся на markdown, и не используют файловую систему. Но все же им недоступен целый ряд удобств которые предоставляет файловая система + git. Например сквозной патч по всей модели т.к. версионность баз знаний на основе документов в СУБД атомарна.
Я веду свою личную базу знаний в obsidian с 2025, сначала вел хаотично, потом перестроил по PARA методологии. У меня конечно еще мало MOC (Map of Content), и связи слабоватые, есть куда расти.
Но я понимаю что мне влом писать все заметки руками. И хочу в ближайшее время как раз попробовать писать эту базу знаний и рефакторить через агента, ровно в таком же стиле как мы сейчас пишем код.
Из забавного что obsidian понял куда ветер дует и сегодня выпустил консольные команды управления собой. Т.е. он понял что агенты могут стать одним из основных интерфейсов взаимодействия с базой знаний.
К чему все веду: нам нужен гибридный интерфейс ведения базы знаний. Когда мы ведем ее через агента (чат), можем через него запрашивать файлы и все же имеем возможность просматривать структуру и манипулировать ей вручную.
В такой архитектуре хранения исходных данных в СУБД может слишком усложнять реализацию. Возможно, хранение исходных данных в файлах с механиками DocsAsCode (в т.ч. возможностью ревьюить сквозные изменения внесенные агентом) будет наилучшим архитектурным решением для баз знаний будущего.
P.S. На картинке мой скромный граф из обсидиана, далекий от идеала. Если у кого то круче, делитесь скринами, будет чем вдохновляться)
Я любитель концепции docs as code, у меня даже пачка выступлений на эту тему. Но все же, ранее я считал это удел технарей, и применим не для всех проектов. Например сам я использую obisidan, а для семейной вики поднял affine.
Но в последние дни сталкиваюсь с примерами когда его используют уже сильно за пределами технарей т.к. это крайне удобный контекст для AI.
- Мой знакомый коллега рассказал как они внедрили это в юридическую фирму, для улучшения UX в качестве интерфейса используя obsidian.
- Я понимаю что большую часть документации и спецификации можно генерировать кодовыми агентами. Ты можешь попросить кодового агента внести изменения шотганом сразу во все связанные элементы, а самому заниматься ревью этих изменений.
Да, есть новые базы знаний которые априори строятся на markdown, и не используют файловую систему. Но все же им недоступен целый ряд удобств которые предоставляет файловая система + git. Например сквозной патч по всей модели т.к. версионность баз знаний на основе документов в СУБД атомарна.
Я веду свою личную базу знаний в obsidian с 2025, сначала вел хаотично, потом перестроил по PARA методологии. У меня конечно еще мало MOC (Map of Content), и связи слабоватые, есть куда расти.
Но я понимаю что мне влом писать все заметки руками. И хочу в ближайшее время как раз попробовать писать эту базу знаний и рефакторить через агента, ровно в таком же стиле как мы сейчас пишем код.
Из забавного что obsidian понял куда ветер дует и сегодня выпустил консольные команды управления собой. Т.е. он понял что агенты могут стать одним из основных интерфейсов взаимодействия с базой знаний.
К чему все веду: нам нужен гибридный интерфейс ведения базы знаний. Когда мы ведем ее через агента (чат), можем через него запрашивать файлы и все же имеем возможность просматривать структуру и манипулировать ей вручную.
В такой архитектуре хранения исходных данных в СУБД может слишком усложнять реализацию. Возможно, хранение исходных данных в файлах с механиками DocsAsCode (в т.ч. возможностью ревьюить сквозные изменения внесенные агентом) будет наилучшим архитектурным решением для баз знаний будущего.
P.S. На картинке мой скромный граф из обсидиана, далекий от идеала. Если у кого то круче, делитесь скринами, будет чем вдохновляться)
1👍11
Идем дальше в контексте где и как хранить знания.
На днях узнал что в одном крупном банке начали писать спецификации в репе рядом с кодом запуская эксперимент с множеством команд. Сделано это в 1 очередь не из классических плюсов подхода docs as code, а потому что это лучший AI driven подход в настоящее время.
А мы как раз сейчас думаем об обновлении стандарта структуры документации: коллеги аналитики из Вебпрактика представили хороший стандарт спецификации в confluence, но меня гложат сомнения.
- С одной стороны я понимаю что чуть позже я могу и RAG построить по этой доке, и MCP прикрутить.
- С другой, очевидно понимаю что если писать спеку в репозитории то можно применять паттерны SDD простым кодовым агентом БЕЗ ВСЯКИХ НАДСТРОЕК, здесь и сейчас. А RAG не всегда точная штука, не достаточно строго детерменирована.
Да, вытекают и подводные камни, как необходимость адаптации части аналитиков (у нас лишь часть работает с docs as code) и геренацию документации которую может комментить удобно клиент и прочие минусы, но использование AI потенциала здесь и сейчас возможно это все переплевывает.
Но там возникают и следующие вопросы как ее хранить в репозитории. Кажется что SDD фреймверки в виде speckit и openspec возможно не сильно для этого удобны.
Если вы уже меняли образ и структуру своей спецификации для большей AI friednly — делитесь опытом, мне очень интересно)
На днях узнал что в одном крупном банке начали писать спецификации в репе рядом с кодом запуская эксперимент с множеством команд. Сделано это в 1 очередь не из классических плюсов подхода docs as code, а потому что это лучший AI driven подход в настоящее время.
А мы как раз сейчас думаем об обновлении стандарта структуры документации: коллеги аналитики из Вебпрактика представили хороший стандарт спецификации в confluence, но меня гложат сомнения.
- С одной стороны я понимаю что чуть позже я могу и RAG построить по этой доке, и MCP прикрутить.
- С другой, очевидно понимаю что если писать спеку в репозитории то можно применять паттерны SDD простым кодовым агентом БЕЗ ВСЯКИХ НАДСТРОЕК, здесь и сейчас. А RAG не всегда точная штука, не достаточно строго детерменирована.
Да, вытекают и подводные камни, как необходимость адаптации части аналитиков (у нас лишь часть работает с docs as code) и геренацию документации которую может комментить удобно клиент и прочие минусы, но использование AI потенциала здесь и сейчас возможно это все переплевывает.
Но там возникают и следующие вопросы как ее хранить в репозитории. Кажется что SDD фреймверки в виде speckit и openspec возможно не сильно для этого удобны.
Если вы уже меняли образ и структуру своей спецификации для большей AI friednly — делитесь опытом, мне очень интересно)
👍7🤔2
https://martinfowler.com/articles/reduce-friction-ai/knowledge-priming.html
Неплохая статья у Мартина Фаулера с базовыми рекомендациями по контексту в проекте.
Ничего кардинально нового, но неплохо написано и структурировано, с упором на механику работу LLM.
Неплохая статья у Мартина Фаулера с базовыми рекомендациями по контексту в проекте.
Ничего кардинально нового, но неплохо написано и структурировано, с упором на механику работу LLM.
martinfowler.com
Knowledge Priming
Priming an LLM with project context before each session
✍4👍4
Мартин Фаулер спустя 25 лет после создания Agile Manifest собрал в тех же памятных горах закрытую группу для обсуждения будущего разработки с учетом AI реалий.
Ряд участников и в т.ч. сам Мартин выпускали заметки на этот счет.
Мне показался интересным вот этот обзор из 8 тезисов от одной из участниц, мысли занятные.
Ряд участников и в т.ч. сам Мартин выпускали заметки на этот счет.
Мне показался интересным вот этот обзор из 8 тезисов от одной из участниц, мысли занятные.
🔥6