Вот только ты подумал что 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