Не стройте личную «фабрику софта»: это пустая трата времени

Думаю, он прав в том, что фабрика софта в каком-то смысле должна возникнуть. Не стоит начинать проект со слов «ну, сначала мне надо построить фабрику софта, чтобы делать это быстрее». Начни с того, что создаёшь штуку, управляя агентом. Если замечаешь, что пишешь одно и то же снова и снова, вынеси это в skill, который стоит воспринимать и обращаться с ним как с макросом. Когда замечаешь, что у тебя складываются чёткие паттерны того, какой skill когда вызывается, возможно, пора начинать фабрику софта, которая по сути прячет эти решения и связанную с ними информацию за симпатичным интерфейсом.

Моя фабрика софта возникла именно так, и для 50–70% более простых задач, над которыми я работаю, это экономит мне уйму времени и, что важнее, умственной нагрузки.

Из содержания поста в блоге я выношу то, что автор постоянно спорит со своей аудиторией, и я бы суммировал это так: «я считаю твою затею глупой, и тебе не стоит её делать, но я тебе не начальник, так что какая разница, но это плохая идея, но она могла бы быть полезной, но тебе не стоит её делать».

Думаю, если у тебя есть планы на фабрику софта (читай: некая концептуальная основа для цикла, превращающего задачи в код/фичи), тебе стоит попробовать. Моё мнение: даже если твоя реализация провалится или ты никогда не выведешь её дальше proof of concept, ты по крайней мере сделал что-то, чтобы понять, что есть вокруг и что ты уже пробовал.

Лучше иметь кладбище едва начатых проектов, которые придают глубину твоим знаниям, чем обречь себя на рабство промптов, потому что [передовая модель текущего финансового квартала] умеет делать Marvel + Bioshock + Ted Lasso + Command and Conquer или какой-нибудь другой ужасающий Consumptionslop™, который так любят люди вроде Nikita Bier.

По-моему, люди понимают под фабрикой софта разные вещи.

Я считаю, что фабрика софта — это просто следующий шаг в мантре «всё есть код».

Хочется писать описание фичи и критерии приёмки в «коробку» как можно более размыто и с минимумом деталей.

Чтобы это стало возможным, создаёшь для фабрики доступ к информации о домене, требованиях и программном стеке в том объёме, какой требует окружение.

И всё это пытаешься делать с помощью инструментов, документации и процессов, оптимизированных под ИИ.

Всё с целью тратить меньше токенов и контекста и максимально ускорять каждое действие, предпринимаемое агентом.

Вот почему есть тренд на основанные на плагинах самоэволюционирующие обвязки, которые пытаются автоматизировать это с помощью опинионейтед-решений.

Поэтому я не вижу причин, почему создание инструментов для более лёгкого тестирования и меньшего расхода токенов — пустая трата времени, особенно учитывая, что ты узнаёшь всё больше и больше областей в своей работе, которые можно автоматизировать, и что в зависимости от выбора инструментов это может делаться без твоего участия, а ты упускаешь шанс поэкспериментировать, улучшит ли твой вклад в этом отношении фабрику или нет.

Я полностью согласен с этой мыслью, но это атака на соломенное чучело или люди действительно строят «фабрики софта»? Это первый раз, когда я вообще вижу этот термин в контексте LLM. Как вообще могла бы выглядеть фабрика софта поверх LLM?