Проект-пингвин
Сейчас оценка любой по сложности задачи сводится к 120 минутам работы. Это время необходимо чтобы сформулировать план, обновить архитектуру и дождаться работы агентов.
Но код никогда не был узким местом в разработке.
Разработку сейчас принято делить на две фазы - Discovery и Delivery.
Delivery вдоль и поперёк покрыт метриками - DORA, Lead Time, CFR, MTTR, Flow Efficiency и др. От них зависят премии и все изменения процессов должны их улучшать.Тестирование и сопровождение тоже входит в Delivery.
Discovery же может затянуться на год. Согласующий директор в отпуске, консультации с командой разработки требуют их сильного переключения контекста и влияет на качество гипотез, отсутствуют метрики воронки продаж, таймбоксинг генерации идей, процесс не выстроен, много сложных смежников и тд. В итоге работа приходит в движение только по пинку инвестора и в результате все плюют на DoR чтобы делать хоть что-то.
Знакомая ситуация? В Jira есть Накопительная диаграмма потока (Cumulative Flow Diagram). Если у вас три месяца тишина, а под конец квартала резко появляются и закрываются сотни задач - у вас проект-пингвин.
Я бы не был собой, если бы не решал подобные проблемы инженерными методами.
Первое. Для улучшения качества исследований, ИИ нужно скормить весь контекст проекта, вместе с кодом, письмами и чатами.
Чтобы люди, занятые Discovery не отвлекали людей, занятых в Delivery, я сделал KB (knowledge boss - https://github.com/alterfo/kb). Работая на GPU домашнего уровня с локальными моделями заняла первое место в русскоязычном RAG Leaderbord DRAGON (https://huggingface.co/spaces/ai-forever/rag-leaderboard)
Если на вашем проекте очень много кода, документации, вся актуальная инфа в чатах, а доки устарели - это решение для вас.
Второе. Написать инструментарий стало проще, чем найти подходящий. Это приватнее, безопаснее, и удобнее. Мой набор инструментов (трекер решений, редактор диаграмм IDEF0, журнал для записи мыслей, финансовый трекер) лежит тут https://alterfo.github.io/. Я пользуюсь каждым из них минимум раз в день и дорабатываю под свои нужды. Открыв инструмент вы получаете полную его копию локально. Синхронизация по локальной сети через WebRTC по куаркоду реализована в некоторых из них. Доработать для общей работы - дело 120 минут если понадобится. Но суть не в этом. Посыл в том, что каждый может за короткое время разработать удобный для себя инструмент. Будь то визуализация данных или редактор диаграм.
Десерт. Если у вас есть набор автотестов, их можно легко превратить в робота-автопилота, который ходит по вашему приложению как пользователь и иногда заходить туда, куда ваш e2e ещё не написан. Инфраструктура для обучения таких автопилотов лежит в игре, которую я писал на заре внедрения вайбкодинга в энтерпрайз чтобы обкатать то, о чем пишу: https://github.com/alterfo/vacuum-rogues
Обращайтесь за помощью внедрения подобных технологий в ваш AISDLC. Буду рад быть полезен.
· 7 ч
В соседнем посте: «Хорошо проработанная Оценка - это измерение. Как вес или температура», а в комментах «всё зависит от зрелости процессов… Оценка будет разной». Тут: «оценка любой по сложности задачи сводится к 120 минутам работы».
Так всё-таки градусник, разная или 120 минут на всё? Если любая задача — два часа независимо от сложности, то это не измерение, а то самое «давай договоримся на 36,6», только теперь стейкхолдеру даже торговаться не надо, он прочитает это в посте.
И дальше, по-моему, пост сам себя опровергает. Ты пишешь, что код никогда не был узким местом, а Discovery тормозит из-за директора в отпуске, отсутствия метрик и невыстроенного процесса. Это всё про людей и организацию. Как RAG по чатам вернёт директора из отпуска или выстроит процесс?
Про «написать инструментарий стало проще, чем найти» и «доработать для общей работы — дело 120 минут»: написать — да. А поддерживать, обновлять, проходить безбас и онбордить людей кто будет? Для личного трекера это работает, для компании это зоопарк самописных тулов, который потом кто-то разгребает.
По DORA 2025, ИИ увеличивает пропускную способность, но и нестабильность поставки тоже. Посты в духе «любая задача за 120 минут» как раз и создают ожидания, из-за которых команды режут ревью и тесты ради скорости. Хотелось бы видеть от инженерного менеджера трезвые цифры, а не рекламу.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 7 ч
1. Слово "сейчас" меняет контекст. У этих постов совершенно разные контексты и мессадж.
2. 120 минут это в правильно настроенном AISDLC.
3. RAG не вернёт директора. Но вряд ли директор уходил не оставив информации текстом. Просто о ней могли забыть. По возвращению он встретит не вопросы на которые он уже отвечал, а новые, сразу списком и сможет быстрее принять решение.
4. Настроить процесс вокруг RAG и инструментария - это отдельная задача, которая постом не решается. Ишь ты какой, сразу всё на блюдечке тебе.
5. В 2025-м клод был на уровне сегодняшнего qwen3.8. Если мы хотим вести аргументированный диалог, предлагаю тебе поделиться своим опытом, а не обесценивать чужой. 120 минут это реальная цифра. Если у тебя что-то не получается, давай разбираться почему. Аргументированно.
PS: И я бы попросил не писать обесценивающие комментарии с помощью ИИ. Иначе забаню и ты не узнаешь ещё много интересных вещей из моего опыта.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 6 ч
1. Разница у постов 6 часов. Почему там не "120 минут хватит всем"? 2. Сомнительно. Цифры подтверждающие это на какой-нибудь значимой выборке есть? 3. Если кто-то что-то забывает то это сломанные процессы, а это можно лечить и без ИИ 4. Да, любая работа - работа 5. Опять 120 минут реальная цифра. Во всех бизнесах и всех кейсах подтверждается? Выборка-то какая у этих волшебных 2-х часов?
P.S.: использовать ли мне ии для форматирования своих же мыслей, кажется, моё личное дело.
P.S.S: пока, к сожалению вообще не увидел каких-то интересных вещей, так что, если тебе будет проще, можешь банить)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 3 ч
Этот пост я просто поднял, он был одним из первых в ленте, я добавил деталей. 120 минут это по данным июля.
Примеры проектов - ссылки в посте.
Если мой личный опенсорс не аргумент, вот чужой опенсорс - https://github.com/epam/mriviewer, я закрыл там несколько issue недавно, на каждый потратил минут 15.
Если и этого недостаточно, вот пример других коллег - https://github.com/umputun - этот вообще тратит в среднем 5 минут на задачу.
Так что цифры и выборка есть. Жду твоей.
Если ждешь раскрытия какой-то бизнес-информации, то её не будет.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 1 ч
Спасибо, посмотрел. Любопытно.
К сожалению, мой кейс будет без примеров кода, так как не пишу в опенсорс. Но если коротко, то вот один из последних:
Рефакторил компоненты карточек в отдельном npm-пакете: с 3-х компонентов, конфигурируемых через пропсы, на карточки с реализацией через слоты + внутренние компоненты, плюс 2 репозитория-потребителя. Внешний вид должен был остаться, но собираться они должны были иначе.
ИИ использовал как мог: написал спеку, по ней агент реализовал компоненты. По описанным контрактам агент делал правки и в потребителях. Код и правда генерился быстро, но его же нужно ревьюить. Да, часть ревью была отдана агенту, но финальное всё равно ручное. То же самое и с проверкой, что новые карточки не разъехались в потребителях.
В итоге ушло значительно больше 2х часов.
Как в твоём AISDLC такая задача укладывается в 120 минут? Без иронии. Может ты действительно прав и это можно было уложить в этот временной интервал.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён