В рамках серии сессий по агентной инженерии представитель компании Zed Industries Ричард провел детальное обсуждение практических аспектов применения больших языковых моделей с создателем HashiCorp Митчеллом Хашимото. Известный разработчик поделился уникальным опытом использования ИИ при создании своего нового высокотехнологичного эмулятора терминала Ghosty, написанного на языке Zig. В основе его подхода лежит строгое разграничение ролей, где человек выполняет функции стратегического архитектора, а нейросеть берет на себя рутинные задачи уровня младшего инженера.
🛠️ Роль архитектора: почему ИИ-агенты требуют жестких «бамперов» 2:37
Применение языковых моделей в разработке, по мнению Митчелла Хашимото, эффективно лишь тогда, когда человек полностью сохраняет за собой роль архитектора программного проекта. Эксперт подчеркивает, что он самостоятельно проектирует структуру кода, ожидаемые потоки данных и определяет места хранения состояний приложения, предоставляя ИИ-инструментам четкое руководство. По его словам, попытка поставить перед моделью слишком абстрактную задачу — например, просто попросить исправить некорректную работу функции отмены — приведет к неоптимальному результату, когда проблема решается грубой силой («молотком по гвоздю»), что делает код нечитаемым и неремонтопригодным в долгосрочной перспективе.
Хашимото сравнивает взаимодействие с генеративными моделями с обучением начинающих разработчиков (джуниоров). Спикер считает, что отправлять неопытных сотрудников на решение открытых, размытых задач — это катастрофа, и современные ИИ-инструменты находятся в аналогичном состоянии. Лучший способ взаимодействия, по его опыту, заключается в предоставлении хорошо очерченной проблемы с большим количеством ограничений, что напоминает «боулинг с бамперами», где направляющие помогают шару докатиться до кеглей.
Единственное исключение, где создатель HashiCorp использует полностью открытые запросы, он называет «молитвами» (Hail Mary prompts). Для этого у него настроена специальная команда в интерфейсе Claude, которая автоматически загружает текст тикета из GitHub по его номеру. В таких случаях Хашимото не просит ИИ исправить баг, поскольку не доверяет ему настолько, а лишь просит объяснить причины возникновения проблемы и указать возможный путь решения. Это позволяет ему параллельно анализировать до пяти различных багов во время триажа, категоризации и разметки тикетов.
🐛 Анатомия одного баг-фикса: функция отмены закрытия терминала в Ghosty 7:51
В качестве практического примера Митчелл Хашимото привел коммит, исправляющий ошибку в недавно добавленной функции эмулятора Ghosty — возможности отменить закрытие любого терминала, будь то сплит, вкладка или отдельное окно. Функция позволяет пользователю нажать комбинацию клавиш Command+Z (или Control+Z) в течение настраиваемого промежутка времени (около 5 секунд), после чего закрытый терминал восстанавливается со всей историей и окружением. Данный механизм изначально создавался в плотном соавторстве с ИИ.
В текстовом запросе, который Хашимото отправил модели, содержались подробные инструкции по изменению логики работы программы:
- Обновить реализацию функций undo/redo в файле в рамках метода
closeWindowImmediately. - Обработать сценарий, при котором несколько окон в группе вкладок закрываются одновременно, и восстановить их как единое окно с вкладками.
- Собрать все состояния отмены, отсортировать их по индексу вкладок, поместив значения
nullв конец. - Восстанавливать элементы поочередно, возвращая их в исходную группу вкладок.
- Принудительно установить значение группы вкладок в
nilвнутри сохраненного состояния отмены, так как к моменту восстановления старый объект уже будет уничтожен сборщиком мусора.
Интересной деталью является то, что эксперт принципиально не тратит время на исправление опечатток или ошибок правописания в своих промптах. По его наблюдениям, современные модели прекрасно понимают контекст и намерения автора, поэтому случайные лишние символы или неточные термины не мешают генерации корректного кода. Написание такого подробного параграфа текста на английском языке занимает у Хашимото гораздо меньше времени, чем самостоятельное написание аналогичного объема рутинного кода, знание архитектуры которого у него и так имеется.
🔄 Интерактивный цикл: ручное тестирование и автоматический рефакторинг 10:56
После того как модель выдает первый вариант кода, Хашимото переходит к стадии локальной проверки. Описываемый фрагмент относился к Swift-части приложения под macOS, а не к низкоуровневой части на языке Zig. Из-за специфической гибридной архитектуры Ghosty используемый инструмент Claude Code в настоящий момент не способен самостоятельно собирать и запускать проект, поэтому автор отключил все встроенные функции автоматического тестирования в системном промпте.
Процесс верификации изменений со стороны разработчика выглядит следующим образом:
- Выполнение команды
diffдля поверхностного анализа сгенерированного кода, чтобы убедиться в отсутствии критических аномалий или деструктивных команд вроде удаления файловой системы. - Запуск компиляции в среде Xcode с помощью горячих клавиш Command+R.
- Мануальное тестирование исправленного поведения в интерфейсе без детального построчного изучения кода на первом этапе.
В рассматриваемом случае поверхностная проверка показала, что баг был успешно устранен, однако структура и качество кода не соответствовали стандартам Хашимото. Функция, которая изначально занимала около 30 строк, разрослась под воздействием ИИ до 200 строк, превысив размеры экрана ноутбука. Спикер отмечает, что ИИ-модели стремятся решить задачу по кратчайшей прямой траектории, не задумываясь о долгосрочной читаемости.
Для исправления ситуации Хашимото снова применил ИИ, отправив запрос на проведение рефакторинга: «Давай вынесем всю проделанную тобой работу в отдельный приватный метод под названием registerUndoForCloseWindow». По мнению гостя, современные агенты демонстрируют безупречные результаты в задачах рефакторинга, переименования компонентов и реструктуризации файлов, практически никогда не допуская логических ошибок.
🗺️ Специфика языков: зрелость Swift против «необученности» Zig 19:30
Эффективность работы ИИ-агентов кардинально зависит от выбранного языка программирования и степени его представленности в обучающей выборке. По словам Хашимото, при работе со Swift модель демонстрирует глубокие знания устоявшихся фреймворков и генерирует качественный код. Ситуация меняется, когда дело касается новейших возможностей языка — например, анонсированных функций macOS 26 Tahoe. В таких сценариях модель оказывается бесполезной, и инженеру приходится возвращаться в «каменный век» ручного чтения документации и самостоятельного написания кода.
В отношении языка Zig, на котором написана основная часть эмулятора Ghosty, текущее поколение моделей остается некомпетентным в вопросах модификации кода. Тем не менее Хашимото обнаружил, что нейросети хорошо справляются с его чтением и логическим пониманием. На основе этого наблюдения он выработал оригинальный обходной путь:
- Попросить ИИ написать решение архитектурной задачи на хорошо знакомом ему языке (C, Rust, Swift или Python).
- Использовать сгенерированный скрипт или алгоритм как эталон логики.
- Самостоятельно портировать получившееся решение обратно на язык Zig.
В то же время ведущий Ричард поделился альтернативным опытом разработки компилятора языка Rock, который также пишется на Zig. По его мнению, Claude 4 Opus способен успешно писать код на Zig, если предоставить ему объемный контекст из текущей кодовой базы. Имея перед глазами массивные примеры реального синтаксиса проекта, модель начинает точно копировать локальный стиль программирования, что избавляет от необходимости промежуточного перевода на язык C. Этот факт подтверждает тезис участников о том, что продуктивность ИИ сильно привязана к конкретной программной среде и специфике проекта.
⛔ Недоступный уровень: где ИИ бессилен перед низкоуровневой оптимизацией 35:37
Существуют целые категории инженерных задач, которые собеседники считают полностью недоступными для качественного решения с помощью современных ИИ-агентов. К ним относятся глобальные архитектурные вопросы, проектирование систем сборки и создание высокопроизводительных структур данных. Модели способны без труда воспроизводить стандартные структуры данных, но они не понимают их специфического контекста для достижения экстремальной производительности.
В качестве примера Хашимото привел внутреннее устройство Ghosty, где отображение экрана терминала реализовано через связанный список страниц виртуальной памяти фиксированного размера для обеспечения быстрого аллоцирования из пула. Внутри этих страниц адресация удерживается в пределах 16-битного расстояния от базового указателя. Благодаря этому вместо полноценных 64-битных указателей сохраняются лишь 16-битные смещения, что позволяет экономить колоссальный объем памяти: в физическом пространстве одного стандартного указателя умещаются четыре кастомных.
Попытки привлечь ИИ к модификации подобных компонентов заканчиваются неудачей. По наблюдениям Хашимото, нейросеть стремится переписать кастомные хэшмапы и деревья, построенные на концепции смещения указателей, разрушая кэш-дружественность (cache friendliness) и локальность данных ради банального выполнения базовой бизнес-логики. По этой причине спикер ограничивает применение агентов исключительно задачами уровня младшего и среднего разработчиков, не доверяя им чувствительные к производительности участки кода.
📸 Мультимодальный дизайн: копирование интерфейсов по скриншотам 39:19
В противовес низкоуровневому программированию, сфера верстки пользовательских интерфейсов (UI) оказалась направлением, где мультимодальные возможности современных моделей вызывают у разработчиков восхищение. Митчелл Хашимото признался, что создание визуальных слоев приложения и размещение элементов на экране не доставляют ему профессионального удовольствия, в отличие от проектирования бизнес-логики.
Решением стало использование способности ИИ анализировать изображения. Разработчик применил следующий подход для создания командной палитры Ghosty:
- Сделать скриншот готового интерфейса командной палитры из редактора Zed.
- Передать изображение модели Claude с запросом воспроизвести данный дизайн в фреймворке SwiftUI.
- Получить готовый код интерфейса, который совпал с оригиналом на 90–95%.
Полученный результат был сразу добавлен в состав релизной версии Ghosty. Участники дискуссии сошлись во мнении, что делегирование ИИ написания рутинного UI-кода, который человек считает скучным, является одним из самых эффективных сценариев использования технологии на сегодняшний день.
📝 Феномен избыточного комментирования и ревизия кода после коммита 42:10
Интересной особенностью инженерного стиля Митчелла Хашимото является создание крайне детализированных комментариев к коду: на одну строку функционала у него нередко приходится три строки текстовых пояснений в исходном коде. Эксперт вспоминает, что в начале карьеры старшие коллеги заставляли его удалять такие описания, считая их избыточными, однако он остался верен своему подходу. По его мнению, написание логики параллельно на двух языках — программном и английском — создает надежный предохранитель: если комментарий не соответствует коду, значит, в одной из частей допущена ошибка.
Интеграция ИИ вывела эту практику на новый уровень, поскольку большие языковые модели отлично считывают такие пояснения и используют их для более точной генерации кода. В отличие от большинства программистов, которые агрессивно удаляют автоматически созданные ИИ комментарии, Хашимото сохраняет их в исходном виде и иногда просит модель написать еще больше текстовых разъяснений.
Кроме того, Хашимото применяет ИИ в качестве финального рецензента после завершения работы над задачей. Даже если код был написан полностью вручную в редакторе Neovim, перед отправкой изменений разработчик просит агента проанализировать последний коммит на предмет улучшений. Эта практика помогает выявлять скрытые проблемы:
- Скрытые орфографические ошибки, которые пропустили стандартные линтеры.
- Рассогласование комментариев с обновленной бизнес-логикой кода.
- Устаревшие упоминания измененных функций в комментариях внутри других файлов проекта.
Из предложенных моделью шести-семи рекомендаций Хашимото обычно одобряет и переносит в кодовую базу одну или две наиболее удачные идеи.
🧪 Экстремальный TDD и автоматизация рутинного бойлерплейта 46:20
Митчелл Хашимото является строгим приверженцем методологии разработки через тестирование (TDD). Его первое место работы в качестве младшего инженера на протяжении трех лет отличалось радикальным подходом к тестированию, где ни одна строка продуктового кода не могла быть написана до того, как будет создан падающий тест. Хотя сейчас спикер не столь категоричен, при исправлении багов он строго придерживается правила: сначала пишется воспроизводящий ошибку тест, и лишь затем создается решение для его успешного прохождения.
При этом Хашимото предпочитает писать архитектуру тестов самостоятельно, чтобы глубже понять природу бага, перекладывая на ИИ написание самого решения. Однако в вопросах создания сложного и рутинного кода для тестов (бойлерплейта) модели могут демонстрировать выдающиеся результаты. В качестве примера Хашимото привел недавний баг в Ghosty, связанный с изменением размеров окна терминала:
- Сбой происходил при наличии на экране сложных символов Юникода (эмодзи), занимавших до восьми кодовых позиций (grapheme clusters).
- Для точного воспроизведения бага требовалось побайтово заполнить экран терминала последовательностями UTF-8.
- Вместо ручного поиска кодировок Хашимото просто вставил нужный эмодзи в комментарий и приказал ИИ заполнить им сетку размером 2x2.
- Модель безошибочно справилась с задачей, сгенерировав необходимый низкоуровневый массив байтов.
🧠 Развитие инженеров в эпоху генеративных моделей и борьба с контекстом 49:10
Появление мощных ИИ-инструментов меняет требования к обучению молодых специалистов. Хашимото выражает категорическое несогласие с подходом, при котором разработчики начинают слепо доверять генерациям и продвигаться по проектам исключительно за счет интуитивного подбора промптов. Эксперт настоятельно рекомендует джуниорам инвестировать время в фундаментальное понимание того, как работает код под капотом, даже если его написание было полностью делегировано нейросети. Это знание является универсальным и переносимым на другие языки, проекты и архитектурные среды.
Освободившееся благодаря автоматизации рутины время Хашимото советует тратить на обучение и расширение кругозора. Сам он во время генерации длинных ответов моделями изучает видеоматериалы технических презентаций Apple, чтобы подготовить Ghosty к выходу новой операционной системы.
В контексте высокой интенсивности работы Хашимото отмечает, что многолетняя топ-менеджерская деятельность приучила его к эффективному переключению контекста (context switching) каждые 30 минут. При этом использование ИИ-агентов видится ему более комфортным, чем управление людьми:
- ИИ-инструмент, в отличие от живого сотрудника, не требует мгновенной реакции и может находиться в режиме ожидания неограниченное время.
- Разработчик имеет возможность уйти на ужин, оставив сессию открытой, без ущерба для рабочего процесса.
Любопытно, что особенности взаимодействия с ИИ породили новые функции в самом софте. Использование инструмента Claude Code в терминале Ghosty приводило к отправке системных уведомлений macOS при завершении работы агента. Это вдохновило Ричарда добавить аналогичные уведомления в редактор Zed. В свою очередь, интенсивное тестирование этой функции Хашимото заставило его доработать логику уведомлений в Ghosty: теперь они автоматически скрываются через 3 секунды при движении мыши или вовсе не появляются, если окно терминала находится в фокусе.
📐 Изменение структуры кодовой базы под особенности моделей 56:17
Митчелл Хашимото признает, что регулярное использование больших языковых моделей постепенно заставило его скорректировать некоторые паттерны организации кода. В частности, он стал более осознанно стремиться к концентрации контекста в одном месте, сближая связанные функции или даже объединяя их в рамках одного файла. Это обусловлено техническим ограничением инструментов, которые наиболее эффективно считывают строки кода, расположенные в непосредственной близости друг от друга.
Другим важным и укоренившимся за 10 лет методом работы Хашимото является специфический подход к проведению рефакторинга:
- Перед изменением логики полностью копируется старая работающая реализация, чтобы в системе временно сосуществовали две версии функции.
- Модификации подвергается только одна из версий, при этом сохраняется возможность моментального обращения к старому эталону без необходимости переключения веток в Git.
- Подобным образом Хашимото 10 лет назад полностью переписал логику выполнения в проекте Terraform, продублировав целиком всю папку компонента внутри Git-репозитория.
Для ИИ-моделей этот паттерн оказался критически важным. Наличие перед глазами старой реализации в качестве явного шаблона в текущей кодовой базе многократно повышает вероятность генерации точного и корректного нового кода. Перед окончательным удалением устаревшей ветки кода Хашимото отправляет ИИ финальный проверочный запрос с просьбой сравнить старую и новую директории, чтобы убедиться, что в процессе рефакторинга не был утерян редкий или неочевидный функционал.
