Разработка без IDE с Qwen: как устроен эксперимент со сканером NTFS-потоков

Редакция APICODIK · 31.10.2026

Разбираем опыт создания приложения на Rust и Avalonia с помощью Qwen: от технического задания до исправления сборки и границ проверки кода агентами.

Разработка без IDE — не обязательно разработка без участия программиста. В эксперименте, который автор BlackEric001 описал на Хабре, человек выбирал архитектуру, обсуждал требования с моделью, передавал задания агенту и проверял приложение. Генерацию кода выполнял Qwen Coder, а подготовку спецификаций и промежуточную оценку результата автор поручил диалоговой модели Qwen.

Задача была предметной: создать приложение для работы с альтернативными потоками данных NTFS, разделив его на ядро на Rust и графический интерфейс на Avalonia. По рассказу автора, на программирование и общение с моделями ушло около четырёх часов. Это приблизительная оценка: время он специально не замерял.

Что должно было делать приложение

Альтернативные потоки данных, или ADS, позволяют связывать с файлом NTFS дополнительные именованные потоки помимо его обычного содержимого. В статье приведён пример адресации: file.txt:streamname:$DATA. При записи в такой поток размер основного содержимого, отображаемый Проводником Windows, не меняется, а наличие дополнительных потоков Проводник не показывает.

Это не только способ хранить незаметные при обычном просмотре данные. Среди штатных применений автор называет метки безопасности Windows: например, поток Zone.Identifier, связанный с отметкой происхождения скачанного файла — Mark of the Web. Поэтому инструмент для просмотра ADS имеет понятную практическую задачу: показывать данные, которые пользователь не видит в привычном представлении файла.

В исходном запросе автор хотел получить сканирование дисков, каталогов и отдельных файлов, просмотр и выгрузку содержимого потоков, а также операции их создания, загрузки данных и удаления. Поддержка требовалась для Windows и Linux, причём в Linux нужно было учитывать работу через ntfs3 и ntfs-3g. Это перечень требований, а не подтверждение того, что каждый сценарий впоследствии был проверен.

Сначала архитектура и спецификация

Автор предложил отделить работу с файловой системой от интерфейса: модуль на Rust должен предоставлять API, которым пользуется GUI. Такая граница была частью исходной постановки задачи, а не результатом самостоятельного проектирования агента.

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

Следующим результатом обсуждения стал не код, а техническое задание для ядра. Автор сохранил его в SPEC.md и добавил в репозиторий вместе с начальной структурой каталогов. После этого Qwen Coder получил доступ к репозиторию и короткое поручение реализовать приложение по спецификации.

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

Генерация кода потребовала исправлений

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

Для графической части процесс повторился. Сначала в диалоге с Qwen было подготовлено отдельное задание, сохранённое в docs/GUI.md, затем агенту поручили реализовать интерфейс на Avalonia. Первая версия снова не собиралась.

Здесь обнаружилось важное различие условий: агент проверял результат в доступной ему Linux-среде, а автор — в Windows 10. После сообщения о проблеме агент внёс исправления. Получившийся интерфейс автор оценил как простой, но пригодный для дальнейшей работы. После небольшого тестирования он также запросил журналирование и отдельное окно для вывода логов.

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

Что означает проверка другой моделью

После этапов разработки автор просил диалоговую Qwen оценить результат. По его рассказу, она не находила проблем и предлагала двигаться дальше. Все pull request от Qwen Coder он принимал без ручных правок.

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

Без IDE — не без инженерной работы

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

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

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