hllwrld
Software developer
А стек какой?
стек - разный, в зависимости от проекта (у меня разная оркестрация на разных коммерческих проектах)
если говорить про самый свежий, то в пример стек бека примерно такой
- что касается рантайм фреймворка, то это nitro + h3, ts (нода крч)
- для бд постгра, drizzle orm / kit
- кешей и очередей redis / bullmq
- для обсерва OTel + OTLP + pino + всякие там ioredis /undici и SigNoz
- для отказоустойсивости cockatiel / rate-limmiter-flexible
- тестики vitest + testcontainer + k6 + stryker (он у меня выступает как часть "self-reflection")
- инфра compose / caddy / esbuild
для фронта - опять же в зависимости от проекта, но кратко: пишем на мета-фреймворке nuxt
---
Какая llm?
для оркестрации ии-агентов используются самые разные модели, к примеру
- для primary (оркестратора) юзаю Opus 4.6 / gpt-5.3-codex (я в бета-программе, поэтому для обоих мне доступно 1kk контекста)
- для воркер-агентов aka суб-агентов все сильно зависит от того, какую-задачу они решают
- - agentic rag, которые бегают через условный sourcebot в поисках архитектурных документов / стайл-гайд документов / всяким там внутренним либам достаточно либо haiku 4.5, либо локального glm-4.7-flash
- - для агентов которые пишут простенькие юнит тестики, с готовой инфрой, то тоже haiku / glm-4.7-flash
- - для воркер-агентов, которые имплементируют код достаточно Sonnet / gpt-5.3-codex
- - ...
---
Насколько описываете задачу?
смотря какая задача, но т.к. я во всю использую механизм human in the loop с продвинутой инфрой поверх, то для большинства случаев я пишу "мне нужно вот это и вот это сделать" (с точки зрения бизнес-требований), а уже оркестратор через суб-агентов бегает по youtrack / sourcebot / figma и т.п. собирает требования и всю необходимую инфу для старта работы, а если у него есть вопросы по задаче, прежде чем к ним приступить, он их мне присылает в чатик и я на все его вопросы отвечаю
---
сорян за лонг, супер-огромная и большая тема, тут кратче - ващ никак
но в целом, если смотреть на общую тенденцию и прогресс, то и проектирование архитектуры / тех стека / инфры и т.п. можно отдать на плечи оркестрации, но это уже полностью автономные системы, я пока до такого еще не дошел, но ручки чешутся
вот, если интересна тема, глянь как OpenAI написала сложнейшую систему за месяц, без единого участия программистов
смотрю, но с высоты архитектуры, технологического стека, инфраструктуры и т.п., но сам код уже как месяца 3 точно не пишу
ну, раз этими вещами занимаются одни из самых лучших умов планеты Земля, - знач толк есть
P.S. сильно упрощенно, без всяких тонкостей в виде CoT, системы аргументаций, голосований и т.п.
кому интересно, то этот механизм называется Multi-Agent Debate, т.е. это когда агенты спорят друг с другом, прежде чем выдать ответ пользователю
не знаю каким другим словом передать то, на что способны даже не самые сложные оркестрации
вот пример одной из оркестрации на легаси-проекте, которому около 8-ми лет
щелкает разной степени сложности задачи как семечки, и со "сверх-человеческой" скоростью
сам уже прогаю 10+ лет, никогда бы не подумал что технологии дойдут до таких масштабов автоматизации)
проблема в том, что разработка с ии-агентами / оркестраторами, которые делают задачи в полу-автономном режиме (с механизмом HITL), подразумевает под собой совсем другие процессы разработки ПО
смеха ии-агент пишет код -> ии-агент пишет тесты -> ручная верификация PR - неэффективна, ибо ии-агенты генерят код напорядки быстрее и комплекснее, чем если бы это делал человек, тем более если это OSS, отсюда и проблема "нам требуется тонны ресурсов на проверку PR"
тут либо перестраивать процессы под современные реалии (ии-агент пишет код -> ии-агенты пишет тестики -> ии-агент верифицирует код через тонны статических линтеров, продвинутые механизмы само-верификации и т.п.), либо полностью запрещать использование полу-автоматизированных решений (ии-агентов, оркестрации и т.п.), все просто
ощущение, что ты держишь "программных инженеров" за дураков, которые не осознают и не понимают всех рисков подобных схем и только ты один единственный (и лайкнувшие) осознаешь весь масштаб проблем xD
сейчас айтишка очень сильно меняется, методологии, циклы разработки ПО и т.п., и многие инженеры (включая умнейших челиков из топовых биг-техов) уже во всю фурычат над тем, чтобы подобные механизмы были максимально стабильными
так что не надейся на халяву, ее не будет, никогда, тем более в программной инженерии
https://boristane.com/blog/the-software-development-lifecycle-is-dead/