Нейросети с нами надолго. Даже если вдруг исчезнут OpenAI, Anthopic, Z.ai и прочие, мой личный Qwen 3.8 27B никуда не денется. Вопрос - a что с этим делать? Как разрабатывать софт в новую эпоху?

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

Есть такой университетский предмет, который все давненько подзабыли (а люди с ИТ-курсов его и в глаза не видели): "методология разработки программного обеспечения". Разработка хорошего ПО - это всегда вопрос методологии. Это и общие принципы архитектуры, и дисциплина работы, и возможность передать работу соседу, разделить между несколькими людьми, признать нечто готовым или не готовым. Без методологии разработка стремительно теряет управляемость.

Как сейчас.

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

TDD: Test driven development

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

Почему?

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

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

Чтобы ваше приложение можно было разработать через TDD, тестирование должно быть автоматизируемым. Вот здесь большинство разработчиков графических приложений уже чувствует некоторую засаду. А именно - автотесты очень плохо умеют тыкать в графические кнопки и смотреть результат. Но на то мы и разработчики, чтобы решать такие проблемы.

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

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

После того, как входные данные достигли цели, нужно валидировать выходные. Для графических приложений, обычная практика - золотые скриншоты и расхождения от них в дельте по пикселям. Это далеко не всегда годится. Но современные модели, даже упомянутый Qwen 3.8 в локальном издании, уже умеют читать с экрана. Ваша задача как архитектора - дать им пайплайн, который такое чтение позволит. Например, безголовый режим с синтетическим вводом.

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

База знаний проекта

TDD это штука давнишняя, будем переходить к новшествам эпохи нейросетей.

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

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

Структура базы знаний и человеческой документации тоже отличаются: человеку нужно знать то, что покрывает его вероятную задачу, ради которой он пришёл с поисковым запросом. Видя конкретный API, он легко и весьма точно на опыте предполагает, как этот API должен работать. Нейросети нужно знать конкретную структуру и иерархию кода вокруг задачи, а не только API. Если нейросети нужно предполагать, а не знать - она галлюцинирует. Для человека неприменимы толстые таблицы с адресацией по коду - он не сможет в этом ориентироваться. Для нейросети это норма.

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

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

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

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

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

Сеть инвариантов

Специфика обучения моделей для кода в том, что тексты, описанные в виде стандарта, имеют при анализе больший вес, чем произвольные. Это делается для того, чтобы нейронка ценила, например, стандарт C++ больше, чем документацию конкретной реализации STL или ответы на stackoverflow.

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

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

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

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

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

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

Саморазвитие

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

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

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

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

К слову о токенмаксинге

Как же можно обойтись без антипаттернов в такой статье.

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

Важно понять цель всего этого действа. Если ваша цель - работающее ПО, я постарался подкинуть пару идей, как можно к ней идти. используя нейросеть как помощника. Если цель - удовлетворить начальство, стоит посмотреть где-то ещё.

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

Заключение

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

Все описанные аспекты сводятся к одному вопросу: "Что нам сделать сейчас, чтобы в будущем можно было проверить себя и проект". Ровно тот вопрос, который обычно забывается в погоне за сиюминутным результатом. Нейросети дали нам чрезвычайно быстрое прототипирование, от чего у многих людей просто атрофировалось понимание, что прототип не есть работающая система. От нас требуют всё больше сейчас, забывая задуматься - "а как это будет жить в будущем".

Если о будущем никто не подумает, его и не будет.

Делитесь своими наработками и мыслями по нейрослопингу кода в комментариях!