Кстати пропустил новость что 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 процессы трансформируются, все спикеры и активно участвующий в беседе зал больше задаются вопросом как проводить эти трансформации у себя в компании, нежели вопросом "зачем" или "надо ли".
👍11🔥6❤4
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
👍11
Я хоть и не являюсь членом ПК конкретно стрима техлидов в 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 тезисов от одной из участниц, мысли занятные.
🔥7
Forwarded from Книжный куб (Alexander Polomodov)
The third golden age of software engineering - thanks to AI, with Grady Booch (Рубрика #AI)
Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования).
Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:)
В общем, основные тезисы интервью такие
1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код
Буч раскладывает историю на 3 золотых века:
1) 1940-1970 - алгоритмы и автоматизация бизнеса
2) 1970-2000 - объектные абстракции
3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой.
И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции
2️⃣ Экзистенциальная паника - повторяющийся цикл
Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет
3️⃣ ИИ силён там, где паттерны уже установились
Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности.
4️⃣ Software engineering - это не набор кода, а баланс сил и решений
Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями.
5️⃣ Автоматизация ударит по delivery pipeline (и это нормально)
Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение
6️⃣ Чем выше абстракция - тем важнее фундамент
Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами
Кажется, что инженерам теперь качать нужно следующие навыки
- System design и distributed systems, а эта тема неплохо описана на сайте system-design.space
- Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space
- Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом
- Доменные знания: бизнес‑контекст, который теперь ценится еще больше:)
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History
Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования).
Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:)
В общем, основные тезисы интервью такие
1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код
Буч раскладывает историю на 3 золотых века:
1) 1940-1970 - алгоритмы и автоматизация бизнеса
2) 1970-2000 - объектные абстракции
3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой.
И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции
2️⃣ Экзистенциальная паника - повторяющийся цикл
Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет
3️⃣ ИИ силён там, где паттерны уже установились
Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности.
4️⃣ Software engineering - это не набор кода, а баланс сил и решений
Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями.
5️⃣ Автоматизация ударит по delivery pipeline (и это нормально)
Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение
6️⃣ Чем выше абстракция - тем важнее фундамент
Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами
Кажется, что инженерам теперь качать нужно следующие навыки
- System design и distributed systems, а эта тема неплохо описана на сайте system-design.space
- Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space
- Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом
- Доменные знания: бизнес‑контекст, который теперь ценится еще больше:)
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History
YouTube
The third golden age of software engineering – thanks to AI, with Grady Booch
Every few decades, software engineering is declared “dead” or on the verge of being automated away. We’ve heard versions of this story before. But what if it’s just the start of a new “golden age” of a different type of software engineering, like it has been…
👍15
AI code review, поток мыслей.
Сейчас к AI review многие относятся с одной стороны как к "чему-то сбоку".
Поставили, польза какая-то есть, но "до человека далековато".
Часто шумит, нужно немало времени выделить на тюнинг, чтобы повышать его качество.
И вот у целого ряда знакомых это просто как вспомогательный инструмент.
А некоторые даже "поигрались и выключили". Переключились на более важные точки.
В одной из статей услышал фразу что сейчас мы упираемся не в скорость кодинга, а в скорость проверки человеком.
А значит нужно вкладываться в качество AI ревью, уменьшая когнитивную нагрузку.
А значит логично вкладываться в т.ч. в качество AI ревью.
Ок, допустим спустя некоторое количество вложений, мы добились качества AI ревью, которое не "шумит", не вносит переоптимизаций.
Зачем тогда артефакту этого качественного ревью человек? Мы можем подать выход AI ревью сразу на вход агента кодинга.
Т.е. проверка качества сразу после создания, примерно как в нашумевшем Ralph Loop.
Но этот "shift left" не решит вопрос достаточного доверия чтобы убрать и человеческое ревью.
Человеческое ревью мы сможем убрать лишь тогда когда убедимся что не находим ошибок согласно нашему внутреннему чувству компромиссов качества.
Ну и ревью в лупе нужно будет замерять. Ведь возможно модели вырастут настолько, что нужный уровень качества будет выдаваться и без этой петли в виде AI ревью.
Сейчас к AI review многие относятся с одной стороны как к "чему-то сбоку".
Поставили, польза какая-то есть, но "до человека далековато".
Часто шумит, нужно немало времени выделить на тюнинг, чтобы повышать его качество.
И вот у целого ряда знакомых это просто как вспомогательный инструмент.
А некоторые даже "поигрались и выключили". Переключились на более важные точки.
В одной из статей услышал фразу что сейчас мы упираемся не в скорость кодинга, а в скорость проверки человеком.
А значит нужно вкладываться в качество AI ревью, уменьшая когнитивную нагрузку.
А значит логично вкладываться в т.ч. в качество AI ревью.
Ок, допустим спустя некоторое количество вложений, мы добились качества AI ревью, которое не "шумит", не вносит переоптимизаций.
Зачем тогда артефакту этого качественного ревью человек? Мы можем подать выход AI ревью сразу на вход агента кодинга.
Т.е. проверка качества сразу после создания, примерно как в нашумевшем Ralph Loop.
Но этот "shift left" не решит вопрос достаточного доверия чтобы убрать и человеческое ревью.
Человеческое ревью мы сможем убрать лишь тогда когда убедимся что не находим ошибок согласно нашему внутреннему чувству компромиссов качества.
Ну и ревью в лупе нужно будет замерять. Ведь возможно модели вырастут настолько, что нужный уровень качества будет выдаваться и без этой петли в виде AI ревью.
👍9❤5🔥3
Forwarded from AI и грабли
Самый неочевидный лайфхак этого месяца – добавить в системные инструкции своего агента вот это:
Учти, что я с тобой часто общаюсь через транскрибатор голоса. Он иногда каверкает смысл и термины, так что вместо того, чтобы слепо следовать всему, что получаешь от меня – сначала подумай, что я на самом деле сказал. Учитывай контекст проекта/чата
👍7
Anthropic показали Claude Mythos Preview — и сразу заявили: в паблик пока модель выпускать не будут.
Рост по бенчам в коде впечатляющий. И этот зверь через какое то время станет новым опусом.
https://habr.com/p/1020560/
Рост по бенчам в коде впечатляющий. И этот зверь через какое то время станет новым опусом.
https://habr.com/p/1020560/
Habr
Anthropic показали Claude Mythos Preview — и сразу заявили: в паблик модель выпускать не будут
Anthropic запустили Project Glasswing — закрытую инициативу по defensive security вместе с AWS, Apple, Google, Microsoft, NVIDIA, Cisco, CrowdStrike, JPMorganChase, Linux Foundation и другими. Внутри...
👍7
Forwarded from Артём Ерошенко | Тестируем с умом
Тысячи багов, которые мы «протестировали»
Помните мой пост про шахматную фигуру, которой нет в правилах? Тогда я писал про утечку. Теперь всё официально.
7 апреля Anthropic запустила Project Glasswing — коалицию из AWS, Apple, Google, Microsoft, CrowdStrike и ещё десятков компаний. Цель: использовать Claude Mythos Preview для защиты критической инфраструктуры. Модель не будет доступна широкой публике, слишком опасна.
И вот что меня зацепило больше всего.
Mythos нашёл тысячи zero-day уязвимостей. В каждом основном браузере. В каждой основной операционной системе. Самой старой найденной дыре 27 лет. Она жила в OpenBSD, системе, которая известна именно своей безопасностью.
Двадцать. Семь. Лет.
Эти проекты тестируются тысячами инженеров. Проходят code review, фаззинг, пентесты, статический анализ. И всё равно тысячи критических багов сидели в коде годами и десятилетиями.
Как тестировщик, я не могу пройти мимо этого факта. Мы привыкли думать, что если продукт зрелый, если у него большое комьюнити, если его постоянно проверяют, то он безопасен. Оказывается, нет. Мы просто не видели то, что не умели искать.
И тут возникает неудобный вопрос: если AI находит то, что не нашли тысячи специалистов за десятилетия, может, проблема не в количестве тестирования, а в его подходе? 🤔
Но есть и вторая сторона медали, ещё более тревожная.
Найти уязвимость это полдела. Теперь её нужно исправить. А чтобы исправление дошло до пользователя, разработчик должен написать патч, патч должен пройти review и тесты, нужно выпустить новую версию, и наконец пользователь должен обновиться. Для браузера это дни или недели. Для ОС недели или месяцы. А для embedded-систем или IoT? Может, никогда.
Получается парадокс: чем больше дыр находит AI, тем шире окно, в котором эти дыры уже известны, но ещё не закрыты. Это как если бы вы нашли все замки в доме сломанными, но слесарь сможет прийти только через месяц. А адрес уже в интернете.
В комментариях к прошлому посту Сергей справедливо заметил, что если Mythos находит zero-day, он может подсказать и решение. Да, может. Но решение нужно выкатить. А выкатка это процесс, в котором можно наделать новых багов. Скорость нахождения и скорость исправления это два совершенно разных процесса, и первый теперь работает на порядки быстрее второго.
И когда мы слышим, что код, написанный AI, небезопасен, полезно вспомнить про хроническую дырявость кода, написанного людьми. Тысячи уязвимостей в зрелых проектах, которые тестировались годами, лучшее тому доказательство.
Мы живём в интересное время. AI не просто меняет тестирование, он показывает, насколько наше текущее тестирование было неполным.
Меня это одновременно пугает и вдохновляет. А вас?
Помните мой пост про шахматную фигуру, которой нет в правилах? Тогда я писал про утечку. Теперь всё официально.
7 апреля Anthropic запустила Project Glasswing — коалицию из AWS, Apple, Google, Microsoft, CrowdStrike и ещё десятков компаний. Цель: использовать Claude Mythos Preview для защиты критической инфраструктуры. Модель не будет доступна широкой публике, слишком опасна.
И вот что меня зацепило больше всего.
Mythos нашёл тысячи zero-day уязвимостей. В каждом основном браузере. В каждой основной операционной системе. Самой старой найденной дыре 27 лет. Она жила в OpenBSD, системе, которая известна именно своей безопасностью.
Двадцать. Семь. Лет.
Эти проекты тестируются тысячами инженеров. Проходят code review, фаззинг, пентесты, статический анализ. И всё равно тысячи критических багов сидели в коде годами и десятилетиями.
Как тестировщик, я не могу пройти мимо этого факта. Мы привыкли думать, что если продукт зрелый, если у него большое комьюнити, если его постоянно проверяют, то он безопасен. Оказывается, нет. Мы просто не видели то, что не умели искать.
И тут возникает неудобный вопрос: если AI находит то, что не нашли тысячи специалистов за десятилетия, может, проблема не в количестве тестирования, а в его подходе? 🤔
Но есть и вторая сторона медали, ещё более тревожная.
Найти уязвимость это полдела. Теперь её нужно исправить. А чтобы исправление дошло до пользователя, разработчик должен написать патч, патч должен пройти review и тесты, нужно выпустить новую версию, и наконец пользователь должен обновиться. Для браузера это дни или недели. Для ОС недели или месяцы. А для embedded-систем или IoT? Может, никогда.
Получается парадокс: чем больше дыр находит AI, тем шире окно, в котором эти дыры уже известны, но ещё не закрыты. Это как если бы вы нашли все замки в доме сломанными, но слесарь сможет прийти только через месяц. А адрес уже в интернете.
В комментариях к прошлому посту Сергей справедливо заметил, что если Mythos находит zero-day, он может подсказать и решение. Да, может. Но решение нужно выкатить. А выкатка это процесс, в котором можно наделать новых багов. Скорость нахождения и скорость исправления это два совершенно разных процесса, и первый теперь работает на порядки быстрее второго.
И когда мы слышим, что код, написанный AI, небезопасен, полезно вспомнить про хроническую дырявость кода, написанного людьми. Тысячи уязвимостей в зрелых проектах, которые тестировались годами, лучшее тому доказательство.
Мы живём в интересное время. AI не просто меняет тестирование, он показывает, насколько наше текущее тестирование было неполным.
Меня это одновременно пугает и вдохновляет. А вас?
👍5😱4
В прошую пятницу на Devops Conf Александр Поломодов (бывш CTO Тбанк, сейчас руководит AI трансформацией SDLC банка) выступил с хорошим докладом про вектор развития SDLC.
Мне понравилась цепочка мыслей
1. Согласно мировым опросам AI повышает личную эффективность, но не сильно повышает общую производительность потока.
2. Это происходит потому, что в среднем в корпорациях на написание кода уходит далеко не самое большое количество времени (кажется в исследованиях фигурировала цифра до 25%). И большое количество времени уходит на трения между ролями, потеря на передачи работы по конвееру и размазывании ответственности.
3. И один из возможных вариантов куда все пойдут - в схлопывание ролей чтобы убрать потери на передаче.
Т.к. часть функций в каждой роли автоматизируются AI агентом, то ты можешь эти функции попробовать сложить в одну роль. Да, история циклична и мы можем вернуться к тому с чего начинали.
В Тбанк начали экспериментировать с этим форматом, назвав формат этих команд Software Engineering 2.0. Чтобы не травмировать бизнес они новые процессы начали запускать пока только на новых проектах. Обмениваясь практиками и наработками между SE 1.0 и 2.0.
Nessy на этой картинке - это их sdlc агент, который умеет достаточно много всякого, а Blaze это корпоративный аналог lovable для генерации лендосов без помощи разработчиков.
Тбанк не единственный кто идет в эту сторону. Будучи в ПК ряда конференций и имея широкий круг общения я в т.ч. вижу что часть компаний идет в эту сторону. Кто-то пока только останавливает найм узких ролей, а кто-то запускает найм только фуллстеков. И результаты экспериментов (а где-то даже и масштабирования подхода) положительный.
Рынок дает сигналы. Да они еще не достаточно громкие и массовые, но достаточно явные и уже не от лица мелких компаний, а от лица крупных корпораций и бигтехов.
Мне понравилась цепочка мыслей
1. Согласно мировым опросам AI повышает личную эффективность, но не сильно повышает общую производительность потока.
2. Это происходит потому, что в среднем в корпорациях на написание кода уходит далеко не самое большое количество времени (кажется в исследованиях фигурировала цифра до 25%). И большое количество времени уходит на трения между ролями, потеря на передачи работы по конвееру и размазывании ответственности.
3. И один из возможных вариантов куда все пойдут - в схлопывание ролей чтобы убрать потери на передаче.
Т.к. часть функций в каждой роли автоматизируются AI агентом, то ты можешь эти функции попробовать сложить в одну роль. Да, история циклична и мы можем вернуться к тому с чего начинали.
В Тбанк начали экспериментировать с этим форматом, назвав формат этих команд Software Engineering 2.0. Чтобы не травмировать бизнес они новые процессы начали запускать пока только на новых проектах. Обмениваясь практиками и наработками между SE 1.0 и 2.0.
Nessy на этой картинке - это их sdlc агент, который умеет достаточно много всякого, а Blaze это корпоративный аналог lovable для генерации лендосов без помощи разработчиков.
Тбанк не единственный кто идет в эту сторону. Будучи в ПК ряда конференций и имея широкий круг общения я в т.ч. вижу что часть компаний идет в эту сторону. Кто-то пока только останавливает найм узких ролей, а кто-то запускает найм только фуллстеков. И результаты экспериментов (а где-то даже и масштабирования подхода) положительный.
Рынок дает сигналы. Да они еще не достаточно громкие и массовые, но достаточно явные и уже не от лица мелких компаний, а от лица крупных корпораций и бигтехов.
👍7🔥5
Software Engeneering 2.0 в терминологии Тбанк (этот термин пытались использовать еще до AI с другими посылами), открывает вопросы про кадры. Кто должны быть этими универсальными инженерами и как их растить?
Понятно что сеньеры с 10-15+ летним опытом которые в т.ч. могли поработать в компаниях где аналитиков и QA еще/уже не было - справятся, это ок.
В этом плане хочется считать что я как раз в этой парадигме хорошо захожу т.к. всегда качал ширину:
- Поработал и на фронте и на беке (в т.ч. без аналитиков и QA)
- Строил с нуля отделы QA, Аналитики, Devops
- Нанимал и управлял специалистами этого профиля, погружался в специфику их работы при развитии отделов
- Регулярно посещаю и выступаю на конференциях вроде Heisenbug, AnalystDays, Devopsconf и пр. в т.ч. чтобы быть в тренде их развития.
Думаю в целом сеньер-помидор с аналогичным более узким опытом, но системно уделяющего 15 лет своему развитию, тоже достаточно быстро подхватит базу кругозора соседних ролей.
Плюсом, Александр в своем докладе еще подчеркивает что часть сложности в т.ч. должна снимать развитая платформа. Это к слову что инвестировать в платформенную инженерию нужно продолжать, AI ее не замещает.
Но блин, как вырастить широких инженеров С НУЛЯ?
Если пофантазировать, то в целом если бы ВУЗ учил условно год фронту, год беку, и год на QA/Аналитику. Причем все на реальных рыночных задачах... то можно было бы получить такого широкого инженера мидл уровня.
Но звучит не очень реально.
Понятно что сеньеры с 10-15+ летним опытом которые в т.ч. могли поработать в компаниях где аналитиков и QA еще/уже не было - справятся, это ок.
В этом плане хочется считать что я как раз в этой парадигме хорошо захожу т.к. всегда качал ширину:
- Поработал и на фронте и на беке (в т.ч. без аналитиков и QA)
- Строил с нуля отделы QA, Аналитики, Devops
- Нанимал и управлял специалистами этого профиля, погружался в специфику их работы при развитии отделов
- Регулярно посещаю и выступаю на конференциях вроде Heisenbug, AnalystDays, Devopsconf и пр. в т.ч. чтобы быть в тренде их развития.
Думаю в целом сеньер-помидор с аналогичным более узким опытом, но системно уделяющего 15 лет своему развитию, тоже достаточно быстро подхватит базу кругозора соседних ролей.
Плюсом, Александр в своем докладе еще подчеркивает что часть сложности в т.ч. должна снимать развитая платформа. Это к слову что инвестировать в платформенную инженерию нужно продолжать, AI ее не замещает.
Но блин, как вырастить широких инженеров С НУЛЯ?
Если пофантазировать, то в целом если бы ВУЗ учил условно год фронту, год беку, и год на QA/Аналитику. Причем все на реальных рыночных задачах... то можно было бы получить такого широкого инженера мидл уровня.
Но звучит не очень реально.
👍6🔥5