Как думать, когда код пишет ИИ

AI Toolsmith. Разработчик DSL и «обёрток» для агентов внутри компании. Создатель внутренних инструментов для других разработчиков.

Responsible AI Deployer. Специалист по «последней миле» кода: проверка на compliance, безопасность, отсутствие предвзятости.

4. График: «Зависимость зарплаты от процента рукописного кода в проекте» (Обратная корреляция).

Мы представим провокационную иллюстрацию, которая заставит читателя замереть.

Ось X: Процент написанного вручную (от руки) production-кода в проекте.

Ось Y: Ценность разработчика на рынке труда (ЗП + востребованность).

Точка A (90% ручного кода): «Я всё пишу сам на Vanilla JS». Зарплата — нижний квартиль рынка. Продуктивность низкая, оверхеды огромные.

Точка B (50% ручного кода): Тревожная зона. Разработчик автоматизирует часть, но не доверяет ИИ, постоянно переписывая за ним. Стоимость растет, но медленно.

Точка C (5% ручного кода): Пик ценности. Это ключевые модули: ядро системы, уникальные алгоритмы, критичные компоненты безопасности и те самые интеграционные склейки. Всё остальное сгенерировано и верифицировано под его руководством.

Точка D (0% ручного кода): Опасное падение (менеджер, только пишущий промпты и не способный проревьюить результат). Ценность снова стремится вниз, так как отсутствует навык контроля качества.

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

1.4. Деконструкция страха: что на самом деле скрывается за «ИИ меня уволит»

Аннотация (Полная версия):

Это сеанс психоаналитики профессионального сообщества, приглашение заглянуть в собственное нутро. Массовая истерия вокруг «ИИ отнимет работу» — это, как правило, не рациональный анализ рынка труда, а проекция внутреннего конфликта. Страх увольнения редко связан с реальной угрозой голодной смерти. Чаще это ужас перед потерей идентичности «крутого кодера», на которую ушли годы жизни, или кошмар разоблачения «самозванца» (Impostor Syndrome), который годами выезжал на знании синтаксиса и StackOverflow, а не на инженерном мышлении. ИИ не увольняет человека — он срывает с него маску, показывая, чем он является на самом деле: механическим транслятором требований в синтаксис или творцом, решающим проблемы. Глава предлагает пройти через пять стадий принятия неизбежного по модели Кюблер-Росс, чтобы выйти из них не выжившим, а усилившимся.

Мы начнём с провокации: «Если вы боитесь, что вас заменит машина — возможно, вы и были машиной». Это задаст тон беспощадной, но освобождающей честности.

1. Пять стадий принятия ИИ по Кюблер-Росс (Разбор сообщества).

Мы пройдём по каждой стадии, показывая её типичные проявления в профессиональных спорах, и дадим «диагноз», какая часть личности страдает на этом этапе.

Стадия 1: Отрицание. «Он пишет чушь / Он не сможет написать МОЙ код».

Типичное высказывание: «Я попробовал ChatGPT — он сгенерировал ерунду с несуществующим API. Это игрушка для студентов, мой проект слишком сложен для него».

Что на самом деле происходит: Защитный механизм. Разработчик оценивает модель по её текущему срезу (сегодняшнему уровню), отказываясь экстраполировать кривую роста. Это как говорить в 1905 году: «Автомобиль — это игрушка для богатых, он сломался через 5 миль, лошадь надёжнее».

Теневая сторона: Страх утраты монополии на знание. «Если эту сложную штуку можно сгенерировать, то чем я лучше других?»

Стадия 2: Гнев. «Это воровство! Они просто скопипастили код с GitHub!».

Типичное высказывание: «Это не интеллект, а плагиат! Модель обучили на моём опенсорсе и теперь продают, а я должен остаться без работы?».

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

Теневая сторона: Чувство несправедливости не от того, что у человека что-то отняли, а от того, что его сверхспособность (помнить и комбинировать паттерны) обесценили так быстро и нагло.

Стадия 3: Торг. «Я буду использовать, но только как автодополнение / умный гугл».

Типичное высказывание: «Copilot — это удобно, он как продвинутый автокомплит. Но архитектуру и главное я всегда пишу сам. Я контролирую процесс».

Что на самом деле происходит: Самая коварная и залипательная стадия. Разработчик признаёт инструмент, но низводит его до подчинённой роли, чтобы сохранить свою главенствующую идентичность «творца». Это самообман, позволяющий оттянуть перестройку мышления. Это как использовать смартфон только для звонков, отказываясь от интернета.

Теневая сторона: Страх потери контроля и авторства. «Если я не написал эту функцию ручками, я не могу ей гордиться и не чувствую, что это моё».

Стадия 4: Депрессия. «Нас всех заменят. Учить что-либо бессмысленно».

Типичное высказывание: «Джуниоров больше не наймут. Сеньоры через 5 лет станут никому не нужны. Это конец профессии».

Что на самом деле происходит: Крах гедонистической адаптации. Человек искренне наслаждался процессом написания кода (ремеслом), а не только результатом. Осознание, что эта часть уйдёт, вызывает горевание. Это реальная потеря, и её нужно оплакать, а не обесценивать. Мы нормализуем эту печаль: да, мы потеряем радость «набивания» идеального класса ручками, как гончар потерял радость ручной лепки горшков, когда появился круг.

Теневая сторона: Выученная беспомощность, маскирующая нежелание переучиваться под благовидным предлогом «всё равно конец».

Стадия 5: Принятие. «Я — визионер, а не клавиатурный тигр».

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

Что на самом деле происходит: Трансформация идентичности. Разработчик перестаёт измерять свою ценность в килобайтах написанного кода. Он начинает измерять её в килобайтах не написанного кода (сложности, которой удалось избежать) и в качестве решённых бизнес-проблем. Метафора: он перестал быть каменщиком и стал архитектором, который ещё и проверяет качество кладки, не брезгуя мастерком при необходимости.

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

2. Практический тест для самодиагностики: «Кто вы на самом деле?»

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

Дилемма 1 (Гордость): «Вспомните свой лучший рабочий момент за последний месяц. Что вызвало у вас большую гордость: а) красивое применение хитрого алгоритма, который вы написали в 3 часа ночи, или б) архитектурное решение, которое позволило выкинуть 5000 строк старого легаси-кода и упростило жизнь трём командам?»

Интерпретация: Вариант «а» — риск «синдрома ремесленника». Вариант «б» — мышление Архитектора Намерений.

Дилемма 2 (Угроза): «Представьте, что вышел приказ: весь код в проекте с завтрашнего дня пишут ИИ-агенты. Ваша роль — только проверять, задавать вопросы и описывать желаемое поведение. Что вы чувствуете? а) "Меня лишили главного удовольствия и моей сути", б) "Ну наконец-то я смогу заняться тем, до чего вечно не доходили руки — системным анализом и улучшением архитектуры"».

Интерпретация: Это тест на готовность к Стадии 5.

Дилемма 3 (Обучение): «Вам нужно освоить новую предметную область (например, логистику). Вы: а) идёте читать документацию фреймворков и API, которые используются в логистических системах, или б) идёте говорить с логистами, читать учебник по управлению цепочками поставок и рисовать схему процессов?»

Интерпретация: Вариант «а» — фокус на «токенизируемую» ценность. Вариант «б» — движение в сторону Глубины (Ось X из Главы 1.3).

3. Рефрейминг страха: от паралича к действию.

Заключительная часть раздела превратит выявленный страх в топливо.

Страх как компас: Ваш страх указывает на то, какая часть вашей нынешней работы является механической и уязвимой. Боитесь, что ИИ напишет этот модуль? Значит, этот модуль — boilerplate. Не боитесь за архитектуру? Значит, вы чувствуете в себе «нетокенизируемую» ценность.

Упражнение: Возьмите список своих еженедельных задач. Напротив каждой поставьте маркер: «Страх, что это сделает ИИ» (шкала 1-5). Задачи с рейтингом 4-5 — это ваш план немедленного апгрейда навыков. Их нужно передать ИИ первыми, чтобы освободить себя. Задачи с рейтингом 1 — это ваша будущая специализация, которую нужно углублять.

Итоговый вывод подраздела: ИИ не увольняет человека. Он просто делает экономически невыгодным заниматься тем, что не требует человечности. Кризис, вызванный LLM, — это не кризис безработицы, это кризис идентичности. И в отличие от экономического, этот кризис решается не поиском новой работы, а поиском нового себя. Пройдя пять стадий, мы выходим не просто «принявшими неизбежное», а впервые за долгое время — настоящими.

Глава 2. Архитектор намерений вместо наборщика текста.

2.1. Новый центр тяжести: смещение от «Как написать» к «Что заставить сделать».

Это фундаментальный когнитивный сдвиг, без которого все остальные навыки книги не работают. Речь идёт о переходе от императивного мышления (пошаговые инструкции: создай переменную, пройдись циклом, вызови метод) к декларативному (описание желаемого результата и системы ограничений, в рамках которых этот результат должен быть достигнут). Это не просто «написание хороших промптов» — это смена операционной системы мозга. Императивное мышление предполагает, что мы контролируем процесс. Декларативное — что мы контролируем результат, делегируя процесс недетерминированному агенту. Главный вызов здесь — не технический, а психологический: как управлять ожиданиями от системы, которая может решить задачу не так, как вы себе представляли, но при этом формально правильно. Глава учит «дирижировать» оркестром, а не играть за каждую скрипку.

Мы откроем раздел яркой метафорой, которая станет сквозной для всей книги.

1. Два образа: Композитор против Дирижёра.

Мы детально разберём две роли, чтобы читатель мог физически ощутить разницу между старым и новым мышлением.

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

Теперь образ будущего — Разработчик как Дирижёр. Это целевая модель. Дирижёр не играет ни на одном инструменте. У него есть партитура — Спецификация, — но он управляет интерпретацией. Он задаёт темп, то есть скорость разработки и деплоя. Он регулирует громкость — приоритеты фич. Он указывает вступление партий — очерёдность реализации модулей. Он слышит, когда скрипки фальшивят — это баг, — и останавливает оркестр, чтобы поправить общее звучание, а не перебирать струны за музыканта. Его мышление декларативное, управляющее ожиданиями: «Я знаю, что должно прозвучать в этом месте, и я опишу это словами. Как именно скрипач это сыграет — его мастерство, пока оно служит общему звучанию». Ключевой навык дирижёра — слышать целое, а не отдельные партии; управлять не кодом, а поведением системы.

Теперь проведём прямое сравнение этих двух моделей по ключевым критериям.

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

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

Критерий третий — точка контроля. Композитор контролирует процесс — «как именно делается работа». Дирижёр контролирует результат — «что именно должно быть сделано».

Критерий четвёртый — общение с ИИ. Композитор говорит: «Напиши функцию, которая принимает A и возвращает B, проходя циклом по C». Он продолжает программировать, просто на естественном языке. Дирижёр говорит: «Мне нужен компонент, который гарантирует, что при любых входных данных X, состояние системы Y останется неизменным. Опиши, как ты это обеспечишь, а потом реализуй». Он ставит задачу и требует обоснования.

Критерий пятый, самый важный — главный страх. Композитор боится: «Я не знаю, как это написать». Его тревога живёт в пространстве синтаксиса и алгоритмов. Дирижёр боится другого: «Я не могу точно описать, что мне нужно». Его тревога сместилась в пространство спецификации и коммуникации. И это — продуктивный страх, потому что он ведёт к росту, а не к параличу.

2. Практикум: Переписываем сложную бизнес-логику декларативно.

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

Шаг 1. Императивный подход — как мы привыкли думать.

Сначала мы моделируем типичный мыслительный процесс разработчика старой школы. Он звучит примерно так: «Создам таблицу Rooms, таблицу Bookings. В Bookings будет start_time, end_time, room_id, user_id. Потом напишу сервис, который перед созданием бронирования проверяет: а нет ли уже записей, где room_id равен нужному, и интервал времени пересекается? Если есть — возвращаю ошибку. Если нет — создаю запись. О, и ещё надо учесть часовые пояса. И сделать cron-задачу, которая снимает просроченные брони. И админку, чтобы админ мог удалять чужие бронирования...»

Заметим, что происходит в этот момент. Разработчик сразу проваливается в реализацию. Он думает таблицами, запросами, cron-задачами. Бизнес-правила уже искажены техническими деталями: он уже решил, что это будет реляционная база, хотя задача этого не требует; он уже думает о часовых поясах, которые не упоминались в требованиях; он смешивает бизнес-логику и инфраструктурные заботы. Самое страшное — он уже спроектировал систему, не осознав этого. Архитектурные решения приняты на автомате.

Шаг 2. Декларативная трансформация — выделяем сущности и правила.

Теперь мы говорим: «Стоп. Забудем про базу данных. Забудем про код. Что мы знаем о реальном мире переговорок?» И начинаем выписывать декларативные утверждения.

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

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

Третье — переходы состояний. Бронирование создаётся пользователем и переходит в статус «Активно». Бронирование может быть отменено автором или администратором и переходит в статус «Отменено». Бронирование автоматически переходит в статус «Завершено» по истечении времени.

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

Обратите внимание: здесь нет ни слова про SQL, REST, JSON или Docker. Это чистая модель предметной области, очищенная от технологического шума. И именно это — новый центр тяжести работы разработчика.

Шаг 3. Формируем промпт и управляем результатом.

Только теперь мы идём к ИИ-модели. Но не с командой «напиши мне API», а с декларативной спецификацией.

Наш промпт будет выглядеть примерно так: «Я проектирую систему бронирования переговорных комнат. Вот мои ограничения и инварианты. Контекст: офис с множеством комнат, пользователи бронируют слоты. Предложи три разных архитектурных подхода к реализации: первый — классический монолит с реляционной базой, второй — event-driven архитектура, третий — минималистичное решение на ключ-значение хранилище. Для каждого опиши: как он обеспечивает инвариант непересечения броней, как он масштабируется, какие у него риски. Пока не пиши код, только дизайн».

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

После выбора подхода мы даём следующий промпт: «Реализуй решение по архитектуре №2. Но сначала напиши юнит-тесты, которые проверяют инвариант непересечения броней. Тесты должны покрывать: две брони на одно время — отклонено; бронь с началом позже конца — отклонено; бронь, примыкающая к существующей вплотную — разрешено. Когда тесты будут готовы, напиши код, который их проходит».

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

Итоговый вывод подраздела: Новый центр тяжести — это не технический навык, а точка приложения внимания. Императивный разработчик спрашивает: «Как мне описать процесс, чтобы машина его исполнила?» Декларативный разработчик спрашивает: «Как мне описать результат и ограничения, чтобы машина не смогла ошибиться, даже если найдёт неожиданный путь?» Первый вопрос ведёт к контролю над кодом. Второй — к контролю над системой. Разница между ними и есть разница между тем, кого ИИ заменит, и тем, кого ИИ сделает невероятно востребованным.

2.2. Определение новой должности: кто такой разработчик промптов на уровне Senior и Staff

Это развенчание опасного и унизительного мифа, который уже укоренился в индустрии. Миф звучит так: «Промпт-инженер — это junior, который просто пишет "ты — эксперт" и подбирает волшебные слова, и эту роль автоматизируют через полгода». Этот взгляд безнадёжно плоский. Он путает оператора чата с архитектором лингвистических интерфейсов. Настоящий Senior и Staff в этой парадигме — это не человек, который лучше всех формулирует запросы. Это человек, который проектирует системы общения с моделями: создаёт DSL для домена, выстраивает конвейеры верификации, управляет контекстной памятью агентов и оркестрирует ансамбли моделей. Он проектирует не промпт — он проектирует «промпт-программу» (Prompt Program) со своей логикой ветвления, циклами и утверждениями, где каждый отдельный промпт — лишь атомарная инструкция в большой архитектуре. Глава даёт профессиограмму трёх уровней и детальный разбор того, чем на самом деле занят Staff Prompt Architect.

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

1. Профессиограмма: три уровня зрелости новой роли.

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

Уровень 1. Junior Prompt Engineer: «Оператор фактов».

Это входная точка, которую многие ошибочно принимают за всю профессию. Такой специалист решает атомарные задачи: «напиши функцию валидации email», «переведи этот JSON в XML», «объясни, что делает этот код». Его главный навык — чёткая формулировка запроса и умение итеративно уточнять результат: «нет, сделай без регулярок», «добавь обработку ошибок», «теперь на TypeScript». Он работает в парадигме «один запрос — один ответ». Он хорошо знает определённую модель, её капризы и особенности. Его ценность — в скорости решения типовых задач. Но это нижний уровень, и да, он наиболее уязвим для автоматизации, потому что модели становятся лучше в понимании с полуслова, а интерфейсы — удобнее. Расти с этого уровня нужно не в сторону «ещё более хитрых формулировок», а в сторону системного мышления.

Уровень 2. Middle Prompt Engineer: «Управляющий контекстом».

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

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

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

Уровень 3. Senior / Staff Prompt Architect: «Создатель DSL и систем верификации».