Весной 2025 года Anthropic выпустил Claude Code, и разработчик Александр, 12 лет проработавший с Go, решил доверить написание кода ИИ-агентам. С мая 2025 года он в одиночку ведёт закрытый финтех-продукт, а с февраля 2026 — ещё и платёжный проект. Спустя 15 месяцев он заявляет: его собственный код больше не проходит ту планку качества, которую он выставил для агентов. В подтверждение он приводит график, где красная пунктирная линия — уровень его лучшего рукописного кода, а синяя кривая — код агентов. В апреле 2026 синяя кривая ушла под красную и продолжает падать.
Первые месяцы работы с агентами оказались хаотичными. К осени 2025 года кодовая база разрослась до 224 тысяч строк, значительная часть которых была дублями, брошенными ветками и забытыми экспериментами. На срезе октября 2025 года 105 пакетов проекта не проходили проверку типов. Александр коммитил часто, чтобы не терять изменения, и код двигался быстрее, чем сходилась сборка. Обычные линтеры — go vet, staticcheck, golangci-lint — он подключил почти сразу, но они ловили лишь половину проблем. Они рассчитаны на ошибки людей, а нейронка совершала другие: из-за короткого контекста модель не помнила, что делала 15 минут назад, отсюда бесконечные дубли, галлюцинации и ненужные ветки.
| Период | Событие |
|---|---|
| Весна 2025 | Выход Claude Code, начало работы с ИИ-агентами |
| Осень 2025 | Кодовая база 224К строк, 105 пакетов с ошибками типов |
| Январь 2026 | 50 анализаторов, создание glint, чистка 140К строк |
| Февраль 2026 | Добавлен второй проект, платёжный |
| Апрель 2026 | Кривая качества агентов уходит под уровень рукописного кода |
| Июль 2026 | Добавлены десятки доменных правил |
Самый опасный для финтеха класс ошибок — маскировка непонимания. Модель, не разобравшись в ситуации, могла тихо вернуть правдоподобное значение вместо ошибки: пустую структуру, false из функции, которая вовсе не предикат, или сконструированный объект с nil-зависимостью внутри. Под этот класс Александр разработал группу проверок: error-masking, fallback-return, log-and-return-zero, empty-struct-return, constructor-swallows-nil-dep. Ни одна из них не нужна против человека — люди так не ошибаются, а против агентов они работают до сих пор.
К осени 2025 кодовая база разрослась до 224К строк, 105 пакетов не проходили проверку типов, после чистки ушло 140К строк мёртвого кода.
Схема была простой: заметил класс проблем — пишу анализатор. К январю 2026 года в проекте накопилось 50 таких анализаторов. Тогда Александр решил вынести их в отдельный инструмент и применять ко всем своим проектам, включая его самого. За день появился каркас с первым десятком правил, через неделю один коммит удалил все 50 проектных анализаторов. Универсальные правила ушли в общий линтер, который он назвал glint, открыл под лицензией MIT. Продуктовая специфика осталась в отдельном проектном наборе. Тогда же за две недели из проекта ушло 140 тысяч строк мёртвого кода, дублей и протухших инструментов — на графике это первый обрыв.
Цикл улучшения качества замкнулся: Александр получает репорт о баге, агент исследует причину, затем он даёт задачу найти подобные случаи по всему коду. По результатам решается, можно ли сформулировать правило. Правило гоняется по кодовой базе и нередко вскрывает ещё несколько скрытых случаев. Модель находит баги, пишет правило, сама читает выхлоп и дотачивает его. Участие человека сводится к паре решений.
Пример доменного правила, которое невозможно положить в универсальный линтер: в платёжном проекте проверяется, что команда платёжному провайдеру не уходит раньше, чем в собственном хранилище появилась durable-запись о намерении её отправить. Если процесс упадёт между отправкой денег и записью, деньги уйдут без следа. Оба вызова по отдельности корректны, типы сходятся, ошибки обработаны. Дефект — в их порядке. Чтобы это поймать, нужно знать, как в конкретном проекте называются провайдеры и хранилища и что вызов SendPayout не откатывается defer-ом. Это знание предметной области, и оно не может оказаться в staticcheck по построению. Таких доменных правил за июль добавилось несколько десятков, тремя волнами.
Для оценки всей истории проекта Александр применил методику: срезы каждые две недели через всю git-историю, на каждом срезе прогон сегодняшним набором правил, полным, без единого проектного исключения. Один и тот же прибор на все точки, заведомо строже того, что существовало тогда. Тяжёлыми датами стали первые месяцы, когда кодовая база была замусорена, но постепенно кривая качества выправилась. Сейчас в проекте только один пакет не проходит проверку типов, и все коммиты собираются.
История Александра показательна для всей индустрии: ИИ-агенты способны писать код, но требуют новых инструментов контроля. Обычные линтеры, созданные для людей, не покрывают специфические ошибки моделей. Открытый glint — попытка заполнить этот пробел, и любой разработчик может построить свою кривую качества, используя его.

