Хабр Курсы для дизайнеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Дизайн доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Лучшая подача материала, которую я видел на Хабре. Такая последовательность мемов на основе только одного кинопроизведения это топ! Было интересно читать, хотя для меня, как разработчика, было мало что нового :)
Круто!
Очень интересно и понятно )) даже человеку который далек от такого контента )
Ллм вообще не умеют в архитектуру. Максимум что могут - это создать запутанную и наглухо связанную кашу из классов. Нужно прямо подробно описывать структуру классов с методами и аргументами, что почти неотличимо от того если создавать руками. Все что может ллм на данный момент делать хорошо - это генерить бойлерплейт.
А она нужна, эта архитектура? Если целую апку с языка на язык, с платформы на платформу, с фреймворка на фреймвор "перевести" (даже не написать) за пол часа можно? Попутно добавив нужных слоёв, если вдруг это стало нужно.
Мне нужна т.к. мне не наплевать на свои проекты. Я хочу видеть красивый чистый код и быстро масштабировать в тч с ЛЛМ. Мне немного некомфортно работать с нечитаемой запутанной лапшой с дырами в безопасности и производительности.. Для ллм эта лапша также будет контекстом и она в ней легко начнет путаться.
за пол часа можно
В сказках вайбанутых. Даже долго. В реальности недавно переносил легаси на новую архитектуру. Заняло 2 месяца с полностью готовой логикой и топовыми моделями.
Понимаю, что пишу непопулярное мнение и нахватаю, но посмотрите на это со стороны бизнеса и, скажем, лет через 5. Мнение и желание отдельных разработчиков при наличии инструментария, которому пофигу читаемость кода (хотя он и будет читаем) и прочие архитектуры (хотя и они будут) - не первичны, мягко говоря. Когда есть выбор, написать за час или за неделю, при этом результат за неделю ну ни фига лучше не будет - понятно, что выберут. Про способность людей писать безопасный код - я вас умоляю. Issue trackerы забиты багами, созданными именно людьми.
Я сам освежал старьё недавно. Это было не просто. Но не потому, что ЛЛМ туп (я наоборот удивлялся, как он во всём этом старье умудряется ещё правильные выводы делать). Непросто это было из-за отсутствия документации. В перегнанном же проекте и документация появились, и тесты (что тоже документация для ЛЛМ). Поэтому следующая перегонка, при надобности, будет многократно проще.
С каких пор бизнесу нужна ТОЛЬКО производительность? Может каким-нибудь вебстудиям, клепающим по сайту в день - вероятно. А нормальному бизнесу нужны надежность и гарантии, что обеспечивается качеством. В первой главе книги "Чистая архитектура" хорошо описано зачем качество нужно бизнесу. ЛЛМ тоже нужно качество т.к. это контекст. В статье выше написан пример, как ллм запуталась в своей лапше. У меня такое было неоднократно. Вот когда мой легаси проект был еще легаси - там был модуль комментариев. И мы вместе с опусом и гпт не могли их привести в рабочее состояние. Одно починят другое отвалится. У меня тогда времени не было и я решил доверить исправление агентам - так и не смогли завести - запутались. Только количество костылей увеличили в 2 раза. В итоге я все снес в корзину и написал с нуля. как ни странно чистый код модели понимают гораздо лучше. Ну это и очевидно если хоть немного разобраться, как работают ллм.
скажите, зачем сейчас в пайплайне реальных бизнесов есть немаленький такой отдел QA? Наверное потому, что и разработчики чуток завирают про свой качественный код, да и разработка сама по себе сложнее, чем просто написание кода. А теперь ответьте, почему в этих разговорах про LLM вдруг забывается существование этого отдела? Да ещё вооруженного средствами, на много более мощными, чем были ещё год назад.
А что бы агенты не путались, код сначала надо покрыть тестами и запретить их менять, прогоняя в каждой итерации. Разберутся, проверено.
Потому что большая часть часть разрабов говнокодеры. Вот на их паттернах ллм и были обучены по большей части. Я говоря за себя и за свой опыт. Архитектуру ЛЛМ писать не умеет. Даже по готовым примерам умудряется наделать тупости, пересвязать разные сервисы одной функциональностью, по 20 раз везде подгрузить отношения, передачу данных организовать по тупому итд В общем, элементарнейшую логику не понимает. Качество ниже плинтуса. Полу-брак, который нужно долго доводить итерациями до работающего состояния. И все с раздражением т.к. ревьюить глупость задача не из приятных. А без архитектуры растущий большой проект превращается в неподдерживаемую лапшу, где ллм копирует паттерны своих же костылей. По поводу тестов - у меня было такое, что модель не могла заставить фичу работать через падающий тест и тогда изменила тест, чтобы проходил. Говорит "теперь тест не падает, можете проверять". Или наглухо зафолбэчит фнкциональность, как оно все зафоллбэчивает, что ты баг еще долго не обнаружишь.
прогоняя в каждой итерации. Разберутся, проверено.
Зачем мне эти извращения? Эти итерации в попытках разобраться в костылях. Мне такое не нужно. Вот у меня был геморойный легаси проект, я его переписал и сейчас с полуслова развивается без извращений. Времени экономится уйма и удовольствие от работы.
Ну а если не ставить целью, что бы ИИ продумал на 100% сам, а задать ему основу из решений и попросить её "раскрутить"? Именно так будет хороший результат. К сожалению согласен, большая часть говнокодеры и часто именно от них больше всего разоблачений тупости ИИ :) Сильных ИИ делает сильнее, слабых - только усиливает их слабости. К инструменту прилагается (к сожалению - по факту не прилагается) инструкция, как его использовать, для получения результата.
И ещё важный момент - вы про какую модель говорите? Многие попробуют бесплатный чатик в фаст режиме и делают вселенские выводы о всей индустрии.
Зачем мне эти извращения? Эти итерации в попытках разобраться в костылях. Мне такое не нужно.
когда вас загонят в рамки дедлайнов, оцененными теми же LLM, станет нужно
Не нужно если у тебя нет этих костылей. Человек и Ллм хорошо ориентируются в правильном коде. Говнокодеры сейчас как раз и визжат на тему вайбкодинга, как они за пол часа переписывают проекты или пишут стартап за завтраком. Т.к. для них это лучший код в их жизни. Задать ему основу - это просто минимум с которого начнутся потом итерации исправлений. Без основы там будет перевязанная лапша. Но даже с основой очень много тупости. Я сейчас пришел к том что всю архитектуру создаю руками, а ллм юзаю как генератор по шаблонам. Модели естественно Опус, соннет, Гпт. Другие не то что пишут хуже, а просто не работают.
Вы неправы об источнике визга и почему-то (хотя знаю почему), так обожествляете код. Я на своём 30ом году активной работы стал код несколько презирать. Потому, что все те гениальные архитектуры, которые я за это время написал, такими гениальными уже не выглядят. Более того, большинство проектов просто мертвы уже. Знания конкретных тех фреймворков - ничего не стоят вместе с фреймворками. Всё новое каждые 5 лет.
НО, вот весь этот опыт решений, граблей, решения проблем, навыки декомпозиции дремучих легаси - позволил моментально начать получать качественный аутпут в клоде. Потому что интуитивно понимаешь, как к нему подкатывать, что ожидать, а что не надо. Как вдруг стали полезными старые практики - TDD, документация, KISS, unit of work, микросервисы и прочее - всё то, с чем отлично расправляется LLM. Стал за пол дня решать задачи, которые давно были в ящике (неплохо бы сделать, но нет ни времени, ни актуальных компетенций) - то что на новых незнакомых библиотеках / языках, и всё сразу с тестами да документацией, которую никогда не любил писать - и да, я от этого если не визжу, то повизгиваю.
Повизгивают и крутейшие топовые разработчики в блогах. После этого разоблачения об убогости LLMок от вчерашних вкатунов - умиляют.
Кто говорит что ЛЛМ убогие? Полезный инструмент для своих небольших задач. Постоянно юзаю. А вот вайбкодинг, там где не то что фичами, а ПРОЕКТАМИ генерят, это да - способ для любителей, кто ничего не понимает, или кому плевать на результат или говнокодеров со стажем.
Вы путаете результат с кодом.
Код это часть продукта, напрямую влияет на поддержку, развитие, безопасность, быстродействие, эффективность проекта и ощущение разработчика.
Продукт может быть вообще черным ящиком, и при этом оставаться продуктом. Сегодня его может разрабатывать один разработчик, а следующую версию с нуля - другой (реальный случай, мы делали вторую итерацию после успешного MVP другой дорогой команды в штатах, но под другие технические требования).
Вы слишком оторванно смотрите на код. Код лишь часть процесса, он не пишется в вакууме. Код решает задачу конкретного этапа. Все эти архитектуры, расширяемости и прочее, часто карго культ, совершенно бесмысленный для MVP. Да и следующих версий, так как пользователей будет 100 и пятьсот слоев абстракций в продукте нужны только программистам, что бы важно надувать щеки =) KISS в общем
Я вообще на код никак не смотрю. Я с ним каждый день работаю. И для меня есть разница - копаться в запутанной лапше или работать с качественной архитектурой. В одном случае этот ужас лучше вообще не трогать, в другом добавлять фичи быстро и одно удовольствие. И я вижу какой говнокод генерит ии в плане архитектуры (к бойлерплейтам вопросов нет). Мне все равно на надувание каких-то щек. Я такими категориями вообще не живу и не думаю. Но я уже начинаю повторяться.. Нравится копаться в лапше - на здоровье.
Я хочу видеть красивый чистый код
Оратор выше прав. Парадигма кода уже не имеет ценности в новом мире. Это как генерируемый компилятором ассемблерный код - на первых порах тоже все справедливо плевались. А кто вот теперь сейчас без подсказки ИИ скажет что делает команда movsxd rbx, eax? В новом мире теперь гораздо важнее грамотно выстроенный пайплайн и поставленная задача. И на этом многие сыпятся. Никакая ЛЛМка не телепат, и то что вам кажется очевидным, для неё совсем не обязательно очевидное.
с дырами в безопасности и производительности
А вы просили эту безопасностью и производительность? Может вы на коленке MVP чисто для себя пишете где это особо и не нужно. Нейронки по всей своей природе минимизируют функцию потерь от поставленной задачи. Всё что не поставлено и мешает этой минимизации - будет выкинуто.
По поводу тестов - у меня было такое, что модель не могла заставить фичу работать через падающий тест и тогда изменила тест, чтобы проходил. Говорит "теперь тест не падает, можете проверять".
И в чём она не права? Вы дали задачу "чтобы тесты не падали". Тесты не падают? Может просто задачу грамотно ставить надо?
Максимум что могут - это создать запутанную и наглухо связанную кашу из классов.
Это для людей. А для неё - чистейший и оптимальнейший код. Просто не надо в этот код смотреть. Код теперь не для людей.
И даже это не проблема, рефакторят они отлично. Если так же отлично ставить задачу.
Известная фраза про психопата с бензопилой, который знает, где вы живете, как раз стопроцентно про знание архитектуры ПО.
Если есть закрытый SDK со своим закрытым API. Как обучить Claude этому API и портировать мой код на него так, чтобы этот SDK не утёк наружу?
Никак. Отдать все данные Пентагону ради развития llm
А как же локальные модели с ollama? Вроде, с ними это решаемо.
Вы же спрашивали про то как обучить Claude.
Модели с открытыми весами вариант. тот же qwen, но все упирается в вычислительные ресурсы и выхлоп который вы хотите получить.
А так вам нужно копать в сторону RAG, эммбендинга, MCP. Из этого можно получить справку по коду.
Если хотите чтобы кодило ещё и сносно, то посмотрите опыт тех кто дообучал модели на язык Julia.
Можно заюзать GLM Coding Plan через Claude Code. Вроде даже модели Z.ai открытые, так что если заморочиться не отдать все данные китайцам...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я портировал свою программу с Windows на macOS за один промт в Claude Code, ну почти…