Быть или казаться: как ИИ ломает культ «красивого текста» — и заставляет пересобрать систему оценки

На днях вышла интересная статья: Владимир Легойда пишет о текстоцентричности образования и науки — о том, что мы слишком часто принимаем написанный текст за цель и главный результат, а не за инструмент, который должен обслуживать понимание и личностный рост [1]. ИИ, по сути, стал не “виновником”, а прожектором: когда связный, убедительный, «как надо» текст можно получить почти мгновенно, выясняется, что часть наших процедур проверяет не знание и не зрелость мышления, а умение соответствовать формату [1].

Но если остановиться на уровне “школа и сочинение”, мы пропустим масштаб. Потому что это уже не разговор про грамотность. Это разговор про технологическую революцию, в которой текст превращается в универсальный интерфейс труда. LLM — это машина, которая умеет читать и писать то, чем живут институты: заявки, отчёты, заключения, регламенты, письма, договоры, презентации… и да — код. Так возникает эффект домино: там, где профессия исторически была текстоцентричной, “писательство” дешевеет; дорогими становятся замысел, постановка задачи, проверяемость и ответственность.

если завтра “идеальный текст” станет нормой, что именно будет считаться компетенцией — стиль или смысл?


1) Текстоцентричность была симптомом, ИИ стал проявителем

Мы привыкли мыслить так: написанный текст — это доказательство того, что человек проделал внутреннюю работу. В эпоху, когда текст “стоил труда”, это часто было справедливо. Легойда аккуратно показывает, что система зашла в опасную точку: текст стал KPI, экзамен стал единственным итогом, а проверка всё чаще сводится к тому, насколько результат похож на ожидаемый образец [1]. ИИ просто сделал эту подмену массовой и дешёвой: теперь “правильность” можно сымитировать без прохождения пути.

Есть соблазн ответить запретами, но запреты редко лечат мотивационную механику. Если система вознаграждает форму, рынок будет поставлять форму — сначала руками репетиторов и “помощников”, потом руками нейросетей. Выход, кажется, в другом: возвращать в оценку не только продукт, но и процесс; усиливать живой контур проверки понимания; задавать вопросы, на которые нельзя ответить “красивым текстом” — потому что на них нужно отвечать опытом мышления [1].

вы оцениваете того, кто понял, или того, кто научился выглядеть понимающим?


2) Текст как универсальный API: революция шире образования

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

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


3) Программирование — тоже текстоцентричная профессия: строки дешевеют, смысл дорожает

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

Это ощущение совсем не новое. Ещё в 1980-х Фредерик Брукс сформулировал идею, которая сегодня звучит почти как инструкция к эпохе LLM: удешевление инструментов и “механики” не убирает сущностную сложность — саму концептуальную конструкцию того, что мы строим [2]. Иными словами, если машина делает “написание” быстрее, то остаётся то, что не исчезает от автоматизации: понимание предметной области, системные связи, архитектурные ограничения, риски, критерии приёмки.

Параллельно звучит и другой, более прикладной тезис: если требования неправильны, то никакой “идеальный код” не спасёт — получится идеально реализованный продукт, который не нужен или опасен [3]. ИИ как раз ускоряет этот сценарий: быстрее пишем, быстрее ошибаемся, быстрее масштабируем ошибку.

вы принимаете разработку потому, что “код выглядит хорошо”, или потому, что понимаете — как именно система доказывает свою правильность?


4) “Правильно захотеть” становится дороже, чем “правильно написать”

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

В литературе по требованиям это формулируется предельно прямолинейно: неверные требования приводят к неверному ПО, и никакие усилия разработки не исправят исходную ошибку [3]. ИИ здесь — ускоритель. Он не заменяет работу по смыслу; он ускоряет движение по траектории, которую вы ему задали.


5) “Английский — язык программирования”: естественный язык становится средой производства

Андрей Карпаты бросил фразу, которую многие сперва приняли как шутку: “самый горячий новый язык программирования — английский” [4]. Но это не про то, что “теперь программисты не нужны”. Это про то, что меняется интерфейс: намерение всё чаще задаётся естественным языком, а формальный артефакт появляется через генерацию.

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


6) “Vibe coding”: соблазн скорости и неизбежность проверки

Карпаты ввёл термин “vibe coding”, описывая подход, при котором человек задаёт направление, а код рождается в диалоге с моделью — иногда так, будто “кода почти нет” [6]. Это мощно для прототипов, демо, быстрых черновиков. Проблема начинается там, где прототип без пересборки внезапно становится продакшеном — и тогда “казаться работающим” легко побеждает “быть надёжным”.

Саймон Уиллиссон, комментируя этот тренд, настаивает на простом и взрослым принципе: скорость генерации ничего не стоит без дисциплины проверки; там, где ставки высоки, нельзя подменять инженерный процесс ощущением “вроде получилось” [7], [8]. И это снова возвращает нас к ключевому слову эпохи: verifiability — проверяемость.

вы хотите ускорить производство кода или ускорить производство доверия к тому, что система действительно делает то, что заявлено?


7) “Software 2.0”: от кода-как-текста к поведению-как-объекту контроля

В эссе “Software 2.0” Карпаты описывает более глубокий поворот: часть “софтверности” переезжает из ручного кода в модели, данные и обучаемое поведение [5]. Это важно не только для ML-команд. Это меняет сам объект контроля. Раньше мы контролировали текст кода, теперь всё чаще обязаны контролировать поведение системы — то, как она реагирует на мир, и как мы это поведение тестируем и ограничиваем.

И снова всплывает базовый выбор: либо мы строим контуры контроля (тесты, наблюдаемость, ограничения, аудит), либо получаем институциональную симуляцию — уверенные ответы без основания и “магическое” поведение без объяснимости.


8) Это уже не теория: крупнейшие компании фиксируют долю AI-кода

Скептик скажет: “это разговоры”. Но разговоры уже подкрепляются практикой. Сатья Наделла публично говорил, что заметная доля кода в Microsoft генерируется ИИ (в оценках звучали уровни порядка 20–30% в зависимости от языка) [9]. CTO Microsoft Кевин Скотт в интервью обсуждал траекторию, где генерация кода ИИ может стать доминирующей, подчёркивая при этом: это меняет роль разработчика, а не отменяет ответственность инженерии [10].

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


9) “Язык программирования — human”: демократизация и рост цены ошибок

Дженсен Хуанг формулирует этот же сдвиг максимально просто: программирование становится похожим на то, как вы объясняете задачу человеку; “human” превращается в язык взаимодействия [11]. Это делает технологии доступнее, но одновременно расширяет зону риска: если создавать может больше людей, то больше людей будет создавать и ошибки — часто уверенно, красиво и убедительно.

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


10) Проверяемость как главная валюта эпохи

Уиллиссон, обсуждая новую волну “coding with LLM”, постоянно возвращается к тому, что в центре должна быть проверяемость и воспроизводимость: важно не то, насколько уверенно текст звучит, а то, насколько можно убедиться, что система делает правильное [8], [12]. Это — лучшая связка с исходным тезисом Легойды: пока мы оцениваем оболочку, мы производим оболочку; когда оболочка стала бесплатной, остаётся только то, что связано с реальностью и ответственностью.


11) Наша редакционная линия: декларативная этика ИИ и раскрытие “промт-проекта” в чувствительных случаях

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

Мы уже писали об этом на примере права: когда текст начинает подменять человеческое усмотрение, критически важно фиксировать след происхождения решений — версии, контекст, промпты, правки, чтобы было понятно, где заканчивается машинная оболочка и где начинается ответственность человека [13]. И мы же писали шире о превращении ИИ в инфраструктуру: там, где ставки высоки, прозрачность должна быть процедурой, а не моральной просьбой [14].

Отсюда и идея “этики декларативного использования ИИ”: в повседневных случаях достаточно честной маркировки уровня участия ИИ; в чувствительных случаях — должна существовать процедура раскрытия “промт-проекта” (не обязательно публично, но для аудита, комиссии или спора), иначе институты будут жить на симуляции и терять способность отличать “быть” от “казаться”.

где в вашей сфере проходит граница, после которой “помощь ИИ” превращается в риск, требующий прозрачности?


12) Финал: эпоха текста заканчивается — эпоха ответственности начинается

Легойда начинает с образования — и это точка входа [1]. Но сама революция шире: мы видим, как один технологический слой делает дешёвой ту часть труда, которая десятилетиями считалась “профессиональной ценностью” просто потому, что требовала времени и навыка письма. Теперь текст — универсальный интерфейс; следовательно, текстоцентричные профессии первыми ощущают сдвиг.

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


Источники

[1] Владимир Легойда — «Образование после текста, или текстоцентричность как проблема» (Радонеж): https://radonezh.ru/2026/02/25/vladimir-legoyda-obrazovanie-posle-teksta-ili-tekstocentrichnost-kak-problema
[2] Frederick P. Brooks Jr. — No Silver Bullet (UNC tech report, PDF): https://www.cs.unc.edu/techreports/86-020.pdf
[3] Linda Westfall — The Why, What, Who, When and How of Software Requirements (PDF): https://ima.udg.edu/~sellares/EINF-ES2/The_Why_What_Who_When_and_How_Of_Software_Requirements.pdf
[4] Andrej Karpathy — пост “The hottest new programming language is English” (X): https://x.com/karpathy/status/1617979122625712128
[5] Andrej Karpathy — Software 2.0 (Medium): https://karpathy.medium.com/software-2-0-a64152b37c35
[6] Andrej Karpathy — пост про “vibe coding” (X): https://x.com/karpathy/status/1886192184808149383
[7] Simon Willison — заметка/разбор про “vibe coding” (1): https://simonwillison.net/2025/Mar/19/vibe-coding/
[8] Simon Willison — заметка/разбор про “vibe coding” (2): https://simonwillison.net/2025/Mar/6/vibe-coding/
[9] TechCrunch — цитата Сатьи Наделлы о доле AI-кода в Microsoft: https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-30-of-the-companys-code-was-written-by-ai/
[10] Business Insider — позиция CTO Microsoft Кевина Скотта про AI-генерацию кода: https://www.businessinsider.com/microsoft-cto-ai-generated-code-software-developer-job-change-2025-4
[11] Business Insider — тезисы Дженсена Хуанга (NVIDIA) о программировании через natural language: https://www.businessinsider.com/nvidia-ceo-jensen-huang-ai-prompts-human-lets-anyone-program-2025-6
[12] Simon Willison — материалы по теме Andrej Karpathy (теги/подборка): https://simonwillison.net/tags/andrej-karpathy/
[13] Info-Front — «Приговор по промпту: когда язык подменяет ответственность» (про аудит-след и ответственность): https://www.info-front.ru/prigovor-po-promptu-kogda-iazyk-podm/
[14] Info-Front — «AI Journey 2025» (про ИИ как инфраструктуру и нормы прозрачности): https://www.info-front.ru/ai-journey-2025/

Оставьте комментарий

Прокрутить вверх