Autogenesia: разработка AI Code Agent без опыта в системном программировании

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

Сначала мне стоит немного рассказать о себе. Я Эдвард, мне 25 лет, и я юрист с 3-х летним стажем и хоть статьи с Хабр уже несколько лет попадают мне в ленту, но активно программировать и следить за новостями IT стал только в прошлом году.

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

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

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

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

Все началось с идеи

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

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

Потом решил сделать проект с ИИ, а именно юридический чат-бот, где ИИ будет анализировать запрос пользователя, потом смотреть локально скачанные законы (ГК РФ, ТК РФ и т.д.) и давать юридическую консультацию.

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

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

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

Стало понятно, что нужно приложение на компьютере, которое будет «видеть» файлы и их менять.

Я поискал ответы у ИИ, спросил у знакомого программиста, и они посоветовали мне Антигравити или Cursor.

В приложение от Google я просто не смог зайти, так как у меня нет иностранного аккаунта, и я решил не мучится, а в Cursor меня отпугнул дизайн и не понимание, куда нажимать, чтобы было весело.

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

Пару дней формировал идею, и с этого началась разработка.

Начало разработки

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

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

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

Еще одно «фишкой» была мультиагентность, которая заключалась в том, что старший ИИ не пишет код сам, а он лишь писал инструкцию, а непосредственно код писал специализированный агент Генератор. Это было сделано, чтобы улучшить эффективность аналитической работы старшего ИИ, но главное экономить исходящие токены дорогих моделей (таких как Opus, Sonnet и т.д.), но при том взять самое ценное от них, а именно аналитические навыки. Генератором из-за дешевизны, и хороших навыков в кодинге был взят Deepseek V3.2 non reasoner.

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

План был подготовлен, пора было его реализовывать.

Вайб кодил я в основном благодаря Claude Opus 4.5, не хочу перехваливать компанию Antrophic, но они сделали лучший ИИ на рынке, благодаря которому вообще мой проект состоялся.

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

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

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

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

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

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

Тогда я решил, что пора создавать настоящее агентское приложение для автономной генерации кода!

Не мешки ворочать или что было дальше

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

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

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

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

Когда перед ИИ была поставлена задача сделать сложную программу, вылезли первые проблемы.

С особой «любовью» я вспоминаю проблему с  файловыми путями.

Когда я просил ИИ «создать модуль auth.py в папке services», он радостно генерировал код. Но при попытке сохранить его виртуальная файловая система (VFS) падала.

Оказалось, модели мыслят абстрактно. Для них services/auth.py и ./services//auth.py — одно и то же. А для pathlib в Python — это разные вселенные.

Более того, ИИ часто забывал, что папка services может еще не существовать. Он пытался записать файл в пустоту, получая FileNotFoundError.

Пришлось написать «Няньку для путей» внутри virtual_fs.py.

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

Автосоздание родителей: При сохранении файла (stage_change) я добавил проверку: если родительской папки нет — создай её. И не забудь положить туда init.py, если это Python-пакет, иначе импорты потом сломают голову.

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

Кроме путей была проблема с вечным циклом.

Изначально я попросил написать ИИ простой скрипт: система запускает код, ждет завершения и смотрит, нет ли ошибок. На задачах вроде «напиши калькулятор» или «отсортируй список» всё летало. Я расслабился.

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

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

Это было приложение, так называемый «демон — это программа, которая не должна заканчиваться. Она входит в вечный цикл (Event Loop) и ждет действий пользователя. А моя система тестирования, как Хатико, преданно ждал, пока программа завершится сама. Спойлер: никогда.

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

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

Но проблемой, из-за которой я генерировал кучу самых неприличных слов, стала интеграция новейшей Gemini 3.0 Pro. Я ожидал прироста интеллекта, а получил "шпиона", который отказывался работать по правилам.

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

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

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

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

Наверное, родители не так рады первым словам ребенка, как я был счастлив первому ответу от Gemini.

Раз я так расхвалил детище Antrophic, нужно его немного покритиковать.

При тестировании никаких технических проблем с моделями Claude я не выявил, но слишком часто их ответы упирались в лимиты или вообще не парсились и я грешил на парсер, но с другими моделями он работал хорошо.

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

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

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

Я еще много могу рассказывать, но сейчас стоит рассказать, что есть сейчас.

Да это же Codex или Cursor

На данный момент мой проект, который я назвал Autogenesia, продолжает разрабатываться, но уже функционален.

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

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

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

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

Проект мультиагентный, поэтому в нем есть агенты:

• Оркестратор (Senior Partner): Это мозг (сильные, часто дорогие рассуждающие модели). Он не пишет код руками. Он читает задачу, смотрит на карту проекта и составляет план действий — "Инструкцию".

• Генератор (Associate): Это рабочая лошадка (не рассуждающие или с малым бюджетом токенов модели). Он получает инструкцию и просто пишет код, а потом его применяет. Быстро, дешево, но иногда с ошибками.

• Валидатор (Ревизор): Моя гордость. Это отдельный, злой агент (это Qwen 2.5 или малая модель DeepSeek), у которого одна задача — найти, к чему придраться. Он не исправляет код, он просто выносит вердикт: APPROVE или REJECT. Если код не решает задачу или ломает логику — он заворачивает его обратно Оркестратору с комментарием "Переделывай". У Оркестратора есть возможность отказаться принимать его выводы, но тогда уже пользователь решает, кого поддержать.

Чтобы Оркестратор не сходил с ума от объема информации, я создал Индексную карту. Это не просто поиск по тексту (Ctrl+F), эту карту создает малый ИИ (qwen-coder-32b или Deepseek V3.2 non reasoner).

Система не читает все файлы подряд — это дорого и долго. Вместо этого она смотрит в карту: "Ага, класс User лежит в models.py, а его методы — в services.py". Особенность моей реализации в том, что эта карта — живая. Она создается с нуля при смене рабочей директории (чтобы не было галлюцинаций от старых проектов) и обновляется инкрементально. Если агент меняет файл, он тут же переписывает "карточку" этого файла в каталоге.

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

Поэтому я написал слой Виртуальной Файловой Системы.

Когда ИИ "пишет" код, он на самом деле галлюцинирует в изолированную песочницу. Ни один байт на жестком диске не меняется. В этой песочнице:

Проверяется синтаксис (чтобы не было SyntaxError).

Проверяются импорты (чтобы не импортировать несуществующее).

Прогоняется Валидатор.

Код запускается.

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

Теперь давайте я распишу процесс работы на реальном примере.

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

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

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

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

Сейчас я уже полирую получившийся результат, но сгенерированный код уже является полноценным CLI-приложением и вы можете проверить его в моем репозитарии https://github.com/edikobi/Habrnewsrss.

Я смог, сделал мультиагентное CLI-приложение и основных целей уже добился, хотя, конечно, сравнение с Cursor и прочими программами я добавил ради красного словца.

Вообще, мои знакомые сравнивали его то с Cursor, что с Devika, ну и главное с Codex.

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

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

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

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