Как я написал Qt-приложение, почти не написав код

Всё началось с эксперимента. На основной работе руководство довольно настойчиво рекомендовало использовать ИИ в разработке. В какой-то момент мне стало интересно, насколько далеко можно зайти в этом направлении. Можно ли написать реальное десктопное приложение так, чтобы основную часть кода писал ИИ?

Не в смысле «иногда подсказать синтаксис» или «помочь найти ошибку». А именно в буквальном смысле — чтобы код писал ИИ, а человек формулировал задачи и проверял результат.

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

В итоге кандидатов оказалось два.

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

Задача инженерная и интересная.

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

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

Про саму голову я уже писал на Хабре:

https://habr.com/ru/articles/1007864/

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

При прослушивании такой записи в наушниках возникает довольно убедительный эффект пространственного присутствия.

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

Поэтому мысль написать отдельную программу под ПК выглядела вполне логичной — и я попробовал.

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

Задача формулировалась так: написать десктопное приложение на C++ с использованием Qt, которое собирается в Visual Studio 2022. Ничего экзотического — обычное Qt-приложение под Windows.

Я начал эксперимент с бесплатной версии чата и попросил её создать простой проект Qt под Visual Studio — не полноценную программу, а минимальный каркас приложения.

Но на этом месте эксперимент неожиданно застопорился.

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

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

На этом месте эксперимент практически закончился.

Но тут случился небольшой поворот сюжета: мне дали доступ к платной версии чата — и я решил попробовать ещё раз.

Попытка №2: начинаем писать приложение вместе с ИИ

Я начал с вопроса:

Я: Есть ли возможность написать приложение на C++ с использованием Qt и собирать его в Visual Studio 2022?

И какую модель GPT лучше использовать для такой задачи?

Ответ оказался ожидаемым: такую разработку сделать можно, и для неё лучше использовать более продвинутую модель.

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

Модель решила, что речь идёт не о модели GPT, а об архитектурной модели приложения — например MVC или MVVM.

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

С одной стороны, это выглядело забавно.

С другой — сразу показало важную вещь: при работе с ИИ очень многое зависит от точности формулировок.

Для начала я показал модели пример интерфейса. В качестве ориентира был выбран старый добрый Winamp — компактное приложение с меню и базовыми элементами управления.

На основе этого описания модель предложила минимальный каркас Qt-приложения: точку входа программы, класс главного окна и структуру проекта для Visual Studio.

Именно с этого момента эксперимент можно считать начавшимся по-настоящему.

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

Шаг за шагом из этого каркаса начало формироваться работающее приложение.

Генерация первого Qt-проекта

После обсуждения структуры приложения я попросил модель сгенерировать минимальный проект Qt, который можно было бы собрать в Visual Studio 2022.

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

Дальше началась самая интересная часть эксперимента.

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

В ответ был предложен набор кода для простого приложения с главным окном и меню. Интерфейс при этом создавался прямо в C++ коде.

Чуть позже в проекте появились .ui-файлы, но на первом этапе весь интерфейс описывался текстом. Это было осознанное решение: я не являюсь специалистом по разработке пользовательских интерфейсов и не был уверен, что смогу эффективно работать с Qt Designer.

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

После небольшой корректировки настроек проект действительно собрался в Visual Studio и запустился.

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

Сборка проекта: Qt, VisualStudio и немного реальности

ИИ генерировал C++-код Qt-приложения, но интеграцию с Visual Studio всё равно пришлось настраивать вручную. Нужно было проверить пути к библиотекам Qt, параметры проекта и несколько мелких вещей, которые обычно автоматически настраивает Qt Creator.

Отдельная особенность заключалась в том, что в проекте не использовался CMake.

Я работал с обычным решением Visual Studio (.sln) и файлами проекта (.vcxproj), поэтому все настройки вносились непосредственно в конфигурацию проекта.

После корректировки параметров сборки приложение удалось собрать и запустить в Visual Studio.

Это был важный момент эксперимента: стало понятно, что код, генерируемый моделью, можно интегрировать в обычный рабочий проект Visual Studio.

Полностью без ручной работы, конечно, не обошлось — но её оказалось немного.

Первый функционал: начинаем писать реальное приложение

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

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

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

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

В результате структура решения в Microsoft Visual Studio 2022 получилась простой: в .sln находилось два проекта (.vcxproj). Первый содержал библиотеку PortAudio, второй — код приложения. PortAudio оставался неизменным, а основной проект постепенно дополнялся новым кодом.

Дальше процесс разработки начал напоминать своеобразное парное программирование.

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

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

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

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

Когда код начинает жить своей жизнью

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

Рабочий процесс быстро сложился в характерный цикл:

• формулируется задача

• модель предлагает вариант реализации

• код добавляется в проект

• становится понятно, что нужно уточнить, поправить или изменить

• цикл повторяется

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

Модель предлагала стандартную для Qt схему через сигналы и слоты:

connect(ui->recordButton, &QPushButton::clicked,
this, &MainWindow::onRecordButtonClicked);

После чего добавлялся соответствующий обработчик:

void MainWindow::onRecordButtonClicked()
{
// логика обработки
}

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

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

Фактически модель выступала в роли разработчика, который отлично знает документацию и может быстро написать аккуратный код. Жаль только, что этот разработчик не может нажать Compile и увидеть красный экран ошибок.

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

Поэтому мои диалоги с моделью часто выглядели примерно так:
«Ты написал красиво, а я пойду ловить ошибки компиляции».

Иногда модель предлагала решение, которое выглядело корректным на первый взгляд, но в реальном проекте требовало доработки.

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

Бесплатная и платная версии: разница, которую сложно не заметить

Эксперимент с разработкой приложения начался с бесплатной версии чата. Логика была простой: если инструмент способен помогать писать код, он должен справиться хотя бы с созданием минимального проекта — стандартного набора файлов Qt под Visual Studio, с которого начинается почти любое приложение.

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

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

Ситуация изменилась после доступа к платной версии. Разница стала заметна сразу.

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

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

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

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

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

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

Как выглядел процесс разработки

После перехода на платную версию работа с ИИ стала реально продуктивной. Модель уверенно генерировала рабочие фрагменты кода для Qt: создание элементов интерфейса, подключение сигналов и слотов, обработчики событий, структура классов. Всё, что обычно приходится писать вручную или копировать из старых проектов, появлялось почти сразу.

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

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

Что показал эксперимент

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

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

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

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

В этом эксперименте я почти не писал код. Код писал ИИ.

Моя роль сместилась к формулированию задач, интеграции решений, тестированию и корректировке результата. Самая сложная часть работы — точная постановка задачи: если формулировка неточная или неполная, ИИ выдаёт код, который не соответствует ожиданиям.

Со временем стали очевидны и ограничения модели:

• разные имена для одних и тех же переменных или функций;

• повторное внесение исправлений, которые уже были сделаны;

• предложения, не совсем соответствующие исходному запросу.

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

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

В итоге ИИ написал не только код, но и помог собрать рабочее решение, готовое к использованию. Главный вывод эксперимента простой:

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

Стоит ли программистам волноваться?

После эксперимента естественно возникает вопрос: означает ли это, что профессия программиста постепенно исчезнет?

На мой взгляд — нет. Но роль разработчика действительно меняется.

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

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

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

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

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

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

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