Comments 100
Мне понравилось
Спасибо! А что-то конкретное понравилось или в целом подход?
В целом то, что заранее «и об этом подумай, и об этом не забудь», и плавно брюки превращаются в «товарищ, у нас тут для вас/LLM задан контекст проекта, причем глобально… это уже не условная ерундятина, just think».
Я про такое раньше думал, но это казалось очевидно-невероятным, потому что ну вроде да, все это нужно сделать ДО, но если этого не просят… А тут понятно, что таки надо, таки контекст для llm.
Из удобностей в плане "док о проекте" я придумал себе только вписывать в readme.md содержимое отдельного файла plan.md, и если план выполнен, то файл с ним можно переименовать/переместить, и для readme.md он «исчезает», и моя «документация по проекту» генерируется в html не запинаясь. Или где-то в тот же readme положить диаграмму если не модулей, то хотя бы этапов выполнения шагов в main.py, чтобы постоянно видеть, к чему надо придти в итоге и где я сейчас.
Я пришел из мира скриптов на bash, они в принципе монолитно-индивидуальные, «сделай все в одном файле», а сейчас привыкаю разносить шаги в тематические модули единого проекта, и окрепло ощущение необходимости поясняющей информации и в отдельных модулях, и более глобально, потому что постоянно переключаюсь между двумя уровнями восприятия проекта. Наверное, стоит и про vision подумать заранее.
На первых порах, думаю, многие обманывались в ожиданиях от ИИ. Дальше либо находили способы работы с ИИ, либо отвергали, либо просто откладывали до лучших времен
Контекст - это самое важное для ллм! Верно акцент расставили! Спасибо!
Справедливости ради, надо сказать, что и для человека контекст важен не меньше )
Да, пробуйте создавать мини тех проекты на подобии vision. Лучше потратить лишние 15 минут на объяснение LLM общей идеи, но зато сэкономить часы на этапах генерации кода далее )) Кстати опять же, как и с человеком )) Только у "человеков" есть возможность, а у многих и привычка, думать над дизайном в процессе работы над кодом - поэтому нам это сходит с рук местами.
Схему с plan не до конца понял, что значит "вписывать содержимое файла plan.md" (это какая-то директива для системы автогенерации документации)?
Да.
В файле readme.md есть строка
<!-- INSERT_PLAN_MD -->
Сборка документации по проекту через pdoc проходит так:
создаю файл /tmp/README.md,
в который вставляю содержимое оригинального readme.md,
а внутри него вместо строки <!-- INSERT_PLAN_MD --> вставляю содержимое файла plan.md.
ввва
Если файл plan.md отсутствует (удален или переименован), то вместо <!-- INSERT_PLAN_MD --> будет пустота, и сборку документации это не остановит.
Дальше выполняю сборку документации через "pdoc", который бегает по всем файлам и собирает описание модулей из докстрингов, и в браузере открывается html, на главной странице Readme и внутри него раздел «План работы» — он же список задач, он же отчет о том, какие из задач уже сделаны (расставляю смайлики в начале строки).
Когда всё доделаю, переименую файл plan.md в 1plan.md и раздел «План работы» в readme уже не будет отображаться.
Ну текст то можно было и ручками набрать
Ну или хотя бы, по примеру из текста, добавить в него нормальных правил, чтобы он выходил не таким рафинированно-штамповным
+1 от меня вам в карму
Для хеллоувордов сойдет, не более
Не соглашусь с Вами.
Действую по принципу описанному в статье.
Работаю на основном проекте и фриланс проекте.
Flow вполне рабочий, НО, для крупно-габаритных проектов, возможно, нужны улучшения.
ИМХО подход НЕ только для "холоу ворлдов"
А я работаю с решениями в несколько десятков(бавало даже сотен) проектов на разных языках(в основном С/C++, C#) и фреймворках, несколько таких решений написал и спроектировал сам, и есть у меня такое ощущение, что я буду дольше такую доку писать, чем сам проект, это без учета проверки и отладки того, что нагенерировалось, еще есть ощущение, что то, что нагенериться для онбординга будет полным мусором. Если вы думаете, что написать код ручками сложно - нет, не сложно, сложно его поддерживать, оптимизировать, расширять и делать понятным. У вас просто таких потребностей нет, так как пишете отдельные, небольшие, одноразовые проекты.
Мериться и спорить крупностью проектов не буду.
Но, говорить, что у меня проекты "маленькие и глупенькие", не стоит.
Я, как написал автор, "слона по кусочкам режу".
Иногда, проще самому написать код, а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.
Так что, не знаю.
Все эти "поддерживать, оптимизировать и расширять" я понимаю и также придерживаюсь, НО, при этом, ничего не мешает писать код за счет AI, того же cursor.
Так что, скажу еще раз: "ИМХО, не только для `холоу ворлдов`" и чуть расширю мысль - такой подход закрывает часть задач, "СВОЕГО уровня" и такие задачи могут быть на ЛЮБОГО уровня и габарита проектов.
Резать и пилить у нас в стране все умеют, а что в итоге то? А в итоге вы получите ласкутное одеяло, вместо собранного из частей слона, которое разваливается на ходу. Плавали, знаем.
а иногда лучше написать "доку", разбить ее на части, оперируя бизнес логикой, а дальше...ничем не отличается от ревью МРа джуна.
Сомнительно, но окей. Тут две проблемы для большого проекта: либо описывай кучу функционала в больших задачах, либо кучу задач с маленьких функционалом. И там и там куча функционала, а значит и документации. И опять же, как это все потом будет вместе работать - не понятно. Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема, кто вам эту портянку из документации валидировать будет, все ли там согласовано или нет. А с учетом галюнов, то на сколько эта валидация будет корректна. То, что автор указал в качестве архитектуры проекта - типичный хэлоуворд и только для такой архитектуры применим описанный в статье принцип разработки ПО, о чем и был первый мой комментарий.
Весь проект у вас в мозги ИИ не влезет, отсюда еще одна проблема
Это верно, конечно.
Но ведь если следовать low coupling, и всяким буквочкам типа S, I и D - зачем "всему" влезать в мозги?
Это и есть распиливание слона на запчасти - в итоге: куча документации и размывание общей картины в лучшем случае, в худшем - комок грязи (мы переварили слона, мы молодцы). Также стоит заметить, что этого слона нужно грамотно разделать, иначе будет очень неприятно его есть из-за горькой желчи, либо привкуса фикалий, а для этого нужно знать, что такое слон из чего он состоит
Конечно, нужно грамотно разделывать уметь.
Этого никто не отменяет. Пока ИИ за нас такие вещи решать не умеет. Все же ИИ это ассистент.
В одном из докладов разработчиков Антропик - они сказали, что уже дошли до этапа, когда они не проводят ревью кода, сгенеренного ИИ, но это пока только "листовые" куски кода - тот функционал, который не будет меняться в обозримом будущем.
Остальные вещи они у себя в Антропик, кстати решают, очень похожими методами, как описано в статье. Да, мы и сами всеми этими методами пользовались до появления ИИ.
А потом просто многие либо забыли, либо стало лень готовить и разжевывать для ИИ задачу. Не говоря, уже о том, что сильно упал порог входа, и многие без понимания основ и базовых практик SE начали вайбкодить. А по факту, грамотно используй, так как нужно тебе или твоей команде, отталкиваясь от ее уровня.
Такая бюрократия не всегда хорошо, так как много времени отнимает, то есть нужно нанимать промп-инженеров, которые по цене как разработчики, но только промт-инженеры. Опытному разработчику задача понятна по 2-3 предложениям из таска, на крайний случай 1 созвон на 5-10 мин. Будет ли такая задача понятна промт-инженеру для генерации нужного промта, сомневаюсь. В общем, тут много скользких моментов, а профита маловато, если вообще есть.
Не правильно сравнивать ИИ с опытным разработчиком, тем более у которого опыт не только в технологиях, но и в конкретном проекте. Стартовые условия разные. ИИ это не магия. ИИ это как отличник, выпускник ВУЗа. Который не знает ни ваших процессов работы, ни вашего проекта, ни тем более различных велосипедов, костылей и прочего в проекте.
Также можно сравнить опытного разработчика с новым разработчиком на проекте. И даже новому разработчику не будет достаточно двух фраз в таске и 10 минут созвона. Ему надо будет изучать и погружаться в проект, контекст.
А если проект тесносвязанный, запутанный, без модульности, документации. Опытный разработчик перегружен или вообще отсутствует/уволилися? То что будет делать новичок? Разве не разбираться, изучать, фиксировать для себя заметки, доку создавать. Вот это уже все можно кратно ускорить с помощью ллм.
А создав все это и вооружив этим описанием ллм, можно провести сравнение
Опять как то странно все, у вас человек на проект приходит, осваивается, через пару недель уже можно задачи давать, зависит от уровня, какие именно, смотря на сколько вник и какой потанцевал. ИИ каждый раз как новый лист. Только для его работы нужна куча промфтов. Которые не всегда дадут один и тот же ответ.
Возможно так будет работать лучше, не тестил. Из моего коммента ниже:
Тут интересно. Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно. То же самое можно сделать и с нейросетью. Не с LLM, а отдельной локальной специализированной неросетью, под конкретный проект, тогда ей уже можно давать задачи как обычному разработчику, без развернутой документации. Утверждать ничего не буду, еще не пробовал, все руки не доходят.
Опять как то странно все, у вас человек на проект приходит, осваивается, через пару недель уже можно задачи давать, зависит от уровня, какие именно, смотря на сколько вник и какой потанцевал.
И все это время можно потратить не для того, чтобы одного спеца погружать. А создать хорошую базу знаний и контекст проекта удобный для восприятия ИИ.
ИИ каждый раз как новый лист. Только для его работы нужна куча промфтов. Которые не всегда дадут один и тот же ответ.
Суть подхода, как раз в том, чтобы контекст не каждый раз создавать. А фиксировать его в файлах, правилах. Тогда это делается ровно также разово, как и погружении нового спеца в проект.
Удобный для ии, но не для специалиста.
Если контекст проекта простой, как и сам проект - сомнительно, ну окей. Если контекст сложный и масштабируется вы умрете в этих промтах, это уже не говоря о том, что для решения крупной задачи контекста самой llm может не хватить, а если эту задачу пилить, то качество ее решения может сильно упасть.
Мы применяем ИИ как на новых проектах, так и на масштабных легаси проектах с многолетней историей.
Конечно описанный подход, и сам ИИ, не серебряная пуля. В каждом проекте свои особенности, свои нюансы.
Но суть ведь подхода в том, что ИИ это не магия, и относиться к нему нужно, не как к магу, а как к человеку. У ИИ ограничен контекст и у человека ограничен, ИИ не выдаст сразу "конфетку", но и новый в проекте человек тоже не выдаст и т.д. и т.п.
Ну и этапы решения задачи в целом схожи, надо вначале разобрать задачу, подумать, спроектировать решение, построить план решения, учесть существующие соглашения, написать код и т.д. Каждый из этапов ИИ помогает сильно ускорить. Понятно, что для каждого профи точки ускорения будут отличаться.
Я правда не понял, Вы в принципе ИИ не применяете в проектах? Или у Вас какой-то другой способ применения? Можете рассказать?
LLM - это костыль, костыль может быть инструментом, но остается костылем.
У ИИ ограничен контекст и у человека ограничен, ИИ не выдаст сразу "конфетку", но и новый в проекте человек тоже не выдаст и т.д. и т.п.
Тут интересно. Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно. То же самое можно сделать и с нейросетью. Не с LLM, а отдельной локальной специализированной неросетью, под конкретный проект, тогда ей уже можно давать задачи как обычному разработчику, без развернутой документации. Утверждать ничего не буду, еще не пробовал, все руки не доходят.
Для написания кода LLM не использую, так как не ощущаю никакого профита, для решения отдельных задач некоторые алгоритмы машинного обучения справляются неплохо, те же нейросети, но больше нравятся эволюционные вычисления. Как такового ИИ пока не существует в принципе. Его можно создать на основе экспертных систем, что позволит получать достоверные знания, а не гадать как LLM. Вообще, я за искуственный разум, а не интелект.
Нейросеть - это кухонный комбайн (если проводить аналогии). Он не может сделать хорошее блюдо, если повар не знает, как именно блюдо готовится, какие нужны ингредиенты и что из них на каком этапе закидывать в общий котёл. Но если повар шарит - этот комбайн в разы ускоряет работу.
Я сам, конечно, совсем не разработчик (аналитик данных), но с помощью той же нейросети за 4 вечера успешно сделал покерный калькулятор на C# (при том что ранее ни разу ничего не кодил на C#). Калькулятор с точным расчетом Equity и EV. С тепловой картой стартовых рук (которая меняет диапазоны, в зависимости от позиции игрока, есть ли ставка оппонента и соотношении ставки оппонента к банку). С рекомендациями по игре на разных улицах (учитывая количество оппонентов, размер банка и так далее). Считается это все за секунду при 100 тысячах симуляций по Монте-карло (через адаптированный алгоритм оценки руки от Кевина Саффекула). И немного GTO-логики при оценке действий под капотом (которую ещё нужно докручивать). Смог бы ли я сделать тоже самое без нейросети? Нет. А сколько времени бы занял такой небольшой проект у среднего программиста? Наверное неделю, может две. При этом, как уже отметили ранее, для нейросети КРАЙНЕ важен контекст и количество деталей. Мой первый запрос был подробно расписан на нескольких листах А4. И в дальнейшем никаких проблем с написанием кода не возникало.
Я рад за Ваши успехи, но контекст проектов, с которыми я работал и работаю, это сотни( тысячи) листов А4, которые изменяются и дописываются в отличие от правил покера, т.к. появляются новые хотелки, обновляются инструменты, изменяется законодательство, политическая и экономическая ситуация в мире и т.д. И еще один интересный вопрос : каким кухонным комбайном лучше обработать печень рыбы фугу и кто, если что, понесет ответственность? А также насколько критична скорость обработки?
Новый человек может загрузить себе в мозг основной контекст и держать его, это сложно, но можно
Может, действительно сложно. Более того не очень долго. При переключении задач, каждый раз перегружать контекст вообще боль. А если методично создать такой контекст и систему правил по которым такой контекст ллм будет получать для решения задач, то тут скорость прогрева фактически моментальная.
1 вариант - куча связных контекстов, которые вы llm скармливаете, выглядит это, если честно, страшновато - очень много работы с документаций, а еще страшнее глюки llm и отладка кода. 2 вариант - общий контекст, тогда документацию вам сама нейросеть выдаст, по обычному запросу как в гугле, а так же сможет агента запустить на изменение кода при минимуме описания
Весь проект и в ваши мозги не влезет. А если влезет, то едва ли вы видели большие проекты. В любом случае, слишком много «у меня ощущение», зачем вообще спорить если вы даже не побывали по обе стороны и, соответственно, не понимаете, о чем говорите?
Ну дак пост не ставит целью восхваление Юрия или демонстрацию его способности к разработке сложных проектов и поддержанию контекста комплексной архитектуры. Его задача — показать, как обычные разработчики могут улучшить процесс создания простых, масштабируемых решений. Юрий, знакомы ли вы с модульными подходами, или вы приверженец такого стиля кодирования, при котором никто, кроме вас, не сможет разобраться в вашем коде, обеспечивая тем самым вашу незаменимость?
Как раз наоборот, я придерживаюсь такого подхода, при котором, даже пришедший джун мог быстро разобраться в том, что написано, а не взрывать свои и мой мозг в надежде разобраться во взаимосвязи кучи модулей, которые настроили до него, по принципу тетриса на самой высокой скорости.
Если Вам кажется, что у меня высокое чсв, то Вам кажется. Мне вот кажется, что у Вас нет понимания, что такое многослойная распределенная архитектура, а есть понимание как впихать очередной микросервис в кучу других микросервисов так, чтобы эта конструкция не развалилась под собственным весом, то что там будет куча копипасты, непонятные зависимости, дыры в безопасности, ужасная производительность никого не волнует, главное чтобы не развалилось пока мы на проекте сидим, и да нас не выгнали потому, что никто, кроме нас, да и мы сами уже не знаем как это работает как система в целом.
Его задача — показать, как обычные разработчики могут улучшить процесс создания простых, масштабируемых решений
Мой первый коммент как раз на эту тему, хотя по поводу масштабируемых поспорю.
За статью спасибо. Очень близко, т.к. действую в той же "парадигме".
В некоторых "узких местах", добавляю псевдокод или оперирую техническими компонентами. Хз как объяснить, зачем именно так, чем это лучше простого написанич кода, кроме как: "я тян - пруфов не будет"
Интересно 👍 Не совсем понятно, как в случае с conventions.md сочетаются требования «не дублировать информацию из него» и «отразить все главные принципы разработки из документа @vision.md». Ведь без дублирования не обойтись: если изменится vision.md, придётся править и conventions.md. Может, тогда в vision.md оставить только принципы? Что там есть ещё, кроме принципов?
Спасибо.
Не совсем понятно, как в случае с
conventions.mdсочетаются требования «не дублировать информацию из него» и «отразить все главные принципы разработки из документа @vision.md»
Без этой инструкции бывало модель начинала переписывать весь vision.md
А нужно, чтобы основные принципы были внесены, а детали реализации остались в vision
если изменится
vision.md, придётся править иconventions.md
Да, верно, если изменится vision, то и conventions имеет смысл обновить.
Также в ходе развития проекта, корректировок модели, указания ей на ошибки и т.п. очень полезно просить модель учесть это и внести в соглашения. Поэтому соглашения живой документ.
Может, тогда в
vision.mdоставить только принципы? Что там есть ещё, кроме принципов?
В vision у нас по сути мини тех проект нашего решения. На мой взгляд, пусть он там и остается, а в соглашениях будут более общие вещи. В общий контекст пойдут оба файла. Но, если вы разделите эту информацию по-другому, и сократите "повторяемость", то это будет только лучше!
Когда хочешь, чтобы приложение не просто работало, а хорошо работало, то вайб-кодинг заканчивается.
А насколько это хорошо работает для задач, которые миллион раз ещё не кодили?
Например:
разработать генератор gcode для 3Д принтера с XY-core архитектурой на прошивке klipper, шестерен гиперболоидной зубчатой передачи, задаваемой передаточным отношением, расстоянием и углом между осями и минимальным модулем? Профиль зуба стандартный, эвольвентный. Допуски и точность печати игнорируем.
В случае невыполнения ограничений по контактной прочности для выбранного пластика выводить ошибку и предлагать варианты изменения геометрии, решающие проблему.
Задачки по геометрии ИИ решает плохо - известный факт.
Но в остальном, если подать в него доки с примерами, должен справляться, нет?
Я много раз проходил ситуацию, когда надо было работать со свежими инструментами, разработанными в 2025 году, и context7 с доками помогал ИИ переставать глючить и выдавать рабочий код с первого раза.
Никак не работает. И не решает задачи вообще. Может только относительно точно процитировать существующее человеческое решение или интерполировать текст решения чего-то. И то очень неточно.
Задачки по геометрии ИИ решает плохо - известный факт.
Благодаря Декарту мы знаем, что геометрия - это алгебра (даже арифметика) :). ИИ в это тоже не умеет?
Но в остальном, если подать в него доки с примерами, должен справляться, нет?
Как и что подать? Пример решённой задачи? Если она решена, то зачем, простите, ИИ?
Я не против использования генераторов кода как инструмента поиска кода, который неохота писать. Но я не считаю этот процес кодингом и тем более программированием.
И уж точно не буду выпускать это как лично сделанное за деньги в эксплуатацию. Может я, конечно, ретроград и консерватор, но мне кажется, что то, что делаешь, должно пройти через голову и руки.
Генерация кода хорошо идет, если у модели на этапе обучения было много подобных примеров. Для уникальных случаев, которых в реальной жизни меньшинство, будет падать качество - вплоть до сплошных галлюцинаций.
Но есть способы с этим бороться, давая примеры, документацию. Если люди могут решить, опираясь на источники знаний, то можно это и в ИИ заложить, другое дело, что для некоторых нетиповых ситуаций это может быть слишком дорого и затратно.
Генерация кода хорошо идет, если у модели на этапе обучения было много подобных примеров.
Что-то в консерватории не то. Изобретать Вайбить очередной велосипед. После чего нейронки на них обучатся получше, велосипедов станет побольше. Есть сходимость у этого процесса и куда?
Для уникальных случаев, которых в реальной жизни меньшинство, будет падать качество - вплоть до сплошных галлюцинаций.
Если случай неуникальный, то зачем ещё один велосипед?
Тут вопрос скорее философско-идеологический.
Но есть способы с этим бороться, давая примеры, документацию.
А вы можете продемонстрировать эти способы? Ну, например, примитивное - расчёт кулачковых механизмов. Они плоские, САПРы ещё на перфокартах существовали. Учебников и справочников в интернете дофига.
САПР не нужен, просто нужен простой лёгкий код, расчитывающий кулачок с кинематическим замыканием, роликовым контактом и коромыслом.
Необходимо получить Gcode для вырезания кулачка по заданному графику движения ведомого звена. Силовой расчёт ладно, опустим.
Ну прям совсем делать-делать не надо, просто покажите, пожалуйста, что куда запихнуть и какой промт, на ваш взгляд нужен? Методика же у вас рабочая?
Если люди могут решить, опираясь на источники знаний, то можно это и в ИИ заложить, другое дело, что для некоторых нетиповых ситуаций это может быть слишком дорого и затратно.
Для каких - некоторых? Можете перечислить признаки?
Что-то в консерватории не то.
ИзобретатьВайбить очередной велосипед. После чего нейронки на них обучатся получше, велосипедов станет побольше. Есть сходимость у этого процесса и куда?Если случай неуникальный, то зачем ещё один велосипед?
Речь не про копипасту кода или разработку под копирку велосипеда. А речь про тип разрабатываемого ПО, большая часть ПО не является чем-то уникальным с точки зрения кода. Учетные системы, автоматизация бизнес процессов, erp, порталы, мобильные приложения и т.д. и т.п. - все в общем и целом типовое, отсюда и тако изобилие фреймворков, потому что все решают похожие задачи. И вот для такого рода "не уникальных" приложений ИИ получила хорошую базу для обучения.
А если мы заводим речь о чем-то выходящем из этого круга, то базы у ИИ намного меньше, чтобы выдавать хороший код.
А вы можете продемонстрировать эти способы? Ну, например, примитивное - расчёт кулачковых механизмов. Они плоские, САПРы ещё на перфокартах существовали. Учебников и справочников в интернете дофига.
Ну прям совсем делать-делать не надо, просто покажите, пожалуйста, что куда запихнуть и какой промт, на ваш взгляд нужен? Методика же у вас рабочая?
Я не эксперт в расчетах кулачковых механизмов - поэтому не смогу продемонстрировать применительно к этой задаче. Но в общем если брать описанный подход, то я бы на этапе проектирования (создания vision):
вместе с ИИ под задачу провел поиск документации, статей, описывающих алгоритмы вычисления, мб библиотек, решающих такие задачи или даже опенсорс проектов - с этим хорошо справляется deep research (лучший у openai, на мой взгляд)
далее тщательно проработал бы алгоритм
сформировал базу рефернсной документации, на которую бы ссылались как пример написания кода
сформировал правила conventions, в которых бы явно указывал брать примеры из этой доки
дальше план разработки и все по методике
Хорошая и полезная статья. Спасибо за детальную информацию.
В процессе прочтения возникло ощущение, что я быстрее напишу проект руками, чем договорюсь по всем указанным пунктам с нейросетью. Особенно для задачи из примера - которую если исключить настройку докера - я как будто за пару часов решал.
Очень может быть ) Особенно для этого демонстрационного примера, который выбран таким, чтобы сделать акцент на подходе, а не на коде.
Но есть разработчики, для которых, даже по этому примеру, тема создания ИИ-ассистентов новая. Есть не разработчики вовсе, которые могут создать решение, используя этот подход. Видите, даже вы нашли, кусочек про настройку докера, который бы отдали на откуп модели.
Попробуйте подход в деле на своих задачах ) Интересно будет получить обратную связь.
Подход в целом хорош, но как показывает практика, чем больше инструкций, тем менее охотно LLM им следует. Зачастую она их просто игнорирует
Вся эта чипенгузня основывается на полном непонимании любой инжинерии гуманитариями. Гуманитария очень легко поймать за хвост найдя в тексте выражения типа "один раз генерим" и "сделали и забыли". Промпты гуманитария всегда рассчитаны на одноразовое использование. А все дело в том, что гуманитарий не понимает что делает и не желает понимать, более того часто и не может этого понимать - отсюда и мечта об одноразовости. Поэтому все это баловство жёстко ограничено мвп. И со временем ничего не изменится.
Моя (пока очень небольшая) практика показывает - что строить "плоские" приложения с помощью llm можно. И можно делать это быстро и удобно и даже качественно. Нужно поддерживать очень сильную декомпозированность кода, минимальную связанность, и всё, что только можно - выносить в утилиты. Утилиты llm пишут отлично (их конечно приходится править руками, но не много). Классы работающие с простым api - тоже (имеется в виду - что разрабатываемый код опирается на api, который уже оперирует примитивами).
Когда у тебя каждая задача очень маленькая, хорошо описана, и особенно опирается на стандартные вещи (например цвета берутся из темы приложения, данные из репозитория который атомарно отдаёт их примитивами, интерфейс построен из стандартных компонентов) - то это работает круто.
Минусом всего этого - поддерживать такой уровень качества кода и описания задач - не сильно-то проще и быстрее, чем написать все самому. А ещё отпадает возможность писать сложный функциональный инструментарий (какие нибудь свои хитрые ui компоненты например - их llm не поймет тупо)
Плюсом - код декомпозирован, независим, готов к выбрасыванию - любой компонент при необходимости можно даже не исправлять, а перегенерить целиком.
Спасибо!
Звучит, как один из способов правильно использовать ИИ, с пониманием его особенностей. Не исправлять - а перегенеривать. Действительно через какое-то время с развитием ИИ, мы уже не будем вычитывать и ревьюить его сгенерированный код. Как никто уже давно не проверяет работу компиляторов.
Декомпозиция и минимальная связанность в общем является и хорошей практикой написания кода в классическом SE. ИИ, получается, подстегивает нас следовать этим практикам. Как, например, и подход TDD )
На счет сравнения производительности ручного написания и AI-кодинга, то здесь, имхо, все сугубо персонально. Зависит от мастерства разработчика, проекта, технологий. Умения и желания этого разработчика работать и осваивать AI-кодинг. Поэтому я, лично не делаю никаких утверждений и заявлений. Просто показываю, как мы используем ИИ в своей практике, являясь приверженцами этого подхода к разработке.
Одна "беда" - в коммерческой разработке я практически не видел "плоских" проектов т.к. это очень дорого из за минимального переиспользования компонентов.
Везде используется свой инструментарий который базируется на другом своем инструментарии и так в 10 слоев. А с этим llm уже не справляются.
Т.е. мы говорим о том, что большинство проектов построены довольно таки сложно, запутанно. Разбираться в них даже людям-новичкам тяжело. Многие проекты заведены в точку Ж и т.п. Источник правды, почему сделано именно так, а не по другому давно потерян. Используются самописные фреймворки и инструментарии, вместо общепринятых опенсорсных и т.п. Правильно?
Если так, то конечно и ИИ будет это также тяжело и трудно. Но такие проекты с большим тех долгом и людьми то тянутся со скрипом.
По сути как и раньше, выхода два - снижаем техдолг, рефакторим или пересоздание с чистого листа. И в том и в другом случае если мы хотим работать с ИИ надо заботиться о создании хорошей базы знаний/графа знаний, чтобы ии мог быстро находить нужный контекст.
Мы в своей практике используем AI-driven подход в больших проектах, которые создавались и развивались уже более 10 лет. Поэтому для нас это не только для мвп.
Проект, который раньше развивала целая команда из 7 спецов, уже сейчас развивается одним аналитиком с тех бэкграундом. Целиком и полностью от ТЗ до сопровода.
Проект, который раньше развивала целая команда из 7 спецов, уже сейчас развивается одним аналитиком с тех бэкграундом. Целиком и полностью от ТЗ до сопровода.
Код проекта, конечно, "под NDA", "принадлежит работодателю/заказчику", и посмотреть его нигде нельзя. Ну что же, конечно верим на слово.
Интересно, кто-нибудь из посетителей ресурса может пальцем ткнуть хотя бы в один реальный промышленный проект, разработанный и/или поддерживаемый при помощи LLM? Из имеющегося в открытом доступе пока только такое. Впечатляет, по правде говоря ))
Код проекта, конечно, "под NDA", "принадлежит работодателю/заказчику", и посмотреть его нигде нельзя. Ну что же, конечно верим на слово.
Мы планируем в сентябре провести митап, как раз на тему развития этого проекта с помощью LLM. На канале https://t.me/aidialogs будет анонс. Приходите посмотрите, вопросы сможете задать тому, кто непосредственно этот проект в одиночку вместо команды ведет.
вопросы сможете задать тому, кто непосредственно этот проект в одиночку вместо команды ведет
У меня вопрос один-единственный - код проекта можно где-нибудь посмотреть? На этот вопрос не дожидаясь "митапа" может кто-нибудь ответить? Реклама телеграм-канала очередного не интересует.
отдельные куски кода можем и показать, всю кодовую базу коммерческого проекта понятное дело никто не отдаст
но вопрос. а зачем смотреть на код? ИИ может генерить код, так как мы ее проинструктируем это делать. но важнее не то, как этот код красивее для людей, а как этот код удобнее для написания и доработки самой ллм.
всю кодовую базу коммерческого проекта понятное дело никто не отдаст
Уж куда понятнее )) Почему-то код, придуманный и написанный людьми, присутствует в несметном количестве open source проектов, и доступен всем и каждому. А выхлоп из LLM не доступен никогда, потому что "коммерческий проект", "под NDA", "принадлежит заказчику/работодателю", и т.д. Интересно, почему?
а зачем смотреть на код?
Во-первых, затем чтобы убедиться что он реально существует ))
Во вторых, чтобы удостовериться, что он соответствует базовым требованиям к промышленному коду. Тестируемость, читаемость, масштабируемость, вот это все.
Кстати, а что ваш этот "проект" собственно делает? Рандомные фотки котиков раз в день пользователю отгружает? Из Google Maps адреса заведений где тыквенный латте подают тянет? Намекните хотя бы ))
Пока кто-то соперничает с ИИ, пытаясь доказать что ИИ глуп. Другие применяют ИИ, таким какой он есть на данный момент. Учатся с ним правильно работать. Применяют его там, где он поднимает именно их эффективность. А где они лучше - не применяют. Ибо зачем.
Пока кто-то соперничает с ИИ, пытаясь доказать что ИИ глуп
"Кто-то не участвует в хайпе LLM" и "кто-то соперничает с LLM" (ИИ там близко не было, нет и не будет) - это принципиально разные вещи. Смешивать их - это попытка манипуляции, очевидная и бесхитростная впрочем.
Способность человека разрабытывать, развивать и поддерживать крупные ИТ-сервисы, приложения, библиотеки и фреймворки, в том числе и с открытым исходным кодом, доказана бессчетным количеством примеров и в дополнительных обоснованиях не нуждается.
Способность LLM ускорить разработку ПО и/или повысить ее качество существует только в рекламе поставщиков LLM и инструментов на их основе, ни одной строчки кода уровнем выше Hello World, To-Do List и т.п. пока никто не предъявил. Зато обратные примеры есть, и в изобилии.
Да, в теории уже существуют мегатонны кода, написанного при участии LLM. Но все эти мегатонны "под NDA", "принадлежат заказчику/работодателю", "код коммерческого проекта никто не покажет", и т.д. Вот такой замечательный инструмент, только убедиться в его замечательности все время "NDA" мешает. Остается только верить.
Ну верим, чо. Верим же?
Пусть не ИИ, а LLM - ок.
Статья не про веру и попытку обратить в веру кого-то ) А про то где LLM приносит пользу и каким образом.
Тем кто пользуется не надо "слепо" верить или ждать доказательств от кого-то. Потому что они попробовали, научились, пользуются и повышают свои и проектную эффективность.
они попробовали, научились, пользуются и повышают свои и проектную эффективность
На сегодняшний день есть только голословные заявления тех кто якобы попробовали, научились, пользуются и повышают свои и проектную эффективность
И ни одной строчки кода уровнем выше Hello World в подтверждение этих заявлений. Потому что все под NDA
Кстати, а что ваш этот "проект" собственно делает? Рандомные фотки котиков раз в день пользователю отгружает? Из Google Maps адреса заведений где тыквенный латте подают тянет? Намекните хотя бы ))
Когда будет анонс выступления по этой теме я вышлю сюда вам ссылку. Посмотрите в записи или онлайн приходите. Всегда интересно с оппонентами подхода пообщаться. Если, конечно, вы будете сохранять уважение к мнению других специалистов.
Проект решает задачу автоматизации бизнес процессов работы организации и оказания услуг клиентам. Это большая крупная система.
Если, конечно, вы будете сохранять уважение
Уважения заслуживают разработчики Prometheus, Grafana, Yugabyte, и несметного числа других проектов, используемых множеством сервисов и приложений во всех практически областях человеческой жизни.
Уважения заслуживают десятки миллионов безымянных безвестных разработчиков / девопсов / админов, днями и ночами работающих для того, чтобы остальные люди могли купить билет на самолет или поезд, забронировать гостиницу, позвонить или написать сообщение родным и близким, купить какую-нибудь нужную или на самом деле ненужную вещь, записаться к врачу, посмотреть фотки или видео, прочитать рецепт чего-то вкусного и/или полезного, поделиться отзывом про все на свете, проверить свои знания, найти информацию о чем угодно, и так далее.
Продавцы счастья по формуле "LLM и стажер заменили N разработчиков", не показавшие при этом ни единой строчки кода, никакого уважения не заслуживают. Среди разработчиков ПО, во всяком случае.
Talk is cheap, show me your code
Продавцы счастья по формуле "LLM и стажер заменили N разработчиков"
Где Вы увидели такое заявление - мне не понятно. Наоборот речь не про замену, а про сильный инструмент в умелых руках разработчиков. Пользоваться им или нет дело каждого.
А где-то можно взять ваши правила для python для AI? Понравились, но тут у вас все скринами :)
Вот про "всегда согласовывай план прежде чем писать код" - это да, прям основное. Подход скорее файлами интересный. Я обычно просто сходу пишу "without writing the code, ...", и только раз на 4-5 пишу "ок, теперь модно кодить"
Я обычно просто сходу пишу "without writing the code, ...", и только раз на 4-5 пишу "ок, теперь модно кодить"
Все правильно. Главная суть та же - вначале думаем, потом делаем) Просто с ростом задачи, результаты размышлений становится очень полезно фиксировать в документации )
Согласен, в целом. Но интересно было бы увидеть как вы бы в рамках описанного подхода предложили фиксировать изменение логики. Ну, по сути как и в обычной жизни - вчера лодку строили, сегодня лепим на неё крылья, завтра - ракетный двигатель. Мега-длинный файл с апдейтами? Какая-то интеграция с vcs и добавление истории с диффами в контекст? Потому что один конечный файл подходит только для one-shot проектов
Логичный и правильный запрос.
Отвечаю, как это делаем мы: храним описание контекста проекта актуальным (документ vision.md + доп файлы при развитии проекта). Когда приходит новая задача:
составляем спецификацию под эту задачу в новом файле, по аналогии с тем, как мы создавали vision. просим llm указать в этой спецификации как она расширяем функционал, какие требуются внести изменения, в какие файлы, в каике модели данных и т.п.
дальше просим проверить, трбуется ли обновить соглашения
создаем под эту задачу свой тасклист
реализуем тасклист
в процессе или в конце вносим обновления в vision.md, чтобы у нас сохранился единый источник правды о проекте
В этом случае может возникнуть противоречие между разными изменениями внутри контекста либо слишком обширное изменение логики. Плюс надо обрабатывать миграции, которые могут быть ппц тяжёлыми. Как делаете в таких случаях?
И кстати, как тестируете? По опыту ai очень хреново умеет selenium/playwright/прочие e2e. Мы пока думали на cucumber+gherkin подвесить, там хотя бы текст
между разными изменениями внутри контекста
Вы имеете ввиду, если одновременно ведется развитие проекта, затрагивающего общие части?
И кстати, как тестируете? По опыту ai очень хреново умеет selenium/playwright/прочие e2e. Мы пока думали на cucumber+gherkin подвесить, там хотя бы текст
Пока используем подход написания unit тестов и e2e интеграционных тестов. Ограничиваем кол-во тестов, буквально пару e2e. По поводу "хреново умеет" - зависит от модели и наличия примеров (можно использоваться Docs или MCP, например, context7)
Вы имеете ввиду, если одновременно ведется развитие проекта, затрагивающего общие части?
Да, плюс новые решения могут идти вразрез со старыми. Я знаю что это скорее к ПМу, а не к разработке, но по итогу голова болит именно у разрабов.
Ограничиваем кол-во тестов, буквально пару e2e.
Для монолита пойдет, но для микросервисов - не очень.
Для монолита пойдет, но для микросервисов - не очень.
Согласен. Будем набираться опыта, будем делиться им. Пока не на всех этапах и масштабах накоплены бест практики
Небольшой апдейт: попробовал данный подход на новом пет-прожекте. Спасибо, мил человек, правда офигенный метод.
В случае этого проекта я правда его немного доработал. Суть - надо заимплементить один открытый протокол. Не суть какой, но большой. Гигантский. Десятки тысяч страниц в сотне пдф и дополнений к ним. Соответственно в чем доработка:
руками собрал нужные стандарты и перегнал в маркдаун через docling
на основании маркдауна нейросетка сделала выжимки в md/yaml необходимые для собственно работы (весь pdf даже в мд в контекст не лезет)
перед каждым шагом проверяем хватает ли данных в контексте
если не хватает - идём в родительский md и досыпаем что надо
Пока идёт хорошо, хоть и не мгновенно. На подготовку контекста ушёл в сумме день с возней с пдф. Ещё дня 4 до чего-то отдалённо похожего на прототип. Небыстро. Но сам бы я год копался
Спасибо за статью! Что скажете про Windsurf, сильно уступает Курсору?
Это все конечно очень интересно и перспективно, НО я незнаю или непонимаю как вайб-кодить если он в трех микро (50-100 строк) .py проектах путается и перестает понимать что вообще происходит. Да, написать полотно/монолит для микро-задачи это вполне реально, но если мы говорим про фул-стек или микросервисную разработку какого либо более-менее серьезного продукта chat-gpt уже не вывозит в контекст (остальными платными версиями нейросетей не пользовался пока). Спасибо за промтологию, обязательно попробую внедрить, мб что и получится)
Я, как и многие, пытался запилить собственную системы автоматического контроля проекта, чтобы АИ было максимально эффективно кодить с минимум галлюцинаций, с использованием memory-bank. В предлагаемом подходе есть много полезного, что можно почерпнуть в дополнение к распространённым системам memory-bank начиная от идеи и видения чтобы любой АИ-агент на любой LLM всегда лучше понимал конечную цель, следовал плану выполнения. Cursor уступает Kiro или Qoder по планирование, но план можно сделать в Kiro или Qoder и вставить в соответствующий файл плана Cursor.
Спасибо! Все так.
Cursor уступает Kiro или Qoder по планирование
Уступает, так как в нем это не встроено в процесс работы из коробки, как это сделано в Kiro и Qoder. Но на самом деле весь план генерит языковая модель, и никто не мешает в Cursor генерить план самим ) Хотя Kiro и Qoder это шаг вперед к упорядочеванию процесса.
Может быть, кому-то пригодится мой личный сборник правил вайбкодинга: https://docs.google.com/document/d/1dYx1u_L6cSrWaunybjmSLldPusS145Oaz0iOby-UJ9Y/edit?usp=sharing
Моя экспериментальная система контроля проекта на Github: https://github.com/LebedevIV/ProjectGraphAgent
Хорошая статья. Я бы еще архитектурные диаграммы добавил. Очень LLM их любит и постоянно сверяется. (может и было упомянуто, но я проглядел)
Спасибо большое Автор!
Ещё раз несколько раз перечитаю и попробую приметить на практике. С Cursor, как не особо программист, пытаюсь подружился уже третий месяц, путем проб и ошибок. И тут ваша статья со стройным подходом, которая собрала мои ошмётки мыслей, догадок и ошибок в единое целое. Ещё раз спасибо!
Умный вайб-кодинг или семь раз отмерь, один раз сгенерь