О дивный новый код

Продолжение моей статьи Мечтают ли архитекторы об электроовцах? ^[1], в которой я обещал привести практический пример.

Резюме

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

Краткое описание сервиса

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

Сроки реализации

• Старт: 15 января 2026 года, задача взята в работу аналитиками.

• Начало реализации: 26 января 2026 года, задача взята в работу архитектором.

• Финал: 18 февраля 2026 года, успешные тесты и запуск в продакшн.

Итог: 5 рабочих недель или 26 рабочих дней от старта до финала.

Трудозатраты

• Бизнес-аналитик: 13 ч. или примерно 1,625 полных рабочих дней.

• Системный аналитик: 17 ч. или примерно 2,125 полных рабочих дней.

• Архитектор (ваш покорный слуга): 18 ч. или примерно 2,25 полных рабочих дней.

• LLM DeepSeek Reasoner: 2600 API calls, 117M tokens, $4.62 cost.

Итог: 48 ч или 6 раб. дней + $4.62 расходов на LLM.

Технический стек

• .NET 8 -> .NET 10

• Docker + GitLab CI

• Dapper + Microsoft.Data ^[2].SqlClient

• FluentFTP

• Quartz.NET ^[3]

• Polly

Фаза 0. Анализ и подготовка

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

1. Изучение бизнес-процессов: Понимание текущих бизнес-процессов и их сложности.

2. Анализ данных: Анализ данных, необходимых для решения задачи.

3. Определение требований: Определение конкретных требований и ограничений.

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

Фаза 1. Каркас и докеризация

Проводя анализ технического плана, выяснилось, что LLM расположила этап докеризации седьмым пунктом.
Поэтому я указал LLM начать реализовывать п.1 «Каркас» и п.7 «Докеризация».
Так как мне было важно, чтобы сервис изначально собирался и запускался в Docker.

Важно! Всегда проводите анализ того, что собирается сделать LLM!

Фаза 2. Core

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

• Simple HTTP API: health-check, status, version endpoints

• DB Layer

• XML Generation

• FTP Integration

• Job Scheduling

Плюс к этому был реализован базовый набор юнит-тестов.

На этой фазе сервис уже полноценно работал, успешно генерировал XML-файлы и отправлял их на FTP-сервер.
Поэтому я передал сервис аналитикам для тестирования и валидации XML-файлов.

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

Фаза 3. Интеграционные тесты

Во время тестирования аналитики выявили ошибки ^[4] в XML-файлах.
Мы начали изучать причины и выяснили:

1. Изначальные SQL-запросы были некорректными: при изменениях в основной системе продаж SQL-запрос не возвращал часть данных. То есть SQL-запросу нельзя было доверять. Задача вернулась аналитикам на доработку SQL-запросов.

2. Расхождение между данными в CSV-файлах и эталонными XML-файлами.

3. Лишние данные в XML-файлах.

Все эти проблемы были выявлены LLM, я лишь транслировал их аналитикам и обсуждал, как так получилось.
Если коротко, то это человеческий фактор.

Возникла потребность ^[5] в реализации интеграционных тестов. Этот пункт и так стоял в плане, но как обычно откладывался, чтобы быстрее выпустить продукт.

Идея очень простая: у нас есть эталонные XML-файлы и данные из CSV-файлов. Мы можем использовать данные из CSV-файлов для генерации XML-файлов и сравнивать их с эталонными XML-файлами.

После коррекций со стороны аналитиков я реализовал интеграционные тесты. В процессе реализации был исправлен ряд ошибок в коде с прошлых итераций.
И вновь сервис был передан на тестирование и валидацию аналитикам.

Фаза 4. Исправление багов

Естественно, были выявлены еще ошибки в XML-файлах. И вновь основной причиной были помарки в эталонных XML-файлах.
После их коррекции LLM легко исправляла проблемы.
Всего было найдено три бага:

• 1-й и 2-й баг были исправлены в течение 10 минут каждый.

• 3-й баг был более серьезным, ошибка была в бизнес-логике, на исправление было потрачено около 1 ч. Каюсь, это уже мой косяк, я сам не уловил, как должно быть, и так транслировал это LLM.

Опять человеческий фактор, а не LLM.

Ретроспектива

Давайте теперь пофантазируем на тему того, как было бы реализовано это без LLM.

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

Прогнозирование

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

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

1. Веб-приложение.

2. Консольное приложение, которое запускается планировщиком задач Windows (Task Scheduler).

Технические работы:

1. Описать контракты, приходящие из БД по каждому бизнес-сценарию.

2. Описать контракты для сохранения в файл.

3. Написать маппинг БД в файл.

4. Проверить скрипты, добавить хранимые процедуры в базу.

5. Добавить DAL (на Dapper будет быстрее всего).

6. Добавить выгрузку на FTP.

7. Мониторинг.

8. Логирование.

9. Метрики (по желанию).

10. Развертывание и проверки.

Итоговая оценка: 40 ч. + накладные расходы/погрешность.

Моя оценка этого плана: 50 ч.

Вероятный сценарий реализации программистом

Уверен, что стартовый сервис он бы реализовал за прогнозируемое время, т.е. за 40+ часов.

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

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

Итак, предполагаем следующие:

• Он бы понял, что проблема в SQL, за 8 ч. Пофиксили ее.

• Дальше понял бы, что есть расхождение между данными и эталонными XML-файлами за 8 ч.

• Обнаружил лишние данные в XML-файлах за 8 ч.

• Пофиксил бы 1-й и 2-й баг за 8 ч. Это те, которые LLM исправила за 10 минут.

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

Итог: 80+ часов!

Обращаю внимание ^[6], что интеграционных тестов в его плане нет.

Выводы

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

Дальше делайте выводы сами!

P.S.

Статья про фактическое использование LLM в реальной разработке ПО со статистикой, описанием проблем и т.д.

Программист с «лопатой» не сможет «копать» так же, как программист на «экскаваторе»!