Актуальные темы
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Давайте разберемся в истории создания Claude Code, основным источником которой является статья технологического блогера Гергей Ороша, в которой он интервьюирует ключевых участников Claude Code.
Claude Code действительно впечатляет, 500 миллионов долларов годового дохода, за три месяца количество пользователей увеличилось в 10 раз, и теперь это также инструмент, который многие программисты выбирают в качестве своего основного Coding Agent.
Этот инструмент изначально был просто командной строкой, которая могла сказать вам, "какую песню вы сейчас слушаете".
🧵

Гергей Орош интервьюировал трех ключевых членов команды Claude Code:
• Основной инженер Борис Черни (17 лет опыта, бывший главный инженер Meta)
• Второй инженер Сид Бидасария (автор функции Subagents)
• И менеджер по продукту Кэт У.
Они обсудили, как Claude Code превратился из прототипа в продукт, какие технические решения были приняты, и как эта небольшая команда из десятка человек добивается публикации 5 PR в день на каждого.
Это, возможно, самый близкий к образцу "AI-ориентированной инженерной команды" пример на данный момент. Они используют AI для написания кода, написания тестов, проведения код-ревью, устранения неполадок и даже используют Claude Code для разработки самого Claude Code. 90% кода написано им самим.
Я хочу собрать самые интересные моменты из этого интервью, рассказать, как работает эта команда, что можно перенять, а что является их уникальными условиями, которые нельзя просто скопировать.
Ниже разделено на 7 небольших историй, каждая из которых может быть прочитана отдельно, а вместе они составляют полную картину.

【1】Небольшой инструмент для прослушивания музыки, как превратиться в продукт с доходом 500 миллионов долларов в год
В сентябре 2024 года Борис Черны только что присоединился к Anthropic и, не имея дел, написал небольшую командную игрушку.
Что это может делать? Он может с помощью AppleScript сказать вам, какую песню вы сейчас слушаете, и также менять песню по вашему запросу. Вот так просто. Сам Борис оценил это так: "Прикольный демо, но не имеет смысла."

Настоящий поворот произошел после разговора с коллегой Кэт У. В то время Кэт изучала возможности использования компьютера для AI Agent, и в процессе разговора Борису пришла в голову мысль: а что если дать этому инструменту командной строки больше прав? Например, позволить ему читать и записывать файлы, выполнять команды?

Он попробовал. И вот настал момент, чтобы стать свидетелем чуда.
Борис бросил этот усовершенствованный инструмент в кодовую базу Anthropic и задал несколько вопросов. Claude начал самостоятельно исследовать файловую систему — прочитал один файл, увидел в нем инструкции import и продолжил читать упомянутые файлы, углубляясь все дальше, пока не нашел ответ.
"Это меня поразило," — вспоминает Борис, — "Я никогда не использовал такой инструмент."

В области AI есть концепция, называемая «product overhang», что в переводе означает «избыток продукта». Это значит, что модель на самом деле уже обладает определенной способностью, но существующая форма продукта не позволяет этой способности проявиться.
Борис обнаружил огромный «избыток продукта», Claude уже давно мог это сделать, просто никто не создал для него оболочку.

Борис начал каждый день работать с этим инструментом, а затем поделился им с несколькими коллегами. Через два месяца, в ноябре, они выпустили внутреннюю версию.
Данные впечатляющие: в первый день 20% инженеров использовали его; на пятый день — 50%.

В это время возникла интересная дискуссия: стоит ли публиковать это на внешний рынок?
Аргументы против были очень реальными: если это действительно так сильно, как мы думаем, не лучше ли оставить это в качестве "секретного оружия"? Зачем отдавать конкурентное преимущество?
В конечном итоге, Anthropic выбрала публикацию. Логика была следующей: основной миссией Anthropic является исследование безопасности моделей, а лучший способ изучить безопасность — это позволить людям действительно использовать эти инструменты. Поскольку внутренние тесты уже подтвердили, что Claude Code будет широко использоваться, его публикация может принести больше информации о возможностях и безопасности модели.

В мае 2025 года Claude Code был официально представлен. Через три месяца его использование увеличилось в 10 раз, а годовой доход превысил 500 миллионов долларов.
Интересно, что Борис изначально думал, что это будет использоваться только программистами — поэтому и назвал его "Claude Code". Но однажды, проходя мимо рабочего места дата-сайентиста, он увидел, что на экране у того тоже запущен Claude Code. "Ты что с этим делаешь?" "Я заставляю его помогать мне писать запросы, делать визуализации." Теперь у дата-сайентистов Anthropic у каждого есть свой экземпляр, некоторые открывают несколько одновременно.
Небольшой инструмент для прослушивания музыки, который, благодаря нескольким дополнительным разрешениям, превратился в продукт стоимостью несколько миллиардов долларов. Это, вероятно, лучшее доказательство "product overhang" — возможности модели всегда были там, просто ждали, когда кто-то их освободит.

【2】90% кода написано самостоятельно — философия выбора технологий Claude Code
У Claude Code 90% кода написано им самим.
Звучит как рекламный трюк, но на самом деле это заслуга их логики принятия технических решений.
Сначала взглянем на стек технологий: TypeScript для основной части, React в сочетании с фреймворком Ink для терминального интерфейса, открытая библиотека Yoga от Meta для системы компоновки, а Bun отвечает за сборку и упаковку.
Почему выбраны именно эти технологии? Потому что они "в пределах распределения".
"В пределах распределения" (on distribution) — это термин из области ИИ. Это означает, что модель уже видела множество такого кода и умеет с ним работать. TypeScript и React — это сильные стороны Claude. Если выбрать редкий фреймворк, модели придется "учиться", и эффективность будет снижена.
Этот выбор создает замечательный цикл: писать Claude Code с использованием технологий, в которых Claude силен, а затем использовать Claude Code для написания еще большего количества Claude Code. 90% написано самим собой, именно так это и происходит.
Их выбор на архитектурном уровне также прост.

Что касается того, почему это так спроектировано?
Ответ Бориса: "Каждый раз, когда мы принимаем решение о дизайне, мы почти всегда выбираем самый простой вариант. Локальный запуск — это самый простой ответ."
Эта простота распространяется на всю философию продукта: писать как можно меньше бизнес-логики и позволить модели быть главной.
"Это может показаться немного странным," — говорит Борис, — "но мы хотим, чтобы пользователи могли как можно более "оригинально" ощутить модель. Многие AI-продукты добавляют кучу вспомогательных элементов — дополнительные элементы интерфейса, различные функции — и в результате это ограничивает возможности модели. Мы хотим, чтобы интерфейс был как можно более минималистичным."
Чтобы сохранить простоту, каждый раз, когда Claude выпускает новую модель, они значительно упрощают код.
Например, при выпуске Claude 4.0 они удалили около половины системных подсказок, потому что новой модели больше не нужны были эти "костыли". Количество инструментов также постоянно сокращается — что можно удалить, то удаляют, что можно объединить, то объединяют.
Вся архитектура Claude Code может быть обобщена в три вещи: определение интерфейса и его открытие для изменения моделью, открытие инструментов для вызова моделью, а затем отступить в сторону.
Конечно, простота не означает отсутствие сложных частей. Система разрешений — это исключение.
В конце концов, позволять AI выполнять команды на вашем компьютере — это риск. Решение Claude Code заключается в том, чтобы сначала спросить вас: хотите ли вы одобрить это действие? Можно одобрить только один раз, можно одобрить на будущее или отказать.
Система разрешений поддерживает многоуровневую конфигурацию — по проекту, по пользователю, по компании. Команды могут делиться конфигурационными файлами, добавляя часто используемые безопасные команды в белый список.
Принцип, лежащий в основе этой системы разрешений, таков: если вы запускаете Claude Code, он не должен изменять ничего без вашего согласия. Но в то же время, нужно дать пользователю возможность "делегировать" — в доверительных ситуациях можно пропустить этап подтверждения.
Просто, но не примитивно. Сдержанно, но не с отсутствием функций.

【3】Два дня, 20 прототипов — как выглядит итерация продуктов в эпоху ИИ
Раньше, когда я делал прототипы продуктов, за два дня можно было сделать два — это считалось высокой эффективностью.
Борис за два дня сделал 20.
Это не преувеличение, это реальные записи, когда он разрабатывал функцию списка дел Claude Code. Он даже поделился подсказками и скриншотами каждого шага.
Давайте посмотрим, как эти 20 прототипов эволюционировали.
В первой версии он хотел, чтобы список дел отображался под последним вызовом инструмента. Подсказка была короткой: "Пусть список дел не появляется с вводом, а отображается фиксированный список дел над полем ввода, заголовок отображается серым цветом '/todo (1 из 3)'".
Посмотрев на результат, он остался не очень доволен.
Во второй версии он изменил это на отображение списка дел встраиваемым образом при каждом обновлении. Подсказка: "На самом деле не показывайте список дел, измените так, чтобы при начале обработки одного дела название инструмента отображалось жирным заголовком. Сохраните отображение прогресса 'шаг 2 из 4'".
Все еще не то.
В третьей и четвертой версиях он попытался сделать "интерактивную таблетку" — маленький квадрат внизу экрана, который можно открыть, чтобы увидеть прогресс. "Добавьте таблетку дел под текстовым полем ввода, похожую на стиль фоновых задач, отображающую 'дела: 1 из 3'". Затем: "Сделайте эту таблетку интерактивной, как таблетка фоновых задач".
Это стало немного интереснее, но все еще недостаточно хорошо.
В пятой и шестой версиях он сменил подход: сделал "выдвижной ящик" справа. "Отмените предыдущие таблетки и заголовки, измените так, чтобы список дел отображался справа от поля ввода, вертикально по центру, с серой разделительной линией". "Это немного прыгает, можно ли сделать анимацию ящика?"
Выглядит довольно круто, но практичность под вопросом.
Седьмая по девятую версии он снова переместил список дел над полем ввода, экспериментируя с различными способами обрезки и стилями заголовков. "Если больше 5, то отображать '... и еще 4'", "добавить серый заголовок 'Дела:'".
Ответ становится все ближе.
С десятой по двадцатую версии он начал думать, как объединить список дел и анимацию загрузки. Последнее решение заключалось в том, чтобы разместить информацию о прогрессе рядом с индикатором загрузки (spinner), максимизируя видимость.
После публикации пользователи сообщили, что хотят видеть полный список дел. Поэтому была добавлена еще одна итерация: нажав Ctrl+T, можно развернуть все шаги.
Вот версия, которая сейчас в сети.

В процессе Борис использовал удивительно короткие подсказки — большинство из них состояло из одного-двух предложений. Но каждая версия была рабочим прототипом, а не статическим изображением и не презентацией. Он мог действительно протестировать и проверить эту функцию, почувствовать, удобно ли ей пользоваться.
Традиционный процесс разработки продукта выглядит так: идея → обсуждение → создание каркасного прототипа → высококачественный дизайн → разработка → тестирование → запуск. На каждом этапе требуется время, и на каждом этапе могут возникнуть задержки.
Теперь процесс выглядит так: идея → подсказка в одно предложение → рабочий прототип → если что-то не так, делаем новую версию.
Это на самом деле требует от разработчиков изменения мышления, чтобы адаптироваться к такому процессу разработки.
Ранее роль прототипа заключалась в "проверке идеи" — поскольку создание прототипа было дорогостоящим, нужно было сначала все обдумать, прежде чем приступать к делу. Теперь прототип стал "исследованием возможностей" — поскольку создание прототипа стало дешевым, можно сначала сделать его, а потом уже решать, если что-то не так, просто выбросить.
Борис говорит, что, используя Claude Code, он часто пропускает этап создания дизайна и сразу делает рабочую версию, что более наглядно.
Ежедневный ритм команды Claude Code таков: каждый инженер в среднем отправляет около 5 PR в день, внутри компании ежедневно выпускается 60-100 версий, а внешне — 1 версия.
Пять PR в день — это трудно представить для большинства компаний. В Uber, в самый напряженный период рефакторинга, один средний PR в день считался бы неплохим результатом.
Инструменты изменились, ритм изменился, и мышление тоже должно меняться.

【4】Переработанный командный терминал с интеграцией AI
Командный терминал существует уже несколько десятилетий, почему его нужно переработать сейчас?
Потому что до появления LLM терминал не уделял особого внимания взаимодействию с пользователем.
Традиционный командный интерфейс — это вопрос-ответ: вы вводите команду, он возвращает результат, и всё. Нет диалога, нет контекста, нет обратной связи во время ожидания. Вы смотрите на мигающий курсор и не знаете, что происходит в фоновом режиме.
Claude Code — это один из первых продуктов, которые действительно начали задумываться о "UX терминала". Они добавили несколько мелких деталей, которые на первый взгляд незначительны, но использование становится совершенно другим.
Первое: подсказки по загрузке контекста.
Когда модель думает, на экране могут отображаться подсказки, связанные с текущей задачей: например, "Читаю вашу структуру кода" или "Думаю над решением".
Это небольшое прикосновение, но оно придаёт инструменту "личность". Вы чувствуете, что он серьёзно работает, а не завис. Борис сказал, что в последний раз он видел такую приятную мелочь во время обучения новичков в Slack.
Второе: обучающие подсказки во время ожидания.
Когда Claude выполняет длительную задачу, внизу экрана будут поочерёдно отображаться советы по использованию, например, "Вы можете нажать Esc, чтобы прервать текущую задачу" или "Попробуйте /help, чтобы увидеть все команды".
Командный интерфейс учит командному интерфейсу, просто и умно.
Третья история ещё интереснее: рендерер Markdown.
За день до выпуска один инженер пожаловался, что вложенные списки отображаются некрасиво, а расстояние между абзацами тоже неправильное. Проблема заключалась в рендерере Markdown. Борис попробовал все готовые рендереры на рынке, но ни один из них не выглядел хорошо в терминале.
Поэтому он потратил день, используя Claude Code, чтобы написать рендерер и парсер Markdown с нуля.
Да, за день до выпуска. Да, с нуля. Да, с использованием Claude Code.
В результате этот "срочно сделанный" рендерер выглядел лучше, чем все готовые решения. Они просто выпустили его. Борис считает, что сейчас нет ни одного другого терминала с таким же качеством рендеринга Markdown.
Эта история говорит о том, что когда у вас есть достаточно хороший инструмент программирования AI, стоимость "создания колеса" значительно снижается. Раньше компромисс "лишь бы работало" теперь может превратиться в "давайте сделаем что-то лучше".
Старый интерфейс командного терминала обретает новую жизнь благодаря интеграции LLM. Терминал остаётся тем же терминалом, но благодаря добавлению AI нам нужно серьёзно подумать: как лучше организовать диалог между человеком и AI в терминале.

【5】AI проникает в каждый этап — эксперимент «полной AI-автоматизации» инженерной команды
Инженерная команда Anthropic, возможно, одна из тех, кто использует AI-инструменты наиболее эффективно.
Это проявляется не только в написании кода, но и на всех этапах проекта.
Код-ревью: первый обзор всех PR выполняет Claude Code, инженеры делают второй обзор. Борис говорит, что Claude Code может обнаружить много проблем уже на первом этапе. Эта функция изначально использовалась только внутри компании, но затем они сделали её доступной для всех, чтобы каждый мог использовать Claude Code для проверки безопасности.
Написание тестов: тестовый набор Claude Code почти полностью написан самим Claude Code. Борис говорит: «Раньше, если кто-то предлагал PR без тестов, я колебался, стоит ли что-то говорить — это казалось придиркой. Но теперь с Claude написание тестов — это просто вопрос подсказки, нет оправданий, чтобы не писать.»
Ответ на инциденты: дежурный инженер может попросить Claude Code помочь проанализировать коренную причину (основную причину проблемы). Он может извлекать соответствующие обсуждения из Slack, ошибки из Sentry, данные из различных систем мониторинга и затем проводить комплексный анализ. Борис говорит, что в некоторых случаях Claude Code находит коренную причину быстрее, чем человек.
Распределение GitHub issue: каждый раз, когда поступает новый issue, Claude Code сначала проводит анализ, а затем инженер спрашивает его: «Можешь это реализовать?» Борис говорит, что в примерно 20%-40% случаев он может справиться с этим с первого раза.
Графики и запросы: данные продукта хранятся в BigQuery, почти все запросы и визуализации генерируются с помощью Claude Code. Инженеры даже могут попросить его напрямую выводить ASCII-графики.

Самым неожиданным для меня стало возрождение TDD (разработка через тестирование).
TDD — это старая концепция: сначала пишешь тесты, затем пишешь код, который проходит эти тесты. Теоретически это выглядит прекрасно — заставляет тебя сначала четко понять, что нужно. Но на практике большинство людей считает это слишком медленным и хлопотным, поэтому этот метод постепенно оказался на обочине в последние десятилетия.
Но Борис сказал, что после использования Claude Code он сделал много TDD:
"Сначала я заставляю модель написать тест, одновременно сообщая ей, что этот тест сейчас провалится, не пытайся его пройти. Затем я заставляю ее написать код для реализации функции и сделать так, чтобы тест прошел, но не могу изменить сам тест."
"Когда у модели есть четкая цель для итерации — например, юнит-тест или мок — она показывает отличные результаты."
Он особенно отметил, что Claude 4.0 — это первая модель в серии, которая может написать большую часть тестов. Ранее версии могли написать лишь часть, но требовали значительного вмешательства человека.
Есть еще одна новая концепция: multi-clauding.
Это означает одновременный запуск нескольких экземпляров Claude Code, позволяя им параллельно обрабатывать разные задачи. Сид сказал, что он часто так делает — запускает несколько агентов во время совещания, а потом возвращается и смотрит результаты.
Anthropic обнаружил, что 25% пользователей Max (премиум-пользователи с ежемесячной подпиской 100-200 долларов) ежедневно занимаются multi-clauding.
Это интересное изменение. Программирование всегда было "однопоточной" деятельностью: ты можешь делать только одно дело за раз, переключаясь на другую задачу только во время проверки кода или развертывания. Но теперь "параллельное программирование" стало возможным — ты можешь одновременно продвигать несколько дел.
Конечно, здесь много неизвестного: действительно ли параллельная работа более эффективна или это просто кажется более эффективным? Какие типы задач подходят для параллельной работы? Не возникнут ли проблемы из-за того, что внимание каждого агента становится меньше?
На эти вопросы пока нет ответов. Но у нас есть новый инструмент для экспериментов.
В конце расскажу один случай. Одна компания должна была сделать миграцию фреймворка, изначально оценив, что это займет два инженерных года — один инженер работает два года или десять инженеров работают два с половиной месяца. Они использовали Claude Code, и один инженер справился за две недели.
Борис сказал, что раньше он бы скептически относился к таким утверждениям, но они слышали слишком много подобных историй.

【6】Трехдневный хакатон — как появилась функция Subagents
Идея функции Subagents пришла из поста на Reddit.
Кто-то сказал, что он одновременно запустил пять экземпляров Claude Code, задав каждому экземпляру разные роли, а затем использовал файловую систему для их взаимной связи.
Когда Сид Бидасария увидел этот пост, его первая реакция была: это классная идея, но пользователям не должно быть нужно так заморачиваться. Мы должны сделать это встроенной функцией продукта.
Как раз в компании проходил трехдневный внутренний хакатон, и Сид решил использовать эти три дня для реализации этой идеи.
В первый день команда с энтузиазмом нарисовала различные сложные топологии агентов: агенты общаются через шину сообщений, асинхронные режимы, взаимодействие многие-ко-многим... Рисунок получился красивым, концепция — передовой.
На второй день они поняли, что это, похоже, невозможно.
Проблема не в технической реализации — эти сложные схемы можно реализовать. Проблема в том, что пользователи не смогут это понять. Интерфейс Claude Code — это просто терминал, как можно в таком простом интерфейсе объяснить пользователям сложные модели общения агентов?
Они решили начать с нуля и вернуться к основному вопросу: какая самая простая форма, которую могут использовать обычные разработчики?
Они установили для себя два ограничения:
Первое, не изобретать ничего нового. Использовать только уже существующие возможности Claude Code — команды “/” и .md файлы.
Второе, не делать коммуникацию между агентами. Изменить на простую модель оркестрации: есть главный агент, который может вызывать подагентов, подагенты выполняют задачи и возвращают результаты, и только это.
Они также поговорили с исследовательской командой Anthropic. Исследователи изучают многопользовательские модели, но вывод таков: действительно ли сложные топологии агентов эффективны, пока нет окончательного ответа.
Это дало им больше уверенности: раз даже исследовательская команда говорит, что сложное не всегда хорошо, то тем более стоит сделать простую версию.
К концу третьего дня они создали рабочую версию. Пользователи могут в .md файле определять роли и возможности подагентов (например, “подагент фронтенда: использовать React 19 и Next.js”), Claude Code будет вызывать их в нужный момент, или пользователи могут вручную инициировать.
После хакатона, немного доработав, функция была запущена.
Теперь вы можете определять различные специализированные подагенты: бэкенд-агент с экспертизой в области безопасности, фронтенд-агент, знакомый с определенными фреймворками, QA-агент, специализирующийся на написании тестов... Они могут работать параллельно в фоновом режиме, выполняя свои задачи.
Многие команды на хакатонах не хотят отказываться от своих сложных решений, ведь они потратили целый день на рисование и обсуждение, к этому привязались. Признать, что “этот путь не работает”, и начать с нуля требует смелости и веры в “простоту”.
Простота — это не лень. Простота — это нахождение той формы, которая действительно может быть использована пользователем среди множества возможностей.

【7】Какими будут будущие инженерные команды? Некоторые вещи можно перенять, а некоторые нельзя скопировать.
Борис говорит: "Программирование сейчас так интересно. В последний раз я испытывал такое чувство, когда в школе впервые писал код на графическом калькуляторе. Это волшебное ощущение я давно не испытывал, но теперь оно вернулось."
Сид разделяет похожие чувства: "Меня волнуют две вещи. Во-первых, скорость, с которой мы выпускаем продукты — иногда это даже кажется слишком быстрым. Во-вторых, столько экспериментального пространства — хотя и раньше работа была быстрой, но делали мы довольно стандартные вещи, знали, что делать, просто выполняли. Сейчас все иначе, модель меняется каждые три месяца, и нам нужно постоянно переосмысливать, как работать."
Эти чувства очень искренние и заразительные.
Но прежде чем обсуждать, "какими будут будущие инженерные команды", не стоит забывать о специфике Anthropic.
Во-первых, Anthropic — это исследовательская лаборатория, а не продуктовая компания. Ее основная миссия — исследование безопасности и возможностей ИИ, продукты — это средство, а не цель. Это означает, что их терпимость к "быстрым экспериментам" гораздо выше, чем у обычных компаний.
Во-вторых, их основной продукт — это сама модель Claude. Claude Code — это всего лишь "обертка" для модели. Поэтому "удаление кода, чтобы модель могла делать больше" — это естественный выбор для них, но для других компаний это может означать передачу основной бизнес-логики в черный ящик.
В-третьих, все сотрудники имеют неограниченный доступ к Claude, включая самую дорогую модель Opus. В большинстве компаний подписка на ИИ — это бюджетный проект, за который нужно бороться, и невозможно, чтобы все пользовались ею без ограничений.
В-четвертых, команда состоит всего из нескольких человек, процессы крайне упрощены. Они почти не используют feature flag (функциональные переключатели), потому что "это слишком медленно". Это невозможно представить в продуктах с большой пользовательской базой и высокой стоимостью ошибок.
Поэтому просто скопировать подход команды Claude Code не всегда реалистично для большинства команд.
Но некоторые вещи можно перенять.
Мышление быстрого прототипирования: даже если вы не можете делать 10 прототипов в день, можно ли перейти от "одного каждые две недели" к "трём за неделю"? Инструменты изменились, и ожидания по поводу того, как быстро должны быть прототипы, тоже должны обновиться.
AI-помощь в код-ревью: пусть ИИ делает первый обзор, а человек — второй. Этот процесс не зависит от неограниченного доступа к API, и большинство команд могут попробовать это.
Возрождение TDD: если написание тестов становится достаточно простым, то "нет времени на написание тестов" больше не будет оправданием. Это может стать недорогим способом улучшения качества кода.
Увеличение ценности инженеров с продуктовым мышлением: команда Claude Code не имеет дизайнеров и PM, полагается только на несколько инженеров с продуктовым мышлением. Инструменты ИИ значительно расширили возможности таких "универсальных специалистов".

Конечно, есть вещи, которые не могут быть заменены инструментами.
Борис может выбрать лучший из 20 прототипов, потому что у него есть суждение — он знает, что "чувствуется правильно", а что просто "выглядит рабочим". Этот вкус — результат 17 лет опыта в разработке программного обеспечения, который не может дать AI.
Команда в первый день разработала сложное решение, а на второй день смогла решительно все начать заново — эта решительность также является человеческим суждением.
Знать, когда нужно удалить код, а когда оставить — это также интуиция архитектора.
AI ускорил выполнение, но он не упростил понимание "что нужно делать". Напротив, из-за снижения затрат на выполнение, решение о "что делать" стало более важным — вы можете быстро создать 20 версий, но вам нужно знать, какая из них правильная.
Как будет выглядеть программная инженерия через несколько лет? Никто не может точно предсказать. Но сегодняшний день команды Claude Code может быть предвестником для многих команд завтра — более быстрые итерации, меньше "перетаскивания кирпичей", больше суждений и решений.
Инструменты меняются. Не меняется то, что в конечном итоге решение принимает человек.

2,56K
Топ
Рейтинг
Избранное
