Согласен. Команды постоянно меняются, технологии меняются, измерять что-то в целом очень сложно :) Я возьму на вооружение идею - а стали ли мы делать больше сложных задач)
Так вопрос-то у этих людей: гоняли ли они на конкретных бенчах своих агентов и навыки? У каждой организации/стартапа/человека есть свои стандарты и контекст. Поэтому бенчмарки и эвалы должны соответствовать тому, как вы собираетесь решать задачу. Если вы просто берете и пишете "generic" запрос клоду и ожидаете результата, который вас удовлетворит, у меня для вас плохие новости =)
Решать тому кто принимает решение о внедрении ИИ в организации - так как внедрение, это в том числе про удобство и результат. Мы ж делаем все для какого-то результата. Если вы фрилансер - то сами и решаете - ваша же инвестиция :)
Вопрос провокационный. Мы не моё использование обсуждаем, а ваш скептицизм (на который вы имеете право, я его не оспариваю). Мой стек - это в основном java, где у людей есть возможность попробовать перевесить на агентов написание бойлерплейта и кусков логики в контролируемом окружении, которое они сами допиливают (добровольно). Думалку никто у нас и вас не отбирает)
А вот с точки зрения пересборки: просто организация часто хочет чтобы было быстрее.
А быстрее без пересборки процессов не получится, потому что надо уменьшить цепочку передачи артефактов.
А если результат от работы агентов получается некачественный, вы, безусловно, останетесь 1-1 с нейрослопом, который нельзя проверить адекватно. Мы даже знаем статы от того же coderabbit: багов в PR от ИИ в 1.7 раз больше, а люди кликают в два раза чаще "аппрув не глядя", когда видят огромный PR от ИИ-шки.
И все это надо решить, перед тем как пересобирать процесс. Вот только кто ответственен за решения этих проблем? В одном случае команда сама может туда контрибьютить (у меня таких много): делает обвязку, эвалы, улучшает повторяемость результатов на разных моделях. В других командах - ждут централизованного решения, потому что им не до этого. В данном случае каждая организация/отдел/команда должны иметь явный ответ на вопрос - кто доводит до нормального состояния ИИ-тулы.
Если вы не хотите разбираться - это ваше право, мне кажется базовое. Тут вопрос - если агенты плодят нейрослоп, может быть вам дают плохой инструмент? Плохих агентов? Хреновую обвязку? А кто за это ответственен (за DevExperience, который в вашем случае плохой).
Глобально, вы бы, наверное, не были бы против удобного инструмента, избавляющего от рутины?
Так и статья про то что не надо оголтело и без цели внедрять ИИ. И ничего вы не внедрите, еслрине будете работать с людьми и если они не будут выкупать - зачем это и какой бенефит будет.
А если сопротивляются - это проблема в системе, а не людях.
Ковыряться в нейрослопе вы больше полугода не сможете, надо пересобрать весь процесс работы - причем самой команде - и чтобы она в этом была сама заинтересованна.
Не меняются потому что надо перестраивать весь процесс поставки, а не просто давать людям инструмент. Иначе точечное , в не системное использование инструментов не ускоряет end 2 end процесс
Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)
Специфика стартапа: жизнь от раунда к раунду инвестиций.
Безусловно вы правы, закон Гудхарта так и говорит. Поэтому самой команде мы никогда такие цели не ставили. Это договор и трекинг на уровне sales, csm, engineering, support. Zero Bugs Policy - это входная точка на практику работы с качеством и ориентированием на клиента: когда начнут отваливаться платящие клиенты, вы сразу поймете что команду больше держать не на что - и дело в качестве. Поэтому поставите (как в тойоте) линию на стоп и будете фиксить дефекты или переделывать системно работу с качеством (shift left, re-architecture, refactoring, еще что-то релевантное вам).
У команды есть явная ответственность за Uptime своего сервиса (который потом обвалится), у руководителя - есть ответственность по архитектуре перед своим CIO. Для остального есть сонар и внешний аудит.
Поэтому там и написано про то что данные потом идут в общую ретроспективу, на которой надо принимать системные решения - и вкорячиваются в Definition of Done.
Согласен. Команды постоянно меняются, технологии меняются, измерять что-то в целом очень сложно :) Я возьму на вооружение идею - а стали ли мы делать больше сложных задач)
Огонь)
Аминь!
Так вопрос-то у этих людей: гоняли ли они на конкретных бенчах своих агентов и навыки? У каждой организации/стартапа/человека есть свои стандарты и контекст. Поэтому бенчмарки и эвалы должны соответствовать тому, как вы собираетесь решать задачу. Если вы просто берете и пишете "generic" запрос клоду и ожидаете результата, который вас удовлетворит, у меня для вас плохие новости =)
Решать тому кто принимает решение о внедрении ИИ в организации - так как внедрение, это в том числе про удобство и результат. Мы ж делаем все для какого-то результата. Если вы фрилансер - то сами и решаете - ваша же инвестиция :)
Вопрос провокационный. Мы не моё использование обсуждаем, а ваш скептицизм (на который вы имеете право, я его не оспариваю). Мой стек - это в основном java, где у людей есть возможность попробовать перевесить на агентов написание бойлерплейта и кусков логики в контролируемом окружении, которое они сами допиливают (добровольно). Думалку никто у нас и вас не отбирает)
А вот с точки зрения пересборки: просто организация часто хочет чтобы было быстрее.
А быстрее без пересборки процессов не получится, потому что надо уменьшить цепочку передачи артефактов.
А если результат от работы агентов получается некачественный, вы, безусловно, останетесь 1-1 с нейрослопом, который нельзя проверить адекватно. Мы даже знаем статы от того же coderabbit: багов в PR от ИИ в 1.7 раз больше, а люди кликают в два раза чаще "аппрув не глядя", когда видят огромный PR от ИИ-шки.
И все это надо решить, перед тем как пересобирать процесс. Вот только кто ответственен за решения этих проблем? В одном случае команда сама может туда контрибьютить (у меня таких много): делает обвязку, эвалы, улучшает повторяемость результатов на разных моделях. В других командах - ждут централизованного решения, потому что им не до этого. В данном случае каждая организация/отдел/команда должны иметь явный ответ на вопрос - кто доводит до нормального состояния ИИ-тулы.
Погодите, давайте разделять. Тут два вопроса.
Если вы не хотите разбираться - это ваше право, мне кажется базовое. Тут вопрос - если агенты плодят нейрослоп, может быть вам дают плохой инструмент? Плохих агентов? Хреновую обвязку? А кто за это ответственен (за DevExperience, который в вашем случае плохой).
Глобально, вы бы, наверное, не были бы против удобного инструмента, избавляющего от рутины?
Так и статья про то что не надо оголтело и без цели внедрять ИИ. И ничего вы не внедрите, еслрине будете работать с людьми и если они не будут выкупать - зачем это и какой бенефит будет.
А если сопротивляются - это проблема в системе, а не людях.
Ковыряться в нейрослопе вы больше полугода не сможете, надо пересобрать весь процесс работы - причем самой команде - и чтобы она в этом была сама заинтересованна.
Пока в мире на масштабе нет ни одного кейса, что внедрение ИИ и агентизация принесли больше денег кому-то (кроме антропика и openai)
Не меняются потому что надо перестраивать весь процесс поставки, а не просто давать людям инструмент. Иначе точечное , в не системное использование инструментов не ускоряет end 2 end процесс
По итогу первых двух гипотез не было от слова совсем изменений в Lead Time, Throughput, Defect Rate.
Я попробовал ответить на вопрос во второй статье, где мы наконец-то локально смогли увидеть, как AI-first команды изменяют нужную сторону метрики потока.
Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)
Ну вот я ж писал что мы трекам после выхода на нужную траекторию смотрим не на уменьшение багов, а на баланс и предсказуемость (быть внутри SLA).
Так-то, вы можете любую метрику хакать, это нормально. Если вы хотите какое-то ультимативное решение - то сферических коней в вакууме не бывает :)
Но это же не метрика, а подход. С какой целью вы его применяете - это уже другой вопрос.
Я упоминаю психологическую безопасность не просто так.
Специфика стартапа: жизнь от раунда к раунду инвестиций.
Безусловно вы правы, закон Гудхарта так и говорит. Поэтому самой команде мы никогда такие цели не ставили. Это договор и трекинг на уровне sales, csm, engineering, support. Zero Bugs Policy - это входная точка на практику работы с качеством и ориентированием на клиента: когда начнут отваливаться платящие клиенты, вы сразу поймете что команду больше держать не на что - и дело в качестве. Поэтому поставите (как в тойоте) линию на стоп и будете фиксить дефекты или переделывать системно работу с качеством (shift left, re-architecture, refactoring, еще что-то релевантное вам).
У команды есть явная ответственность за Uptime своего сервиса (который потом обвалится), у руководителя - есть ответственность по архитектуре перед своим CIO. Для остального есть сонар и внешний аудит.
Поэтому там и написано про то что данные потом идут в общую ретроспективу, на которой надо принимать системные решения - и вкорячиваются в Definition of Done.
поправил, надеюсь что теперь чище и лучше видно - что агент делает параллельно несколько этапов, но человек должен завизировать.
Потому что там можно сделать один аппрув сразу на два этапа. И один вытекает из другого.
Если это немного смущает, могу для простоты перерисовать)
Что было бы для вас актуально? Есть ли в целом у вас как у архитектора какие-то мысли по поводу трансформации SDLC, или все таки нету?