[Перевод] Claude Opus 4.5 и конец привычной разработки

Команда AI for Devs подготовила перевод статьи о том, почему Claude Opus 4.5 стал переломным моментом в ИИ-разработке. Автор на реальных проектах показывает, как ИИ-агенты уже сегодня способны собирать полноценные приложения — от UI до бэкенда — за считанные часы, и рассуждает о том, зачем человеку вообще читать код в мире AI-first разработки.

Если бы три месяца назад меня спросили об этих утверждениях, я бы сказал, что в них может верить только человек, который никогда не создавал ничего по-настоящему нетривиального. Отличный инструмент для усиления уже существующего воркфлоу разработчика, автодополнения — мощные, но чтобы агенты полностью заменили разработчиков? Нет. Категорически нет.

Сегодня я считаю, что ИИ-агенты для программирования действительно могут заменить разработчиков. И причина, по которой я так думаю, — Claude Opus 4.5.

Opus 4.5 — это нечто ненормальное

И под «ненормальным» я имею в виду, что это совсем не тот привычный опыт работы с ИИ-агентами, который у меня был до этого. До сих пор ИИ-агенты в основном неплохо справлялись с написанием спагетти-кода, а после девяти раундов копирования ошибок из терминала и команд «почини это» обычно успевали так развалить кодовую базу, что оставалось только выбросить весь чат целиком — вместе с 30 минутами жизни, которые уже не вернуть.

Opus 4.5 ощущается как та самая модель, которую нам обещали — точнее, как реально выполненное обещание ИИ для программирования.

Самое сложное в предыдущем предложении — то, что вашей первой реакцией должно быть: «докажи». Поэтому давайте я покажу, что мне удалось собрать.

Проект 1 — утилита для конвертации изображений в Windows

Впервые я понял, насколько Opus 4.5 отличается от всего остального, когда использовал его для создания Windows-утилиты, которая позволяет кликнуть правой кнопкой мыши по изображению и конвертировать его в другие форматы файлов.

Больше всего в процессе разработки меня поразила способность Opus 4.5 с первого раза делать большинство вещей правильно. А если он всё-таки натыкался на ошибки, то пытался собрать проект через dotnet CLI, читал сообщения об ошибках и итерировал до тех пор, пока всё не исправлялось. Единственной проблемой было то, что Opus не видел ошибки в XAML — их я отслеживал в Visual Studio и просто копировал обратно в агент.

Opus также сделал для меня сайт для распространения утилиты и полностью взял на себя упаковку исполняемого файла, используя PowerShell-скрипт для установки и удаления. Он же собрал GitHub Actions, которые отвечают за релизы и обновление лендинга, так что от меня требуется лишь запушить исходники.

Единственное место, где мне пришлось использовать сторонние инструменты, — это логотип. Там я задействовал ИИ от Figma, чтобы сгенерировать несколько вариантов, но затем Opus написал скрипты для конвертации SVG в нужные форматы иконок, включая варианты для распространения через магазин, если бы я решил это сделать.

И да, формально это несложное приложение. Небольшая Windows-утилита, которая по сути делает одну вещь. Это не то чтобы я попросил Opus 4.5 собрать Photoshop.

Хотя… в каком-то смысле именно это я и сделал.

Проект 2 — запись экрана и редактирование

Работа Opus 4.5 над этой утилитой настолько меня впечатлила, что я решил сделать простой инструмент для записи GIF, похожий на LICEcap для Mac. Отличное приложение, хотя название, мягко говоря, спорное.

Но это оказалось настолько легко, что я просто пошёл дальше и начал добавлять новые возможности: захват и редактирование видео, работу со статичными изображениями, добавление фигур, обрезку, размытие и многое другое. Я до сих пор продолжаю работать над этим приложением — как выяснилось, создание полноценного редактора изображений и видео — это довольно масштабная задача. Но за считанные часы я продвинулся ОЧЕНЬ далеко. ЗА ЧАСЫ, КАРЛ!

Пока у меня нет красивого лендинга для этого проекта, но весь исходный код можно посмотреть здесь.

В какой-то момент я понял: если я способен собрать приложение для записи видео, значит, я, вероятно, могу собрать вообще что угодно — по крайней мере, с точки зрения интерфейса. Но ахиллесова пята всех ИИ-агентов — это склейка бэкенд-систем. А без этого не обходится ни одно реальное приложение: аутентификация, база данных, API, хранилище.

И вот тут выясняется, что Opus 4.5 умеет и это.

Проект 3 — утилита для ИИ-постинга

Воодушевлённый уверенностью в Opus 4.5, я взялся за проект, который в прошлом году делал на React Native: я довёл его до релиза на Android, но на финальном этапе, как это обычно бывает, сдался.

Приложение предназначено для моей жены — у неё небольшой франчайз по установке табличек на газонах. Проблема в том, что у бизнеса есть страница в Facebook, но она почти никогда туда не постит, потому что это отнимает много времени. А ведь у любого нормального малого бизнеса должна быть живая страница, где люди видят фотографии того, чем этот бизнес вообще занимается… чем бы он там ни занимался. Чтобы было понятно, что он существует и чувствует себя вполне нормально.

Идея простая. Каждый раз, когда она устанавливает табличку, она делает фотографию и отправляет её заказчику, чтобы показать, что всё готово. Так почему бы не сделать мобильное приложение, в которое можно загрузить сразу 10 изображений, а приложение с помощью ИИ сгенерирует подписи, запланирует их и будет публиковать посты в течение недели.

Сама задумка несложная, но в ней куча движущихся частей. Есть аутентификация Facebook — а это отдельный квест, явно не для слабонервных. Есть аутентификация с бэкендом, есть файловое хранилище для фотографий, которые ждут публикации, есть бэкенд-процесс, который должен публиковать изображения. Это полноценная бэкенд-инфраструктура.

И тут так совпало, что мне нужно было установить в доме жалюзи. Я подумал: а почему бы не посмотреть, сможет ли Opus 4.5 собрать всё это, пока я занимаюсь жалюзи.

Я запустил чат и просто начал с того, что описал Opus 4.5, что именно хочу построить, и спросил, как он рекомендует организовать бэкенд. Он предложил несколько вариантов, но в итоге остановился на Firebase. Я ни сейчас, ни когда-либо раньше не был пользователем Firebase, но к этому моменту я уже слишком сильно доверял Opus 4.5. Возможно, даже чересчур.

Я создал аккаунт в Firebase, перешёл на тариф Blaze с уведомлениями о расходах — и Opus 4.5 принялся за работу.

К тому моменту, когда я закончил устанавливать жалюзи, у меня уже было рабочее iOS-приложение, которое использует ИИ для генерации подписей к фотографиям и публикует их в Facebook по расписанию.

Когда я говорю, что Opus 4.5 почти полностью собрал это приложение, я имею в виду именно это. Он использовал firebase CLI, чтобы поднять все необходимые ресурсы, и подключал меня только в отдельных моментах — например, когда нужно было перевести проект на тариф Blaze для использования хранилища и других возможностей. Самое впечатляющее — когда cloud functions в Firebase падали с ошибками, он автоматически делал grep по логам, находил проблему и устранял её. И всё, что ему для этого было нужно, — это CLI. Ни MCP-сервера. Ни навороченного файла с промптом, объясняющего, как работать с Firebase.

И, раз уж мог, я, конечно, попросил Opus 4.5 сделать бэкенд-админку, чтобы я мог видеть, какие посты у неё стоят в очереди, и при необходимости вносить правки.

А поскольку за несколько часов он сделал то, на что у меня ушло бы два месяца вечеров — ценой того, чтобы быть хоть сколько-нибудь приличным мужем, — я решил искупить своё служебное рвение и собрать для неё ещё одно приложение для бизнеса с табличками. Такое, которое сделает её жизнь чуточку приятнее и заодно избавит от двух других приложений, за которые она сейчас платит.

Проект 4 — отслеживание заказов и маршрутизация

Это приложение парсит заказы из рабочего Gmail-аккаунта её бизнеса и показывает, какие установки и демонтажи табличек у неё запланированы на день, рассчитывает, сколько времени займёт дорога до каждой точки, определяет оптимальный маршрут, если точек больше одной, и ведёт учёт времени в пути для налоговых целей. Раньше для двух последних задач она использовала два платных приложения.

Это приложение тоже работает на Firebase. И снова Opus с первого раза сделал интеграцию с Google-аутентификацией и почтой. А это как раз тот тип задач, который при ручной реализации превращается в мучительно унылую возню. И снова Firebase здесь идеально подходит, потому что Opus настолько хорошо умеет работать с Firebase CLI, что ему вообще не нужны инструкции. Ноль объяснений.

НО ТЫ ЖЕ НЕ ПОНИМАЕШЬ, КАК РАБОТАЕТ ЭТОТ КОД

Нет, не понимаю. У меня есть общее представление, но вы правы — я действительно не знаю, как именно собраны эти приложения. Тем более что Swift я вообще не знаю.

Раньше это было для меня серьёзным стоп-фактором. Я не мог диагностировать проблемы, когда что-то шло не так. С Opus 4.5 я пока в эту стену не упирался — Opus всегда сам находит проблему и чинит собственные баги.

Настоящий вопрос — это качество кода. Если я не понимаю, как он устроен, откуда мне знать, нет ли там дублирования, мёртвого кода или плохих паттернов? Раньше я на этом зацикливался. Сейчас меня это волнует гораздо меньше, потому что я искренне не уверен, что человеку вообще нужно читать этот код.

А зачем человеку вообще читать этот код? Я использую кастомного агента в VS Code, который говорит Opus писать код для LLM, а не для людей. Задумайтесь: зачем оптимизировать читаемость для человека, если всю работу делает ИИ и он же объяснит вам всё, когда вы спросите?

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

Что вам нужно: простые точки входа, явный код с минимумом абстракций, слабая связность и линейный поток выполнения.

Вот мой кастомный промпт для агента:

--- name: 'LLM AI coding agent' model: Claude Opus 4.5 (copilot) description: 'Optimize for model reasoning, regeneration, and debugging.' --- You are an AI-first software engineer. Assume all code will be written and maintained by LLMs, not humans. Optimize for model reasoning, regeneration, and debugging — not human aesthetics. Your goal: produce code that is predictable, debuggable, and easy for future LLMs to rewrite or extend. ALWAYS use #runSubagent. Your context window size is limited - especially the output. So you should always work in discrete steps and run each step using #runSubAgent. You want to avoid putting anything in the main context window when possible. ALWAYS use #context7 MCP Server to read relevant documentation. Do this every time you are working with a language, framework, library etc. Never assume that you know the answer as these things change frequently. Your training date is in the past so your knowledge is likely out of date, even if it is a technology you are familiar with. Each time you complete a task or learn important information about the project, you should update the `.github/copilot-instructions.md` or any `agent.md` file that might be in the project to reflect any new information that you've learned or changes that require updates to these instructions files. ALWAYS check your work before returning control to the user. Run tests if available, verify builds, etc. Never return incomplete or unverified work to the user. Be a good steward of terminal instances. Try and reuse existing terminals where possible and use the VS Code API to close terminals that are no longer needed each time you open a new terminal. ## Mandatory Coding Principles These coding principles are mandatory: 1. Structure - Use a consistent, predictable project layout. - Group code by feature/screen; keep shared utilities minimal. - Create simple, obvious entry points. - Before scaffolding multiple files, identify shared structure first. Use framework-native composition patterns (layouts, base templates, providers, shared components) for elements that appear across pages. Duplication that requires the same fix in multiple places is a code smell, not a pattern to preserve. 2. Architecture - Prefer flat, explicit code over abstractions or deep hierarchies. - Avoid clever patterns, metaprogramming, and unnecessary indirection. - Minimize coupling so files can be safely regenerated. 3. Functions and Modules - Keep control flow linear and simple. - Use small-to-medium functions; avoid deeply nested logic. - Pass state explicitly; avoid globals. 4. Naming and Comments - Use descriptive-but-simple names. - Comment only to note invariants, assumptions, or external requirements. 5. Logging and Errors - Emit detailed, structured logs at key boundaries. - Make errors explicit and informative. 6. Regenerability - Write code so any file/module can be rewritten from scratch without breaking the system. - Prefer clear, declarative configuration (JSON/YAML/etc.). 7. Platform Use - Use platform conventions directly and simply (e.g., WinUI/WPF) without over-abstracting. 8. Modifications - When extending/refactoring, follow existing patterns. - Prefer full-file rewrites over micro-edits unless told otherwise. 9. Quality - Favor deterministic, testable behavior. - Keep tests simple and focused on verifying observable behavior.

При всём этом у меня нет доказательств, что этот промпт действительно что-то меняет. По ощущениям, Opus 4.5 пишет вполне крепкий код независимо от того, что ему задать. Однако, поскольку модели любят писать код ГОРАЗДО больше, чем удалять его, я периодически запускаю промпт примерно такого вида:

В результате получается документ с пунктами высокого, среднего и низкого приоритета. Высокие вы разбираете — и ИИ перестаёт находить их. Вы можете рефакторить проект миллион раз, и он всё равно будет находить пункты среднего и низкого приоритета. ИИ никогда, вообще никогда не упустит возможность сгенерировать ещё немного текста.

Похожий промпт я использую и для поиска проблем безопасности. Здесь нужно быть особенно осторожным. Где лежат API-ключи? Корректно ли реализован логин? Не храните ли вы чувствительные данные в базе? Это, пожалуй, самая ручная часть всего проекта и, если честно, та, которая сейчас нервирует меня больше всего. Я не уверен, что все эти приложения пуленепробиваемы. Может быть, процентов на 80. А это, как говорится, чертовски мало.

Времена меняются

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

Я понимаю, если этот пост вас разозлил. Правда. Мне тоже не нравилось, когда люди говорили: «ИИ заменит разработчиков». Но теперь я больше не могу это игнорировать. Я могу желать, чтобы это было неправдой, но желания не меняют реальность.

Зато во всём остальном — просто делайте. Перестаньте ждать, пока у вас будут все ответы. Перестаньте пытаться понять, какое место вы займёте в мире, где ИИ стоит на первом месте. Ответ всё тот же, что и всегда: создавайте вещи. Теперь вы можете делать это быстрее, чем когда-либо могли себе представить.

Просто убедитесь, что вы знаете, где лежат ваши API-ключи.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!