Призрак в машине: почему ИИ умеет писать код, но проваливает документирование «институционального долга»

В соцсетях снова заговорили о том, что ИИ скоро заменит технических писателей. Автор из DEV Community убедительно объясняет, почему это не так — и почему ключевая проблема кроется в «институциональном долге», который алгоритмы не способны раскопать.

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

LinkedIn снова в эйфории

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

Проблема: код живёт не в вакууме

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

«Я задокументирую это на следующей неделе», — говорит разработчик. Но следующая неделя никогда не наступает.

Именно здесь появляется понятие Institutional Debt (институциональный долг) — он же Tribal Knowledge (племенное знание). Это массив неформализованной информации, который живёт только в головах людей: почему архитектура выглядит именно так, какие решения привели к текущему состоянию, какие ошибки были допущены и какие обходные пути придуманы.

Что умеет ИИ — и чего не умеет

Если загрузить в языковую модель «грязный» код, она без труда разберётся, что делает каждая функция. Она опишет переменные, объяснит логику, даже предложит рефакторинг. С синтаксисом проблем нет.

Но ИИ принципиально не может ответить на вопрос «почему».

Почему этот обходной путь появился три года назад? Потому что на том конкретном легаси-сервере есть баг, из-за которого API падает каждое воскресенье. Почему используется именно эта, а не более современная библиотека? Потому что предыдущая попытка миграции привела к катастрофическому сбою. Почему в коде стоит загадочный sleep(500)? Потому что без него вся система сыпется при определённой нагрузке.

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

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

Технический писатель — детектив, а не форматировщик

Здесь стоит развенчать ещё один миф. Технический писатель — это не человек, который красиво оформляет Markdown-файлы и знает грамматику английского языка. Это специалист, который работает с людьми, а не с документами.

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

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

ИИ не способен предотвратить эту «утечку мозгов». Человек — способен.

Практические последствия

Стоит задаться вопросом: что конкретно теряет компания, если заменит технического писателя на ИИ?

Краткосрочно — ничего. README сгенерирован, API-документация выглядит прилично, бюджет сэкономлен.

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

Долгосрочно — зависимость от конкретных людей, которые «помнят». Когда эти люди уходят, система становится чёрным ящиком.

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

Важная оговорка

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

Итог

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

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

Вопрос «заменит ли ИИ технических писателей» сформулирован неправильно. Правильный вопрос: готов ли ваш ИИ нести ответственность, когда продакшен упадёт из-за незадокументированного легаси-бага?