Написать код легко. Если у вас в голове сложилось решение, и вы уверенно владеете синтаксисом вашего любимого языка программирования, то напишете код с лёгкостью. А может быть у вас есть LLM, которая напишет за вас целые функции? Тогда ещё проще. Но сложнее всего не писать код, а читать. Требуется время, чтобы загрузить себе в голову ментальную модель системы. Вот это по-настоящему трудозатратно.
Ментальная модель складывается у вас в голове, когда вы читаете код. Это ваша внутренняя «карта», по которой понятно, как работает система, где находятся самые хитрые её части, что от чего зависит. Не имея такой карты в голове, вы просто смотрите на текстовые строки.
Когда я выполнял работу по заказу, большинство из моих заданий начинались одинаково. Мне ставили задачу пофиксить баг или добавить новую фичу в приложении, которое я видел впервые. Сначала моя ментальная модель была как чистая доска. Чтобы приступить к её заполнению, я открывал домашнюю страницу и разбирался, на что она похожа. Я открывал исходный код страницы: это React? jQuery? Сторонний плагин? Я просматривал базу кода, чтобы выяснить, используется ли у них где-нибудь ещё такая карусель, которую они просят поставить на первой страницы. Знакомился с их сборочным процессом, конфигурацией для тестирования, с тем, каким инструментарием они пользуются. Каждая мелкая деталь, которую я обнаруживал, встраивалась в ту модель, которая складывалась у меня в голове.
Ощущение было такое, как будто я переехал в незнакомый город. Вы выходите за порог вашего номера, проходите пару улиц, обращаете внимание, где выезд на шоссе, где овощной магазин, постепенно начинаете ориентироваться на местности. Примерно так ощущается и чтение кода: вы постепенно выстраиваете в уме мысленную карту, поэтому не заблудитесь, в очередной раз свернув куда-то в программе.
Допустим, вам требуется понять простую функцию, такую как getUserPreferences(userId). Чтобы построить её ментальную модель, вам нужно проследить следующие вещи:
-
Где именно определена эта функция?
-
Что она возвращает? Это промис? Какова форма данных?
-
Как именно она обращается к базе данных — напрямую или через API?
-
Участвуют ли в работе какие-либо уровни кэширования?
-
Что произойдёт, если пользователя не существует?
-
Кто ещё вызывает эту функцию и в каких контекстах?
-
Есть ли у неё побочный эффект?
Чтобы понять смысл конкретной функции, вам, возможно, придётся переключаться между схемами баз данных, промежуточным ПО для обработки ошибок и множеством точек вызова. Только выстроив такую сеть отношений, вы приобретёте достаточно подробный контекст, с опорой на который сможете спокойно что-то менять.
Это медленно. Поэтому читать код сложнее, чем писать. Гораздо сложнее. Когда вы пишете код, вы движетесь вперёд, укладываете свежий асфальт. Читая код вы, как правило, вынуждены ступать по чьим-то следам, а значит — переходить от файла к файлу, выслеживать вызовы функций, догадываться о побочных эффектах и расшифровывать намерения, которые автор кода только подразумевал. Чтобы понять функцию, зачастую требуется заглянуть в пять и более файлов. Только после этого у вас будет примерная карта, с которой можно хотя бы начать.
По той же причине отладка сложнее программирования. Один из самых распространённых комментариев на Stack Overflow, который можно встретить под плохо сформулированным вопросом — «Можете показать, что именно вы сделали»? Не проследив шаги, читатели треда не могут составить в голове картину того, что именно происходило. Опять же, именно поэтому то и дело всплывает проблема XY. Спрашивают о симптоме, не сообщая контекста, который помог бы отвечающему восстановить всю картину.
Меня до сих пор удивляет тот адвокат, который применил ChatGPT в суде. Он предоставил записку по делу, в котором процитировал шесть эпизодов, как оказалось — несуществующих. Все его спрашивали: почему вы не прочитали эти дела? Ответ тот же: чтобы выстроить модель, требуются силы и время. Ему следовало бы проследить каждое дело, прочитать его, а затем вставить в более широкий контекст юридического прецедента. Читать сложно. Генерировать легко.
Прочитать код – означает не просто разобрать его строку за строкой. Вам также придётся проработать документацию, посмотреть ревью кода, попрограммировать вместе с коллегами. На самом деле, есть решения, помогающие ускорить выстраивание ментальной модели. Но, даже помня об этом, всё равно придётся читать и вникать. Вы заметите, что программисты зачастую предпочитают написать всё с нуля, потому что «старый код отстой». В данном случае самое «отстойное» — это необходимость прочитать и понять.
Именно поэтому в LLM заключена такая сила, и одновременно они так опасны для программиста. Что бы ни генерировал ИИ — совершенный код или галлюцинации, вам всё равно придётся это прочитать. Проследить, как предположительно должен работать этот код, как он взаимодействует с оставшейся частью системы, каковы его побочные эффекты. Чем длиннее сгенерированный код, тем больше времени требуется, чтобы выстроить на его основе ментальную модель. Справившись с этой задачей, вы сможете увидеть в коде проблемы, места, где сгенерированный код неуместен, либо тихо ломает что-то ещё.
Притом, что LLM может в неограниченном количестве генерировать код или текст, всё время остаётся соблазн это не читать. Но без модели не обойтись. Вы не хотели бы загрузиться в чужую игру и оказаться посреди схватки с боссом. Именно такие ощущения вас ждут, если вы унаследуете или сгенерируете код, который не понимаете.
Так что вот самое главное узкое место в разработке ПО. Не писать, а понимать.
Пока у нас нет аналога LLM для понимания. Нет инструмента, который мог бы мгновенно переносить полную ментальную модель из системы прямо вам в голову. Пока он не появится, это узкое место никуда не денется. Мы решили проблему «медленной печати». Теперь мы можем сгенерировать больше кода, чем вообще в состоянии прочитать. Но пока мы не решим проблему с пониманием, стоимость разработки ПО не изменится: она стоит столько, сколько нужно времени человеку, чтобы осмыслить код.
Вот что реально скрывается за использованием ИИ-инструментов. Лучше не ставьте ИИ задачу сгенерировать большой кусок кода, а попросите его помочь вам понять уже имеющийся код. Не измеряйте продуктивность по количеству строк кода, а проверьте, насколько быстро команде удаётся построить точную ментальную модель создаваемой системы.
Возможно, будущее программирования — не в ускорении генерации кода, а в ускорении его понимания. А эту проблему решить гораздо сложнее.
Хотим напомнить, что у нас стартовала осенняя распродажа 🍂
Условия акции:
16–28 сентября 2025 г.
Скидка 35% на все бумажные книги по купону — Бумажная
Скидка 50% на все электронные книги по купону — Электронная
Автор: ph_piter
