GPT, Claude, Cursor и Copilot? Или проблема всех AI агентов.

На дворе 2026 год. Время довольно серьёзных технологических перемен.

Но у всех AI агентов одна и та же проблема

Сегодня у человека, который хочет заниматься разработкой с ИИ, по сути два варианта: либо постепенно получать реальный навык, либо так и остаться на уровне «поиграться в программирование».

И речь сейчас вообще не о том, умеешь ты писать код руками или нет

Последние пару лет постоянно идут споры:
кто лучше — классический программист или человек, который работает через ИИ и промты?

По-моему, сам спор неправильный

Одно совершенно не мешает другому.

Хороший программист с ИИ становится сильнее.

А человек без классического программистского бэкграунда благодаря ИИ впервые получает возможность создавать довольно серьёзные вещи.

Но есть одна проблема.

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

Вот здесь я много раз обжигался. Начинаешь новый проект. Первые дни всё идеально. ИИ быстро пишет код. Интерфейс появляется. Функции появляются. Кажется, что ещё немного — и продукт готов. А потом на каком-то этапе внезапно ловишь себя на мысли: нить проекта потеряна.

Чаще агент просто предложит очередное логичное решение.
Иногда хорошее.

Иногда такое, которое противоречит тому, что вы сами сделали несколько дней назад.

Потом появилась идея: нужен просто хороший промт
Я хорошо помню этот период.

Все рассказывали примерно одно: главное — научиться правильно писать промты.

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

И он не способен заранее придумать за тебя то, чего ты сам ещё не решил.

Особенно когда разработка идёт месяцами.

Проект меняется.
Появляются новые требования.
Какие-то решения отменяются.
Другие, наоборот, становятся фундаментальными.

Один огромный промт постепенно превращается просто в ещё один документ, который нужно поддерживать.

Потом пришли тесты
И это был огромный шаг вперёд.

Не надо верить модели на слово. Пусть докажет, что код работает.

Но и здесь есть ловушка.

Зелёный тест означает только то, что прошёл именно этот тест. Он не означает автоматически, что продукт работает правильно.

У меня был случай, когда прошло 158 тестов.
Выглядит убедительно?

Но затем при более глубокой проверке мы всё равно нашли критические проблемы.

И вот здесь приходит очень важное понимание:

Если программа должна запускаться на реальном устройстве — мало проверить функцию внутри кода.
Нужно запустить её на реальном устройстве.

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

Со временем у меня появилось простое правило:
не «ИИ сказал, что готово», а «мы получили доказательство, что готово».

Следующим большим трендом стали агенты.

Появились целые рои. И снова возникло ощущение:

На практике всё оказалось сложнее.

Потому что десять агентов без общей дисциплины способны в десять раз быстрее создать хаос.

Даже схема: исполнитель → аудитор
сама по себе проблему не решает.

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

Один агент написал:

Второй увидел красивый отчёт и подтвердил

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

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

Человек несколько месяцев играет со всем этим.
Очередной «революционный» инструмент.

Потом проект начинает ломаться, и возникает очень понятная мысль:

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

Но тебе нужен другой навык. И он далеко не про синтаксис.

Для меня это прежде всего две вещи: дисциплина и усидчивость.

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

Как я сам к этому пришёл. Я начинал довольно давно и тяжело. У меня не было готовой системы. Очень многое я держал в голове.
Где-то записывал решения.
Где-то просто помнил:

Со временем проектов становилось больше. Цепочек решений становилось больше. Работа с ИИ становилась сложнее.
И в какой-то момент я решил отдельно проанализировать собственный подход.

И оказалось, что определённая система уже давно существует.
Я просто никогда не оформлял её как систему.
Так постепенно и появился метод (AEM).

Что такое этот метод (AEM) простыми словами — это инженерный слой между человеком, ИИ-аудитором и агентами-исполнителями.

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

Задача другая: не дать разработке потерять направление.

У проекта появляется внешняя память. Не память чата. Не память человека. А память самого проекта.

Мы фиксируем важные решения. Фиксируем текущее состояние.
Отделяем то, что уже доказано, от того, что пока является гипотезой.

Большие изменения разбиваются на небольшие этапы.У каждого этапа заранее понятен критерий завершения.

Если задача прошла проверку — появляется PASS. Если доказательств недостаточно — FAIL.

Кроме этого, мы отделяем роль исполнителя от роли аудитора.

Исполнитель должен решить задачу.

Аудитор не должен помогать ему оправдывать результат.Его задача — попытаться доказать, что результат неправильный.

И только если это не получилось, мы принимаем работу. Это очень простое изменение ролей, но оно сильно меняет качество разработки.

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

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

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

Если мы хотим его изменить — нужна причина.

Новая проблема.
Новое требование.
Новое доказательство.
Просто фразы: «Я бы сделал иначе» недостаточно.

Именно это в какой-то момент резко снизило количество ситуаций, когда ИИ сам создаёт проблемы в уже работающей части системы.

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

Длинные чаты почти перестали деградировать так сильно, как раньше.

До этого было привычным что ИИ агент теряется в контексте, в зависимости от увеличения объема информации, начинает путать старое и новое.

А теперь модель больше не обязана помнить весь проект.
Мы можем открыть новый чат и передать ему не километры старой переписки, а нормальное состояние:

То есть память постепенно переехала из разговора в сам процесс разработки.

Для меня именно это оказалось одной из самых сильных вещей во всём подходе.

Стоит понимать, что метод AEM нужен далеко не всем и не всегда.

И здесь тоже важно не перегнуть.

Если ты вечером решил сделать маленького Telegram-бота для себя — тебе не нужна сложная инженерная система.

Если делаешь простой сайт на выходные — тоже.

В таких случаях можно открыть ИИ агента, написать несколько промтов, получить результат и радоваться жизни.

Наш подход начинает иметь смысл тогда, когда проект собирается жить дальше.

Вот тогда система начинает окупаться.

И вот какая мысль у меня появилась дальше

Я подумал: а что если собрать вокруг себя не профессиональных программистов, которые и без меня знают, как вести разработку?

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

Не обещать им:

И не пугать:

А дать возможность начать с реального проекта и постепенно освоить именно инженерное мышление.

Причём сам метод мы стараемся строить таким образом, чтобы ИИ с самого начала понимал:

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

Поэтому если ты боишься начать — не бойся

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

Но нужно просто быть готовым учиться. Ошибаться. Проверять.

Не верить красивому ответу только потому, что он красиво звучит илиВозвращаться к проблеме ещё раз, если доказательств недостаточно.

И главное — не бросать после первого момента, когда ИИ превратил хороший проект в кашу.

Потому что это происходит почти у всех.
Разница лишь в том, что кто-то после этого говорит:

А кто-то начинает искать способ сделать сам процесс надёжнее.
Я выбрал второй вариант.

Так и появился наш метод.

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

Если хочешь учиться, экспериментировать, приносить свои проекты, ошибки и вместе разбираться — приходи. Денег за вход мы не берём.

[DEV IT AI |Chronicle]

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

И этим шансом, мне кажется, точно стоит воспользоваться.