Вайбкодинг всерьёз: деньги на токены и очень неоднозначные ощущения

Мой код работает. Он собирается, проходит тесты и делает ровно то, что задумывалось. Проблема в другом: я не могу с уверенностью сказать, что именно внутри него происходит, и это напрямую угрожало добавлением новых фишек.

Первую версию проекта мы с другом писали почти руками, зато каждый коммит был понятен до последней строки. Потом я остался один, подключил AI‑агентов, и темп вырос настолько, что моё понимание перестало успевать за строчками. Итог четырёх месяцев такой гонки: деньги на токены, сожжённые все бесплатные лимиты, какие вообще можно было найти, и ядро проекта, переписанное несколько раз. О том, как я докатился до такой жизни и почему больше не хочу так работать.

О чем эта статья?

Данный материал — это мой субъективный опыт работы с современными AI‑агентами от лица молодого специалиста (студента) без какого‑то огромного экспириенса.

Я не причисляю себя ни к одному из лагерей радикалистов, связанных с современными LLM; в выводе тут не будет ни «вайбкодинг — это зло», ни «вайбкодинг — это манна небесная», я просто решил попробовать собрать что‑то серьезное, используя современные инструменты, и увяз в этом на длительное время.

Мне захотелось оформить весь накопленный опыт, говоря конкретно о вайбкодинге, и совсем немного о самом проекте, над которым работал; кроме того я раскрою тему современных инструментов, которые я применял, а также способы организации проекта. Постараюсь ответить на вопрос: «Как справляться, когда агент пишет 1к+ строк каждые 30 минут на протяжении недель, и оно вроде работает?»

Что вообще такое вайбкодинг?

Здесь мое определение, которое кажется мне верным, исходя из моего опыта:

Вайбкодинг — это написание кода с помощью LLM, при этом сам код не проверяется, либо проверяется очень бегло и редко.

Из этого определения, если вы просто генерировали код в браузере а потом его переносили туда‑сюда, то это не вайбкодинг. (но здесь введу ремарочку, что проект просто большой — весь он в чат с ИИ не помещается, и при такой генерации, кода человек все равно выполняет много умственной работы и рано или поздно понимание кода доходит в процессе разработки)

Это важно потому, что полноценные агентские среды крайне много делают за разработчика, который раньше сам знал, что и как ему закинуть в чат и как требовать ответ, и сам же его валидировал, просматривая ответ от ии. И те, кто тогда посчитал, что AI это чисто игрушка для маленьких проектов или продвинутый гугл для чего‑то немного серьезнее, не понимают мощность современных технологий вокруг написания кода именно с LLM. Это не значит что человек бесполезен, но об этом позже.

Смешная ироничная картинка про эволюцию инструментов

С чего все началось

В вузе мне с моим одногруппником (мы были в команде) прилетело задание от преподавателя: сделать умного агента для университета, который бы мог помогать на сайте, используя базу данных студентов (например узнать свое расписание просто по фио, путем запроса на естественном языке) и иметь возможность также выполнять поиск по документам (RAG). Мы быстро набросали сначала MCP, потом полноценного агента, а позже и демку старыми методами вайбкодинга (ну то есть, это скорее делалось руками). На том уровне код проекта был читаем и понятен нам двоим, а каждый коммит разбирался спокойно и внимательно.

Уже тогда мы тестили codex от OpenAI, но там в то время урезали бесплатный лимит, из‑за чего такие тесты были очень ограничены, но нам стало понятно, что такая штука слишком сокращает время. То, что мы делали путем ресерча и муками с самим кодом, эта штука делает за 10–20 минут в автономной режиме, особенно учитывая, что мы начали с создания MCP (через него и шло обращение к базе и документам).

Я лично протестировал различные агентские среды, куда его можно подключить; идея еще была в том, чтобы это все могла тянуть слабенькая тупая моделька, которую можно запустить локально (у меня Macbook air m2 на 16gb а у друга была 5060 на 16gb, так что пул допустимых моделек был небольшой, но это были и не самые глупые модельки). Вот тогда я понял, как строится вайбкодинг и что там внутри, потому что напрямую трогал фронтир проекты и наблюдал, как одна и та же моделька ведет себя по‑разному при решении задачи, в зависимости от того, где она крутится.

После того, как мы собрали тестовую демку с элементами хардкода на тестовой базе (естественно нам никто просто так не давал базу вуза), наш преподаватель благополучно слился (у него работа, бизнес, помимо университета и нас, студентов — понять его можно) и я уже лично решил довести проект до полноценного финала, и вот тут началась движуха.

Идея была проста: проект для резюме, чтобы показать какой‑то пре‑прод уровень, ну или развить идею до конца и попробовать собрать на этом SaaS или типа того. Просто нормальное резюме у меня как‑то не вырисовывалось (оно получалось похожим на портфолио вкатуна, что в текущее время очень плохо, работу так не найти). И я подумал, зачем писать большой проект руками, когда я могу использовать AI, так как я уже видел и слышал, что на вакансиях требуют владеть каким то агентом, например, Claude‑code, да и я протестировал насколько это сильные инструменты. Тогда начались поиски дешевого и сердитого варианта для такой задачи.

Дальше я уже не буду так подробно акцентировать внимание на проекте и сконцентрируюсь непосредственно на процессе его разработки и того, что я пробовал для этого.

Агентская обвязка

Первое, что стоит понимать в вайбкодинге — это в какой программе и где у вас будет крутиться моделька. С помощью этой программы LLM может читать файлы, запускать bash и пользоваться иными инструментами и MCP. Основная идея (для тех, кто еще не знает, как это работает):

ИИ может только выдавать на выходе текст → модель отдельно дообучают выдавать корректный типизированный json по инструкциям, которые приходят с системным промптом → агентская система присылает сами инструменты и их описание в своем системном промпте → модель думает и в конце ответа выдает json → программа валидирует этот вызов и либо выполняет инструмент, либо выдает ошибку → LLM запускается обвязкой еще раз с историей диалога + результат вызова инструмента.

На этой логике строятся все агенты на текущем этапе развития AI.

Написать такую программу, как вы понимаете, совсем не сложно, и одним из первых популярных в этом был OpenCode. Лично я его не тестировал, и когда начался хайп, я увидел статьи, где технологии OpenCode применялись для разработки его самого, и, как вы догадываетесь, там все было очень плохо. Из‑за этого я не хотел его использовать, потому что, как казалось, это был по атмосфере очередной ai‑slop.

Таких обвязок стало очень много; самые базовые, о которых вы скорее всего слышали, это Codex и Claude Code, от OpenAI и Anthropic соответственно, но являются ли они лучшими? Оба фактически платные, они заточены под модели преимущественно их компаний (я сталкивался таким, что в Claude‑code неродная модель работает криво).

Модель и оплата

Второе, что нужно первым понимать, это собственно: а какую модель сувать в агентский workflow? И тут все очень пессимистично, если на сайте производителей, обычно даже топовые модельки, частенько имеют, какую‑то бесплатную бета версию после регистрации, то в случае с вайбкодингом у нас все очень скудно, очень мало кто дает халявный доступ, а те кто дает такое счастье — делают это очень ограниченно. И тут есть несколько вариантов:

Что выбрал я

Попробовав много чего я, много денег и времени, потратил на связке Pi + DeepSeek V4 Flash (после подъема цен я пересел на GLM-5.3 Flash, а потом и на новый DeepSeek V4.1 ). Но откровенно говоря траты составили по админ панели провайдера — 6,000руб+, там не только младший синий кит 4 версии, но преимущественно он и его ценовой диапазон.

В день я тратил в среднем от 150 до 300 рублей на старых ценах Deepseek провайдера (+ считайте оверхед, того кто предоставлял оплату в рублях, я считал там примерно 15–20% надбавка), после 16 августа цены были подняты почти в 3 раза, в зависимости от часа, но они уже неприятные бы выходили, поэтому я ретировался на бесплатные штуки, которые каждый раз разные и тяжело кого то одного назвать, кого вам хватит на реальную работу, и дальше как будто такой халявы будет только меньше.

В критические моменты я использовал NVIDIA NIM, но по стабильности он слаб и модельки там не все работают нормально, и выбор только nemotron'ы от самой NVIDIA или step-3.7-flash (нынче удален у них), он примерно сравним с DeepSeek V4 Flash до версии 0731 (что вышла 31 июля 2026 года).

Да, я постоянно в поисках легальных акции и так далее, оплата — это одно из самых неприятных, только если вы не готовы платить за подписку 100–200$, и даже там с вас хотят все соки кошелька, как для студента, все крайне плохо и стабильности тут нет от слова совсем аналогично с дешевыми API, часто тоже просто это акция на какой то длительный период (Deepseek v4 flash, GPT-5.6 Luna, Gemini-3.7 flash, GLM-5.3 Flash и тд, это просто акции и даже на акциях лично для меня стоимость не близка к бесплатной).

При этом вся бесплатная модель не годится никуда, если вам требуется работать с чувствительными данными (корпоративный код, важный узел, ключи в.env и так далее) и придется либо заниматься локальным инференсом (что идеально для такого), либо хотя бы идти к официальным провайдерам, если данные не уж слишком важные и выбранная вами компания вряд ли будет использовать ваши данные боясь за свою репутацию (но как бы тут уже сами решайте, использовать их может кто угодно и вы не можете быть в этом уверены, только если вы не крутите свою все на собственных GPU).

Немного про выбор LLM

Бенчмарки на данный момент все более сомнительный способ выбрать модель, мало бенчмарков за которыми стоит следить (только уже названный Terminal‑bench и в том мало конкурентов особенно на последних его версиях) и они постоянно появляются новые и бесконечно обновляются.

Модель в облаке вам могут спокойно подменить, чтобы сэкономить,что неоднократно замечено за главными игроками рынка (да это бывает редко, но заметите ли вы такую подмену например на несколько промптов за ту же цену?) при этом выходит новый «малыш» и вот он опять рвет топы а в других бенчмарках — нет.

Поэтому лучше изучать даже в общих смыслах сами архитектуры LLM и как по мне даже мелких хватает для вайбкодинга сейчас за глаза даже на сложные задачи, просто потому что их целенаправленно на это тренируют и используют дистилляцию старших моделей и я бы не стыдился китайцев.

По опыту самый топ делает меньше шагов для решения задачи и меньше думает, а также чаще с первого раза пишет рабочий код и как будто смотрит наперед, но если он все равно решил задачу за умеренный срок но стоил в 10 раз дороже разве это стоит того?

Лично по мне топ модели имеют смысл вне кода, а как раз для общих сфер или их границ может такое мнение и покорежило мне проект и условный GPT6-Astra мне бы все написал с первого раза, но я его разок использовал и результат мне не понравился, поэтому я в это не верю

С крутыми моделями хорошо советоваться, искать информацию, принимать решения, разбирать текст, декомпозировать задачу, а черновое по коду выполняет уже почти все, в том числе и все вместе (план + декомпозиция + код + дебаг, но это все еще не идеально)

Лично я ориентируюсь обычно на цену и то как модель себя ведет при решение задач не отвергаю, что топы делают это лучше, но за цены в 10х этого недостаточно.

Проблема первая: недостаток внимания

И так код пишется, mvp работало, контейнеры созданы, все работает, проект должен развиваться. после появления новых идей, как придти от гнусного хардкода к самогенерирующимся инструментам из схемы базы, начинаются появляться потребности, которые требуют вмешательств в существующий код, в существующую архитектуру, сначала все понятно, добавить это потом добавить то, проблем не возникает.

Проанализировать diff легко, но дальше на подъеме, что я могу взять и легко переписать пол приложения и все будет работать, начинает проседать обычное внимание к коду: то, что ты раньше смотрел обязательно, сейчас не вызывает столько скепсиса, прошлый же раз все прокатило, и это суть первой проблемы — я перестал читать важный код.

Многие списывают это к лени и проблему я будто знал заранее, но все больше доверял игрушке, она же справляется. Но чем гуще код, тем хуже выхлоп. Я бы не сказал, что читать надо каждую строчку, что пишет машина, но забить на core часть это фатальная ошибка, которая откинула меня на несколько недель разработки.

Понял я это просто — когда важный код начал тестироваться на сложных базах, я увидел, как вся изюминка проекта рассыпается, потому что вовремя не потратил свое внимание на обсуждение и планировку важной части — генерации тулов из схемы, и отдал это на самотек (просто сказал агенту: сделай generic генерацию, вон там есть у PostgreSQL такая‑то функция для получения схемы бд, так вперед) и когда до меня дошла эта ошибка так и появилась идея этой статьи.

Когда я полез смотреть в код, как и что там происходит, я ничего не понимал, и не потому что я слабый программист, а просто писал это ИИ для ИИ и никто его не контролировал, в том числе и тесты он писал для себя. Я не хочу сказать LLM глупа, она накидала все как надо, пока я не попробовал базу покрупнее и сложнее и все развалилось как карточный домик. Честно тут нет решения это проблемы, каждый сам как инженер должен понимать, где и какие части проекта важны, в теории это можно разбирать с агентом вместе, но только общая картина всей доменной зоны проекта в голове программиста позволяет видеть, где AI делает правильные архитектурные решения а где нет.

Умственный долг — аналогия с тех. долг, только не в коде а в голове, решение, которое применил агент.

Но вайбкодинг продолжается и уже делаются иные не связанные фичи, а та фишка все еще висит в голове с тегом «надо разобраться», пока в той части программы, что‑то не сломается и простая задача «прочитать код» превращается в реальный тех долг, когда уже следует заняться сложным и муторны рефакторингом, а это все можно было избежать просто остановившись и подумать, над тем, что написал ии.

Не помню у кого я впервые услышал этот термин, но он въелся мне в память даже без объяснения что это такое, и я его наблюдал прям в работе над проектом и пытался как мог побороть.

Проблема вторая: документация

Когда проект мал хватает одного README + AGENTS.md + какой‑то точечный файл для важной логики. Как только проект разрастается наступает мрак. Основная моя ошибка, что я просил ИИ описывать сервисы, но не контролировал его, что он туда пишет, это не значит, что надо всегда руками писать такие файлы, но пускать на самотек файлы на 400+ строк это верный путь в рефакторинг всего сервиса через недельку точно, это же относится к AGENTS.md на большом проекте важно глазами проверять, что там находится, это касается всех файлов 400+ строк.

Сюда же прямой запрет на переписывание с нуля больших файлов (что любит делать ии), лучше пускай он увеличит всю точную доку до 2к строк и потом вы вместе это все разберете по кусочка, чем он будет сжимать, а иногда и откровенно убирать, важные части.

Также тут надо понимать как агент видит сами доки, привычное: положил README в сервис, описал там его и его части и потом, когда опять залезешь, что‑то менять, увидишь этот файлик и перечитаешь его — не работает с LLM.

Я могу только предполагать почему так происходит, но сам факт, человеку удобна такая документация, она проще запоминается — для ИИ это контринтуитивно. В итоге я просто стал все хранить в docs/, а в AGENTS.md прямо указал где вся документация, чем писать размытое «внутри каждого сервиса есть файл README.md с важными тех спеками» и это работает намного лучше. Предполагаю, что это связано с тем, что ИИ не видит файловое дерево как человек и отдельная директория со всеми доками, где куча ссылок ему приятнее, чем классическому разработчику.

Также ИИ подвластно поведение человека во время дебага: судорожно перебирать разные способы запуска, настроек, окружения и в какой то момент останавливаться и заниматься важным делом и на следующий день человек то помнит, что и как он вводил в терминале и почему, для ИИ в новой сессии такого нет.

Есть различные проекты, которые нацелены на контроль такого поведения, но лично все что я тестил, работает криво и выше мы уже разобрали, что доки, описанные самим ИИ для ИИ, часто ему же и вредят, а самому там тем более ничего непонятно и вызывает ужас, страх и непонимание. И я принял прямо в AGENTS.md вести такие артефакты в доках, отдельно их помечая, как ненадежные, но важные, если они были созданы недавно + ручной запуск чистки и миграции данных из ненадежных доков в надежные. А также в CI добавлено тестирование ссылок внутри доков, чтобы они были валидные.

Проблема третья: ИИ просто хочет вам помочь

Звучит немного абсурдно, но это касается тех областей в которых вы плохо разбираетесь, беря пример моего проект это был фронт. Сам фронт то мне знаком, до появления ИИ я делал простенькие сайты на HTML5 и даже подключал к ним AJAX, связывая все это с таким же простеньким беком на Django, но реально разбираться в тысячи строк HTML, CSS и JS мне не хотелось, я просто давал задачу: добавь в админку новую кнопку для вот той настройки и агент делал.

В какой то момент я перестал доверять UI проекту от слова совсем, а изменения в нем приводили к 30–40 минутным сессиям агента, где он, добавляя что‑то новое, ломал что‑то старое, и потом я заметил файл app.js на 3к строк… Я просто не хотел трогать фронт + я в нем совсем мало что понимал + я думал, что там же делать нечего, как мне казалось вакансии на фронт давно просто пустышки и любой LLM уже с нуля верстает самый сложный сайт, но ИИ + JS это смертельное комбо.

Как только вы даете ИИ задачу, в которой не понимаете от слова совсем, хотя бы просто глазками понять правильно он или неправильно мыслит — вы обречены. Это на самом деле проблема, которую описывали в самом начале становления AI, но она трансформировалась, если раньше надо было заранее продумывать промпт, чтобы агент сделал хоть что‑то рабочее, то сейчас он будет делать «рабочее» и плевать, что внутри просто мрак а не код, и проблема вскроется реально поздно, раньше это было намного заранее понятно, особенно без агентский обвязок, которые позволяют самому ИИ понять собирается его код или нет.

Также важное замечание, что лично у меня воспроизводилось на разных моделях и workflow, это стремление агента оставлять старый код, возможно, это происходит потому что ИИ обучают в том числе и на реальных продакшен данных разработки, где добавить новую фитчу не так легко и, в идеале, иметь совместимость со старой версией API кода, но когда во время разработки хочется сменить какую‑то логическую часть на новую AI, зачем‑то старается оставить прошлый код в живых, всячески создавая пристройки к прошлому коду, если такое не отловить это может сломать очень много тестов и важных контрактов над кодом и отправит проект на длительный рефакторинг.

Последнее время, агенты становятся более упорными и случается даже такое: часто бывает, когда агент чем‑то долго занят и я вижу, что он лезет в дебри, я спрашиваю его «что не так?», «чем помочь?», «что не получается?», но он просто игнорит и продолжает работать над задачей, бывает сложно его нормально стопнуть в такой момент, а делать он может, ну полную ерунду по логам.

Это следует из самого behavior (поведение) LLM и последние время оно все больше отличается от модели к модели, старые экземпляры реально максимально поддакивали пользователю, что было проблемой, текущие пытаются это совместить с тем, чем их пытались научить, а также то, как их учили вести себя при решение тех или иных задач. И это реально важный атрибут при выборе мозгов для агента.

постироничная картинка: не стоит доверять ии

Я лично поставил специальную пройслойку, которая ловит действия агента и запрещает ему, например читать.env (ссылка: https://github.com/kenryu42/cc‑safety‑net ).

Проблема четвертая: агент видит весь проект целиком

Это уже фундаментальная проблема всех современных трансформеров — они видят каждое слово, каждый токен и не могут выбросить что‑то. В классическом (плотном) attention каждый новый токен «смотрит» на все предыдущие, а весь контекст хранится в KV‑кэше. Выбросить из него лишнее модель не может, ей остаётся лишь уделять этому лишнему меньше веса.

пЧем длиннее сессия, тем больше в контексте старых логов, файлов и диффов, и тем хуже модель отделяет актуальное от шума. Поэтому качество падает на длинных сессиях (в исследованиях это называют «lost in the middle»: середина контекста используется хуже, чем начало и конец), а раздутый системный промпт портит результат ещё до начала работы. Сжатие контекста это не лечит: суммаризацию делает сама модель или обвязка, и после неё стоит проверять, не потерялось ли важное.

Возможно эту проблему решат в скором будущем, уже разрабатываются новые слои, которые станут на замену или в помощь к стандартным attention (на тех на которых сейчас держится вся эмерджентность LLM), но на данный момент — эта проблема без очевидного решения для конечного пользователя инференса.

Да, на самом деле современные LLM все‑таки показывают поведение, когда как раз они, делают вид, что в тексте важное а что нет, но самого механизма их работы это не отменяет и + это все наслаивается на то, как модель ведет себя.

Пример когда это портит разработку: у модели большой контекст (например под 150к) там много различных файлов, какие‑то документы, логи, модели прилетает новый таск, решить который, надо сначала найти нужную документацию, потом прочитать новые файлы кода, и только потом писать правки, но ей это не важно, ей кажется она и так все знает уже про проект и начинает писать архитектурно ужасный код.

Также про то, что модель симулирует внимание, это свойство особенно некоторых ИИ перечитывать те файлы, которые и так целиком уже в контексте (я понимаю что последние и первые токены важнее, чем то что в центре, но это некий абсурд к которому прибегает LLM). У каких‑то моделей все с этим лучше, у каких‑то сильно хуже, но случается это у всех, если ваш harness вам этого не показывает это не значит, что такого не происходит под капотом.

Также яркий пример: говорю модели «не используй длинное тире!», а ей без разницы уже через пару минут и, я вижу, как она его все равно, и в комментарии кода добавляет дальше, и в документацию, и мне в отчет по 5 штук на предложение. Вот вам и AGI.

Я говорю про эту проблему, скорее как пользователь, а не как разработчик современных LLM, но это непосредственно, то что я вижу во время вайбкодинга, и это достаточно странное поведение, которое портит результат.

И все это странное поведение, и следует из современных архитектур, из которых, вот вот, выжаты все соки и придет ли что‑то новое им на замену — непонятно. (ну наверное придет, но когда никто не скажет точно, кроме CEO этих AI‑стартапов, по их словам AGI уже всех заменил еще вчера)

И решения тут просто нет, так как обычный юзер не в состоянии это поправить, над этим бьются самые топовые лабы в мире AI и, конечно, чем больше и дороже LLM, которую вы используете, тем этого меньше, но даже так это не панацея на текущем этапе развития, а вот цены на фронтир класс невероятно высоки.

Проблема пятая: новые инструменты

Когда я только вот заходил в агентский вайбкодинг, я начитался новостей про тысячу крутых инструментов и дополнений (MCP), которые сделают агента умнее всего на свете и мне искренне хотелось в этом верить (как когда‑то в промпт инжиниринг), тем более сам проект, над которым я работал, был в какой‑то теме про это же, но я ошибался жестко. Модели, даже с кастомным системным промптом, плевать на ваш граф знаний, на то как спрашивать пользователя, ей безразлична общая память между сессиями и куча подобного, что обещает сделать из Deepseek → Fable 5.1 (а из Fable супер AGI). И тут я просто вывел для себя важное понятие:

Поведение модели намного лучше, чем крутой системный промпт и тысяча расширений.

Не поймите меня неправильно, иногда какие‑то дополнение реально работают, но чаще всего я про них вспоминал, а не мой агент почему‑то, и я его просил это использовать прямо по ходу решения задачи несколько раз. Это же относится к скиллам.

Личные скиллы, которые вы создаете под свою боль — реально работают, то что вы качаете с GitHub, по принципу «ну вдруг пригодится, гонку данных в GO не допустит прочитаев скилл, наверное» это вообще лажа, работает только если вы сами помните какие у вас скиллы и под что, самому агенту что‑то плевать конкретно на всю эту тему, не говоря о том, что большая часть скиллов, это то еще вайбкодерское месиво (а мы знаем, что когда ИИ пишет для ИИ, это ничем хорошим обычно не заканчивается) вот так и получается, что вы расширения для себя подкидываете, а агент крайне редко туда заглядывает, и токены эта бурмалда крутит будь здоров.

И такой мини вывод тут: максимально тщательно проверяйте, что вы там подкидываете, и ведите для себя заметки, хоть в голове, работает эта штука или нет, потому что 95%, того что вы найдете в репозитории «это лучшие скиллы от бигтех корпа, что сделают из ИИ человека» — это просто мусор и мрак, который только вредит, реально работает что‑то, только когда вы сами создаете (даже пусть и со своим агентом) скиллы под конкретную боль и задачу.

С расширениями все еще сложнее, я вот пользуюсь графом знания для агента и так получается, что только когда я агента прошу через него что‑то поискать, только тогда, да, он его использует и что‑то делает, но так и я мог его обойти и найти то же самое. При этом большая часть расширений это вайбкодерский мрак, которые страшно использовать, даже если, они работают.

Большая часть, тех кто хоть что‑то делает для вайбкодеров — зачастую сами вайбкодеры, в плохом смысле.

И как бы плохой софт всегда существовал, но тут это уже какое‑то пост‑мета‑программирование.

Проблема шестая: агент решает кейс, а не задачу

Иначе говоря:

Либо мы строим план, как писать код, либо мы пишем код.

То есть это и есть выше упомянутый «умственный долг», когда агенту летит тз, даже без примерного понимания, что реально должно быть внутри (какая логика), и задача сделать, и агент делает, плохо делает, но оно работает. При старом вайбкодинге такая штука ловилась, тем, что перед тем как вставить код, он хотя бы мельком просматривался и было сразу видно как LLM не заходит свысока на проблему, а просто решает определенный кейс, который ей был описан.

Это же часто отражается в ситуации, когда агента просишь покрыть новый код тестами, и он там использует твой же кейс, и даже, если глазками проверить только тест, кажется все отлично, но когда этот код встанет поперек проекта — вопрос времени. Поэтому передать агенту общий контекст проекта достаточно важно, а также контролировать, как он сам себя проверяет, иногда упрекая его в этом (если он делает это узконаправлено).

Сюда же можно вынести и еще одно интересное поведение ИИ в такой ситуации: он либо оверинженерит, либо хардкодит в одном файле. Да чем умнее становится AI, тем такого меньше, но это никуда не делось, особенно в формате решения проблем в кодовой базе, а не во время генерации новой (в чем ИИ реально силен).

Проблема, откровенно говоря, комплексная, и вот тут реальная разница насколько вы опытный как разработчик, как инженер, и взгляните ли вы на этот код от ии. В какой‑то мере, это все возвращается к первой, обозначенной мной проблемы — нехватка внимания к кодовой базе, но увы это просто база которая забывается.

Также я бы отметил такую штуку как субагенты. В общем своем это очень неплохая фишка и я видел, как можно интересно выстроить процессы с ними, но все еще оно не является панацеей и, многие модельки крайне криво работают с ними, а также контроль еще и за субагентами просто пропадает в край.

Но иногда от них есть толк потому что, LLM реально может забыть план, который лежит же у нее в контексте — субагенты в каком‑то смысле решают эту проблему. Но для решения задач внутри существующей кодовой базе это подходит слабо, а вот для ресерча, или поиска, или аудита это достаточно сильный инструмент, который еще и токены может сохранить.

Проблема седьмая: ветвистый код

Узконаправленная, но острая проблема кода со сложной ветвистой логикой — в первую очередь асинхронного. У модели нет реального исполнения: какая таска жива, что отменено, какой лок удержан, этого нет в тексте файла, это существует только в рантайме, поэтому ИИ рассуждает о поведения, а не мыслит логически и находит тем самым проблемы и баги. В полной мере это проявляется на файлах/классах 1000+ строк, где агент начинает бесконечно находить баги сам за собой в рамках одной задачи «проведи аудит», и зацикливается, потому что нет нормального критерия готовности.

Если дать в новом контексте LLM такой файл и попросить проверить, то она всегда найдёт «критические» проблемы, здесь важна оговорка: без фильтра она завышает серьёзность и выдаёт за критическое и реальный спин на 100% CPU, и теоретический краевой случай. Отличить одно от другого можно только своей головой или реальными тестами на коде.

Контрмеры: контролировать архитектуру и технологии (ИИ любит изворачиваться со старой синхронной либой, когда давно есть нативное решение) и декомпозировать файлы, чтобы ветвистость не копилась в одном месте. Но это не панацея: часть конкурентных багов (семантика отмены, гонки при переподключении, зависшие таски) не воспроизводится в простых юнит‑тестах и стандартном E2E и всплывает только под реальной нагрузкой.

Поэтому против них работают не обычные тесты, а прицельные конкурентные и хаос‑тесты плюс профилирование, а если их нет, такие баги выживают и ловятся уже мониторингом и алертами. Ну и свои мозги тут бывают очень как нужны иногда они буквально экономят время, лучше 30 минут вникнуть в ключевой класс, чем 4 часа ждать «полного» фикса от агента.

К чему я пришел?

Некоторые решения я уже обозначил или намекнул на них здесь я просто перечислю все и добавлю больше комментариев от себя.

Как выделять внимание

Коротко: никак. Это по сути — то зачем вообще все еще нужен человек в этом и что и является важно частью создания любого решения с AI. Из банального что уже многие слышали:

• Не делать проект с теми технологиями, в которых не понимаешь даже базы (я так обжегся на фронте, и пришлось быстро брать под контроль архитектуру кода и контролировать, что пишет агент уже на TypeScript а не JS, который я прямо запретил)

• Не доверять ИИ бизнес логику (конкретно я, взял и отдал важную часть проекта, про генерации тулов из SQL‑базы, простой командой, что потом разгребал уже глазами и в три‑четыре агента сверху, переписывая, что есть, 3 раза точно, и даже так реальные баги вычищались уже по бенчмарку и e2e тестированию) главное тут правило — сначала полное понимание и.md план, проверенный своими глазами, потом уже команда агенту делать.

• Следить что делает агент, какие команды вызывает (особенно все что связано с git он мне так как‑то затер все правки и какой‑то магией спустя 40 минут восстановил их из закэшированных блобов и от этого никто не застрахован на такие случае только кастомные скиллы и инструкция под свой кейс и свою модель), какие файлы он читает (иногда он не читает, то что следовало по задаче, об этом прямо ему надо говорить, до сих пор) Это самое незначительное правило, но как минимум оно позволяет понять некоторые проблемы проекта просто наблюдая без какой либо работы над кодом и умственных задачек.

Это все банальщина, но на сложном проекте без этого никуда.

Из чего‑то новенького: я вернулся к старому вайбкодингу с LLM в чате браузера, и для меня это как раз способ контролировать мое внимание, но тут важно, с какой моделью вы общаетесь, лично мне заходит только фронтир и модельки от Anthropic. Идея в том что в чате вы ограниченно даете контекст и сами его выбираете для поиска решения, тем самым разбираюсь в проекте, а также браузерные решения часто бесплатные и имеют поисковый движок в комплекте, это буквально делает лучше самому разработчику, а не только ИИ агенту, хотя, отчеты от одного и второго, я туда сюда гоняю, как раз так проще разобраться, что за проблема и кто не в те дебри лезет. Как по мне — это реальный хак, если вы и свою голову в этом процессе включаете, а не просто выступаете прокладкой между двумя LLM.

Используй чатик в браузере, чтобы ИИ стал наставником (помог с выбором технологий или проконсультировал с текущем стеком), или чтобы он наоборот провел дотошный анализ (контекст я сам ему объясняю и скидываю) и помог проконтролировать уже агента в терминале — это самые частые сценарии, как я это использую.

И да, способа решать умственный долг толком нет. Мне помог возврат к старому вайбкодингу — так я проник головой в проект и поправил некоторые архитектурные дефекты, но совершенно не факт что это решение подойдет вам, термин этот помогал мне обращать внимание, когда я такое пропускаю, и заставлял в голове запоминать некоторые таски, как то что надо разобрать такой долг, а только потом пушить коммиты.

Связность проекта

Это первое что страдает: когда агент сам пишет в AGENTS.md, он сам ведет доки и сам за собой проверяет и пишет тексты, то получается картина, когда ИИ пишет для ИИ — что тратит читаемость проекта. Из банального если проект небольшой вы просто тратите больше токенов, раздутый начальный промпт, кривые инструкции, которые пробует агент и потом тянет ошибки в контексте дальше, но и контролировать каждый.md файл почти нереально особенно если эти файлы реально нужны только вашему агенту, или агентам коллег.

Первое решение, что приходит на ум, это брать AGENTS.md (и подобные ему файлы, например в pi есть еще один APPEND_SYSTEM.md, который по названию встраивается между системным промптом и AGENTS.md) на ручной контроль, но это не глобальное решение и со временем также стагнирует, намного логичней начать организовывать сами док файлы. В итоге я выстроил в своем проекте систем, похожу на то что делает OpenSpec (да, в теории вы можете просто взять его и это будет решения, но мне стало лень его тащить в проект, ведь я уже сделал организацию которая работает) если быть точнее, то я выделил отдельную директорию под.md файлы — doc/ (можно назвать и docs/ или как то еще, разницы для ИИ особо нет, главное чтобы она была отделена от кода) и организовал правила какие доки и куда попадают и по каким причинам.

1. Основные доки, их я оставил в сервисах (просто чтобы не тащить, если честно лучше правда оставить в doc/ и так далее)

2. Доки с поверхностными знаниями (чтобы агент мог быстро найти информацию не забивая контекст, при этом внутри всегда ссылка на больший документ)

3. Архив, сюда агент может писать что угодно, но обязан указать дату и актуальность (также их надо периодически чистить и я это делаю с агентом)

На самом деле в своем проекте я еще выделил отдельную поддиректорию под бенчмарк, но это специфика проекта, а не общее правило, там же есть свой архив с анализами прогона на тот или иной момент, чтобы не путать это с архивом.

AGENTS.md стал описывать только:

1. Общую цель проекта (Saas, b2b и другие общие вещи, чтобы понимать, что он делает, и над чем работает в общем)

2. Ключевые глобальные части (конкретно в моем проекте это микросервисы)

3. Базовое движение данных в проекте

4. Описание контрактов между частями проекта

5. Примеры как читать доки, при решение той или иной задачи

6. Тесты и CI (как запускать, как проверять)

7. Как формируется документация проекта, и также как она и устроена

8. Ссылки на сами доки

Также в пункте про устройство документации есть пометки про то, как структурировать те или иные доки, а также в конце дата верификации этой доки и последний коммит, когда верифицировали доку.

Также в CI добавлено тестирование путей на доки, чтобы они не были битыми, что также отмечено для AGENTS.md.

Только подобным образом мне удалось заставить агента читать доки а не рыскать по коду без моих упреков или прямых ссылок это делать, а также позволило быстро верифицировать с ним эти доки и разгребать устаревшие строчки внутри. Придуманная система все еще не идеальная, и я раздумываю о большем дроблении первого промпта, но то что сейчас есть оно работает и требует минимум внимания.

CI и Pre‑commit наше все

Ну тут для тех кто в курсе автоматического тестирования и автоформатирования кода — ничего нового, но с ИИ агентами это выходит на новый уровень важности, даже в соло разработке, если вы используете самый самый лучший агент, то без этого просто никуда.

Эти несложные решения бьют по руками агенту, когда он пишет кривой и нерабочий код, и самое важное — делает это не в момент написания, иначе он зациклется на своих ошибках, а не над общей целью, над которой работал только что, а как раз перед коммитом. Раньше это нужно было только командам, в которых портить кодовую базу мог малоопытный человек — кем собственно AI до сих пор и является.

По сути раньше эти штуки добавлялись уже через какое то время развития проекта, либо если сразу намечался серьезный проект с нуля, сейчас даже, если только вы собираетесь пользоваться этим софтом, я бы задумался, хотя бы об e2e и unit тестах, которые вы бы проконтролировали даже поверхностно на уровне чтения файлов.

В принципе контроль за тестированием это, то к чему придется привыкнуть и смотреть на реальность разработки софта через призму тестировщика, нежели кодера, который высматривает архитектуру кода, планирует файловую иерархию и всячески ломает голову, как назвать переменную, и чинит типы, без этого, в какой то мере, все равно никуда, но встречается намного реже чем при ручном кодировании и тратит очень много внимания и времени при разработке.

Тут же я бы взял на контроль как ИИ находит баги, а если точнее, то смотреть, чтобы он сначала писал падающий тест, а потом уже лез в сами файлы и исправлял какой‑то код. Это лично меня спасало на асинхронном коде, в котором по версии разных LLM были всегда ошибки, чтобы и как там не правилось и тут правило:

Падающий тест → анализ → новый рабочий код → прохождение теста → e2e общий

База. Вполне достаточно просто наблюдать, что агент именно так и идет, не обязательно прямо проверять каждую строчку за ним, но это уже зависит от важности узла.

Техническая часть обвязки

Как я говорил выше, вам ничего не мешает зайти на Terminal‑Bench и просто выбрать по топу себе обвязку, заплатить 18–100$ за подписку и, в теории, это уже будет работать. Основные вендеры типа OpenAI, Anthropic и даже китайские компании и стартапы уже имеют инструменты со всем нужным внутри, но я заходил вначале июня и тогда назвать каждый harness было сложно и как я сказал я просто взял минимализм, который я могу настраивать как душе угодно.

Если говорить по честному конкретно мой Pi конфиг и (как я думаю) похожие штуки требуют внимания, раз в неделю‑две ну и каждая новость про новые плагины или MCP также требуют вашего внимания, как говорилось выше 95% это ai‑slop мусор. Отчасти это следствие как относятся к вайбкодерам сейчас и то что всякие «супер расширения» создают они же и внутри это мрак, который еле работает, иногда вполне себе может потребовать внимание вашего же агента, чтобы там что‑то исправить внутри (но к такому я прибегал только в некоторых MCP, которые мне были нужны как‑то в другом деле, все остальное я просто удалял и забывал как страшный сон)

Тут важно понимать, что у самой LLM внутри есть память и некоторые знакомые ей паттерны, а также ее поведение, многие скиллы и дополнительные тулы просто шлак, которые только мешают, потому что ии и так это знает или уже имеет неплохой паттерн поведения при решение таких задач, при этом если вы кинете ссылку на новую фичу для агента — он вам расскажет насколько это крутая и незаменимая ему вещь!

Лично я после добавления чего‑то новенького люблю, по итогам длинной сессии (например под 200к контекста), спросить у самого агент как ему тот или иной инструмент (если он его использовал), и так можно сформировать свое мнение, работает оно или нет, а также возможно нормально подправить системный промпт, указав рабочие инструкции использования новой штуки (если такое происходило внутри сессии). Также в новой сессии можно попросить самого агент проанализировать сколько раз тот или иной инструмент или скилл использовался (конкретно в Pi есть у него такая возможность и работает это неплохо на деле)

Решение тут такое же как и со вниманием к проекту — отсутствие очевидного решения. Только анализировать глазами, как агент с этим работает, именно поэтому я выбрал Pi, а не варианты типа Codex, как по мне они скрывают это, и когда ты платишь за токены мне не нравится, когда пользовался всякими акциями, где harness обязательное условие акции, то честно разницы немного, потому что по факту агенту достаточно минимального набора инструментов и некоторые точные плагины под точные задачи (например MCP для браузера если надо править верстку). Просто уже все современные модели учатся как раз на базе в виде bash, edit, write и read.

Про субагентов: я оставил их полностью на волю самого агента закрепив, только некоторые кейсы типа исследования репозитория и мелкие задачки, что реально лучше делать через субагентов, остальное вполне делается без них, не говоря о том что современные LLM уже сами дергают субагентов без каких‑то прямых команд и знают где этот инструмент неплох. У меня был период мании на этих субагентов но честно это ну такое, в теории если руководит ими супер огромная моделька может работать но так я бы не стал таким пользоваться внутри кодовой базы, хотя допускаю что это супер эффективно для создания всего с нуля.

В каком состоянии проект

Последний месяц я вообще не добавлял новые фичи в проект, один раз переписал саму логику harness внутри проекта (да, у меня сам проект строится вокруг LLM, кто забыл), также, постоянно идет фикс багов там и тут. Не говоря о том, что когда я правлю корневой README.md я так или иначе застреваю в багах, некоторых баги повторяются в разных этапах проекта, что с вайбкодингом стала нормой (и да это бесит и тратит токены, иногда дизморалит, что баг повторился, хотя тебе казалось, что вы с агентом закрыли его регрессионным тестом)

В общем оно работает, при масштабе 100к± строк (считала утилита scc), это явно крупный проект для вайбкодинга просто в браузере. Много ли строк в проекте бесполезные? я ставлю на 20%, как неочевидный мертвый код (потому что весь очевидный вычищали линтеры и иногда агент, по прямой просьбе, а также граф знаний, который в этом помогал агенту).

Честно я думаю я бы не смогу полностью руками написать такого же масштаба систему за такой срок, при этом если бы это писалось руками размер при таком же функционале ну точно был бы меньше, не говоря что там половина или больше это тесты, без которых на соло проекте вполне можно жить в отличие от работы с агентом, где качественное автоматизированное тестирование это залог успеха рабочего кода не просто на словах.

Но да, создается впечатление, что я не в состоянии полностью отвечать за проект, это немного странное чувство, больше похожее на, то как будто я списал код и слабо понимаю как он работает под капотом (это не значит что я вообще не знаю). Может даже похоже чувство, когда проект писался в том году и мне сказали, вспомни что там было, а я уже давно не использую, ни тот стек, ни те привычки написания кода. Хотя проект буквально пишется в ту же секунду, что и эти строчки.

Не говоря уже о том, что если я дам агенту задачу «найди проблемы и баги в этом проекте», я уверен, что он что‑то да найдет и будет ли это корректно, я не факт, что смогу дать точный ответ ему, и как минимум сложный вопрос может заставить меня полезть в код проекта напрямую посмотреть, что он там править собрался. Иногда моя лень не посмотреть баг, что нашел агент, не раз ломала проект и основную его логику.

Я лично считаю, что вот сейчас (в момент написания) проект готов на 90%, его вполне можно показать, про него вполне можно говорить, про те или иные архитектурные решения, как балансировать нагрузку, куда добавить кеш, где вставить брокер, как обернуть в кубер, и заниматься уже децентрализованной архитектурой, потому что каркас в виде независимых микросервисов готов, остается вот 10% где я правлю баги + выстраиваю защиту, хотя бы минимальную (конечно тоже с агентом, потом что в своей жизни ни разу еще проект не доводил до такого состояния) у меня есть именно инженерные идеи, как с агентом над этим работать.

Вывод

AI добавляет еще один слой абстракции, как это делали операционные системы, компиляторы, библиотеки, фреймворки, и да это совершенно иной слой абстракции не напоминающий предыдущие, как это всегда бывает, и он также имеет свои минусы, в сравнении написанием кода руками, так и очевидные плюсы, но все еще ИИ создает больше работы, чем полностью ее забирает, сам подход к разработки меняется.

Картинка про современных разработчиков

Для каких‑то сфер ИИ до сих пор не заменил обычного кодера. В некоторых популярных областях, уже с начала 2026, многие признаются, что не написали ни строчки (по данным того, что я вижу в интернете), мой личный опыт просто пересказ того, с чем столкнулся я, используя этот инструмент, и он не претендует на истину а нацелен просто найти единомышленников и составить отчет о текущем развитии таких инструментов и на что они способны.

Но это сказки если бы эта штука работала без ошибок реальный косяк это:

Самая главная проблема ИИ — выросшая нагрузка на разработчика.

Если вы не типичный вайбкодер с ютуба и код все‑таки читаете, то эта штука вызывает сильно больше когнитивной нагрузке, в основном из‑за того, что не знаешь, где и как оно сделает ошибку, при этом человеко‑часы могут быть, как кажется, потрачены впустую, потому что код написанный ИИ оказался правильный и корректный, не говоря о случаях, когда он буквально пишет лучше, чем мог сделать сам (да крайне редко, но и такое бывает) при этом остается такое:

Код, который был просто сгенерирован, не воспринимается собственным.

И как по мне это убивает хобби‑разработку, ты просто перестаешь получать удовольствие, когда решил задачу или написал 500 строк за день, тогда как раньше это одно из немногих, что создавало почву под ногами и позволяло тратить много времени на проект.

По тезисам выше, честно признаюсь у меня были мысли бросить проект и не раз. Они как раз появлялись, когда приходилось переписывать основную логику — агент это делал долго, с проблемами, с ошибками, не с первого раза, а я чувствовал себя беспомощно, это угнетало, и думалось бросить весь этот нейрослоп или хотя бы начать сначала, уже понимая как будет выстраиваться проект (ну банально заранее прописать ключевую логику, хотя бы в файле‑документе и заранее настроить автоматическое тестирование, а также обращать на него больше внимания).

Но в итоге я разруливал такие случаи, помогло только терпение и какой‑то минимальный опыт построения кодовой архитектуры. В такие моменты я начинал описывать агенту, как я вижу устройство абстракций, файлов, какие ключевые требования мне нужны, при выполнении которых, агент бы создал нормальный код, который можно расширять и тестировать без прошлых проблем. И сам этот же инструмент, который наплодил этот мрак, помогал мне все это разруливать (иронично).

Код который пишет агент, потом который переделывает агент, и не дай бог человек почти не читает git diff и не проверяет, что в доки добавляются новые важные строки — это мрак и оно гниет с невероятной скоростью, у меня, возможно, получилось исправить это, но качество как это получилось судите по исходникам, я не претендую на идеальный способ, понятное дело руками получилось бы лучше, но и заняло бы столько времени, что с нуля быстрее бы было все пересоздать даже теми же руками.

В моем случае «плохим поведением» я недели две‑три конкретно адски вайбкодил не читая код (и вот попал в классическую ловушку, где кажется ИИ и так неплохо делает зачем его лишний раз проверять), представить, что на такие грабли наступает вся команда в течение там двух‑трех месяцев, это реально ужасно и может сильно ударить по скорости разработки, а то и по финансовой составляющей этой «команды», но это мои догадки по собственному опыту (хотя истории про, то как агент уронил какому‑то стартапу базу данных, я думаю вы наслышаны).

Из хорошо отметить: теперь я могу писать некоторый несложный код, например разгребать типичные проблемы, которые скорее рутина, не напрягаясь и все равно получать удовольствие от сделанной работы, но это относиться только к рутинными проблемам, которые улучшают вид общий и, что раньше делалось долго и по очереди, а сейчас можно самим расписать список и агент это разгребет быстро, и может даже, в несколько субагентов.

Также современные агенты полная имба для переписывания чего‑то на что‑то новое или на другой стандарт, например синхронный код в асинхронный (да конкретно в этом примере без ручного контроля никуда, но условно с JS на TS вполне нормально работает), как вспоминаю руками это занимается несколько дней и ты все равно не будешь уверен, что все в точности как было и будет работать, тогда как агенту можно задать контур e2e тестирования, который будет его пинать, что где‑то что‑то не работает (да тесты он напишет тоже сам достаточно быстро, а руками они проверяются только один раз на старой кодовой базе). Это пожалуй реальные плюсы ИИ в кодинге где заменить их почти нереально и стоимость сильно дешевле любых человеко‑часов.

Конкретно по тратам на проект вышло достаточно скромно, просто потому что я частенько выжимал все соки из бесплатных или лимитированных акций разных компаний и стартапов, а также использовал только самые дешевые модели за их интеллект (это могло в моменте губить проект я не спорю, но как по мне это не настолько ужасно, как технические ошибки, когда код не читается, а архитектура этого кода остается на волю самого агента, что плодит спагеттикод и хардкод намного и намного быстрее, чем модель задешево от китайцев или дорогая от западных компаний)

Помог ли мне агент или наплодил больше проблем?

На самом деле я не обладаю такими компетенциями, чтобы точно понять сколько бы мне потребовалось времени для создания такого же масштаба проекта и нужен ли такому проекту такой масштаб, что позволили создать современные технологии, точно могу сказать — будь на моем месте далекий от кода человек (по сути целевая аудитория проекта) у него бы не получилось построить, то что получилось у меня.

Будь на моем месте более опытный — я не знаю, сейчас понимаю некоторые новые проблемы конкретно проекта, а не только вайбкодинга, что применял, но это как раз тот же опыт, что и нарабатывался и до появления современных LLM и агентов, и которым обладает не студент типа меня, а реальный разработчик, проварившийся несколько лет в реальных проектах.

По тому, что я создавал ранее, точно могу сказать масштабы были бы не те, и я бы точно большую часть времени просто пытался одну технологию подключить к другой и тесты бы не писал и не тратил на их время (наверное), но создал бы я то же самое за то же время или меньше? не думаю, хотя может и этот проект по фактам мусор (мне сложно оценить это не создав это все еще раз с нуля), на данный момент могу констатировать только факт:

ИИ наконец‑то стал делать меньше проблем чем пользы, но не избавился от первого в корне.

Но требования к разработчику начального уровня сильно выросли из‑за ИИ, сама ниша терпит изменения каждый год, за время создания этого проекта я толком не приобрел новых точных знаний, я не фиксил проблемы асинхронного кода, я не копался в доках библиотек, которые использовал, я не конструировал большую часть кодовой архитектуры (хотя некоторые моменты брались под мое руководство, потому что ИИ не справлялся, но я не считаю те решения какими‑то суперумными и требующие много опыта или типа того), как по мне базовые знания все еще актуальны и бустят непосредственно разработку как по скорости, так и по качеству, собственно что и раньше было.

За это время я не стал себя чувствовать тупее (как многие любят говорить после 2 часов вайбкодинга), я просто стал мыслить в других координатах, но и говорить что «я стал намного умнее» тоже не хочется — это немного другой кластер работы скорее, это больше похоже на то если бы я был просто тех менеджером, который оркестрирует работу маленькой команды и головой отвечает за каждую их строчку, это дало новые знания, но они не похожи на типичные навыки, которые получаются при написании проекта руками и не станут ли эти знания бесполезными через уже полгода сложно сказать.

Также не стоит списывать всех вайбкодеров в одну кучу, плохие разработчики и плохие проекты были и будут всегда, какие бы новые технологии не придумали и не давали бы начинающим — они всегда будут делать плохие проекты и так не только в сфере IT, просто кто‑то продолжает учиться а кто‑то стоит на месте и кричит всем что его уровня достаточно, хотя это очевидно не так.

AI поднял планку требования от разработчика, конкретно от самой единицы, и я также думал, когда начинал проект (и вначале оно все скорее так и получалось быстро и эффективно не думая про название и тип данных у переменной) я думал, что сделаю больше, лучше, продуктивнее, еще и фронт красивый наклепаю по всем современным технологиям, но на деле обжегся, и об лень, и об незнания, и об то что с ИИ тоже надо сидеть, как с маленьким ребенком, настраивать все, при этом это не бесплатно, а роль человека стала еще стрессовее, как в итоге мне просто хочется писать код руками, а не вот это все…

Картинка на подумать

Я по‑настоящему соскучился по написанию кода руками после этого проекта.