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
Новый сезон Podlodka PHP Crew с темой про современный PHP
Что планируем в сезоне С 20 по 24 апреля:
- Тема про NATS + асинхронный PHP от Валентина Удальцова.
- Практика на RoadRunner + Temporal
- Воркшоп по FrankenPHP от Саши Макарова
- Саша Новиков расскажет про развитие docker окружений за последние годы.
Обещает раскрыть много полезных фишек как можно улучшить деплой.
- Ну и конечно не забыли про AI, который все больше пронизывает все процессы разработки!
Будут доклады про практику AI кодинга, про лучшие практики в виде использования SDD фреймворков, архитектуру построения RAG и векторного поиска и как писать автотесты на современном PHP фреймворке защищаясь от AI слопа.
И да, я как член ПК готовил почти все AI доклады, а про архитектуру RAG расскажу сам)
Напомню как проходит сессии Podlodka:
Формат — пять дней живых Zoom-сессий по утрам и вечерам, закрытое комьюнити в Telegram и общение со спикерами.
Если хотите лучше понимать, куда движется современная разработка на PHP — залетайте)
https://podlodka.io/phpcrew
Скидка по промокоду techlead_stream_8
Что планируем в сезоне С 20 по 24 апреля:
- Тема про NATS + асинхронный PHP от Валентина Удальцова.
- Практика на RoadRunner + Temporal
- Воркшоп по FrankenPHP от Саши Макарова
- Саша Новиков расскажет про развитие docker окружений за последние годы.
Обещает раскрыть много полезных фишек как можно улучшить деплой.
- Ну и конечно не забыли про AI, который все больше пронизывает все процессы разработки!
Будут доклады про практику AI кодинга, про лучшие практики в виде использования SDD фреймворков, архитектуру построения RAG и векторного поиска и как писать автотесты на современном PHP фреймворке защищаясь от AI слопа.
И да, я как член ПК готовил почти все AI доклады, а про архитектуру RAG расскажу сам)
Напомню как проходит сессии Podlodka:
Формат — пять дней живых Zoom-сессий по утрам и вечерам, закрытое комьюнити в Telegram и общение со спикерами.
Если хотите лучше понимать, куда движется современная разработка на PHP — залетайте)
https://podlodka.io/phpcrew
Скидка по промокоду techlead_stream_8
❤4👍4⚡3
Забавные мысли о том что мы отвыкаем кодить руками:
1. Сделать через годик хакатон. Для лампового кодинга без ИИ )
Уже можно будет говорить "для настоящих хардкорщиков".
2. Делать одну неделю в квартал неделей кодинга без ai, чтобы порох не промокал)
1. Сделать через годик хакатон. Для лампового кодинга без ИИ )
Уже можно будет говорить "для настоящих хардкорщиков".
2. Делать одну неделю в квартал неделей кодинга без ai, чтобы порох не промокал)
😁5👍4😱4
Как с AI решают одну из классических проблем поддержки одного продукта с несколькими паралельно живущими версиями
https://t.me/elkornacio/546
https://t.me/elkornacio/547
https://t.me/elkornacio/546
https://t.me/elkornacio/547
Telegram
ElKornacio
ну и раз я давно молчал, то надо бы поделиться чем-нибудь полезным!
очень много в последний год было разговоров про гипер-кастомизацию.
дескать, теперь можно продукты адаптировать даже под очень небольших клиентов, потому что стоимость доработок копеечная…
очень много в последний год было разговоров про гипер-кастомизацию.
дескать, теперь можно продукты адаптировать даже под очень небольших клиентов, потому что стоимость доработок копеечная…
👍6❤3🤨2
Если кому то казалось что виден край дефицитам мощностей для вычислений, или хотя бы плато - то нет, все только начинается.
Сейчас начинается переход от модели чатов к агентным нагрузкам, а это кратно возрастающая нагрузка https://t.me/book_cube/4517.
Кстати, кто не знал, даже функции в ide автокомплита и контекстного изменения потребляют кратно меньше токенов т.к. работают по другому, и часто вызываются на других моделях. И все больше разработчиков переходя на следующий уровень к агентной нагрузке давят на мощности.
В связи с этим мы начинаем видеть как основные поставщики дотационных подписок начинают закручивать гайки. Последние дни мы видим кучу сигналов:
1. Деградация opus 4.7, быстрее иссякающие лимиты.
2. Обсуждения и ab test что Pro подписка теперь без claude code возможностей.
3. Отмена github новых халявных pro подписок (которые многие абъюзили по черному)
4. В целом все большая "лень" openai моделей которые нужно постоянно уговаривать сделать всю работу, а не только ее часть.
5. Проверка антропиками подписчиков через верификацию по паспортам.
Халява должна была рано или поздно заканчиваться, но у меня были ожидания что это начнется позже. И были надежды что графики стоимости инференса (стоимость падает с годами) и себестоимости подписок пересекутся в какой-то относительно комфортной точке.
Некоторый бизнес в европе работающий на enterprise подписках с расходом по токенам выделяет по 2.5-3k евро на разработчика. Эффективность потребления большинства людей подписок за 20/100/200 долларов далека от того чтобы при росте до 2-3k (в токенах это реальная себестоимость) давать окупаемость.
Что делать:
1. Начинать думать об эффективности потребления токенов в командах.
2. Смиряться с мыслью что нужно будет всем разрабам со временем сидеть на 100-200$ подписках, и даже их будет нехватать. Риск что антропики задушат Pro подписки не мал, и за ними последуют остальные.
3. Лучше изучать возможности локального инференса, держать руку на пульсе когда их уровень будет достаточным. Пока что откровенго демпингованные подписки конечно кратно выгоднее и быстрее любого локального инференса.
Сейчас начинается переход от модели чатов к агентным нагрузкам, а это кратно возрастающая нагрузка https://t.me/book_cube/4517.
Кстати, кто не знал, даже функции в ide автокомплита и контекстного изменения потребляют кратно меньше токенов т.к. работают по другому, и часто вызываются на других моделях. И все больше разработчиков переходя на следующий уровень к агентной нагрузке давят на мощности.
В связи с этим мы начинаем видеть как основные поставщики дотационных подписок начинают закручивать гайки. Последние дни мы видим кучу сигналов:
1. Деградация opus 4.7, быстрее иссякающие лимиты.
2. Обсуждения и ab test что Pro подписка теперь без claude code возможностей.
3. Отмена github новых халявных pro подписок (которые многие абъюзили по черному)
4. В целом все большая "лень" openai моделей которые нужно постоянно уговаривать сделать всю работу, а не только ее часть.
5. Проверка антропиками подписчиков через верификацию по паспортам.
Халява должна была рано или поздно заканчиваться, но у меня были ожидания что это начнется позже. И были надежды что графики стоимости инференса (стоимость падает с годами) и себестоимости подписок пересекутся в какой-то относительно комфортной точке.
Некоторый бизнес в европе работающий на enterprise подписках с расходом по токенам выделяет по 2.5-3k евро на разработчика. Эффективность потребления большинства людей подписок за 20/100/200 долларов далека от того чтобы при росте до 2-3k (в токенах это реальная себестоимость) давать окупаемость.
Что делать:
1. Начинать думать об эффективности потребления токенов в командах.
2. Смиряться с мыслью что нужно будет всем разрабам со временем сидеть на 100-200$ подписках, и даже их будет нехватать. Риск что антропики задушат Pro подписки не мал, и за ними последуют остальные.
3. Лучше изучать возможности локального инференса, держать руку на пульсе когда их уровень будет достаточным. Пока что откровенго демпингованные подписки конечно кратно выгоднее и быстрее любого локального инференса.
👍11❤1
Forwarded from Этихлид
Media is too big
VIEW IN TELEGRAM
Нет, вы посмотрите на этого еретика, о чём он вообще?
Да что этот дед может знать про разработку?
Хотя погодите...
Да это же Роберт Мартин - "Чистый код", "Чистая архитектура", "Идеальный программист", "Быстрая разработка программ"!
За последний год от умеренного скептика он окончательно перешёл в стан апологетов использования ИИ в разработке, а теперь вот сидит у себя на веранде в халате по утрам и жжот глаголом :)
Да что с него взять - дед наверное просто на старости лет выжил из ума, раз такое предлагает!
Нуу, а что насчёт всех вот этих людей?
Kent Beck (XP, TDD)
Martin Fowler (Refactoring, PoEAA)
Dave Farley (Continuous Delivery)
Grady Booch (UML, OOAD)
Gene Kim (Phoenix Project, DevOps Handbook)
—
Это ж всё сплошь архитектурные астронавты - что они могут знать про реальную разработку: как мы перекладываем JSON'ы, про наши CRUDогенераторы, и про то, насколько важно использовать табы вместо пробелов?
Ну да, ну да :)
А получается у них с ИИ именно потому, что для них разработка всегда была не про написание кода.
Идеи этих дедов стали актуальны как никогда.
Кстати, довольно интересно отслеживать эволюцию их взглядов, а с дядей Бобом ещё и спорить иногда случается :)
#rant #дедпримитаблетки
Признайте: ИИ с лёгкостью уделает вас в кодинге. Нет такой задачи, на которую у вас ушёл бы день, а ИИ не сделал бы её за пять минут.
Всё кончено. Код будете писать не вы. Да-да, я знаю. Смиритесь.
Но вот в чём штука - это даёт вам огромную силу, потому что теперь можно делать то, о чём раньше и мечтать не приходилось.
Например, подумайте о покрытии тестами: вы же помните, какая это была морока. Надо писать все эти чёртовы тесты, и вы знаете, что тесты на самом деле не доказывают, что код работает.
Запускаешь code coverage, ухмыляешься и говоришь: ну да, ладно, но это же не значит, что код работает. Это значит только, что он исполняется.
Так вот, теперь это можно исправить, у вас появились ресурсы, чтобы это сделать. Говорите ИИ: покрой этот чёртов код тестами. А потом берёте mutation tester (да, это такой инструмент - и пусть ИИ его вам и напишет, уйдёт минут пять), дальше ИИ запускает этот инструмент, тот вносит изменения в исходный код и прогоняет все тесты. И если тесты не падают - он допишет тест, который поймает эту мутацию, и это значит, что у вас будет покрытие тестами. Ей-богу, у вас будет покрытие тестами.
И знаете, что ещё можно? Можно анализировать качество кода. Можно написать инструмент, который смотрит на цикломатическую сложность.
Кстати, есть отличный инструмент для этого. Ему лет двадцать. Называется CRAP - хорошее название, как расшифровывается - не знаю и знать не хочу. Это комбинация покрытия тестами и цикломатической сложности.
И вы можете сказать ИИ: понизь метрику CRAP - ниже пяти, ниже четырёх, как хочешь. И это заставит его порезать все жирные функции на маленькие и покрыть их все тестами. Ей-богу - подумайте, какие у вас теперь рычаги, чтобы довести код до качества, какого вы никогда не видели.
Знаю-знаю, я тот самый старый дед с Clean Code, но вот что я вам скажу: теперь вы можете сделать код чертовски чище, если заставите ИИ сделать это за вас.
Да что этот дед может знать про разработку?
Хотя погодите...
За последний год от умеренного скептика он окончательно перешёл в стан апологетов использования ИИ в разработке, а теперь вот сидит у себя на веранде в халате по утрам и жжот глаголом :)
Да что с него взять - дед наверное просто на старости лет выжил из ума, раз такое предлагает!
Нуу, а что насчёт всех вот этих людей?
За 52 года программирования оно никогда не приносило столько удовольствия ⬈
90% моих навыков теперь стоят $0 …но остальные 10% стоят в 1000 раз больше
Kent Beck (XP, TDD)
Появление LLM меняет разработку настолько же радикально, как переход от ассемблера к языкам высокого уровня ⬈
Меняется само понятие того, что значит "программировать" ⬈
Martin Fowler (Refactoring, PoEAA)
ИИ выведет на чистую воду тех, кто никогда не умел думать как инженер ⬈
Верификация становится узким местом. Кодогенерация сама по себе дешевая ⬈
Dave Farley (Continuous Delivery)
Это третий золотой век разработки софта - благодаря ИИ ⬈
Меня это не пугает. Меня это радует. Меня это освобождает ⬈
Grady Booch (UML, OOAD)
Писать код руками - это как проявлять фотоплёнку в тёмной комнате. Никто так больше не делает ⬈
Тебе больше не нужны шесть разработчиков плюс UX плюс продукт. Тебе нужен человек с проблемой и разработчик, который её решит ⬈
Gene Kim (Phoenix Project, DevOps Handbook)
—
Это ж всё сплошь архитектурные астронавты - что они могут знать про реальную разработку: как мы перекладываем JSON'ы, про наши CRUDогенераторы, и про то, насколько важно использовать табы вместо пробелов?
Ну да, ну да :)
А получается у них с ИИ именно потому, что для них разработка всегда была не про написание кода.
Идеи этих дедов стали актуальны как никогда.
Кстати, довольно интересно отслеживать эволюцию их взглядов, а с дядей Бобом ещё и спорить иногда случается :)
#rant #дедпримитаблетки
👍15❤1
За неделю много очень событий и пополнение коллекции уточек.
Посетил AiConf (он слеплен с golang, бейджик от голанга выдали), клуб cto от онтико, выступил на подлодке и побывал на heisenbug. Очень много общался с коллегами по рынку на тему развития ai в sdlc.
Ряд важных мыслей за этот период.
1. Многие компании до сих пор на околонулевом уровне адопшена. И даже есть некоторое количество тех кто считает что это не нужно, ссылаясь на избирательные исследования годичной давности.
У многих до сих пор стадия очень ограниченных пилотов.
2. Ключевые страхи многих CTO как не превратиться в машину генерации нейрослопа и не просесть трагически по качеству. Тесты, статанализ - новая критическая инфраструктура. Важность платформы - растет.
3. Многие cto смотрят в сторону и экспериментируют с SDD. Но SDD воспринимаю многими по разному, есть те кто воспринимают его чуть ли не как plan/act на уровне только разработчика, а не инструмент сквозного процесса.
Порадовала коллега qa из авито, которая рассказала что SDD в каких то вертикалях внедряют уже очень широко, и делилась сложностями при написании скилов генерирующих интеграционные тесты.
4. Чуть растроил доклад Артема Ерошенко, в прошлом году он ворвался с ноги про ai, но за год возможно немного не успел за трендами, по этому доклад был больше про исторический обзор, что тоже интересно, но все таки хотелось огонька)
Надеюсь догонит и на следующем HB ворвется с трендами)
5. В большом зале HB на вопрос у кого в продуктах ai видел много рук, на вскидку треть точно. От многих qa слышу не только понимание сложностей тестирования недетерминированной логики, но и осмысленные практики с evals, llm judge, ragas и прочего. Причем прям много было толковых вопросов на эту тему спикерам и хороших кулуарных обсуждений.
6. Яндекс делился практикой адопшена через тренеров которые ходят в команды и помогают настраивать AI процессы. Демократичный достаточно подход который со слов коллег очень помог в разработке, а теперь помогает в процессах тестирования.
7. Важные мысли что путь в 4ый уровень может лежать через автоматизацию узких процессов. Например агентом решать задачки из Sentry, который часто у многих засран и руки не доходят. Присылая MR с решением багов. Коллеги поделились что так разобрали достаточно большой беклог. На них обкатывать решая конкретные узкие задачи, это сильно проще, и потом расширять на продуктовый беклог.
8. Один из руководителей внедрения AI в компании ответил что возможность схлопывания ролей в старых командах появится лишь когда будет автоматизированно агентами достаточное количество подпроцессов. Причем уровень автоматизации будет хорошо покрыт evals прежде чем действительно в существующих командах возможны изменения.
Но новые команды нужно стараться запускать уже в ai first подходе.
9. Новые узкие горлышки, чаще всего слышу что это: бизнес, тестирование (если плохие процессы) и дизайн (что скорее временно, в момент времени или инструмента дизайна не поспевают или дизайнеры не успевают за инструментами).
Посетил AiConf (он слеплен с golang, бейджик от голанга выдали), клуб cto от онтико, выступил на подлодке и побывал на heisenbug. Очень много общался с коллегами по рынку на тему развития ai в sdlc.
Ряд важных мыслей за этот период.
1. Многие компании до сих пор на околонулевом уровне адопшена. И даже есть некоторое количество тех кто считает что это не нужно, ссылаясь на избирательные исследования годичной давности.
У многих до сих пор стадия очень ограниченных пилотов.
2. Ключевые страхи многих CTO как не превратиться в машину генерации нейрослопа и не просесть трагически по качеству. Тесты, статанализ - новая критическая инфраструктура. Важность платформы - растет.
3. Многие cto смотрят в сторону и экспериментируют с SDD. Но SDD воспринимаю многими по разному, есть те кто воспринимают его чуть ли не как plan/act на уровне только разработчика, а не инструмент сквозного процесса.
Порадовала коллега qa из авито, которая рассказала что SDD в каких то вертикалях внедряют уже очень широко, и делилась сложностями при написании скилов генерирующих интеграционные тесты.
4. Чуть растроил доклад Артема Ерошенко, в прошлом году он ворвался с ноги про ai, но за год возможно немного не успел за трендами, по этому доклад был больше про исторический обзор, что тоже интересно, но все таки хотелось огонька)
Надеюсь догонит и на следующем HB ворвется с трендами)
5. В большом зале HB на вопрос у кого в продуктах ai видел много рук, на вскидку треть точно. От многих qa слышу не только понимание сложностей тестирования недетерминированной логики, но и осмысленные практики с evals, llm judge, ragas и прочего. Причем прям много было толковых вопросов на эту тему спикерам и хороших кулуарных обсуждений.
6. Яндекс делился практикой адопшена через тренеров которые ходят в команды и помогают настраивать AI процессы. Демократичный достаточно подход который со слов коллег очень помог в разработке, а теперь помогает в процессах тестирования.
7. Важные мысли что путь в 4ый уровень может лежать через автоматизацию узких процессов. Например агентом решать задачки из Sentry, который часто у многих засран и руки не доходят. Присылая MR с решением багов. Коллеги поделились что так разобрали достаточно большой беклог. На них обкатывать решая конкретные узкие задачи, это сильно проще, и потом расширять на продуктовый беклог.
8. Один из руководителей внедрения AI в компании ответил что возможность схлопывания ролей в старых командах появится лишь когда будет автоматизированно агентами достаточное количество подпроцессов. Причем уровень автоматизации будет хорошо покрыт evals прежде чем действительно в существующих командах возможны изменения.
Но новые команды нужно стараться запускать уже в ai first подходе.
9. Новые узкие горлышки, чаще всего слышу что это: бизнес, тестирование (если плохие процессы) и дизайн (что скорее временно, в момент времени или инструмента дизайна не поспевают или дизайнеры не успевают за инструментами).
1🔥9👍7