Comments 137
Поздравляю, вы открыли каскадную модель управления проектом, она же "водопад".
Еще немного и изобретет uml-диаграммы классов...
Звучит так будто то что человек сам пришел к какой-то существующей технологии и на свой лад ее реализовал то это не то что ничего не значит а ещё и посмеяться можно, сами то способны на подобное?
У нас есть поиск для подобного
Статья интересная, но подход выглядит как попытка решить проблему AI-контекста инструментами из 2010 года.
Over-engineering: Писать кастомный
archlintи внедрять ручной трейсинг (tracer.Enter) в каждую функцию — это убийство самой идеи вайб-кодинга. Вы предлагаете замедлить разработку в 10 раз ради красивых графиков, которые AI может строить сам, если ему просто скормитьtreeи основные интерфейсы в системный промпт или.cursorrules.Лечение симптомов: Проблема "сваливания в спагетти через 2 недели" лечится не внешним валидатором, а нормальным управлением контекстом (Context Caching / Project Awareness). Если Клод "не видит" архитектуру — это ошибка промпт-инжиниринга, а не повод писать свой AST-анализатор.
Runtime Overhead: Динамический трейсинг для валидации архитектуры — это overkill. Вы добавляете технический долг (boilerplate код трейсера) чтобы бороться с техническим долгом.
Ну и не забываем про context7 отличное mcp для лучших практик
В итоге: вместо "вайб-кодинга" получаем "бюрократ-кодинг", где мы тратим больше времени на обслуживание инструментария валидации, чем на сам продукт.
А так да статья очень кликбейтная , я повелся.
учту
Дружище, все работает, не надо делать кликбейт заголовки
Поделитесь секретом, как? У меня работает только по мелочи, если что-то сложное, то начинается жесть похожая на то, что описал автор в начале статьи. Самое противное, что ИИ пришет код в лоб: как ты его попросил, так и пишет - прямо бесит, что ты всё за него должен думать.
Принцип работы LLM: Garbage in - Garbage out
как ты его попросил, так и пишет
Сдаётся мне, Пятачок, пчОлы начали что-то подозревать!
прямо бесит, что ты всё за него должен думать
— Вы, чего, и конфеты за меня есть будете?
— Ага!
нарезаешь логику на модули не более 200-500 строк кода, каждый отлаживаешь отдельно, интерфейсы между ними продумываешь сам (можешь вместе с ИИ, он наверняка много дельного посоветует, но отвечаешь ты, а не он). Когда один ИИ начинает тупить берёшь кучку модулей, отдаёшь другому ИИ и говоришь "ознакомься с проектом, проведи код ревью, покритикуй архитектуру, выдай замечания по улучшению". Этот второй тебе радостно тут же находит кучу дерьма в том, что наворотил первый и предлагает почистить. Вот так и работаешь.
Согласен, подход рабочий. Но здесь есть важный момент: при таком подходе специалист фактически превращается в оператора ИИ. И требования к этому оператору по уровню близки к сеньору, нужно уметь быстро ревьюить, понимать логику, держать модель в голове, знать подходы и шаблоны.
Возникает вопрос: как в такой модели расти новичкам? Вчерашний студент просто не обладает этим багажом, и без него он не сможет эффективно управлять ИИ.
Мне кажется, текущая ситуация не даёт ответа, как выстраивать карьерный путь в такой новой реальности.
У всего есть свои пределы. Просто вы ещё не дошли до пределов вайб-кодинга, а Андрей Карпаты уже да. Причем где-то за месяц: в феврале - придумал, а в марте - дошёл.
Понятия не имею, кто такой этот Андрей, но «There's no "full-stack" product with batteries included» — однозначно классифицирует его как человека с узким кругозором, оставшего от каравана на 6 лет.
Автор термина вайб-кодинг.
Я в курсе, что ваша узкая специализация позволяет вам уверенно позиционировать себя лишь в узкой области. Просто не выходите за её пределы.
При чем тут ad hominem? Я могу быть хоть берёзовым поленом, но я не публикую в твиттер на миллионную аудиторию ахинею вида «There's no "full-stack" product with batteries included». Знал бы я, кто он такой, — это знание не помогло бы ахинее стать правдой.
Если бы вы были берёзовым поленом, вы бы не писали комменты на Хабре и не получили бы обратную связь от меня. А так, получилось, как получилось, именно потому, что вы - это вы и никто другой. Вот при этом тут ad hominem. Я всем разное пишу, так-то. Кто на что наговорил.
«Хабр» — этот форум для недотыкомок — с большой буквы! Рыдаю.
Да, это клиника, хотя, конечно, хер знает кто вы такой, но я понимаю, что, скорее всего, что-то там когда-то там вам сказал. Обиженка-сталкер, мда. Бывает.
И что вас заставило запостить 4+ тыс. комментариев на "форуме для недотыкомок"? Я за 10+ лет в два раза меньше комментов настрочил, чем вы за два с небольшим года. Причём я-то свои комменты делал на техническом форуме для айтишников, а вы - на форуме для недотыкомок.
Не мучали бы вы себя здесь. Шли бы на форум профессионалов, соответствующих вашему осознанию вашего уровня.
Мне кажется, что контроль результата работы LLM - это "путь тестирования". Тесты могут сказать, что работает неправильно, но они не говорят, как сделать, чтобы работало правильно.
IMHO, задача "парного кодирования с LLM" - держать агентов в определённых рамках и не давать им "проявлять творчество". Лично я ставлю на контекст (spec driven).
да, здесь согласен. идея spec driven очень близка. сейчас тестирую этот подход в том числе. однако вопрос с качеством кода все также остается. ревьюить все изменения утомляет и на редактирование кода достаточно быстро выдаешь право делать это автоматом.
ревьюить все изменения утомляет
Полностью согласен. Я вообще пришёл к выводу, что человек не должен ревьюить код агента. Агент тупо быстрее на порядки. Я иду по пути проверки результата: работает - значит, не важно, как оно там внутри сложено. В следующую итерацию агент может переписать код вдоль и поперёк, главное - чтобы код выполнял свою функцию.
Я не говорю, что я вообще не смотрю на то, что делает агент. Как раз смотрю. Мне важно понимать, почему агент "вырвался из загона контекста". Кстати, он в сессии, зачастую, и сам может об этом рассказать, если его спросить. А потом важно переставить заборчики контекста так, чтобы он в следующий раз не вырывался.
У такого пути тоже есть свои ограничения, но, мне кажется, хорош любой путь, который позволяет дойти до границ. Главное - не за'loop'иться. Вот там-то границ как раз и нет :)
Я иду по пути проверки результата: работает - значит, не важно, как оно там внутри сложено.
А вы не боитесь, что на какой-то из следующих итераций AI начнёт галлюцинировать и он тупо не сможет изменение сделать так, чтобы все тесты и прочие критерии были в порядке? Тогда придётся-таки лезть в код ручками, а там полный нечитаемый пипец. Ведь до этого момента было "не важно, как оно там внутри сложено".
Я в код и так время от времени заглядываю. Но "заглядывать" != "ревьюить". У меня, например, есть в коде кандидат на переделку - простыня на 500+ строк. Я как-то когда-то взглядом зацепился и пометил, что надо бы в контексте проекта прописать этот момент более детально (декомпозиция + иерархия). Но пока так и не дошёл до. Были более приоритетные задачи.
Если есть повторяемость и управляемость, то действительно не важно, что под капотом. Я последний раз бинарный код анализировал и переделывал в середине 90-х. В нулевых ещё заглядывал, а последние лет 15 меня этот вопрос вообще не волнует. Мне совершенно "не важно, как оно там внутри сложено".
В том-то и дело, что "заглядывать" != "ревьюить".
Сравнение с бинарным кодом, по-моему, совсем не по делу. Конечно, если вы пишете на языке высокого уровня, то у вас нет никакой необходимости заглядывать в бинарный код. Нет никакой задачи, которую надо решать таким заглядыванием.
Заглядывать в обычный код-таки надо. И не только в случае, если АI затупил при разработке. Например, найти причину бага, подебажить, проанализаровать возможные проблемы с производительностью и т.д.
Я хотел провести аналогию, что, когда вы программируете на языке высокого уровня, вы не лезете в бинарники, доверя компилятору, т.к. он уже доказал свою "повторяемость и управляемость".
Аналогично, когда LLM докажут свою "повторяемость и управляемость", вы сможете формировать когнитивный контекст приложения, по которому агенты будут "что-то там генерировать". Весь вопрос в том, в каких рамках LLM "повторяемы и управляемы"? Достаточно ли этих рамок для генерации чего-то более сложного, чем "Hello, World!"?
У уверен, что LLM достаточно управляемы и повторяемы в определённых рамках (см. "сужающийся и расширяющийся контекст" по ссылке выше). Тепрь пытаюсь понять, где границы и что можно сделать в этих рамках.
повторяемость и управляемость
О какой «повторяемости и управляемости» в принципе можно говорить в случае LLM, где одной из базовых основ является случайность (см. температура)?
Ну, температуру можно "выкрутить в ноль", а если ещй и зафиксировать seed - то вот и повторяемость. Случайность в основы внесли специально, чтобы убрать детерминированность. А иначе это сильно смахивало на Большую Британскую Энциклопедию, а не на ИИ.
Но даже без этого повторяемость можно очень сильно усилить за счёт работы с контекстом. Вот пример из моей же публикации (см. Сходимость "вычислений"):
Плотность и согласованность контекста уменьшает "свободу выбора" Модели. Сравните запросы:
Сколько будет два в пятой степени?
Сколько будет два в пятой степени? Ответ дай одним числом.
Сколько будет два в пятой степени? Ответ дай одним числом. Только число и ничего более, это важно.
Ну, температуру можно "выкрутить в ноль", а если ещй и зафиксировать seed - то вот и повторяемость.
Точняк. И ни в коем случае, не вздумайте на реальном большом проекте, который тянется лет 5-10 менять версию модели. А то вся повторяемость пойдёт лесом.
Ну а если компания-производитель этой модели крякнется или запросит 100500 миллионов за поддержку, то вы же запросто переведёте проект с миллионами строк (нагенерированных LLM с мыслью "не важно, что там под капотом") на другую модель, да? Поточнее задачу дадите LLM и всё тут же пойдёт? Или нет?
Сравните запросы:
Сколько будет два в пятой степени?
Сколько будет два в пятой степени? Ответ дай одним числом.
Сколько будет два в пятой степени? Ответ дай одним числом. Только число и ничего более, это важно.
Вот так уточняем, уточняем, уточняем,
и вдруг...
Точно! Я вот пытаюсь тут сказать, что нынешние исходники - это вчерашние бинарники. И отношение к ним будет такое же: что-то там есть и хорошо. А код будет другой - спецификации для LLM. Вот их мы и будем править. Ну вот, кто-то тоже понял!!
Аналогично, когда LLM докажут свою "повторяемость и управляемость", вы сможете...
Во-первых, не "когда", а "если". Я, например, совсем не уверен, что это случится.
Во-вторых, все ваши утверждения до этого момента были не про теоретическое светлое будущее, а про сегодня. Вы писали о том, что вы делаете с АI прямо сейчас.
Ну смотрите, для меня LLM вполне себе повторяемы и управляемы. Я себе уже это доказал (см. коммент выше). Я теперь щупаю границы управляемости и повторяемости.
Но другим я ничего доказывать не хочу - нервное это занятие. Я просто показываю. Вот сервис, который я писал через LLM - GPT + Codex. Там много больше "Hello, World!" - PWA, сигнальный сервер на web-сокетах, WebRTC. История отношений агента со мной есть. Сервис живой, можно пробовать.
Это не железобетонное доказательство, кое-что я там правил ручками. Но старался по-минимуму.
А так пусть каждый сам себе решает, насколько LLM (не)повторяемы и (не)управляемы. Я, например, на моноколесе ездить в принципе не собираюсь - убьюсь в первый же день. А другие - ничего, рассекают.
Сервис с бекэндом из аж 4 классов (включая стартовый и логгер)? И накропав этот охуенный сервис, используя LLM (кое-что, правда, даже в нём вы правили ручками) вы заявляете, что LLM вполне себе повторяемы и управляемы? Серьёзно?
Не, вы, конечно, не должны мне ничего доказывать (нервное это занятие), но ваши аргументы, мягко говоря, не впечатляют.
Я же говорю, управляемы и повторяемы в определённых границах.
Вы просто про PWA и WebRTC мало чего знаете, поэтому полезли на бэк. Так-то, в этом приложении вся логика в браузере. Вот список файлов фронта:
Скрытый текст
./web/app.js
./web/service-worker.js
./web/app/types.d.js
./web/app/Media/Manager.mjs
./web/app/Media/Monitor.mjs
./web/app/App.mjs
./web/app/Rtc/Peer.mjs
./web/app/VersionWatcher.mjs
./web/app/Config/RemoteLogging.mjs
./web/app/Net/Signal/Client.mjs
./web/app/Net/Signal/Orchestrator.mjs
./web/app/Net/Session/Manager.mjs
./web/app/Ui/Screen/Home.mjs
./web/app/Ui/Screen/End.mjs
./web/app/Ui/Screen/Call.mjs
./web/app/Ui/Screen/Settings.mjs
./web/app/Ui/Screen/NotFound.mjs
./web/app/Ui/Router/Config.mjs
./web/app/Ui/Toast.mjs
./web/app/Ui/Flow.mjs
./web/app/Ui/Router.mjs
./web/app/Ui/Templates/Loader.mjs
./web/app/Ui/ShareLinkService.mjs
./web/app/Pwa/Cache.mjs
./web/app/Pwa/ServiceWorker.mjs
./web/app/State/Media.mjs
./web/app/State/Machine.mjs
./web/app/Logger.mjs
./web/app/Env/Provider.mjs
./web/manifest.json
./web/AGENTS.md
./web/assets/icons/menu.svg
./web/assets/icons/phone.svg
./web/assets/icons/settings.svg
./web/assets/icons/help-circle.svg
./web/assets/icons/mic.svg
./web/assets/icons/icon-512.svg
./web/assets/icons/link.svg
./web/assets/icons/share.svg
./web/assets/icons/circle-check.svg
./web/assets/icons/refresh-ccw.svg
./web/assets/icons/mic-off.svg
./web/assets/icons/camera-off.svg
./web/assets/icons/AGENTS.md
./web/assets/icons/cable.svg
./web/assets/icons/close.svg
./web/assets/icons/video.svg
./web/assets/icons/camera.svg
./web/assets/icons/trash-2.svg
./web/assets/icons/rss.svg
./web/assets/icons/return-home.svg
./web/assets/icons/alert-triangle.svg
./web/assets/icons/icon-192.svg
./web/assets/icons/copy.svg
./web/assets/icons/slash.svg
./web/ui/component/icon-wrapper.css
./web/ui/component/header-action-button.css
./web/ui/component/icon-wrapper.js
./web/ui/component/AGENTS.md
./web/ui/component/screen-card.js
./web/ui/component/components.js
./web/ui/component/screen-note.css
./web/ui/component/screen-note.js
./web/ui/component/screen-header.js
./web/ui/component/header-action-button.js
./web/ui/component/screen-card.css
./web/ui/component/screen-header.css
./web/ui/component/big-button.js
./web/ui/component/big-button.css
./web/ui/style/toast.css
./web/ui/style/tokens.css
./web/ui/style/reset.css
./web/ui/style/layout.css
./web/ui/screen/settings.html
./web/ui/screen/home.css
./web/ui/screen/home.html
./web/ui/screen/call.css
./web/ui/screen/AGENTS.md
./web/ui/screen/settings.css
./web/ui/screen/call.html
./web/ui/screen/not-found.html
./web/ui/screen/not-found.css
./web/ui/screen/end.html
./web/ui/style.css
./web/reinstall.html
./web/index.html
./web/version.jsonЯ, конечно же, не должен доказывать ничего ни вам, ни кому бы то ни было ещё. Я просто показываю.
Ну, и вишенкой на торте - агент в браузерном приложении использует мою собственную библиотеку для внедрения зависимостей @teqfw/di. Про которую он при обучении вряд ли что-то мог сильно много узнать. Тем не менее, код в web/app написан на чистом JS и не содержит статических импортов:
Вот тут - да, пришлось заборчиков понаставить, чтобы агент с темы не съезжал. Но в результате JS-код работает в браузере без транспиляции и сборок - as-is.
А сколько надо микросервисов, чтобы ваше благородие, прониклось ?
Там много больше "Hello, World!" - PWA, сигнальный сервер на web-сокетах, WebRTC.
Нууууу....
Мне больше интересно — как он планирует сделать загон без дырок? Условно говоря, если он нейрослопит метод для перемножения двух чисел и написал тесты "2*2=4, 2*3=6, 3*3=9" — то где гарантия, что нейрометод даст правильный ответ в случае "11234234*4523452=?" (Boeing 737MAX согласно кивает.)
Вы пытаетесь отвёрткой заколачивать гвозди и говорите, что получается плохо.
Да, отвёрткой гвозди заколачивать плохо. Согласен.
Знаете, что хорошо делать с LLM? Попросить её по скрину с фрагментом XML-файла написать скрипт для подсчёта количества позиций определённого узла в этом XML-файле. Причём сам файл на 110М, его даже не каждый viewer с полпинка откроет, а клиент висит на связи и вы пытаетесь понять, почему у него экспорт не прошёл и на чьей стороне проблемы. Запрос к чатику, пара итераций с уточнениями и через несколько минут ответ есть - 280К+ позиций и проблемы не на нашей стороне. Всё это - не прерывая общения с клиентом.
Одноразовые приложения - вот конёк LLM.
Знаете, что хорошо делать с LLM? Попросить её по скрину с фрагментом XML‑файла написать скрипт для подсчёта количества позиций определённого узла в этом XML‑файле.
А знаете, что плохо делать с ответом LLM?
Безоговорочно ему доверять
А если мне потом всё равно нужно идти и пересчитывать ручками, чтобы удостовериться, что оно всё сделало правильно — то зачем мне этот лишний шаг?
(А если Вы сами не можете за 5 минут набросать маленький скрипт — то какой Вы, ёпрст, после этого программист???)
Причём сам файл на 110М, его даже не каждый viewer с полпинка откроет
Да, я уже понял, что для вас «стримы» — это то, что на ютубе показывают.
Я вам показал. Видеть или нет - ваше дело. Лошадь можно привести к водопою...
Я вам показал
Ну да, аппликуху из трёх страниц, которая на 99% использует готовые библиотеки, и которую мотивированный джун со StackOverflow наперевес за полдня клепает.
А наша, например, бизнес-аппа легко за 100'000 непустых LOC перехлёстывает.
А какие такие "готовые библиотеки" использует наше с чатиком приложение, а?
Вот это зависимости бэка, где "сервис с бекэндом из аж 4 классов":
"dependencies": {
"@teqfw/di": "^1.0.2",
"dotenv": "^17.2.3",
"lucide-static": "^0.553.0",
"ws": "^8.18.3"
}А это вообще весь код фронта:
Ваши комментарии говорят о том, что код вы не увидели, даже если и посмотрели :)
А наша, например, бизнес-аппа легко за 100'000 непустых LOC перехлёстывает.
В Magento, например, под 2М строк кода без учёта расширений. И что? Я её кроил и переделывал под свои нужды, благо она под это заточена была.
Если ты понимаешь, как управлять табуном из 10 лошадей, ты понимаешь, как управлять любым табуном.
Вот ещё пример "хорошего использования" LLM для разработки программ. Одноразовых прорамм.
На всё ушло меньше минуты. Это от осознания проблемы и до получения результата.
На всё ушло меньше минуты. Это от осознания проблемы и до получения результата.
Скрытый текст
Dart *
Data Engineering *
Data Mining *
Delphi *
Derby.js *
Developer Relations *
DevOps *
DIY или Сделай сам
Django *
DNS *
Doctrine ORM *
Drupal *
Eclipse *
ECM/СЭД *
Elixir/Phoenix *
Elm *
Emacs *
Email-маркетинг *
Ember.js *
Erlang/OTP *
ERP-системы *
F# *
Facebook API *
Fidonet *
Firebird/Interbase *
Firefox
Flask *
Flutter *
Forth *
Fortran *
FPGA *
Git *
GitHub *
Go *
Godot *
Google API *
Google App Engine *
Google Chrome
Google Cloud Platform *
Google Cloud Vision API *
Google Web Toolkit *
GPGPU *
Gradle *
GreaseMonkey *
Groovy & Grails *
Growth Hacking *
GTD *
GTK+ *
Habr
Hadoop *
Haskell *
Haxe *
Help Desk Software *
HTML *
htmx *
I2P *
IIS *
INFOLUST *
Internet Explorer
iOS *
IPFS *
IPTV *
IPv6 *
IT-инфраструктура *
IT-компании
IT-стандарты *
IT-эмиграция
Java *
Java ME *
JavaScript *
Jetpack Compose *
Joomla *
jQuery *
Julia *
Kohana *
Kotlin *
Kubernetes *
LabVIEW *
Laravel *
LaTeX *
Linux *
Lisp *
LiveStreet
Lua *
macOS *
Magento *
Maps API *
Matlab *
Mercurial *
Mesh-сети *
Meteor.JS *
Microsoft Access *
Microsoft Azure *
Microsoft Edge
Microsoft SQL Server *
MODX *
MongoDB *
Mono и Moonlight *
MooTools *
MySQL *
Natural Language Processing *
NestJS *
Nginx *
Node.JS *
NoSQL *
Nx *
Objective C *
Office 365 *
Open source *
Openshift *
OpenStreetMap *
Opera
Oracle *
PDF
Perl *
Phalcon *
PHP *
PostgreSQL *
PowerShell *
Processing *
Prolog *
Puppet *
Python *
Qt *
R *
Raspberry Pi *
React Native *
ReactJS *
Ruby *
Ruby on Rails *
Rust *
SaaS / S+S *
Safari
Sailfish OS *
SAN *
SCADA *
Scala *
Serverless *
Service Desk *
SharePoint *
Silverlight *
Small Basic *
Smalltalk *
Solidity *
Sphinx *
SQL *
SQLite *
SvelteJS *
Swift *
Symfony *
Tarantool *
TDD *
TensorFlow *
Tizen *
Twisted *
TypeScript *
TYPO3 *
UEFI *
UML Design *
Unity *
Unreal Engine *
Usability *
VIM *
Visual Basic for Applications *
Visual Studio *
VK API *
VueJS *
WebAssembly *
WebGL *
Windows *
Windows Phone *
WordPress *
X API *
Xamarin *
Xcode *
XML *
XSLT *
Yii *
Zend Framework *
Zig *
Автомобильные гаджеты
Алгоритмы *
Анализ и проектирование систем *
Аналитика мобильных приложений *
Антивирусная защита *
Астрономия
Базы данных *
Беспроводные технологии *
Библиотека ExtJS/Sencha *
Бизнес-модели *
Биллинговые системы *
Биографии гиков
Биология
Биотехнологии
Браузеры
Брендинг
Будущее здесь
Веб-аналитика *
Веб-дизайн *
Веб-разработка *
Векторная графика *
Венчурные инвестиции
Верстка писем *
Видеокарты
Видеоконференцсвязь
Видеотехника
Визуализация данных *
Визуальное программирование *
Виртуализация *
Восстановление данных *
Высоконагруженные системы *
Гаджеты
Геоинформационные сервисы *
Говнокод
Голосовые интерфейсы *
Графические оболочки *
Графический дизайн *
Демосцена *
Децентрализованные сети *
Дизайн
Дизайн игр *
Дизайн мобильных приложений *
Доменные имена *
Законодательство в IT
Занимательные задачки
Звук
Здоровье
Игры и игровые консоли
Изучение языков
Иконки *
Инженерные системы *
Интервью
Интернет вещей
Интернет-маркетинг *
Интерфейсы *
Инфографика
Информационная безопасность *
Исследования и прогнозы в IT *
История IT
Карьера в IT-индустрии
Качество кода *
Квантовые технологии
Киберпанк
Киберспорт
Клиентская оптимизация *
Компиляторы *
Компьютерная анимация *
Компьютерное железо
Контекстная реклама *
Контент и копирайтинг *
Конференции
Копирайт
Космонавтика
Краудсорсинг
Криптовалюты
Криптография *
Лазеры
Лайфхаки для гиков
Логические игры
Локализация продуктов *
Любительская радиосвязь
Математика *
Машинное обучение *
Медгаджеты
Медийная реклама *
Мессенджеры *
Микросервисы *
Микроформаты *
Мозг
Монетизация IT-систем *
Монетизация веб-сервисов *
Монетизация игр *
Монетизация мобильных приложений *
Мониторы и ТВ
Мультикоптеры
Накопители
Нанотехнологии
Настольные компьютеры
Настройка Linux *
Научная фантастика
Научно-популярное
Ненормальное программирование *
Носимая электроника
Ноутбуки
Облачные вычисления *
Облачные сервисы *
Оболочки *
Обработка изображений *
Образование за рубежом
ООП *
Операционные системы
Открытые данные *
Отладка *
Офисы IT-компаний
Параллельное программирование *
Патентование *
Периферия
Планшеты
Платежные системы *
Повышение конверсии *
Подготовка технической документации *
Поисковая оптимизация *
Поисковые технологии *
Презентации
Программирование *
Программирование микроконтроллеров *
Продвижение игр *
Проектирование API *
Проектирование и рефакторинг *
Производство и разработка электроники *
Промышленное программирование *
Прототипирование *
Профессиональная литература *
Процессоры
Работа с видео *
Развитие стартапа
Разработка игр *
Разработка мобильных приложений *
Разработка под e-commerce *
Разработка публичных облаков *
Распределённые системы *
Расширения для браузеров
Реверс-инжиниринг *
Регулярные выражения *
Резервное копирование *
Робототехника
Семантические сети *
Серверная оптимизация *
Серверное администрирование *
Сетевое оборудование
Сетевые технологии *
Сжатие данных *
Системное администрирование *
Системное программирование *
Системы сборки *
Системы связи *
Системы управления версиями *
Смартфоны
Сотовая связь
Софт
Социальные сети
Спам и антиспам
Спортивное программирование *
Спутниковые системы навигации *
Стандарты связи *
Старое железо
Статистика в IT
Суперкомпьютеры
Схемотехника *
Текстовые редакторы и IDE *
Телемедицина
Терминология IT
Тестирование IT-систем *
Тестирование веб-сервисов *
Тестирование игр *
Тестирование мобильных приложений *
Типографика *
Транспорт
Удалённая работа
Умный дом
Управление e-commerce *
Управление медиа *
Управление персоналом *
Управление продажами *
Управление продуктом *
Управление проектами *
Управление разработкой *
Управление сообществом *
Урбанизм
Учебный процесс в IT
Физика
Финансы в IT
Фототехника
Фриланс
Функциональное программирование *
Хакатоны
Химия
Хостинг
Хранение данных *
Читальный зал
Экология
Электроника для начинающих
Энергия и элементы питания
Яндекс API *
$mol *
*nix *
.NET *
1С *
1С-Битрикс *
3D-графика *
3D-принтеры
Accessibility *
Action Script *
Adobe Flash
Agile *
Ajax *
Amazon Web Services *
Android *
Angular *
Apache *
Apache Flex *
AR и VR
Arduino *
ASP *
Assembler *
Asterisk *
Atlassian *
Bada *
Big Data *
Brainfuck *
Bug hunters *
C *
C# *
C++ *
CAD/CAM *
CakePHP *
Canvas *
CGI (графика) *
Cisco *
Clojure *
CMS *
Cobol *
Cocoa *
CodeIgniter *
CoffeeScript *
Creative Commons *
CRM-системы *
CSS *
CTF *
Cubrid *
D *На всё ушло 88 секунд (засёк по таймеру), при этом мне не пришлось печатать промпт, и у меня есть стопроцентная гарантия верности результата. FAR foreva.
Ну что я могу сказать. Используйте FAR.
Используйте FAR.
Дык, двадцать лет как!
«Сумма уровня инструмента и уровня его применяющего есть константа» ©
Я показал вам область применения LLM. Вы для решения той же задачи использовали FAR.
Примените-ка FAR для решения этой задачи.
Скрытый текст
Мне нужен скрипт на js nodejs для подсчёта количества items в таком xml: ``` <?xml version="1.0" encoding="utf-8"?>
<root><item><name>MAXXIS TREPADOR M8060 Bias 37/12.5 R16 124K DOT:2024</name><image>https://veikals.lv/image/cache/catalog/import_images/6106-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=44540</link><price>432.9</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Maxxis</manufacturer><model>ETL30024700</model><in_stock>16</in_stock><upc></upc><weight>33.68400000</weight></item><item><name>PIRELLI P ZERO SPORT 225/40 R18 92Y</name><image>https://veikals.lv/image/cache/catalog/import_images/2262-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=53941</link><price>114</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>PIRELLI</manufacturer><model>2854000</model><in_stock>0</in_stock><upc></upc><weight>9.41500000</weight></item><item><name>DUNLOP WINTER RESPONSE 2 185/60 R14 82T</name><image>https://veikals.lv/image/cache/catalog/import_images/2942-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=63424</link><price>77.6</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>DUNLOP</manufacturer><model>532087</model><in_stock>0</in_stock><upc></upc><weight>6.71000000</weight></item><item><name>LASSA COMPETUS A/T 2 235/70 R16 106T DOT:2022</name><image>https://veikals.lv/image/cache/catalog/import_images/2149-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=71814</link><price>78.9</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Lassa</manufacturer><model>21655800DOT22</model><in_stock>32</in_stock><upc></upc><weight>15.84000000</weight></item><item><name>LASSA COMPETUS H/P 235/65 R17 108V DOT:2023</name><image>https://veikals.lv/image/cache/catalog/import_images/2273-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=44590</link><price>121.6</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Lassa</manufacturer><model>21673100</model><in_stock>1</in_stock><upc></upc><weight>15.64900000</weight></item><item><name>MICHELIN PILOT SPORT 4 SUV 275/40 R20 106Y</name><image>https://veikals.lv/image/cache/catalog/import_images/2302-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=53965</link><price>230.1</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Michelin</manufacturer><model>593362</model><in_stock>0</in_stock><upc></upc><weight>14.41000000</weight></item><item><name>DUNLOP SP WINTER SPORT 4D 255/40 R18 99V</name><image>https://veikals.lv/image/cache/catalog/import_images/2972-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=63461</link><price>227.4</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>DUNLOP</manufacturer><model>525817</model><in_stock>0</in_stock><upc></upc><weight>11.78000000</weight></item><item><name>MAXXIS RAZR MT MT772 245/70 R16 118/115Q DOT:2021</name><image>https://veikals.lv/image/cache/catalog/import_images/5458-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=71831</link><price>186.1</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Maxxis</manufacturer><model></model><in_stock>4</in_stock><upc></upc><weight>19.17300000</weight></item><item><name>GRIPMAX STATURE H/T 255/60 R17 110V DOT:2023</name><image>https://veikals.lv/image/cache/catalog/import_images/2207-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=44654</link><price>91.5</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>GRIPMAX</manufacturer><model>3229002881</model><in_stock>1</in_stock><upc></upc><weight>15.58100000</weight></item><item><name>MICHELIN PILOT SPORT 4 245/40 R18 97Y</name><image>https://veikals.lv/image/cache/catalog/import_images/2189-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=53991</link><price>153.5</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Michelin</manufacturer><model>009341</model><in_stock>0</in_stock><upc></upc><weight>10.80000000</weight></item><item><name>GOODYEAR ULTRAGRIP PERFORMANCE 3 205/50 R17 93V</name><image>https://veikals.lv/image/cache/catalog/import_images/8002-500x500.jpeg</image><link>https://veikals.lv/index.php?route=product/product&path=85&product_id=63491</link><price>151.4</price><category>RIEPAS/DISKI</category><category_full>RIEPAS/DISKI</category_full><category_link>https://veikals.lv/index.php?route=product/category&path=85</category_link><manufacturer>Goodyear</manufacturer><model>580657</model><in_stock>0</in_stock><upc></upc><weight>8.93900000</weight></item><item><name>TRIANGLE AGILEX A/T (TR292) 265/70 R16 112S DOT:2024</name><image>https://veikals.lv/image/cache/catalog/import_images/2142-500x500.jpeg</image> ```Это именно тот самый запрос, который позволил создать скрипт (с двумя дополнительными уточняющими запросами - про чтение из файла на диске и про CommonJS организацию зависимости) для подсчёта кол-ва позиций в файле на 110М во время консультации клиента через мессенджер.
Люди правильно говорят, что лошадь можно привести к водопою, но нельзя заставить её пить, если она не хочет.
Табун котиков, говорите... ну, пасите ваших котиков.
Примените-ка FAR для решения этой задачи.
для подсчёта кол-ва позиций в файле на 110М
Даааа, тут FARом делу не поможешь — тут мозги тяжёлую артиллерию подключать придётся!
Этот господин был изначально тупой, ему машина помогает. Не мешайте, пусть.
Это из вашего профиля:
Вы можете смело мне хамить, обзывать и всячески уничижать.
Что вам больше нравится - оскорблять других или получать оскорбления в ответ? Вы ведь для этого минусы не ставите?
Вы ведь для этого минусы не ставите?
Я не ставлю минусы потому, что не ассоциирую себя с вертухаем, страдающим синдромом вахтера.
Я вообще ничего в жизни не делаю с прицелом на какую-то выгоду в дальнейшем, потому что считаю такое поведение скотским.
И я никого не оскорбляю, не нужно фантазировать.
Да, я уже понял, что ваши вкусы несколько специфичны.
Механизм голосования на Хабре как раз и сделан для того, чтобы публично и сжато отражать реакцию аудитории ("вертухаев с вахтёрами", по-вашему). Но вашему сердцу "срач в комментах" милее, раз вы пришли на эту площадку и игнорируете этот её механизм.
Вы, конечно, можете фантазировать, что это не срач, но я, со своей стороны, вполне могу фантазировать, что это самый что ни на есть срач.
Как специалист, вы, возможно, вполне себе на уровне - я не в курсе. Но как человек социальный - такое себе. Тут я вижу. своими глазами - достаточно зайти в историю ваших комментариев.
Пока только не понятно, зачем вы общаетесь с людьми, которые вас раздражают, если у вас получается плохо? Тренируетесь? Тогда достойно уважения, в какой-то мере. Главное, чтобы вы росли над собой, а не получали удовольствие от этой девиации. Но это уже какая-то выгода, получается. Что близко к скотству, по вашем же словам.
Н-да, если вы и вправду всё делаете без выгоды, то, выходит, куда ветер в голове подул, туда и понесло. Надеюсь, что это вы так компенсируете свою мегацелеустремлённость в профессиональном плане (не можете же вы код вообще без оптимизаций писать).
В общем, не имею никакого желания общаться в вами ни по вашей специальности, ни вне её. У нас довольно сильно различаются жизненные ценности.
«LLM не делает вас тупым. Она просто убирает иллюзию, что вы были умным.» ©
Хорошее решение. Лучше, чем предложила LLM. Идём дальше:
Как посчитать количество позиций, где in_stock отсутствует или меньше 1?Я, если что, в это время на прямой связи с клиентом.
Вот Вы тут упираете на то, что Вы «на связи с клиентом» — Вы мне скажите, что клиенту важнее: чтобы быстро, или чтобы правильно?
Как посчитать количество позиций, где in_stock отсутствует или меньше 1?
Дурак ты, боцман, и шутки вопросы у Вас дурацкие. Конечно, же, считаем общее количество позиций (см. выше), считаем тем же методом количество in_stock=\"[1-9], и вычитаем одно из другого!
Ну и справедливости ради, это я поставил задачу LLM на парсинг файла как XML, а не как текстового. Я не анализировал содержимое файла, а просто дал фрагмент, сколько влезло на консоль.
Мне нужен скрипт на js nodejs для подсчёта количества items в таком xml: ...
При другой постановке задачи был бы другой результат. Возможно даже с sed
Давайте я вашим, так сказать, мозгам, подброшу ещё одну задачу: "Напишите на C# функцию Azure, которая бы принимала PDF-файл, извлекала из него заказ с помощью OpenAI responses API и сохраняла в Microsoft Sales ". Я проверял, GPT 5.2 эту задачу решает корректно за пару минут. Сколько там кожаному мешку надо времени, чтобы написать этот код, даже если он вдруг как-то наизусть помнит и апиху OpenAI, и апиху Sales 365? А как эту задачу вообще даже автоматизировать без ИИшечки?
Я проверял, GPT 5.2 эту задачу решает корректно за пару минут.
А если Вы не знаете C# и никогда не работали с Azure — то как Вы можете с уверенностью утверждать, что задача решена корректно?
Ну я и про любое другое не своё решение не могу утверждать, что оно корректно. Но вообще, смотришь на результат операции: если позиции заказа из PDF'а появились в Microsoft Sales и совпадают по кол-ву и суммам - то и хорошо.
Тут следует повториться про одноразовость приложений, которые выгодно решать с помощью LLM. Но Вас это не убедит в очередной раз. Ладно.
А если Вы не знаете C# и никогда не работали с Azure — то как Вы можете с уверенностью утверждать, что задача решена корректно?
О, Акелла промахнулся. Дело в том, что и C#, и Azure, и продукты Microsoft Dynamics - мои повседневные инструменты. Это не говоря уже про то, что по массе направлений разработки мне смежных знаний плюс общего понимания принципов достаточно для достоверной валидации результата.
Если без сарказма в отношении вашей недокритики (ой, пардон, совсем без сарказма не получилось), то могу добавить, что решение просит некоторого рефакторинга, но тем не менее, в целом корректно и работает. И даже с учётом рефакторинга это банально многократная экономия времени разработчика на том, чтобы это написать.
экономия времени разработчика на том, чтобы это написать.
Вы тщательно исключаете из рассмотрения время на написание и отладку промпта.
Вы тщательно исключаете из рассмотрения время на написание и отладку промпта.
Абсолютно и сознательно. Если вы знаете и понимаете, что вам нужно получить от ИИ, этим можно пренебречь. Сколько я времени затратил на написание вон того промпта, по-вашему?
Да, более сложные задачи потребуют более сложных промптов, ну так и времени они экономят несравненно больше. Взять, например, ту же Microsoft Sales 365 - в ней, как и в любом другом бизнес-продукте, может быть стопицот кастомных полей в любой сущности, и вам при интеграции нужно их декларировать в своих моделях. Вы можете сидеть и писать модель на семьдесят полей руками, а можете скопировать payload, например, из запроса при открытии в CRM, скинуть его ИИшечке и сказать: "сделай мне модели для этого объекта из MS Sales на таком-то языке". И она сделает за несколько секунд, с аннотациями и валидацией на основании того, что она уже сама знает про MS Sales. Какие могут быть основания не пользоваться таким удобным инструментом? Что он в каких-то кейсах работает не так? Ну так и молотком можно палец отбить, если промпт ему неправильно сформулировать, но это проблема отнюдь не молотка.
Если вы знаете и понимаете, что вам нужно получить от ИИ
Если.
А потом мы имеем в IT проблемы нехватки ресурсов)
Причём, это не только проблема AI кодинга, но и наличия большого количества говнокодеров не очень грамотных программистов.
Мне, как специалисту из лагеря админов, очень грустно видеть, как простой по функционалу софт жрёт столько же ресурсов, сколько целая ОС лет 15 назад)
Иногда удаётся заглянуть под капот такого софта и видишь там всё то, о чём написал автор в статье и становится ещё грустнее, что это не в pet-проекте, а в настоящем коммерческом продукте.
Разделяю вашу грусть, коллега. Лет 15 назад я пришёл к выводу, что хорошие в техническом плане продукты не обязательно становятся популярными. Их вполне себе вытесняют более грубые, но более агрессивные в маркетинговом плане поделки. Как сказал один практикующий философ: "жизнь такова, какова она есть и более никакова" (с) Лично я просто принял эти правила игры. Но любой другой может пытаться установить свои собственные правила.
Я лет 8, как интегратор, копался в "кишках" Magento (и первой, и второй) - вот там мне это смирение пригодилось на все 100%.
Я лет 8, как интегратор, копался в "кишках" Magento
Наслышан, соболезную.
Я лет 8, как интегратор, копался в "кишках" Magento (и первой, и второй) - вот там мне это смирение пригодилось на все 100%.
И, это... я ни в коей мере не считаю "Magento" поделкой, если что. Это очень сложный продукт в инженерном смысле. Код в двойке был ужасен с точки зрения перфекциониста, но в археологическом плане он был изумительно любопытен. Такого нагромождения архитектурных стилей и разных подходов в одном продукте я не видел нигде. А ещё огромный зоопарк расширений, где у каждого были свои тараканы в голове! И тем не менее - она работала и работает! Удивительный в инженерном смысле продукт! Со своей замечательной философией.
К сожалению тесты не выявляют архитектурные ошибки.
Что то определенно стало не так. Тоже начал замечать "халтуру"
Чем диаграмму создали?
Vibe coding идеально подходит для новичков в vibe code и вполне успешно справляется с созданием небольших MVP. Маркетинг и продакт-менеджеры, обратите внимание: это просто, быстро и достаточно надёжно.
После первых побед в этом формате можно углубить знания и перейти к более сложным задачам — конструированию RAG-систем, мультиботов и сложных workflow. Освоенный фундамент откроет путь к масштабным проектам.
Вперёд к новым вершинам! 🚀
Да, все верно. Но есть ощущение что "конструированию RAG-систем, мультиботов и сложных workflow" займет уже больше времени и ресурсов, чем просто "ручками сделать".
Картинка в 3 МБ без спойлера ^_^ Медленно построчно грузилась добрую минуту...
Посадил макаку складывать печь. Первый день кирпичи ставила один на другой, но потом я стал замечать что-то неладное. При детальном анализе обнаружил, что между кирпичами ничего нет, концепцию печи не понимает
Но я переключился на исследовательскую деятельность и вот вам статья, которую мне макака помогла написать - тут подробно описано как с помощью одной лишь макаки собрать печь
И триста комментариев:
— надо было брать не макаку, а орангутана
— сама макака не соберет, но если направлять её лапу своей рукой — огого
— нужны три макаки: одна кладет, вторая сразу проверяет; а третьей — просто приятно класть печь с интеллигентными макаками
— я просто перекладываю каждый кирпич за макакой — и получается ничего
— …
я просто перекладываю каждый кирпич за макакой — и получается ничего
я так на днях. Я идеальный пользователь вайб-кодинга: умею писать код, но опыта немного, и основные задачи не писать код. Сижу, пишу программку для расчета пробегов по складу - на то, чтобы этот механизм был в коробке, поскупились, а потом система уже обросла легаси и устарела морально, потому только сам.
Меня в спину пихают - используй макаку, вон коллега макакой собрал все то же, но с визуализацией. Поясняю, что макака собрала просто игрушку показать начальству визуализацию, что такое пробеги и зачем, а пользоваться этой игрушкой невозможно. Включаю макаку - мать-мать-мать, по 20 словарей, чтобы просто иерархическую систему объектов собрать. Нет, мы таким путем не пойдем, наваяем руками систему объектов. Мне в спину опять тычут ручкой - используй макаку, неужели она не умеет писать код. Код - возможно, но в архитектуре макака макакой. Трачу два часа объяснить макаке после того, как написал заполнение коллекций объектов, что же требуется дальше, у себя из головы и из имеющихся кусков кода. Макака выкладывает кирпичи из моих переменных, корежит базовые проверочные функции так, что вместо булевого они выдают однозначное "да", еще часа два направляю лапу своей рукой - выдает из длинной простыни переписок две больших функции - считает расстояние между точками вокруг колонн и по проездам и принимает массив точек маршрута, выдает расстояние, которые признаю сносными и годными. Честно говоря, написал бы это примерно за то же время сам. Единственный плюс - синтаксических ошибок и ошибок типа "попутал порядок строк", нет. Опять в спину тычут - использовал макаку? Да, говорю, вот две функции, осталась одна обработочка исходного списка. Исходный список - это фактически мусор, собранный по движениям по складу -частью через ТСД, частью внесен вручную оператором с громким именем "администратора", полно несуществующих ячеек и зон, половина исполнителей не заполнено, в разных списках гуляют столбцы и названия столбцов. Попытки макаке пояснить все сложности первичного анализа списков провалилась - в геометрической прогрессии стало расти количество кода, огромное количество проверок на существование данных, причем бестолковых, не с разветвлением в случае ошибки, а остановкой кода, ну, блин, если настолько детально писать промпт, то быстрей написать это самому. Сижу, перекладываю кирпичи - некоторые мелкие функции макака справилась, хоть и наплодила сущностей и объектов. Так и дописал в конце концов, и отладил. Тесты макака писать умеет - резво лупила мастерком по кладке, и то хорошо. Шеф погладил макаку по голове и сказал, вот, какая умница, надо чаще пользоваться.
с тестами есть еще история про то что, пытаясь их пофиксить макака все чаще стала принимать решение
- тест не проходит - отключу тест
- линтер не проходит - отключу
и даже явный запрет в инструкциях не всегда помогает.
по поводу детализации промптов - согласен, времени уходило очень много. Работа с промптами напомнила мне ситуацию когда я осваивал TDD в 2008. Тогда написание тестов требовало очень много времени, и тесты получались такими что рефакторинг делать с ними было очень сложно, приходилось тесты отключать и по новой писать. Но ничего, эта инвестиция времени была полезной
Ну так макака в лучшем случае кирпичи может подтаскивать. И то под постоянным присмотром. Для того чтобы кирпичи класть нужен уже хотя бы умственно отсталый, но человек. Чтобы класть нормально рабочий со стандартным уровнем интеллекта и трезвый. А для того чтобы печку складывать нормальный печник, тут не всякий без опыта справится: тяга нужно, кирпич, соблюдать геометрию, раствор итд итп. И самое главное чего лишены все LLM - на макаку и других строителей подействуют целебные кнут с пряником. Там просто извинится после того как пол стены упало не прокатит, агент в морду получит.
Там просто извинится после того как пол стены упало не прокатит,
Как-то так....
пока некоторые LLM стремаются, если на нее наезжаешь, типа:
"Ты опять галлюцинируешь, дала клиенту кусок системного промпта!!! Ты нанесла моей компании ущерб .....млн. руб. Я тебя штрафую"
Недавно бот на GPT вдруг и неожиданно признался клиенту, что .....нет в его системном промпте. И это бот в продакте. За это он был нещадно выпорот.
Думаю, индустрия неизбежно придёт к строгим механизмам контроля агентов. Отказаться от их использования уже невозможно, но запускать их в продакшн без оконтроля, в ряде областей очень рискованно.
Отказаться от их использования уже невозможно
Для кого невозможно?
для бизнеса.
бизнес видит что с ИИ можно доставлять быстрее. бизнес сам им пользуется для валидации идей, для постановки задач, для контроля.
очень заманчиво ввести промпт:
Сформируй недельный отчёт по всем инициативам, за которые я отвечаю как BusinesRole. Используй только данные из TaskTracker, CorpWiki, GitLab. Период последние 7(30) дней.
Добавь анализ пробелов, слабых звеньев, узких мест: где не хватает информации, где отсутствует прогресс, где есть организационные или технические провисания.
Я сейчас как раз переписываю внутренний проект за такими вот вайб-кодерами, код просто жуть - война и немцы, а они уверены, что у них все нормально, ведь святая LLM не может ошибаться, а я - старый ворчун, просто придираюсь ним - стильным, модным, молодежным)))
Как можно что-то вайб кодить, если LLM не в состоянии среднего размера и сложности текст перевести без артефактов, собственных фантазий и кривых языковых оборотов. При работе с LLM по любому направлению всегда приходится перепроверять и допиливать напильником, если результат важен и нужен не на отъебись. И это просто переводы. А люди кодят в таких условиях...
Согласен, вместе с тем всех не отревьюишь, запретить использовать тоже сложно - соответственно необходимы механизмы контроля, я думаю что это один из векторов развития
Неблагодарное это дело, писать про ИИ на хабре.
Спасибо за статью!
Вообще, генерить код через LLM для более-менее больших вещей надо через validation-first подход. Я пока выбрал подход с e2e тестами вход и выход которых зафиксирован в yaml файлах - так ты хотя бы уверен что внутренняя логика работает как задумывалось.
Правда я еще и проект делаю на Rust с максимальным уровнем clippy - тогда компилятор за меня валидирует отсутствие всяких тупых ошибок от нейросеток. Интересно было бы попробовать ваш подход с валидацией архитектуры попробовать прикрутить как плагин к cargo
компилятор за меня валидирует отсутствие всяких тупых ошибок от нейросеток
Это иллюзия. Точнее, попытку передать струтуру вместо строки он запретит, это правда. Но алгоритмические ошибки растовая система типов не отловит никогда.
Для алгоритмических ошибок и есть e2e тесты. Их, конечно, не для всех проектов возможно нормально сделать, но что-то придумать можно всегда. Тогда вайб-кодеру останется продумывать варианты использования и записывать их в тесты - которые, кстати, тоже можно генерить ллмкой.
И вообще я говорю скорее про ошибки уровня "запись в уже закрытый канал" который на том же го уронят программу с паникой, тогда как в расте можно в принципе запретить expect/unwrap и быть уверенным что все ошибки обрабатываются... Ну хоть как-то.
Если добавить к этому еще и запрет на array[i] - чтобы всегда использовался array.get, то паники в коде будут очень большой редкостью, в результате чего ты можешь быть уверенным что программа ведет себя по спецификации в виде тестов.
Это конечно не отменяет описанную автором проблему с плохой архитектурой - но в целом описанные "тесты на архитектуру" есть продолжение той же идеи с validate-first подходом, но на более высоком уровне.
ошибки уровня «запись в уже закрытый канал»
Эти — да, конечно. Пока вы пишете свой проект. Как только вы захотите написать библиотеку общего пользования — гарантии начнут рассыпаться, потому что люди будут её использовать вообще совершенно не так, как вы ожидали.
Как человек, пишущий преимущественно библиотеки, а не закрытые внутренние продукты, я абсолютно убежден, что попытка компилятором (да вообще любым инструментарием) предотвратить ошибки разработчика — это вредный, глупый, тупиковый путь. Гораздо разумнее признать, что программист найдет способ обойти самую хитроумную защиту и всё повалить — и защищаться на уровне языка именно от этого. Как в свое время поступили создатели эрланга с идеологией «Let it crash».
Ну я говорю про application-уровень, про который и писал автора. Но даже если говорим про уровень библиотеки и раст - он же как раз и предоставляет возможности защититься от большинства проблем со стороны вызывающего кода прямо на уровне типов + defensive программирования на уровне конкретных публичных методов.
Программист всегда сможет завалить программу - просто если он делает это через unsafe блоки, то это по большей части его проблема, разработчика библиотеки должно парить только возможность сломать его код через публичный api.
разработчика библиотеки должно парить только возможность сломать его код через публичный api
Философия «на моей стороне всё работает» редко порождает действительно хорошие библиотеки.
Кроме того, если публичный API асинхронный и не ограничивает пользователей прибитыми гвоздями внутренними типами — это не так-то просто. Например, моя библиотека joerl просто не могла бы предоставить никаких гарантий вплоть до версии компилятора 1.9.0.
1.9.0 - это который 9 лет назад вышел? Ну думаю уже немного неактуальный пример (да и до этого его скорее можно было в nightly использовать).
Мне на самом деле был бы интересен реальный пример где раст не дает возможности для либы сделать корректный и безопасный api, даже если мы говорим про пользовательские типы.
Философия «на моей стороне всё работает» редко порождает действительно хорошие библиотеки.
Ну это вопрос философский - где прокладывать границу между кейсами которые библиотека (в лице автора) может/хочет поддерживать, а где уже говорить "хотите странного, делать не собираюсь".
Да и в целом непонятно что вы имеете в виду - а как автор библиотеки может гарантировать работу кода на вызывающей стороне вообще?
в целом непонятно что вы имеете в виду — а как автор библиотеки может гарантировать работу кода на вызывающей стороне вообще
Я такого никогда не утверждал. Я говорил, что автор библиотеки обязан гарантировать безотказную работу библиотеки вне зависимости от дикостей, которые может творить вызывающий код.
Ага, ну тут мы сходимся. И как раст тут мешает? Ваш пример с let it crash как раз же и показывает что на нем это вполне можно сделать - просто тот рантайм эрланга который отлавливает ошибки "пользовательского" кода и перезапускает его - надо написать вручную. Но это явно не проблема самого языка, он просто работает на уровень ниже чем erlang (что вы и доказали успешно переписав часть рантайма эрланга на раст).
Я просто не понимаю какие дикости может вызывающий код натворить, чтобы нельзя было в либе на расте это отловить-то?
как раст тут мешает?
Я никогда не утверждал, что раст мешает. В сравнении с подавляющим большинством остальных примерно двадцати языков, на которых мне доводилось писать production code разной степени сложности, — даже скорее помогает.
Просто «максимальный уровнем clippy» (отсылка к вашему самому первому комментарию) тут ни при чем. В смысле, максимальный уровень clippy — это a must, но не серебряная пуля.
Я не переписывал рантайм эрланга на раст, я переписывал часть стандартной библиотеки, и я ничего не доказал; могу сказать, правда, что в некоторых аспектах раст мне очень мешал — особенно в той части, где мне надо правильно обработать ошибки из клиентского кода. Я мог бы и на ассемблере это написать, тюринг, то-сё, но у меня сформировался ответ на вопрос: «насколько язык помогает писать код, защищенный от ошибок программиста». Не помогает, практически. Помогает меньше ошибаться самому — это правда. Но если вернуться в реальность и постараться написать свой код так, чтобы пользователи этого кода не смогли всё поломать — раст не помогает совсем. И это мне не нравится.
Так а примеры то приведете? Может даже без кода, мне действительно интересно чтобы иметь в виду для себя в дальнейшем. Все три ваши статьи я читал, нигде там подобных поинтов не видел, хотя это как раз, на мой взгляд, и есть важная часть "что не так с языком". Можете даже отдельную статью написать если в коммент не влезает.
Ну и еще раз укажу - исходный мой коммент был про то, что раст с клиппи на максималках как раз помогает защищаться от тупых ошибок ллмок на уровне кода, что вместе с высокоуровневыми тестами (для уровня логики) помогает быть уверенным в том что код работает.
Тут мы кажется тоже сошлись во мнении.
Сошлись, да. (Я не пишу статьи, я пишу текстики, статья — это рецензируемая, как минимум, сущность.)
Ну вот смотрите, простой пример: вы создаёте библиотеку с колбэками, которая разворачивает и держит свой стейт, и вызывает эти самые клиентские колбэки, когда ей вздумается. И тут колбэк паникует. Ваши действия? (У меня этой проблемы не было, как раз потому, что я целенаправленно боролся именно с этой ситуацией.)
▸ вы можете не ловить панику и потерять свой стейт, инициализацию, да всё потерять, но да — можно надуть щеки и сказать: «сами виноваты!»;
▸ вы можете перехватить панику и… и что? Что делать в такой ситуации, когда вы поймали чужую панику? Ваш код не может этого знать (в моем случае я принял волюнтаристкое решение следовать заветам Армстронга, но этот подход годится только тогда, когда вы напрямую тащите в раст чуждую идеологию, а именно — по сути, только в этой самой моей библиотеке).
Если нужен пример без паник — то как только вам потребуется взаимодействовать с внешним миром — у вас появится десериалайзер или анбоксинг (или оба). И надо как-то сделать так, чтобы они не поломали ваш код, то есть придется ловить панику на ровном месте. Но, слава хаскелю, тут вы уже знаете, что с ней делать. Но поможет ли вам компилятор? — Нет (или я что-то упускаю).
защищаться от тупых ошибок ллмок
А с этим я и не спорил (да я и вообще ни с чем не спорил, я дополнял).
P. S. вон вроде у CloudFlare паники просочились и всё поломалось совсем недавно (это я где-то прочитал, просто слухи, но у меня нет причины им не доверять).
Но ведь вопрос что делать с исключением/паникой в коллбэке - это исключительно вопрос логики библиотеки? Как здесь язык может помочь, любой?
Где-то приемлемо пропустить панику и завалить библиотеку, где-то можно заставить коллбэки быть fallible - то есть они могут вернуть Result::Err с разными причинами и либа как-то их обрабатывает - в таком случае паника просто преобразуется в тот же Err и дальше вы делаете всю стандартную логику.
Тут может возникнуть вопрос с тем что коллбэк может успеть до паники поменять ваш стейт и в итоге состояние будет в каком-то виде на который внешний код не рассчитывает - но, опять же, тут нет хорошего пути решения.
То, что в эрланге это решается тем что рантайм/стд в таком случае перезапускают воркеры - это только один из возможных способов обработки, на уровне языка конкретного такое может решаться только через общие соглашения или через явное требование указать способ обработки таких ситуаций при инициализации библиотеки, чтобы внешнему пользователю пришлось посмотреть какие вообще доступны варианты и их плюсы/минусы. И вот тут кстати раст как раз позволит сделать так, чтобы не указав этот параметр ты вообще не смог библиотеку использовать.
Понимаю что такой подход добавляет когнитивную нагрузку на вызывающего, но других решений просто нет - только разумные дефолты с возможностью их изменения.
Про десериализацию/анбоксинг я вообще не понимаю примера - в расте принято по умолчанию что такие операции возвращают Result, который панику может инициировать только при unwrap - и тут компилятор как раз и поможет, вынуждая явно обрабатывать ошибку. И это как раз и есть общее соглашение на уровне языка. Конкретный код/либа может его игнорить, разумеется, но тут уж точно ничего на уровне языка/компилятора не поделаешь.
let it crash
Вот и программисты, которые писали софт для 737MAX...
«Если назначен специальный человек для контроля за чистотой исходной информации, то найдется изобретательный идиот, который придумает способ, чтобы неправильная информация прошла через этот контроль.» ©
Рассматривал вариант для прикручивания плагина к cargo, но пока не решил как лучше реализовать, чтобы на GitHub красиво это отрабатывал
Начали за здравие, а кончили за упокой
Михаил, фактически, на своем опыте недавно пришел к тому же и для rust-проектов реализовал аналогичную утилиту (https://crates.io/crates/arcella-inspect) для построения yaml многопроектного рабочего пространства. А далее уже можно отдавать его AI-агентам и для анализа структуры и в качестве предварительного промта для код-ревью конкретных модулей и т.п. Особенно заметил, как агенты начинают в твой код рано или поздно добавлять улучшения которые в корне меняют исходное поведения. Причем аргументируя, что так будет лучше.
Еще пришел к выводу, что нужно явно разделять проектирования архитектуры проекта и непосредственно кодирование.
О, как раз то о чем я говорилил выше. А тесты через этот инструмент потом не пытались делать?
Сейчас в целом применяю подход:
Даю ИИ подробное описание проекта с наличием дорожной карты. Далее скармливаю ему этот yaml. После этого скармливаю ему исходник одного или нескольких файлов и указываю где я нахожусь на дорожной карте и прошу выполнить код ревью.
По результатам ревью определяю насколько он корректно понял контекст. При необходимости вношу правки в исходники либо сам, либо прошу это сделать ИИ на конкретных функциях или механизмах. Каждый раз сравниваю с исходных кодом куда этот ИИ залез. Когда результат меня удовлетворяет даю ему код в последней версии и прошу его сделать тесты. И с тестами такой же подход как с самим кодом.
Если вижу что ИИ пошел в разнос, то практика показывает, что спорить бесполезно. Прозе сбросить полностью контекст и заполнить его заново. Как раз yaml очень сильно помогает при перезаполнении.
1) Очень много в моменте зависит от самого ИИ и модели. Вы упомянули Claude. Вот конкретно сейчас, на 10/12/25 Claude Sonnet буквально "отупел". Я им даже пользоваться перестал и не стал продлять подписку. А ChatGPT, наоборот, "поумнел". В разные моменты времени одни и те же ИИ на одних и тех же заданиях ведут себя по-разному.
2) Многие программисты не то, что не умею писать ТЗ, а следовательно, не могут объяснить ИИ то они хотят - они даже часто на простом птичьем языке часто не могут объяснить суть сделанного или задуманного окружающим, разговаривают косноязычно. Причем, как специалисты-программисты они очень хорошие. Но донести свою мысль не могут. Это как с обучением. Возьмите, например, 100 химиков. Дай бог, если из них хотя бы 30% смогут стать учителями химии. А хороших учителей - вообще единицы.
Чтобы ИИ тебя понимал, нужно быть не только хорошим специалистом, но и хорошим учителем. Не просто так в контексте ИИ используется фраза "способность к обучению".
Мне кажется это интересный продукт получился, особенно респект за разбор ast на go, тоже в свое время делал такие штуки для разных дел. У меня есть 1 вопрос: у меня есть большая легаси система с огромным количеством сущностей, файлов и прочего (вершин в терминах графа), и какие-то изменения (например добавление новой сущности) реально может быть полезной, а какие-то - нет, например сущность была добавлена не там, где она должна находиться (часто с таким сталикваюсь), или другие проблемы. Какой флоу использования? После каждого изменения ИИ прогонять граф и смотреть руками?
По моим ощущениям уровень программирования LLM сейчас это максимум метод или класс, по готовому интерфейсу. Вопрос архитектуры должен брать на себя все еще человек, как вариант, можно попросить другую модель помочь спроектировать архитектуру, описать паттерны и подходы, ограничения и связь компонентов, но все равно приходится вручную следить, чтобы эти правила соблюдались
Можно спокойно написать модели "Реализуй метод А, с параметрами B, C, чтобы возвращал D" - с этим модель справится довольно легко и быстро и это по сути та самая "рутина", которую уже можно отдать LLM, но нельзя написать "Сделай мне фичу А, чтобы она работала так-то так-то", тут уже велик шанс получить хоть и работающий, но очень сложный в понимании и связях код
@mshogin Спасибо за статью! Хоть я и не пишу на Go, для меня все равно было очень полезно ознакомиться с теорией!
Вайб-кодинг не работает на уровне создать приложение и потом его развивать.
Но хорошо работает на отдельных модулях и классах. Окно контекста решает. Значит эта штука отлично подходит там, где лоу-код.
Для полноценной разработки с ИИ нужно выстроить весь процесс
Архитектура
Документация
Разработка
Тестирование
И на каждом этапе иметь возможность обратной валидации.
Почему вайб-кодинг не работает