Когда создать софт может каждый, кто решает, что создавать не стоит?
When Anyone Can Build Software, Who Decides What Not to Build?
Генеративные модели удешевили написание кода, но не устранили главную проблему: архитектурные обязательства — данные, интеграции, регуляторные требования — накапливаются и не перегенерируются за один день. Автор с двадцатилетним опытом утверждает, что узкое место сместилось с производства на согласованность решений. Ключевой навык — суждение до фиксации: способность увидеть последствия локального выбора для всего предприятия и вмешаться до того, как потрачены ресурсы.
Чем дешевле становится создавать софт, тем дороже обходится несогласованность.
- deminature
Создание качественного софта с помощью LLM по-прежнему отнимает очень много времени. Подавляющее большинство людей просто не будут этим заморачиваться, независимо от того, насколько низок порог входа, потому что время не бесплатно. К тому же создание софта неинтересно большинству людей по той же причине, по которой сборка электроники неинтересна большинству. Это нишевый интерес с ограниченной массовой привлекательностью. По этим двум причинам профессия разработчика переживёт ИИ.
- OakNinja
Эта проблема не нова. Новое в том, что любой может понять основную проблему, которую пытается решить, не привлекая команду разработчиков, за счёт быстрой генерации идей и стремительного прототипирования.
Как и всегда, дальше уже компания решает, на чём сосредоточиться — как это было всегда.
* Не цепляйтесь за идею или вывод промпта только потому, что потратили на это время.
* Писать код легко. Поддерживать его — сложно.
* Если это не экономит время и не приносит доход, это просто расход.
* Вывод не равен ценности.
- anonzzzies
У нас (в моей компании) есть корпоративная LoB-«база», которая за долгие 40 лет собрала любой процесс, какой только можно вообразить, и используя её, мы просто смотрим на процессы крупных корпораций и предлагаем автоматизировать их на уровне департамента, чтобы им не требовалось одобрение совета директоров или ИТ-отдела для оплаты. SOTA ИИ может сделать это за день-два с нашей базой, почти самостоятельно, и мы берём чуть меньше, чем бюджеты департаментов. Нам приходится посылать на многие встречи мерзких саркастичных «проектных менеджеров/продажников», так как, конечно, эти средние менеджеры хотят выглядеть полезными, поэтому такие встречи объективно бесполезны для нас, но всё равно требуются как неизбежное страдание. Они (встречи в реальном мире) теперь, конечно, обходятся куда дороже, чем (чисто) техническая часть, даже если оценивать фреймворк в какие-то $ лицензионных и SLA-затрат.
Эти корпорации, а это в основном транснациональные компании, в основном принадлежащие владельцам из США, Индии или Китая, и буквально все их ИТ-отделы абсолютно отстойны; застряли на Java или C# 20-летней давности с нулевым стимулом что-то улучшать или учиться; они слышали об ИИ, но не используют его ни для чего.
Это золотая жила, стоимостью в миллиарды в любом регионе, если удастся войти на правильном уровне. Не уверен, что это продлится, так как, по моему опыту, большинство этих людей в таких отделах можно заменить сегодня LLM, работающей на iPhone, а LoB-приложения довольно скучны, если у вас есть один надёжный консультант с несколькими десятилетиями знаний; неужели они не обучают LLM именно этому?
- CurleighBraces
Мне кажется, всё сложнее, по крайней мере пока.
Верно, что любой может создать софт, но это не делает софт хорошим, и неверно говорить, что это зависит именно от вкуса.
Например, я сейчас работаю с предпринимателем без опыта программирования, но он успешно сделал продукт, который уже продал средней компании.
Однако без моего участия и знания нужных рычагов для настройки ИИ софт просто не работал так, как нужно, несмотря на то, что новейшие фронтирные модели изо всех сил пытались достичь того, что он описывал.
По крайней мере пока опытные разработчики всё ещё нужны.
- ma2kx
Я несколько озадачен. Интересный пост, но я не уверен, что точно понял, куда он клонит со своей «policy as code». Он заключает: «policy-as-code обеспечивает корпоративную согласованность без центральной архитектурной функции», с чем я бы согласился, но поспорил бы, что он упускает, что сегодня не хватает инфраструктуры / компании как кода. По крайней мере, если вы хотите, чтобы агент мог решать или хотя бы осознавать проблемы, с которых он начал. Политики определяют границы нашей рабочей среды, но не саму работу. Это «ноу-хау» в основном неявно для людей, но невидимо для LLM и ограничивает контекстные рамки, в которых работает агент, его заданным промптом (и, возможно, ограничено политиками, если они в контексте).
Вот если взять его пример:
«Сотрудники на передовой могут пропускать обязательные поля, потому что процесс добавляет пятнадцать минут трения к каждому взаимодействию с клиентом.»
Во-первых, неясно, какова политика для этих полей, когда они обязательны и в то же время могут быть пропущены. Затем, почему они обязательны, если их пропуск, похоже, только снижает трение без других последствий? Как модель должна решить, следует ли ей применять политику для этих полей, написать автоматизацию или просто сделать их необязательными?