Английский стал моим основным языком программирования
Учёт рабочего времени показывает соотношение 80/20 в пользу английского языка, а не кода. Переход от vibe coding к Spec-Driven Development доказывает: ключевая инженерная компетенция эпохи ИИ — ясность спецификации, а не свободное владение синтаксисом.
Март 2026
В прошлом году я начал отслеживать, на что на самом деле уходит время разработки. Ответ оказался неприятным: текста на английском я пишу больше, чем кода. Не документацию — спецификации, критерии приёмки, контекст для моделей ИИ, проверочные запросы, заметки по итерациям. Соотношение примерно 80/20 в пользу прозы.
Этот сдвиг произошёл не за одну ночь, и я в нём не одинок. Андрей Карпати назвал это явление ещё в 2023 году. С тех пор Дженсен Хуанг в том или ином виде повторяет эту мысль в каждом крупном выступлении. Саймон Уиллисон уже два года описывает её на примерах реальной работы. Но в начале 2026-го, когда Claude Code, Cursor, Aider и Kiro применяются в рабочих конвейерах тысяч команд, это уже не смелый прогноз, а очевидный факт для всякого внимательного наблюдателя.
Вот как переход выглядел на практике. Я начал с того, что сообщество называет vibe coding, — снисходительное название для принципа «скажи модели, чего хочешь, и посмотри, что получится». Для прототипов это работало неплохо. Но всё рассыпалось, как только требовалась сопровождаемость. Регрессии появлялись в местах, которых я не касался. Размывание контекста превращало чистую кодовую базу в лоскутное одеяло. Модель не ошибалась — ошибался я. Я давал ей расплывчатые входные данные и ждал точного результата.
Решением стала смена методологии, а не обновление модели. Spec-Driven Development означает, что структурированная спецификация пишется до того, как сгенерирована хотя бы строка кода. Конкретные требования. Явно названные граничные случаи. Критерии приёмки, которые одновременно служат заданиями для тестов. Стоило мне отточить формулировки на английском, как качество кода резко выросло. Расход токенов снизился: модель перестала домысливать намерения. Спецификация стала первоисточником, а я — её автором.
Английский не заменил Python или TypeScript. Он стал интерфейсом к ним. Полезно представлять это так: вы пишете входные данные для компилятора, только компилятор здесь — большая языковая модель, а её сообщения об ошибках приходят в виде выдуманных функций и расползающихся границ задачи. Точность спецификации снижает шум на последующих этапах. Это не метафора. Это рабочий процесс промышленной разработки.
Неприятный вывод носит географический и лингвистический характер. Носители английского языка — точнее, те, кто пишет на нём ясно и структурированно, — имеют ощутимое преимущество. Не потому, что модели предвзяты, а потому что неоднозначность на входе порождает неоднозначность на выходе. Разработчик, пишущий спецификации на третьем языке и добивающийся точности в каждом слове, тратит на ту же задачу больше итераций. Инструменты открывают доступ к созданию программ для всех, но языковое требование незаметно возводит новый барьер.
Есть и второе противоречие, о котором стоит сказать. Навыки, которые в 2019 году делали человека сильным разработчиком, — свободное владение синтаксисом, знание API наизусть, низкоуровневая отладка — не обеспечивают эффективности в новой модели. Новый профиль — скорее технический писатель и системный архитектор в одном лице: человек, способный разложить задачу на части, описать её ограничения и критически проверить результат. Большинство компаний при найме пока этого не проверяют.
Моё мнение: в ближайшие пять лет преуспеют не те, кто быстрее всех пишет код, а те, кто яснее всех пишет спецификации. Способность написать строгое, однозначное описание системы — её входов, выходов, режимов отказа и ограничений — теперь ключевая техническая компетенция. Если считать её «мягким навыком», команда в итоге получит сгенерированный ИИ код, который никто до конца не понимает и никто не хочет сопровождать.
Какую долю вашего рабочего дня теперь занимает английский?