Комментарии 8
Очень здравое и взвешенное мнение посреди истерии про "ИИ убьет заменит всех человеков"
В таком случае одиночки теоретически получают бешеный буст производительности, потому что только они могут извлечь выгоду от такой автоматизации труда, добрать недостающие компетенции и крайне сильно сэкономить на отсутствии коммуникаций с командой (начиная от более низкой платы и заканчивая заменой асинхронного общения на промпты в режиме on-line).
Я бы сказал, что ЛЛМ не ускорил разработку в тех командах, которые догматично применяют доЛЛМные практики.
Очевидно, что старые подходы оптимизировали объем кода на +1 задачу и сапортабилити каждого куска кода.
С ЛЛМ эти вещи обесцениваются. Приведу пример: есть, скажем, CRM система написанная на махрово-энтерпрайзном C#/Java, и работающая с MSSQL/Postgres. Раньше было принципиально важно правильно продумать объекты, интерфейсы, суррогаты, дто, взаимодействие объектов. И потом, на основе этой базы уже делать фичи просто и лаконично (никому ж не придёт в здравом уме на каждую фичу писать с 0 полключение к БД и все такое). Да, в такой подход LLM вообще даром не нужен. Ибо сложно описать каждый раз контекст и легко нагенерить говнокода, начав "пилить поперёк волокон". Но прикол в том, что, в случае LLM, вот эта база из объектов-интерфейсов-etc вообще не нужна. Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние). Зато можно каждый такой блочек инкапсулировать в свой сервис, протестировать, и просто написать заново, когда он устареет. Вообщем, надо мозг развернуть. Или подождать, пока умные люди придумают новые догмы за нас
Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние).
Машине написать не лень, зато пользователю потом пользоваться неконсистентной системой будет лень.
Более менее ваш подход работает на статичной вёрстке фронтенда, но и там есть проблемы, даже тот же Lovable не случайно делает все свои интерфейсы приколоченными гвоздями к одной и той же библиотеке компонентов (что характерно, написанной кожаными мешками). И всё равно возникают проблемы с высокоуровневыми абстракциями. А пользователям почему то не нравится пользоваться системой, в которой на каждой таблице фильтр работает и выглядит немного не так как на остальных.
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет. И никто не скажет, в каких именно, потому что разработчкики сами не знают. А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Впрочем, существующие парадигмы написания кода возникли и выходили из моды из-за давления инструментов: класс с паттерном "Посетитель" появился пришёл в ООП-ориентированные языки из Java из-за отсутствия анонимных функций (и был затем поглощён ими), а длинные методы и процедуры оказались вне фавора из-за того, что их трудно тестировать.
LLM точно так же могут затребовать специфичную структуру проекта, которая для них оптимальна (что собственно уже и происходит - специально для них создают rules-файлы с выжимкой архитектуры и код стайла проекта).
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет
Вы так говорите, будто оно сейчас не так. Поскреби любой продукт, на который потрачены миллиарды $, чуть глубже поверхности, и так все вот такое полезет. Общался пару лет назад с сотрудником техподдержки ФБ: он рассказывал, что в рекламном кабинете баг на баге, от которых рвет пукан рекламодателям, и ниче, всем до жопы, пока метаверс на кону.
>А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Представил. "Финансовый софт" звучит, как догма. А оно там внутри далеко не все так офигенно. Там внутри полно индусов, которые делают работу, которую должен делать софт, но не делает. Полно ноукода, в котором иногда, при очередном редактировании, происходит мисклик, и "съезжает" процесс. Куча задач, где вообще всем пох, сколько там багов (условно, пуш надо разослать с партнерской рекламой, и, в принципе, если он уйдёт чуть не тем, кому надо, то норм). Понятно, что есть ядро, где так не пишут. Но, оно, как правило, уже давно написано. А вот прямо сейчас надо фич накидать, которые, что с, что без ллм, будут написаны примерно с одинаковым качеством
Почему LLM снизили стоимость кода, но не ускорили разработку