у меня тут вопрос скорее про то что в продуктовой разработке по мере реализации начинаешь понимать что же пользователю надо. Супер четкого тз с чертежами возможно не будет. Если итерации в идеале небольшими кусочками в вашем случае вшиты в процесс, то ок. Просто ухо резануло немного что мы хотим 100% upfront документацию
Есть трансляторы с CUDA на свою технологию, но Nvidia из-за этого судится. Ну и как бы большинство компаний под ограничениями или санкциями, так что им даже не дадут интегрироваться нормально.
Логика такая: H100 это де факто самый массовый GPU на рынке и по нему удобнее сравнивать - так как ты сравниваешь с базовым рыночным решением (а не премиумом, который ему сейчас H200).
Если с 200й сравнивать, там разрыв космически растет :)
Если я правильно понял, то как раз в примере, где сравнивались для небольшого проекта SP / Issue Count, оказался Issue Count точнее.
Но я опять повторю, что прогноз надо постоянно обновлять потому что динамика работы команды может сильно поменяться (зависимости, болезни, увольнения, инфра, ...) - поэтому каждый спринт (минимум) мы должны итерировать прогноз, чтобы после этого его обновлять и коммуницировать со стейкхолдерами.
поправил, надеюсь что теперь чище и лучше видно - что агент делает параллельно несколько этапов, но человек должен завизировать.
Потому что там можно сделать один аппрув сразу на два этапа. И один вытекает из другого.
Если это немного смущает, могу для простоты перерисовать)
Что было бы для вас актуально? Есть ли в целом у вас как у архитектора какие-то мысли по поводу трансформации SDLC, или все таки нету?
у меня тут вопрос скорее про то что в продуктовой разработке по мере реализации начинаешь понимать что же пользователю надо. Супер четкого тз с чертежами возможно не будет. Если итерации в идеале небольшими кусочками в вашем случае вшиты в процесс, то ок. Просто ухо резануло немного что мы хотим 100% upfront документацию
а как качество обеспечивать и отлавливать?
такое ощущение, что это местами тупиковая ветвь)
но базово в статейке все таки здравая мысля - прокачивай observability и будет уже получше
вопрос, как быстро потом придем к авариям как в Амазоне https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de?syn-25a6b1a6=1
ну мы как будто по Амазону и еще паре отечественных компаний начинаем видеть масштаб аварий из-за ai генерированного кода.
респект за "ө"
набрел три года спустя на коммент! Это стоило примерно как один senior разработчик на аутсорсе в Индии)
dry в целом можно запихнуть как правило в agents.md, думаю.
Есть уже какие-то заработки и практики, которыми можно было бы поделиться?) круто было б почитать
Блин, у нас часто похоже на воскресный приход)
fixed, спасибо за наблюдение.
а, не так прочел) сорян
Так как китайцы часто сами позиционируют и сравнивают с H100, проще и реалистичнее найти сравнение с ней
Никакой 🙈
Есть трансляторы с CUDA на свою технологию, но Nvidia из-за этого судится. Ну и как бы большинство компаний под ограничениями или санкциями, так что им даже не дадут интегрироваться нормально.
Логика такая: H100 это де факто самый массовый GPU на рынке и по нему удобнее сравнивать - так как ты сравниваешь с базовым рыночным решением (а не премиумом, который ему сейчас H200).
Если с 200й сравнивать, там разрыв космически растет :)
Если я правильно понял, то как раз в примере, где сравнивались для небольшого проекта SP / Issue Count, оказался Issue Count точнее.
Но я опять повторю, что прогноз надо постоянно обновлять потому что динамика работы команды может сильно поменяться (зависимости, болезни, увольнения, инфра, ...) - поэтому каждый спринт (минимум) мы должны итерировать прогноз, чтобы после этого его обновлять и коммуницировать со стейкхолдерами.
Если прям приводить кейсы, то есть вот такой пост https://www.prokanban.org/blog/trustingmcs
https://www.prokanban.org/blog/https-prokanban-org-blog-monte-carlo-simulations-accuracy-and-unplanned-work-a-case-study
+ бложик Мэтт Филипа https://mattphilip.wordpress.com/wp-content/uploads/2018/02/to-estimate-or-not-to-estimate-is-that-the-question_-by-matt-philip.pdf