Второй доклад от Павла Бучнева сосредотачивается на 3 уровне: как разработчику грамотно заниматься контекст инжинирингом — на мой взгляд одним из самых главных современных скилов современного разработчика, аналитика, qa, еtc.
Иллюстрации в докладе потрясающие, взял небольшое количество для примера).
Павел на своем опыте разработал свой личный фреймворк успешной AI разработки, сфокусированном на управлении контекстом. По факту можно считать его подход разновидностью CDD (Context Driven Development).
Подход основан основана на:
- Целом ряде best bractis,
- Написанным им open source CTX библиотеке,
- Ручном ювелирном управлении контекстом (даже Claude Code в его парадигме хуже т.к. добавляет много своего контекста)
- Feature Request в строгом и детализированном формате
- Продуманных гайдлайнах в базовом контексте
- Из непривычного - очень много Feature Request и контекста он задает голосом, на его личном опыте это работает гораздо быстрее и в большем потоке чем описывать руками. Исходник прогоняет через chatGPT превращая его в FR.
UPD: кстати это видео выложили в открытый доступ.
Иллюстрации в докладе потрясающие, взял небольшое количество для примера).
Павел на своем опыте разработал свой личный фреймворк успешной AI разработки, сфокусированном на управлении контекстом. По факту можно считать его подход разновидностью CDD (Context Driven Development).
Подход основан основана на:
- Целом ряде best bractis,
- Написанным им open source CTX библиотеке,
- Ручном ювелирном управлении контекстом (даже Claude Code в его парадигме хуже т.к. добавляет много своего контекста)
- Feature Request в строгом и детализированном формате
- Продуманных гайдлайнах в базовом контексте
- Из непривычного - очень много Feature Request и контекста он задает голосом, на его личном опыте это работает гораздо быстрее и в большем потоке чем описывать руками. Исходник прогоняет через chatGPT превращая его в FR.
UPD: кстати это видео выложили в открытый доступ.
🔥7👍3❤1
Исследование. Взяли 46 команд которые использовали AI в разработке и сопоставили их с аналогичными 46 командами не использующими AI.
Самая важная мысль: разрыв в производительности этих команд увеличивается со временем.
Уже сейчас х4.
Если гипотетически предположить что тенденция сохранится через несколько лет разрыв будет лишь кратно (второй слайд).
"Богатые становятся богаче". Те кто раньше внедрил AI могут наращивать преимущество, в то время как отстающие будут все больше отставать.
Самая важная мысль: разрыв в производительности этих команд увеличивается со временем.
Уже сейчас х4.
Если гипотетически предположить что тенденция сохранится через несколько лет разрыв будет лишь кратно (второй слайд).
"Богатые становятся богаче". Те кто раньше внедрил AI могут наращивать преимущество, в то время как отстающие будут все больше отставать.
👍5🔥2
Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 Prompt Caching: токены LLM в 10 раз дешевле — но за счёт чего?
Подготовили перевод просто пушечной статьи про кэширование промтов. Внутри много теоретической базы изложенной простыми словами, с классными примерами и наглядными анимациями(без математики тоже не обошлось 🫠) .
Вот как сам автор описал свою статью и мы с ним полностью согласны:
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
Подготовили перевод просто пушечной статьи про кэширование промтов. Внутри много теоретической базы изложенной простыми словами, с классными примерами и наглядными анимациями
Вот как сам автор описал свою статью и мы с ним полностью согласны:
Не удовлетворившись ответами в документации вендоров ПО для разработчиков, которые хорошо объясняют, как пользоваться кэшированием промптов, но аккуратно обходят вопрос о том, что именно кэшируется, я решил копнуть глубже.
Я нырнул в кроличью нору устройства LLM, пока не понял, какие именно данные провайдеры кэшируют, для чего они используются и как это делает всё быстрее и дешевле для всех.
К концу этой статьи вы:
– глубже поймёте, как работают LLM
– сформируете новую интуицию о том, почему LLM устроены именно так
– разберётесь, какие именно нули и единицы кэшируются и как это снижает стоимость ваших запросов к LLM
📚 Читайте и комментируйте на Хабр.
@ai_for_devs
👍3🔥3❤1
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