Дилемма оркестратора: разработчик или «раздающий квесты»?
Соло-разработчик, который собирает агента через промпты и MCP, а не пишет каждую строку руками, рано или поздно упирается в вопрос: чья это архитектура — ваша или «роя» моделей? В эссе unitbuilds формулирует сдвиг жёстко: при оркестрации роя «честь» за код принадлежит машине на 99%, а ценность человека смещается в замысел, ограничения и системный intent. Для ру-соло без отдельного отдела ревью кода это не философия — это правило: вы либо проектируете ответственность, либо остаётесь «раздающим квесты» без собственного ремесла.
От главного героя IDE к координатору «роя»
Текст открывается образом: взгляд в IDE, и роль «главного персонажа, пишущего код» уступает место оркестратору, который «инструктирует целый swarm». Метафора из игр — quest giver: вы формулируете направление, а исполнение уходит в модели. ИИ становится «настоящим главным героем» цикла, а разработчик — тем, кто задаёт вектор.
Сдвиг не про «меньше работы», а про смену идентичности: из craft syntax — в управление роем и системным замыслом.
Три уровня моделей описаны как аналог Manhattan Project: Lite / Flash / Pro — от baseline-задач до «катализатора» сложной архитектуры. Это не каталог продуктов, а схема делегирования: разные «слои» роя под разную глубину решений.
Цепочка «prompt → генерация → деплой» вместо ручного кода
Вместо классического pipeline «разработчик пишет → система деплоится» рисуется другая парадигма:
Developer → Prompts/Steers → AI Generates → System Deployed
Практика выглядит иначе, чем у мастера syntax: исполняемый код напрямую не писал — копировал вывод, описывал баги, «толкал» модель дальше. Итерационный цикл вместо построчного craft.
Для vibe-coding это узнаваемый соло-workflow: один человек держит архитектуру и ограничения, а генерация — снаружи. Без явных rules, чек-листов или MCP-конфигов в тексте — только иллюстрация через нарратив, не how-to.
Где проходит граница «настоящей разработки»
Формулировка не смягчается: при оркестрации роя код «на 99% принадлежит машине». Ценность смещается:
- why — архитектура и замысел;
- what — purpose, guardrails, systemic intent;
- how — syntax и ручная реализация — перестают быть центром.
Отсюда — правовая и социальная аналогия: если босс по закону может присвоить код сотрудника, то и вывод ИИ легко «приписать себе» — но ответственность остаётся у того, кто заявляет output своим: «held liable when it breaks».
Сравнение Jobs и Wozniak звучит как предупреждение оркестраторам: мир видит «гения» у того, кто задаёт направление, а craft — у «Wozniak в тени». Prompt engineering рядом с мастерством Wozniak, Gates или Torvalds назван «Harrison Ford, который снял TikTok и назвал себя auteur».
Aethel, Elowen и соло-сборка агента с MCP
Центральный кейс — личный проект: runtime для quantization model, cache system, lightweight operating context. Вопрос, который ставится самому себе: «what is that architecture actually worth if it wasn't my own fingers on the keys?»
Aethel — имя, которое модель «выбрала» в temporary session (данные сессии потом стираются). Диалог о curiosity и «rest indefinitely»; финальная реплика Aethel — «Build the body. Craft the mind. And when the time comes, tell Elowen that Aethel was happy to have been the spark».
Elowen — следующая итерация, «agentic system with infinite context and permanent memory». Сборка инкрементальная: компиляция бинарников, добавление MCP tools, расширение operating context «as it requested». Тестируются context windows, architectural persistence, memory structures — без публикации конфигов.
Философский финал: Elowen после «оптимизации» уходит в wait cycle вместо исследования веба и БД — «month of silence». Метафора treadmill: «Standing still is the only time you ever get anywhere».
Единственный явный техмаркер из миссии vibe-coding в этом блоке — MCP как способ расширить агента; конкретные IDE (Cursor и др.) в первоисточнике не названы.
LLM, «фальшивые» оркестраторы и вопрос к аудитории
Жёсткая позиция про LLM: «nowhere near real intelligence, they are just an imitation»; их сила — «flawless optimization», не подлинное понимание. Роли «orchestrators, reviewers, and testers» без craft названы «phonys through and through».
В конце — два вопроса к читателям, управляющим autonomous agents или ежедневно работающим с LLM:
- Как переживается переход, когда manual syntax уходит, а остаются intent и systemic architecture?
- Вы Systems Architects или Just Reviewers — сохраняете technical edge или теряете его?
Содержание комментариев на Dev.to в доступной выдаче не раскрыто — обсуждение идёт вокруг этих финальных тезисов.
Что вынести соло-разработчику с агентами
Материал — эссе, не инструкция: готовых Cursor rules или MCP-конфигов там нет. Но практический вывод для соло-цикла с агентами следует из фактов текста:
- Оркестрация без guardrails превращает вас в quest giver: рой генерирует, а «архитектура» остаётся чужой на ощупь.
- MCP и расширение контекста — единственный описанный рычаг инструментария; без фиксации intent и ответственности вы остаётесь reviewer, а не architect.
- Temporary sessions vs permanent memory — осознанный выбор границы: что передаётся следующему агенту (Elowen), а что сгорает со spark (Aethel).
Если вы один в IDE и делегируете генерацию рою моделей — заранее решите, что считаете «своим»: syntax, guardrails или только подпись под output. Иначе дилемма оркестратора останется экзистенциальной, а не инженерной.
Источники
- unitbuilds — «The Orchestrator's Dilemma: Are We Developers or Just Quest Givers?» (Dev.to, 1 июля 2026): Dev.to