Код был не самой трудной частью — и генеративный ИИ это подчеркнул

Новичок часто воспринимает работу инженера как вопрос синтаксиса: точки с запятой, имена функций, «умные» абстракции. Опытный разработчик связывает результат с разговором за недели до появления этого синтаксиса — с тем, что успели согласовать и зафиксировать. В заметке на Dev.to этот контраст связывают с искусственным интеллектом: не потому что «код пишет машина», а потому что внимание смещается к ясности требований и контрактов.

Материал «Writing Code Was Never the Hard Part» (Jon Herrington, публикация на платформе 2026-04-20, 13:47 UTC) развивает эту линию на примере enterprise commerce и зрелых практик постановки работы.

Синтаксис в кадре — и почему дорогой оказывается не опечатка

Тот же контраст, который в анонсе связывают с искусственным интеллектом, — «работа как синтаксис» против «работа как разговор за три недели до синтаксиса». Автор проводит разделение: для джуниора сложность в коде, для сеньора — в переводе неоднозначности в спецификацию и в умении отталкивать требование, если оно не согласуется с системой. Более десяти лет в enterprise commerce platforms, по его словам, «дорогими» оказывались не пропущенные знаки препинания, а предположения, похожие на требования; требования, сдвигающиеся между встречами; поведение, которое «все знали» — кроме тех, кто строит систему. Работа за клавиатурой выглядела тяжёлой, потому что на неё уходило много времени, хотя по сути это была более лёгкая часть процесса.

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

UAT на greenfield: когда ломается не техника, а формулировка

В тексте приводится эпизод UAT при пересборке React checkout в greenfield-проекте: участники исходили из логики «так работало раньше, значит будет работать и дальше», хотя репозиторий новый и спецификация такое поведение не фиксировала. Акцент смещается на ошибки спецификации, а не на «технические сбои». На ретроспективе вывод формулируется так: дело не в объёме коммуникации, а в ясности контрактов — в явном согласовании того, что значит «готово», до начала разработки. Этот разрыв позже связывается с тем, как генеративные системы используют формулировки: при дырах в критериях приёмки проявляется не только человеческое недопонимание, но и предел того, что можно вывести из текста задачи.

Spec-driven development: контракты по фазам вместо «ещё документации»

После эпизода с UAT автор описывает сдвиг в сторону не «больше бумаги», а более чётких контрактов на каждой фазе: соглашения по интерфейсам до реализации, критерии приёмки без опоры на свободную трактовку, письменное и согласованное определение «done». Явно называется spec-driven development как способ «выживания»: при ясной спецификации код «пишется сам»; при неоднозначности каждый инженер «изобретает свою правду», а стейкхолдеры подставляют старые правила. Для сценариев с ИИ это читается буквально: модель опирается на то, что задано явно, а не на недосказанность в чате.

Что меняет ИИ: паника про «код» смотрит не туда

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

• нет замены живой встрече, где уточняющий вопрос к VP Merchandising мог бы вскрыть невысказанное предположение;
• нет «отталкивания», когда требование противоречит только что отгруженной соседней командой системе;
• нет указания на дыру в критериях приёмки, которая проявится уже на UAT.

Контракты, которые помогали людям согласовывать намерение, по тезису текста также помогают при работе с ИИ: машина не извлекает намерение из недосказанности, а опирается на явно заданное; неоднозначность путает и людей, и модель; ясность снижает ошибки с обеих сторон.

Новый разрыв: кто умеет писать спецификацию под совместную работу с моделью

Дальше вводится дихотомия: инженеры, которые умеют писать спецификации, делающие ИИ продуктивным, против тех, кто этого не умеет. Первая группа описывает архитектуру, ограничения и краевые случаи; ИИ генерирует реализацию; люди ревьюят и корректируют — узкое место смещается с пальцев на суждение. Вторая группа сталкивается с теми же провалами (предположения в UAT, «плавающие» требования, код «как просили — но не как нужно»), но с более быстрым помощником по набору.

Спецификация как навык: от кодов ошибок до P95

Утверждается, что ясные требования — это навык, который можно выучить, и что большинство этим систематически не занимается. В качестве примеров конкретики приводятся формулировки уровня перечисления кодов 400, 409 и 500 с привязкой к сценариям вместо общего «handle errors gracefully», и уточнение «быстроты» через ориентир вроде P95 under 200ms при ожидаемой пиковой нагрузке — не как метрика платформы, а как иллюстрация дисциплины формулировок. Отдельно поднимается контекст вне тикетов: зависимость от соседней команды, ограничения легаси, стейкхолдер вне стендапов.

В финале этого блока формулируется метафора translation layer между намерением человека и исполнением машины: ИИ убрал «transcription tax», но не «thinking tax» — то есть не снял необходимость думать о требованиях, даже если набор ускорился.

Раскрытие: выигрывают не те, кто печатает быстрее

Заключительный аккорд — доминируют не те, кто набирает код быстрее (в том числе с ИИ-помощником по набору), а те, кто формулирует спецификацию яснее; клавиатура «никогда не была самой трудной частью», её просто было легче заметить.

Источники

1. Herrington J. Writing Code Was Never the Hard Part — Dev.to: Dev.to (дата доступа: 2026-04-20, 21:03:58 UTC).
2. На странице поста указана рассылка «The Builder's Leader» — подписка: https://www.jonoherrington.com/newsletter (дата доступа с той же страницы: 2026-04-20, 21:03:58 UTC).