[Перевод] Код больше не ваш. Разработка в эпоху AI

Введение

Я писал код всю свою жизнь. И сейчас осознаю — если бы я родился на 15 лет позже, я бы не написал ни одной строчки. Но я бы всё равно создавал отличные продукты.

Это не антиутопическая фантазия. Это траектория, по которой мы движемся. AI-агенты уже могут генерировать код, писать тесты, создавать миграции и отправлять pull request'ы. Вопрос, который не даёт мне покоя: когда AI пишет код, важна ли ещё архитектура программного обеспечения?

В моей предыдущей статье я исследовал инструменты и агентов, которые меняют IT-разработку — «что» революции AI. Эта статья идёт глубже. Она о «как» — как AI меняет наше мышление о коде, архитектуре и всей индустрии. Она объединяет мои личные размышления, разговоры с десятками разработчиков, исследования новых методологий и наблюдения за экосистемой в состоянии стремительной трансформации.

Гипотеза языковой модели

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

Архитектура, которую понимает AI

1. Маленькие файлы, сфокусированный контекст. Clean Architecture поощряет классы с единственной ответственностью. Файл юзкейса — это 50-100 строк. AI-модель удерживает весь контекст в окне внимания, полностью его понимает и генерирует точные модификации. «God-класс» на 2000 строк — это потеря контекста и неизбежные галлюцинации.

2. Предсказуемая структура проекта. Повторяемый паттерн — Entities → Use Cases → Interface Adapters → Frameworks — помогает AI быстрее ориентироваться в незнакомом коде. Модель распознаёт «где я нахожусь» по структуре директорий и файлов, а не по содержимому каждого класса.

3. Явная бизнес-логика в центре. DDD даёт словарь, который одновременно читаем человеком и парсится машиной. Когда класс называется CreateOrderUseCase и принимает OrderDTO, возвращая OrderId — имена и есть документация. Core-слой содержит чистые правила без фреймворк-магии, и AI не нужно одновременно разбираться в бизнес-логике и в особенностях ORM или HTTP-фреймворка.

4. Контракты и интерфейсы понятны модели. Чёткие интерфейсы (Ports) позволяют AI безопасно генерировать адаптеры, моки и реализации. Интерфейс — это контракт, который AI может выполнить буквально: типы входов, типы выходов, ожидаемое поведение.

5. Подходит для пошаговой генерации. Можно просить AI реализовать конкретный Use Case или Adapter отдельно — без необходимости загружать в контекст весь проект. Декомпозиция архитектуры естественно совпадает с тем, как мы формулируем задачи для AI-агентов.

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

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

Выбор языка для AI-ассистированной разработки

Фактор видимости

Не все языки программирования созданы равными, когда речь идёт о разработке с помощью AI. Рассмотрим, что происходит, когда AI-агенту нужно понять зависимость в вашем проекте:

• PHP, Go, JavaScript/TypeScript: Зависимости скачиваются как исходный код (vendor/, $GOPATH/pkg/mod/, node_modules/). AI-агент может открыть любой файл, отследить любой вызов, понять любое поведение. Это идеальная среда для AI-ассистированной разработки.

• Java, Kotlin: Зависимости по умолчанию скачиваются как скомпилированные артефакты (.jar, .aar). Исходники можно получить отдельно (mvn dependency:sources), но это дополнительный шаг, который не все настраивают. AI видит интерфейсы и типы, но доступ к реализациям требует настройки.

• C/C++: Системные библиотеки скомпилированы. Заголовочные файлы дают сигнатуры, но реальное поведение скрыто в бинарном виде. AI работает с чёрным ящиком.

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

Обучающие данные и прозрачность экосистемы

Больше публичного кода = лучшая производительность AI. Языки с большими open-source экосистемами (Python, JavaScript, PHP) имеют больше доступных обучающих данных. AI видел больше паттернов, больше идиом, больше решений на этих языках. Это не значит, что AI не может писать на Rust или Haskell — может. Но глубина его понимания коррелирует с объёмом публично доступного кода.

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

Это не значит, что нужно отказываться от Go или Java. Но если вы выбираете стек для нового проекта и AI-ассистированная разработка — приоритет, прозрачность экосистемы — фактор, который стоит учитывать.

Важна ли ещё архитектура?

Шесть практических аргументов

1. Чтобы AI генерировал хороший код, ему нужна хорошая структура. AI-модели — это машины следования паттернам. Они обучались на миллионах репозиториев и усвоили, как выглядит «хороший код» в контексте. Когда ваш проект следует DDD и Clean Architecture, AI распознаёт паттерны и генерирует код, который вписывается. Когда ваш проект — бесструктурный хаос, AI генерирует... ещё больше хаоса. Стабильно.

2. Атомарные изменения. Хорошо спроектированный код с изолированными модулями означает, что изменение в платёжной системе не ломает случайно сервис уведомлений. Для AI-сгенерированного кода это критично — агент модифицирует один ограниченный контекст, не понимая (и не рискуя сломать) остальные.

3. Меньше токенов, лучше результат. Декомпозированный код означает, что AI обрабатывает только релевантный контекст. Файл юзкейса, его DTO, интерфейс репозитория — это всё, что AI нужно видеть. В монолитной архитектуре AI пришлось бы обрабатывать тысячи строк для того же изменения, сжигая токены и увеличивая шанс галлюцинации.

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

5. Рефакторинг работает. Добавление фич, выделение сервисов, разделение агрегатов — эти операции просты, когда архитектура направляет AI. «Добавь расчёт скидки в агрегат Order» — ясная инструкция с ясным местоположением. «Добавь логику скидок куда-нибудь в приложение» — рецепт спагетти.

6. DDD как документация. Ограниченные контексты, агрегаты, объекты-значения, доменные события — это не просто инструменты организации кода. Это живая документация. Они говорят и людям, и AI, что система делает, как концепции связаны и где проходят границы. Это документация, которая никогда не устаревает, потому что она и есть код.

Что говорит сообщество

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

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

Вымирание Stack Overflow

Произошло то, чего никто не предсказывал ещё пять лет назад: Stack Overflow стремительно теряет релевантность. Не потому, что он плохой. Не потому, что ответы неправильные. А потому, что AI заменил его основной сценарий использования. Разработчики больше не ищут ответы — они спрашивают AI напрямую. Зачем открывать браузер, вводить запрос, просматривать ответы (половина устаревших, некоторые неверные, большинство с оговорками, которые могут или не могут относиться к вашей ситуации), если можно спросить Claude или ChatGPT и получить контекстный ответ за секунды?

Цифры говорят сами за себя

Трафик упал более чем на 40% с 2023 года. Компания прошла через несколько раундов сокращений. Сообщество — когда-то бьющееся сердце обмена знаниями разработчиков — сжимается. Активные контрибьюторы уходят. Количество новых вопросов снижается. Геймификация, которая когда-то мотивировала экспертов делиться знаниями, потеряла свою притягательность.

Скрытый риск

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

Мы строим AI-системы на фундаменте знаний, который медленно тухнут. Модели продолжают выдавать ответы из 2020 года о библиотеках, которые к 2026-му изменились до неузнаваемости. И не осталось сообщества, чтобы их исправить.

Это не просто ностальгия. Это структурный риск для всей экосистемы AI-ассистированной разработки. AI-ассистенты учатся на вашем коде в реальном времени: каждый файл в контексте, каждый промпт — это обучающий сигнал, формирующий качество генерации. Когда внешние источники знаний устаревают, ваша кодовая база становится главным учебником для AI. CreateOrderUseCase, OrderRepository, PaymentGatewayPort — чистая архитектура учит модель правильным паттернам. Хаотичный код учит воспроизводить хаос. Если вы хотите, чтобы AI писал качественный код — дайте ему качественную архитектуру как образец.

Кризис open source

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

Вторжение вайб-кодеров

Появилось новое явление: вайб-кодеры заваливают open source AI-сгенерированными pull request'ами. Паттерн удручающе предсказуем:

1. Кто-то находит баг в open-source проекте

2. Вставляет описание бага в AI-агента

3. Агент генерирует «исправление»

4. Они отправляют PR, не понимая, что делает код

5. Мейнтейнер теперь должен ревьюить AI-сгенерированный код от человека, который не может его объяснить

Ревью PR'ов — и так времязатратный и ментально изматывающий процесс. Каждый pull request требует переключения контекста: понять изменение, продумать крайние случаи, проверить на регрессии, верифицировать стилевую консистентность. Теперь умножьте это на поток AI-сгенерированных PR'ов от контрибьюторов, которые не могут ответить на вопрос «почему ты сделал именно так?»

Дилемма мейнтейнера

Мейнтейнеры стоят перед невозможным выбором:

• Ревьюить вручную: Изматывающе. Каждый AI-сгенерированный PR требует столько же (или больше) усилий, как написанный человеком, но контрибьютор не может осмысленно участвовать в обсуждении ревью.

• Использовать AI для ревью AI: Соблазнительно, но рискованно. Без глубокого контекста мейнтейнера — истории решений, известных крайних случаев, архитектурного видения — AI-ревью поверхностно в лучшем случае, опасно в худшем.

• Закрыть всё: Некоторые мейнтейнеры именно так и поступают. Закрывают все внешние PR'ы, ограничивают контрибуции или вовсе бросают проекты.

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

Более фундаментальная защита — архитектура самого проекта. Чёткие слои, интерфейсы-контракты, изолированные модули — это барьеры, которые работают автоматически. Плохой PR виден сразу: он нарушает границы слоёв, ломает контракты или не вписывается в существующую структуру. Архитектура — это не только про то, как AI пишет ваш код. Это ещё и про защиту от кода, который AI пишет для других.

Spec-Driven Development: снова проектируем до написания кода

Если Stack Overflow терял своё значение как источник знаний, а open source задыхается под потоком AI-контрибуций, то что может дать AI правильный контекст для генерации кода? Один из ответов — формальные спецификации.

Разработка от спецификации — Spec-Driven Development (SDD) — возвращается в новой форме. Мартин Фаулер анализирует этот набирающий силу тренд, выделяя три эволюционных стадии.

Три стадии SDD

Spec-first: Вы пишете детальную спецификацию до генерации любого кода. Спецификация — вход; код — выход. Это наиболее структурированный подход — вы серьёзно вкладываетесь в определение того, что хотите, а AI занимается реализацией.

Spec-anchored: Спецификация существует рядом с кодом и служит точкой отсчёта. Код может отклоняться, но спецификация возвращает его обратно. Считайте это полярной звездой, которая направляет и человеческую, и AI-разработку.

Spec-as-source: Спецификация И ЕСТЬ источник истины. Код — сгенерированный артефакт, как скомпилированный байт-код. Вы не редактируете код; вы редактируете спецификацию, а код перегенерируется. Это самое радикальное видение.

Появляющиеся инструменты

Несколько инструментов материализуются вокруг этой философии:

• GitHub Spec Kit: Фреймворк для spec-driven разработки. Вы пишете спецификации, инструмент генерирует план, разбивает его на задачи, и AI реализует каждую задачу. Ставка GitHub на «специфицируй → планируй → задачи → реализуй».

• Kiro: Spec-driven IDE от Amazon, которая структурирует разработку вокруг спецификаций, направляющих документов и task-based реализации.

• Tessl: Платформа, целиком построенная вокруг идеи, что спецификации, а не код, должны версионироваться и поддерживаться.

Формулировка Microsoft, пожалуй, самая убедительная: «контроль версий для вашего мышления». В традиционной разработке мы версионируем код — результат. В SDD мы версионируем намерение — входные данные.

Почему это важно для архитектуры

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

Критический взгляд

SDD перекликается с Model-Driven Development (MDD) из 2000-х, который обещал похожие вещи и в основном провалился. Разница может быть в том, что AI лучше генерирует код из спецификаций, чем шаблонные движки двадцатилетней давности.

Есть также проблема соответствия агента: AI не всегда точно следует спецификациям. Он отклоняется, галлюцинирует, принимает «креативные» решения. SDD работает только если AI последовательно выполняет спецификацию, а мы ещё не полностью там.

Слепые зоны AI: где агенты терпят неудачу

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

Сложные алгоритмические задачи

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

Крайние случаи и баги на уровне данных

AI-сгенерированные тесты прекрасно покрывают happy path. Позитивные кейсы проходят. Код выглядит чисто. Но баги всплывают на уровне данных — null-значения в неожиданных полях, Unicode-символы в именах, крайние случаи с часовыми поясами, конкурентная запись в одну и ту же запись. Это баги, которые вызывают инциденты на продакшене, и именно их AI пропускает чаще всего.

Производительность под реальной нагрузкой

Следовать принципам SOLID — одно. Обеспечить производительность системы под нагрузкой с реальными данными — другое. AI может написать код, который архитектурно чист, но создаёт проблему N+1 запросов, удерживает соединения с БД слишком долго или выделяет память паттернами, вызывающими паузы сборщика мусора под нагрузкой. Оптимизация производительности требует понимания поведения в рантайме, аппаратных ограничений и паттернов данных, которых у AI просто нет.

Бизнес-контекст и история проекта

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

Безопасность

AI регулярно генерирует код с уязвимостями — SQL-инъекции в обход ORM, небезопасные значения по умолчанию, hardcoded секреты, отсутствующая валидация на уровне авторизации. Модель оптимизирует «чтобы работало», а не «чтобы было безопасно». Ревью AI-сгенерированного кода на безопасность — не опция, а обязательный этап, причём требующий экспертизы, которую сам AI пока надёжно обеспечить не может.

Новый разработчик: архитектор, а не кодер

Роль разработчика переживает свою самую фундаментальную трансформацию со времён перехода от ассемблера к языкам высокого уровня. Мы движемся от «написания кода» к «проектированию систем и ревью AI-вывода».

Разработчик как архитектор

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

• Задаёт структуру: Определяет архитектуру, настраивает ограниченные контексты, устанавливает паттерны и конвенции

• Устанавливает ограждения: Создаёт Команды, Агентов, Скилы, Правила — новые «документы онбординга» для AI

• Ревьюит результат: Оценивает AI-сгенерированный код на корректность, соответствие архитектуре, крайние случаи и безопасность

• Принимает решения: Выбирает технологии, разрешает неоднозначности, обрабатывает компромиссы, требующие бизнес-контекста

• Предоставляет контекст: Объясняет «почему» за решениями, которые AI не может вывести из кода

Заметьте, чего нет в этом списке: написания кода. Для senior-разработчиков основная деятельность смещается от производства к направлению. От набора текста к мышлению. Junior и middle разработчики по-прежнему будут писать код — но в тандеме с AI, и их рост будет измеряться способностью перейти от «кодирования» к «проектированию».

AI-файлы онбординга

Возникает новая категория артефактов: файлы, написанные специально для потребления AI. CLAUDE.md, .cursorrules, .windsurfrules, проектные SKILL.md файлы — это новые документы онбординга. Они кодируют ваши архитектурные решения, конвенции именования, запрещённые паттерны и предпочтительные подходы в формате, который AI-агенты могут потреблять и следовать им.

Умение хорошо писать эти файлы становится критическим навыком. Хороший CLAUDE.md может быть разницей между AI-агентом, который производит код, которым вы гордитесь, и тем, который создаёт хаос, на уборку которого вы тратите часы.

Понимание остаётся необходимым

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

• Прочитать diff и заметить уязвимость безопасности

• Посмотреть на запрос к базе данных и предсказать его характеристики производительности

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

• Оценить, будет ли архитектурное решение масштабироваться

Сервисы для агентов, а не для людей

Экономика «агент-агенту»

Пожалуй, самый захватывающий формирующийся тренд — создание сервисов, предназначенных не для людей, а для AI-агентов. Появляется новая категория платформ: сервисы, построенные для межмашинного взаимодействия. Model Context Protocol (MCP) от Anthropic стандартизирует то, как AI-агенты подключаются к внешним инструментам. GPT Actions от OpenAI, платформы вроде OpenClaw и Entire — они не предназначены для разработчиков, чтобы те просматривали их в браузере. Они предназначены для AI-агентов, чтобы те потребляли их программно. API, которые обслуживают другие API. Агенты, которые общаются с другими агентами.

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

Что это значит для архитектуры

Когда ваши потребители — машины, правила меняются:

• Машиночитаемые спецификации становятся критичными. OpenAPI, JSON Schema, Protocol Buffers — это больше не nice-to-have. Это основной интерфейс вашего сервиса.

• API-контракты важнее UI. AI-агенту нет дела до вашего красивого дашборда. Ему важны консистентность вашего API, обработка ошибок и документация.

• Версионирование становится обязательным. Когда сотни AI-агентов зависят от вашего API, ломающее изменение не раздражает нескольких разработчиков — оно ломает сотни автоматизированных воркфлоу одновременно.

Сценарий чёрного ящика

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

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

Заключение

Архитектура важна больше, чем когда-либо. Не вопреки AI — благодаря ему.

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

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

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

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

С чего начать

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

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

2. Опишите проект в README и CLAUDE.md. README — это точка входа для людей и агентов. CLAUDE.md (или .cursorrules) — кодифицированные архитектурные решения, конвенции, запрещённые паттерны. Без этих файлов AI работает вслепую — с ними он становится частью команды

3. Освойте агентный подход. Современные AI-инструменты — это не автодополнение. Это агенты, которым можно делегировать задачи: написание тестов, рефакторинг, code review, генерацию документации. Научитесь формулировать задачи для агентов так же, как вы формулируете их для джуниоров — с контекстом, ограничениями и критериями приёмки

4. Пишите агентов и их скиллы. Создавайте специализированных агентов под задачи вашего проекта: агент для code review по вашим стандартам, агент для генерации миграций, агент для аудита безопасности. Каждый скилл — это переиспользуемый промпт с чётким контрактом входа и выхода. Это новый уровень автоматизации — не скрипты, а интеллектуальные помощники

5. Изучите DDD и Clean Architecture — не как академическое упражнение, а как язык общения с AI-агентами. Bounded Contexts, Value Objects, Use Cases — это словарь, который делает ваши промпты точными, а результат предсказуемым

6. Попробуйте SDD-подход. Напишите спецификацию перед тем, как просить AI генерировать код. Опишите интерфейсы, контракты, поведение — и сравните результат с промптом «просто напиши». Разница покажет, почему архитектура решает

7. Ревьюьте AI-код как продакшн-код. Безопасность, производительность, крайние случаи, соответствие архитектуре. AI генерирует быстро — но ответственность за качество остаётся на вас. Не принимайте код только потому, что он компилируется

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