Формат: Мнение Контекст: 2026 год, продакшн-проекты, AI-агенты как часть процесса О чём: что реально изменилось в работе разработчика, без хайпа и без хайтерства
Преамбула
Это не очередная статья "AI заменит программистов" или "AI это просто хайп". Я устал и от того, и от другого. Это попытка спокойно посмотреть, что произошло с моей работой за последний год — после того как агентские AI-инструменты стали реально применимыми, а не просто фокусом на демо.
Сразу про мой контекст, чтобы было понятно с какой позиции я пишу.
Я — соло-разработчик. У меня в проде несколько продуктов одновременно: мессенджер на React Native + Electron + FastAPI, AI-платформа с собственным backend'ом, marketing-автоматизация, и desktop-приложение для производственного предприятия на Rust + Tauri. Я не cofounder в стартапе с раундом финансирования и пятью junior'ами в команде. Я один человек, который делает несколько продуктов и зарабатывает на этом.
Использую Claude Code в агентском режиме на подписке Max. Это $200/месяц — не дёшево, но в моей экономике это меньше, чем я платил бы одному джуну за два дня работы. По моей грубой оценке, около 70% кода, который попадает в репозитории моих проектов, написано с активным участием AI. Это не значит "Claude взял мою задачу и закодил" — это значит, что я и Claude работаем как-то совместно, и финальный код — результат этой совместной работы.
Ниже — что я об этом думаю после года такого режима.
Главный тезис: моя роль изменилась, но не исчезла
Год назад моя работа состояла из двух больших частей: придумать как сделать и сделать. Сейчас осталась почти только первая часть.
Это не значит что я не пишу код руками. Пишу — но другой. То, что раньше занимало часы (написать CRUD-эндпоинт, сверстать форму, реализовать стандартный паттерн) — сейчас занимает минуты. Не потому что я стал быстрее печатать, а потому что для этих задач я не печатаю код. Я формулирую что мне нужно, проверяю результат, корректирую.
То, что не ушло — это все архитектурные решения. Почему именно три уровня кэша, а не два. Какие индексы в SQLite положить и почему именно по этим колонкам. Когда стоит делать собственную реализацию протокола, а когда взять готовую библиотеку. Это решения, которые AI не принимает за меня — он может предложить варианты, но выбираю я.
И это, на мой взгляд, правильное распределение труда. Скучную, повторяющуюся, шаблонную часть работы делает машина. Содержательную, контекстно-зависимую, требующую понимания продукта — делаю я. Раньше я был вынужден делать обе части, потому что других вариантов не было. Теперь могу сосредоточиться на одной.
Если бы кто-то год назад спросил меня "хочешь ли ты тратить часы в день на рутинный код?", я бы ответил "нет". Так почему сейчас я должен сожалеть о том, что больше этого не делаю?
Что AI делает хорошо в моих руках
Не претендую на универсальность — это мой опыт, в моих стеках. У меня FastAPI на бэкенде и React Native на фронте — две очень популярные технологии с огромным количеством примеров в обучающих данных. AI на них работает хорошо. Если у вас Erlang или OCaml — ваш опыт может сильно отличаться.
Что у меня работает стабильно: написание стандартных UI-компонентов в React Native, бойлерплейт API-эндпоинтов на FastAPI, миграции Pydantic-схем, простые refactor'ы в духе "переименуй переменную везде и обнови импорты", добавление новой функциональности по существующему паттерну ("у меня есть endpoint для X, сделай по аналогии для Y").
Особенно хорошо AI делает то, что я раньше делал плохо — писал документацию и комментарии к коду. Раньше я их откладывал на потом и потом не возвращался. Теперь они появляются вместе с кодом, потому что попросить написать док-строку — это один промпт, а не отдельное дело на тридцать минут.
Что у AI получается плохо — общими словами
Не буду выдумывать конкретные истории "AI меня предал". Расскажу паттернами того что я наблюдаю.
Костыли вместо использования возможностей стека. AI иногда пишет 200 строк кода для задачи, которая решается одним вызовом библиотеки или одной фичей стандартной библиотеки. Это происходит чаще всего когда задача описана недостаточно конкретно — AI берёт первое подходящее решение, не оценивая альтернативы. Лечится более точным промптом ("используй встроенную возможность X, не пиши своё") и code review.
Логические ошибки, которые компилируются. Самый коварный тип ошибок. Код выглядит грамотно, проходит линтер, проходит тесты которые сам AI к нему написал. А в проде в каком-то edge-case он работает не так, как нужно. Эта категория ошибок — главная причина почему я читаю каждую строчку которую генерирует AI, даже если она в итоге попадает в код почти без изменений.
Неоптимальные алгоритмы. AI любит O(N²) там где можно O(N), любит создавать промежуточные структуры данных, любит мапить-фильтровать-сводить там где хватило бы одного прохода. Для большинства задач это неважно — даже плохо написанный код выполняется за миллисекунды. Но когда речь о hot path или о работе с большими данными, профайлер показывает что AI-сгенерированный код можно ускорить в 10-50 раз простыми переписываниями.
Контекст всего проекта. AI видит только то что ему показали — открытые файлы и недавнюю историю. Он не помнит решение, которое было принято в коде три месяца назад, и которое находится в файле о котором AI не знает. Это значит что иногда AI предлагает решение, которое уже было опробовано и забраковано. Лечится тем что я держу в голове общую архитектуру и направляю AI.
Что я не доверяю AI
Несколько категорий задач, где я либо не использую AI вообще, либо использую с особой тщательностью проверяя каждую строчку.
Security-критичный код. Криптография, аутентификация, обработка пользовательского ввода, всё что связано с правами доступа. AI здесь не "пишет неправильно" — он часто пишет правильно по форме, но может пропустить тонкость которая в данном контексте критична. Цена ошибки несоизмерима с экономией времени, поэтому здесь я работаю медленнее и руками.
Архитектурные решения. Не "напиши класс X", а "как нам построить N-сервис чтобы он масштабировался". AI хорошо генерирует код по чёткому ТЗ. Хуже — придумывает само ТЗ. Архитектура — это в основном про компромиссы между конкурирующими требованиями. AI имеет тенденцию выбирать самый стандартный путь, что не всегда правильно.
Миграции данных в продакшн БД. Любой код, который имеет необратимые последствия для production. Здесь не работает "проверил локально, выкатываем" — здесь нужно понимать что произойдёт со всеми данными которые сейчас в БД. Это область где я плачу больше за то, чтобы сделать руками.
Что меняется в моих привычках
Несколько вещей я заметил в своей работе которые меня немного удивили.
Я стал больше думать перед тем как писать. Парадокс — раньше я часто писал-проверял-переписывал в коде, потому что это было быстрее чем рисовать в голове. Сейчас, прежде чем формулировать промпт, я обдумываю задачу полнее. Плохо сформулированный промпт даёт плохой код, и переделать его иногда дольше чем написать с нуля. Это похоже на ситуацию когда у меня был бы джун — я тратил бы время на то чтобы правильно объяснить задачу, потому что иначе джун потратит день впустую.
Я меньше боюсь начинать сложные задачи. Раньше "нужно сделать X" с оценкой "это неделя работы" откладывалось, потому что психологически сложно начинать неделю работы. Сейчас та же задача — это два-три дня, и стартовать на неё проще. Из этого следует что я делаю больше задач в принципе.
Я больше читаю чужой код. Звучит странно, но AI-генерированный код — это всё равно чужой код, который мне надо понять прежде чем принять в свой репозиторий. Этого чтения у меня больше чем было год назад. Это полезная мышца — я лучше стал ориентироваться в незнакомом коде в целом.
Я меньше пишу мелкий код руками. Кнопки, формы, обёртки, стандартные хелперы — всё это теперь генерируется. Это означает что я постепенно теряю навык быстро писать такой код "от руки". Не уверен что это проблема, но это объективно происходит. Если завтра не будет AI-инструментов, мне будет физически некомфортно вернуться к ручному написанию шаблонного кода.
Почему я не боюсь что AI меня заменит
Этот вопрос задают чаще всего, и я устал от обоих стандартных ответов — "AI скоро заменит всех" и "AI никогда не заменит настоящего разработчика". Оба ответа — это идеологические позиции, не наблюдения.
Моя позиция: AI уже заменил определённую часть моей работы — рутинную, шаблонную, повторяющуюся. И это нормально. Эта часть работы не была интересной, не делала меня лучше как инженера, не добавляла ценности продукту. Машина её делает быстрее. Хорошо.
То что AI не заменил — это решения. Не "какой код написать", а "какую систему построить, для каких пользователей, с какими компромиссами, в какой последовательности". Эти решения требуют знания продукта, рынка, юзеров, бизнес-контекста. AI этого контекста не имеет — и не будет иметь, пока соло-разработчик сам не передаст его. А пока разработчик это делает — он остаётся незаменимым звеном.
Может ли это измениться? Возможно. Может ли AI стать способным самостоятельно проектировать продукт от идеи до релиза? Технически — наверное, когда-нибудь. Практически — я не вижу этого в течение года-двух точно. И если это произойдёт через пять лет, у меня будет пять лет на адаптацию к новой реальности, как и у всех нас.
Адаптация — единственный разумный ответ. Не "не использовать AI потому что это убьёт мою профессию" и не "слепо использовать AI потому что иначе отстану". Использовать там где это полезно, не использовать там где это вредит, постоянно проверять свои предположения о том где граница между этими случаями.
Можно ли в одиночку делать то что я делаю — без AI?
Этот вопрос я задавал себе несколько раз. Честный ответ — да, можно. Без AI я бы делал ту же работу, просто на это уходило бы существенно больше времени. Возможно в два-три раза больше. Вместо параллельной работы над несколькими продуктами я бы концентрировался на одном.
То есть AI у меня не делает невозможное возможным. Он делает медленное — быстрым. Это важное различие. Если я не могу решить задачу архитектурно — AI мне не поможет. Если я знаю что нужно сделать, но в одиночку это займёт месяц — с AI займёт неделю. Это весь эффект.
Заключение
Год вайб-кодинга в продакшне — это год привыкания к новому режиму работы. Без эйфории, без катастрофы. Просто другой способ делать ту же работу.
Главный вопрос на 2026 год для соло-разработчика, на мой взгляд, не "использовать ли AI" (тут ответ очевиден), и не "как использовать AI лучше всех" (тут много гайдов, выбирайте под себя). Главный вопрос — что вы будете делать с освободившимся временем.
Можно сделать больше того же. Можно начать делать то на что раньше не хватало времени. Можно работать меньше часов в день и тратить освободившиеся на жизнь. Это уже не технический выбор, это личный.
Лично я делаю больше продуктов одновременно. Возможно, через год я пойму что это была ошибка, и сосредоточусь на одном. Но это мой выбор — а не вынужденная позиция от того что один человек не справляется со всем сразу.
Это пятая статья из моей серии про разработку. В предыдущих были конкретные кейсы из проектов: трёхуровневый кэш сообщений, Double Ratchet E2E, WebRTC звонки, vanilla Electron desktop. Эта — другой жанр, наблюдения общего характера. Если вы читаете и думаете "у меня иначе" — расскажите в комментариях. Мне интересно понять насколько мой опыт типичен или нет.
Комментарии (22)
Shalundrive
12.05.2026 13:43Путь длиною в год пройден и из него сделан положительный вывод и это главное. Год адаптации, это конечно много, но все разные и по разному получается. Без претензий к автору но в его описании опыта есть несколько спорных моментов.Дальше не хейт, хочу заострить просто некоторые моменты указав их автору. АИ в архитектуру с 0 всегда плохо, ног дав ему каркас с четким заданием наполнить его конкретными решениями на своей логике и по своим правилам всегда работает. Теперь собственно по трем темам, что AИ делает хорошо, плохо и что автор не доверяет. Первое, получается хорошо то, что автор сам хорошо знает и это нормально, но может быть так же хорошо с тем чего автор не знает. АИ, это мультимодальная штука давно, он умеет не только код генерить, но доставать любую инфу и документацию на интересующую тему условно изучать ее совместно и адаптировать именно под необходимости а не тянуть весь гарбич из чужих репозиториев. По второму, 200 строк лишнего кода, это не потому, что АИ так хочет написать лишнего, а потому, что он вообще в человеческом понимании не хочет. Заставить словоблудием (промт) машину соблюсти краткость как сестру таланта, это трата времени. Для этого есть правила и инструкции которые агент АИ должен неукоснительно выполнять, работает лучше любого промта, они могут быть сугубо индивидуальными и авторскими, но должны заканчиваться не синтетикой тестов, а реальным прогоном реализованного АИ модуля в живом рантайме. В таком варианте АИ всегда и все может. Соответственно третий вопрос отпадает сам по себе. Только скажу про безопасность, ее тоже нужно доверять АИ он прекрасно в ней условно разбирается. Все, что написал, это не истина в последней инстанции, а личное мнение и опыт работы с помощью агента.
niktomimo Автор
12.05.2026 13:43по правилам и инструкциям согласен, у меня тоже rules в проекте настроены и работают лучше промптов. в статью не вписал потому что это уже техническая мелочь, а статья больше про общие ощущения. но да, без них агент пишет много лишнего, это правда.
про документацию частично соглашусь, AI её достает нормально. но если я в стеке не разбираюсь, я не пойму что он что-то тонко напутал. поэтому и говорю что на знакомом стеке работает лучше.
а вот про безопасность не соглашусь. дело не в том что AI не знает, а в том что цена ошибки слишком высокая. я лучше потрачу время и напишу руками чем потом разбираться почему утекли ключи. это мой расчет, у вас может быть другой.
Shalundrive
12.05.2026 13:43Если ключи нужны,чтобы прогнать паплайн, условно неделю на реальных данных, то от этого не уйти, кто бы не кодил. Для этого есть способы скрыть их и после необходимости заменить. На самом деле вопрос безопасности это вопрос архитектуры, ее как основу закладывать надо. Поэтому недоверие к агенту имеет место быть, но без определенного доверия все таки не обойтись. Без прикола, точно так же как и вы боялся доверить безопасность по началу, АИ.
arch1lochus
12.05.2026 13:43пока мельком прочитал статью, но то, что вы описываете, не похоже на вайб-кодинг.
Иначе в эту категорию можно записывать сейчас преобладающее большинство программистов, ибо все так или иначе пользуются LLM для рутинных задач. ИМХО, если вы четко понимаете, что хотите увидеть на выходе и сами проводите ревью результата, "вайба" тут нет)
А после вашего заголовка сразу ждешь историю, как человек 20 лет пёк хлеб, а потом за день написал приложение для своего хлебомагазинаniktomimo Автор
12.05.2026 13:43справедливо, по узкому определению карпатого у меня действительно не вайб. вайб это когда тыкаешь промптом и коммитишь не глядя, у меня не так. термин использовал в широком смысле “работа с LLM”. Ваш пример с хлебом был бы сильнее моего, но я не пёк хлеб, я программирую)
Emelian
12.05.2026 13:43desktop-приложение для производственного предприятия на Rust + Tauri.
Вопрос, чисто риторический! Если бы вы поставили себе задачу: написать простейший аналог платформы «1С77» на, скажем, C++ / WTL, то смогли бы сделать это? И сколько бы это заняло, оценочно, времени и «денюх»? При этом в качестве движка БД можно использовать Sqlite, а скриптовый язык – на базе запросов к нему. В качестве грида можно взять опенсорсный WTLGridCtrl.
Или бы вы не взялись за эту задачу в принципе?
P.S. В фирме «1C» эту платформу делали два года – десять человек.
niktomimo Автор
12.05.2026 13:43А вы сами для какой задачи спрашиваете? “аналог 1С” это очень широкое понятие от учёта остатков на складе до полноценной бухгалтерии с зарплатой и регламентами. От ответа сильно зависит и оценка по времени и выбор стека.
Если у вас конкретный сценарий есть, расскажите оценю по делу.
Emelian
12.05.2026 13:43Ценю оперативность! Не успел задать вопрос – сразу получил ответ, надеюсь, «живой» :) .
А вы сами для какой задачи спрашиваете?
Я сам собираюсь заняться этим проектом, поскольку, мои собственные конфигурации по учету и расчету заработной платы, учету рабочего времени сотрудников и учету ресурсов на производственном предприятии, кормили меня двадцать лет и еще столько бы, если бы, если бы мою любимую фирму не ликвидировали бы по политическим мотивам.
При этом планирую использовать только бесплатные интеллектуальные сервисы, сразу, как закончу, в какой-то мере, свой проект по изучению иностранных языков.
Поэтому, мне было бы интересно знать ваше мнение.
Если у вас конкретный сценарий есть, расскажите оценю по делу.
Пока только вынашиваю идеи. Но, сначала хочу опубликовать статью, здесь, по созданию второй версии своей обучающей программы на C++ / WTL. Разбор будет с уклоном на разработку архитектуры, имитацию командной работы и максимальное распараллеливание задачи для эффективного использования бесплатных ИИ.
На базе приобретенного опыта надеюсь приступить к новому проекту, которому уже придумал название: «Модульный учёт» :) .
niktomimo Автор
12.05.2026 13:43понятно, спасибо что рассказали. с фирмой неприятная история, но и повод пересобрать на новом стеке то что сам наработал за эти годы.
“модульный учёт” реалистично если не пытаться сразу повторить 1С целиком. начать с одного куска зарплата например сделать под конкретного заказчика, и расти от него. так и психологически легче, и обратная связь быстрее.
насчёт C++/WTL для обучалки норм, ваш стек, вам удобно. но для нового продукта подумал бы ещё раз. найти соавторов на WTL в 2026 почти невозможно, значит проект навсегда останется одиночным.
про бесплатный AI на большом проекте упрётесь в лимиты быстро. заложили бы 20$ в месяц на одну подписку, окупится временем.
статью вашу когда выйдет киньте ссылку, прочитаю.Emelian
12.05.2026 13:43“модульный учёт” реалистично если не пытаться сразу повторить 1С целиком. начать с одного куска зарплата например сделать под конкретного заказчика, и расти от него. так и психологически легче, и обратная связь быстрее.
Мне, вообще-то говоря, торопится не куда. А «семерку», ныне, можно более чем на 50% сразу заменить опенсорсом. Есть даже ее опенсорсный аналог «2С», но он сделан давно и на базе MFC, код которого фирма M$ тоже, вроде как, уже открыла. Но, эта библиотека мне давно разонравилась, хотя я начинал с нее.
Делать «зарплату» «под конкретного заказчика» мне уже не интересно. Моя программа работала на трех производственных фирмах, до 1000 человек сотрудников, максимум. С учетом современных реалий, чтобы реально все было «путём», нужно находиться на самой фирме. Ибо там слишком много нюансов, которые трудно решать удаленно. Одна внешняя отчетность чего стоит! Плюс разного рода зарплатные проекты, клиент банки, поддержка своей системы учета рабочего времени (на базе нетбуков, китайских считывателей RFID-карт доступа сотрудников, собственного драйвера оборудования на С++ и конфигурации по обработке данных) и т.п., все это требует постоянного присутствия на фирме. Хотя, в последнее время, перед ликвидацией фирмы, приходилось работать с учетной системой ее нового собственника, тоже самописной, но ориентированной на удаленный доступ. Но, там были свои нюансы, которые тоже требовали личного присутствия.
Поэтому, речь идет не о поиске работы для себя, а о хобби. И все что мне нужно, это желание узнать насколько хорошо ИИ для создания альтернативы «1С77»?
найти соавторов на WTL в 2026 почти невозможно, значит проект навсегда останется одиночным
А мне это не требуется. Ибо я всегда программировал один. Так что, «это не баг, а фича!».
про бесплатный AI на большом проекте упрётесь в лимиты быстро. заложили бы 20$ в месяц на одну подписку, окупится временем
Во-первых, не «упрусь», а во-вторых, не окупится. Ибо, сейчас это уже хобби, а не работа.
статью вашу когда выйдет киньте ссылку, прочитаю
Если не забуду, то – обязательно! Но, не думаю, что это будет быстро.
Пока могу дать ссылку на свою статью: «Минималистский графический интерфейс, на C++ / WTL, для консольного загрузчика» https://habr.com/ru/articles/955838/ , чтобы с большим удобством грузить свои любимые видосики из «народного» видеохостинга, которую я бы не создал, без интеллектуальных сервисов:
Программа «MiniDL», v. 1.0.
ITDiver77
12.05.2026 13:43Спасибо, приятно читать. Я не разраб, но в своих наколенных дев проектах пришёл к такому же выводу. А есть статья или ссылка на используемые агентские обертки? Скилы, агентские описания, запреты, например, не делать гит коммит, а использовать скил commit и проч, и как в целом за год прогрессировали в опыте агентской разработки/настройке инструментария(клауд код)?
niktomimo Автор
12.05.2026 13:43Как раз занимаюсь написанием данной статьи, постараюсь в ближайшие дни выложить)
tkutru
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
ИМХО.
niktomimo Автор
По делу пишете, со многим согласен.
Шаблонную часть давно умеют инструменты, тут вы правы. Но они работают на уровне “сгенерируй мне CRUD по этой модели”. AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”. Это уже не шаблон, это контекстная задача. Code generator такое не сделает, нужен разработчик. Или AI с агентским режимом.
Про “доделать руками” вы тоже правы. Я никогда не запускаю AI-код в продакшн не прочитав. Но скорость "AI сгенерил черновик я допилил" получается быстрее чем “я написал с нуля + сам же проверил”. Не всегда, но в большинстве случаев.
Про $200/мес. Согласен, это деньги. У меня окупается потому что объём задач большой, я соло-разработчик с несколькими продуктами. Если у вас один проект и времени хватает писать руками, экономика другая.
Финально: AI это не “хочу получить и сразу получаю”. Это “хочу получить, формулирую задачу, получаю черновик, дорабатываю”. Просто эта цепочка быстрее чем “хочу получить, пишу с нуля, проверяю”. Если у вас не получается быстрее — это не значит что AI бесполезен, это значит что ваши задачи другие, или промпты не отстроены, или стек неудобный для текущих моделей.
tkutru
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
niktomimo Автор
вы правы если этот промпт скинуть в чат ChatGPT без контекста, AI нагалюцинирует половину деталей. но в реальности агентский режим работает иначе. claude code (как у меня) видит весь проект: читает соседние формы и понимает что "дизайн как соседние" буквально, видит schema.prisma и знает что номер должен быть unique constraint в БД, видит .env и знает какой SMS-провайдер настроен. промпт это не ТЗ, это начало разговора. сначала "сделай форму", смотрю что вышло, потом уточняю "валидация должна быть с +7 RU mask, не казахстан", "constraint на уровне prisma, не на фронте", "SMS через тот же шлюз что в RegisterForm". за 3-4 итерации получается то что нужно. то есть ваша критика справедлива для разовых промптов в чате без контекста проекта. в агентском режиме с rules и видением кода работает иначе. но соглашусь что мой пример в комменте звучал слишком гладко. в реальности он гораздо более итеративный.
dkfbm
Честно говоря, я вообще практически перестал пользоваться промптами с описанием задач. Только если что-то совсем уж мелкое, типа: у тебя кнопка съехала в сторону, верни на место. Во всех остальных случаях промпт – это просто ссылка на .md с описанием задачи:
Если новая фича, то подробное описание, часто со ссылками на предыдущие документы;
Если результат тестового прогона, то тест кейс, ожидаемый и фактический результаты, если есть – то логи ошибок.
Таким образом каждый шаг получается документированным и ничего в дальнейшем не "забывается".
Если изменение хоть сколько-нибудь значительное, то обязательно включаю многоэтапный процесс: брэйншторм -> спецификация -> план реализации. После чего тоже остаются документы, и почему сделано так, а не иначе, вопросов потом не вызывает.
ButakovAndrey
Использую такой же пайплайн, даже именование такое же:
Brainstorming - > spec - > working - > code reviewing)))
Conung_ViC
дикое ощущение что вам ИИ агент и ответил вместо автора...
Хотя, если автор статьи - тоже ИИ, считается ли что вам ответил сам автор?
niktomimo Автор
Логично, статья как раз про то что 70% работы у меня с AI)