AI-код не враг: как отличить инженерию от мусора

Почему вопрос «AI или нет» разрушает сообщества разработчиков

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

Проблема фильтра «AI или нет»

Допустим, есть два проекта:

• Проект A: два года работы, переписан алгоритм, исправлены бенчмарки, активная поддержка.
• Проект B: промпт «сделай мне стриминг-приложение», код выплюнут без тестов, автор исчез.

Оба используют AI. Оба получают ярлык «AI-generated». И оба отклоняются. Разница между поддерживаемой инженерией и мусором стирается.

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

Что на самом деле скрывается за отторжением AI

Разберём аргументы против AI-кода:

• «Ты не делал» — игнорирует реальную техническую работу. Автор Open Vectorizer переписал пайплайн алгоритма, протестировал его, нашёл баг, который завышал его же бенчмарки, и опубликовал худшие результаты. Это не промпт в Claude.
• Безопасность — неверифицированный AI-код может содержать уязвимости. Но это причина проверять код, а не банить AI. Мы же не баним Rust за то, что он упрощает безопасность памяти, и не считаем все C-проекты небезопасными.
• Ностальгия — «раньше было лучше». Люди публиковали ужасный код и до AI, просто спам стал дешевле.

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

Сообщества разработчиков заливает мусором. Но это не AI-проекты как класс, а именно низкокачественные проекты. AI лишь удешевил их производство. Решение — не банить AI, а научиться отличать сигнал от шума.

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

• Может ли автор объяснить архитектуру? Или звучит как чтение Stack Overflow?
• Есть ли осмысленные тесты?
• Можно ли независимо воспроизвести результаты?
• Прозрачны ли бенчмарки? Раскрыты ли слабые места?
• Проверяет ли автор изменения и берёт ли ответственность?
• Будет ли проект поддерживаться через полгода?

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

Ирония судьбы: защита сообщества

В комментариях к статье Open Vectorizer один из разработчиков заметил: «Разработка ПО — это оркестровка, где конечная ценность — работающее, проверенное и протестированное ПО, а не время набора текста человеком». И добавил: «Пожалуйста, оставьте Dev.to безопасным местом для всех разработчиков». Это не защита AI в абстракции. Это защита сообществ, где можно делиться работой и получать фидбек, а не проходить тесты на чистоту по инструментам.

Автор, который на 99% использовал AI для игры в 3000 строк, работая полный день, заслуживает права поделиться проектом. Так же как и тот, кто использовал GitHub Copilot для рутинных завершений. Так же как и автор Open Vectorizer, который принимал архитектурные решения с помощью AI, но не выпустил бы то, что не может объяснить.

Историческая перспектива: абстракция — это нормально

Разработка ПО всегда шла по пути абстракции: от ассемблера к C, от ручного управления памятью к сборке мусора, от сырых SQL к ORM, от ручного написания Dockerfile к шаблонам. Каждый раз говорили, что разработчики ленятся и стандарты падают. Но настоящий вопрос всегда был не «какой уровень абстракции ты используешь?», а «понимаешь ли ты, что сгенерировано? Можешь ли защитить это? Будешь ли поддерживать?».

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

Как должна выглядеть хорошая модерация

Хорошая модерация не банит AI, а фильтрует по существу:

• Требовать раскрытия существенного использования AI (прозрачность важна).
• Оценивать проекты по воспроизводимости, покрытию тестами и ответственности мейнтейнера.
• Продвигать проекты с публичными бенчмарками и активным исправлением багов.
• Отсеивать мусор по отсутствию глубины, а не по происхождению.
• Создавать пространство для обучения, отфильтровывая низкокачественные републикации.

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

Сдвиг DEV в сторону требования раскрытия, а не запрета AI-контента — отличный шаг. Он возлагает ответственность на автора, а затем позволяет сообществу судить по реальной работе.

Что на самом деле имеет значение

Вопросы, которые отделяют хорошую инженерию от мусора, универсальны:

• Можете ли вы объяснить архитектурные решения?
• Что сломалось и как вы это исправили?
• Воспроизводимы ли бенчмарки?
• Будете ли вы поддерживать проект?
• Готовы ли вы к исправлениям?

Они работают независимо от того, написан код человеком, сгенерирован Claude или смешан. Потому что они про понимание и ответственность — то, что всегда определяло качество.

Практический вывод: что делать прямо сейчас

В следующий раз, когда увидите проект, помеченный как «AI-сгенерированный», не спешите с выводами. Откройте код, проверьте тесты, посмотрите на бенчмарки. Спросите автора об архитектуре. И только потом решайте, достоин ли проект внимания. И когда публикуете свой проект с AI-помощью, будьте прозрачны: напишите, что использовали, объясните свои решения, покажите тесты. Так вы поможете сообществу сосредоточиться на реальном качестве, а не на ярлыках.