Ваша работа — выпускать код, который доказанно работает 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