Comments 14
А зачем вообще заставлять комплюктер использовать промежуточное представление, нужное только человекам? Всякие там си-плюс-плюс и прочие жаваскрипты. Пускай готовый машинный код отдаёт. Нэ? Тогда вопросы архитектуры и прочих красивостей отпадают.
Отпадут, как минимум, аргументы, что с LLM можно писать код и не уметь программировать/знать язык. Хотя ТС и без машинного кода пришел к тому же выводу.
Так это же аргумент уровня "зачем нам ООП, ведь все можно написать и без него, тьюринг-полнота означает, что можно реализовать любой алгоритм". Потому, что это снижает сложность. У LLM тоже есть предел когнитивной сложности, за которым она начинает работать менее эффективно.
Не в последнюю очередь это происходит за счет того, что корпус кода, на котором LLM обучались — он не на машинном коде, он на высокоуровневых языках. Чтобы она эффективно писала даже на ассемблере (не говоря уж о чистом машинном коде) — надо на нем количество примеров (и не просто кода, а пар код:задача), сравнимое с количеством кода на си/питоне/жс.
Ирония в том, что справа от вашего комментария Хабр показывает картинку, где робот карандашом выводит Мона Лизу. И вот что-то я сомневаюсь, что midjourney запускает у себя фотошоп и водит стилусом туда-сюда (чтобы отдать вам подобный рукотворному .psd, например).
Не, я не спорю, что сейчас сложно найти достаточно материала для обучения LLM в обход высокоуровневых ЯП. Я всего лишь делюсь впечатлением, что человекочитаемый код выглядит лишним в поставленной задаче.
Это, конечно, не суть статьи, но хочется прокомментировать "Программисты, которые учатся кодить с применением LLM, — не учатся кодить, они учатся подбирать промты которые дают результат, решающий задачу.". До ЛЛМ все точно так же искали куски кода на стекоферфлоу. Если нужен какой-то хитрый алгоритм - гуглишь его, а не пытаешься сам придумать, потому что это тупо быстрее. Если потом есть желание - можно посидеть разобраться, как он работает. Но и сейчас никто не мешает самому разобраться в коде ЛЛМ или попросить её пояснить. Да, случаются галлюцинации, но и гуглеж далеко не всегда дает оптимальное решение. В общем, не понимаю я снобов, которые подобное говорят.
Ну я скорее про то, что непосредственно взаимодействия с кодом становится меньше. Я уже писал комментарий где-то: там реально мозг переключается на систему 1, и ты начинаешь писать "у тебя скобочка пропущена", хотя быстрее нашел бы сам этот пропуск. Когда ищешь код на SO, хоть сколько-то приходится вникать в этот код, хотя бы в его интерфейсы. Когда этот код с правильной обвязкой LLM сама интегрирует в твой проект, для тебя он гораздо более абстрактен.
Вопрос к методологии остался. Про разбивание на куски все понятно. Непонятно, в какой момент эти куски интегрируются. И что делать, если надо писать что-то, что затронет сразу несколько разных модулей? Какой у вас в этом опыт?
Первые два бота писались примерно по одинакой схеме: ты просто говоришь "а напиши мне бота" и описываешь функционал.
...
Ты ей говоришь "вот ты скачиваешь курсы валют, тебе не надо это делать каждый раз при старте, положи их в кеш вместе с временем скачивания и только если разница во времени больше пяти часов, качай заново"
...
1)В архитектуру LLM не умеет.
К такому выводу, как мне кажется, нужны пояснения. Вот такой prompt для claude (моделька 3.5 Sonnet):
Придумай архитектуру для:
Бот-конвертер валют (тоже в тг). Ждет в личку или в чате сообщение с "100 евро" и реплаит на него с несколькими сконвертированными валютами. Питон.
В результате таки есть кeширование:
Currency converter
Core business logic component
Maintains exchange rates cache
Performs currency conversions
Interfaces with external exchange rate API
Implements retry logic and error handling
Exchange rate provider
Abstracts exchange rate API interactions
Fetches current exchange rates
Updates local cache periodically
Handles API errors and timeouts
Supports multiple fallback providers
На этом этапе можно посмотреть, понять, местами простить и далее принять архитектуру уровня C3.
Далее продолжаем помодульно слать запросы для уровня C4.
Квоты на выполнение запроса - в данном случае по созданию кодовой базы целиком - приводят к тому, что искомая база таки генерируется, но она низкого качества ("не умеет в архитектуру"). Всех много, а всего (вычислительных ресурсов) мало - поэтому всего на всех не хватает.
Отсюда правило (капитанское, конечо) - надо декомпозировать и "брать" частями.
Может и правда, надо просто архитектуру отдельными запросами проектировать..
Но, допустим, я без стадии "поиграться с рабочим ботом и понять какие функции нужны" не скажу, насколько хороша та или иная архитектура.
С другой стороны, переписывать правильно декомпозированный проект гораздо проще рефакторинга лапши.
Основной скилл программиста будет заключаться в том, чтобы правильно и точно ставить задачу, с нужными граничными условиями
Ну да
Нет, боже упаси, пишу все своими руками
Не знаю, как там другие, а я пишу код своей головой.
Ну, нет, множество программистов пишут просто код. Линейный программист в большой компании на задачах уровня "перекладываем джсон" очевидно, имеет очень маленькую возможность творчески подходить к программированию и принимать какие-то умные решения: он просто реализует мостик между двумя чужими спецификациями, и свобода у него в выборе метода сортировки (и то цена современного железа прощает многие косяки), да в названии переменных.
И все программисты определенно вынуждены писать код какую-то часть своего времени. Бойлерплейт всякий, или всякие вспомогательные функции, обертки-конвертеры форматов и так далее. Головой там писать мало, но все же этот код нужен, и его приходится писать.
Я вижу очень большую разницу между написанием программы на си и постановкой высокоуровневой задачи на человеческом языке. Примерно такую же, как между написанием кода в машинных кодах (без использования фишек ассемблера) и программой на си.
И все программисты определенно вынуждены писать код какую-то часть своего времени. Бойлерплейт всякий, или всякие вспомогательные функции, обертки-конвертеры форматов и так далее.
Высокопроизводительный программист уже лет надцать как написал скрипты, выполняющие для него рутинные задачи. (Уголком глаза поглядывает в окошко, в котором исполняется скрипт, формирующий квартальный отчёт.)
Я тоже в итоге убрал все подписки, пользуюсь CursorAI, впрочем мне немного больно/непривычно от того, что мне больше нравится JetBrains, а в итоге надо работать в VS.
Немного, конечно, жутко от того как Cursor может экономить время для PoC. В рамках того же фронта подсказал какие библиотеки можно использовать и накрутил весьма приличный дизайн за пару часов. Теперь с AI хотя бы руки доходят до пет-проектов.
Перешел с подписок на гпт и копайлота на continue. Локальные модели для автокомплита и простого рефакторинга + несколько с openrouter для чего то более хитрого. Скорее всего в чем то такое курсору тому же уступает, но у меня и вариантов особых нет, vscode и производные особо в котлин и андроид не умеют.
Разработка софта через описание: опыты с современными LLM