Команда AI for Devs подготовила перевод статьи о том, почему Claude Opus 4.5 стал переломным моментом в ИИ-разработке. Автор на реальных проектах показывает, как ИИ-агенты уже сегодня способны собирать полноценные приложения — от UI до бэкенда — за считанные часы, и рассуждает о том, зачем человеку вообще читать код в мире AI-first разработки.
"UPD: Многие спрашивали, какие воркфлоу я использовал при разработке этих приложений. Я работал с GitHub Copilot в VS Code и кастомным агентным промптом, который вы найдёте ближе к концу этого поста. Context7 — единственный MCP, который я использовал. В основном я просто пользовался встроенной голосовой диктовкой и разговаривал с Claude. Никаких сложных воркфлоу, планирования и прочего не требовалось. Агентная обвязка в VS Code для Opus 4.5 настолько хороша, что больше почти ничего и не нужно. И работает она поразительно быстро. И да, если вдруг неочевидно — это всего лишь моё мнение. Я ошибаюсь примерно в 50% случаев, так что относитесь к этому с осторожностью."
Если бы три месяца назад меня спросили об этих утверждениях, я бы сказал, что в них может верить только человек, который никогда не создавал ничего по-настоящему нетривиального. Отличный инструмент для усиления уже существующего воркфлоу разработчика, автодополнения — мощные, но чтобы агенты полностью заменили разработчиков? Нет. Категорически нет.
Сегодня я считаю, что ИИ-агенты для программирования действительно могут заменить разработчиков. И причина, по которой я так думаю, — 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 пишет вполне крепкий код независимо от того, что ему задать. Однако, поскольку модели любят писать код ГОРАЗДО больше, чем удалять его, я периодически запускаю промпт примерно такого вида:
Проверь свои принципы LLM-ориентированного ИИ-кодинга и затем сделай комплексный анализ всего приложения. Предложи, что можно отрефакторить, чтобы лучше соответствовать этим принципам. Укажи код, который можно удалить, файлы, которые можно удалить, вещи, которые стоит переименовать, и то, что нужно переструктурировать. Затем сделай описание изменений. Держи всё на высоком уровне, чтобы это было легко читать и не слишком сложно. Добавь разделы с высоким, средним и низким приоритетом. Если что-то не нужно менять — не меняй. Не нужно менять ради изменений. Меняй только если это помогает лучше соответствовать принципам LLM-ИИ-кодинга. Сохрани в markdown-файл.
В результате получается документ с пунктами высокого, среднего и низкого приоритета. Высокие вы разбираете — и ИИ перестаёт находить их. Вы можете рефакторить проект миллион раз, и он всё равно будет находить пункты среднего и низкого приоритета. ИИ никогда, вообще никогда не упустит возможность сгенерировать ещё немного текста.
Похожий промпт я использую и для поиска проблем безопасности. Здесь нужно быть особенно осторожным. Где лежат API-ключи? Корректно ли реализован логин? Не храните ли вы чувствительные данные в базе? Это, пожалуй, самая ручная часть всего проекта и, если честно, та, которая сейчас нервирует меня больше всего. Я не уверен, что все эти приложения пуленепробиваемы. Может быть, процентов на 80. А это, как говорится, чертовски мало.
Времена меняются
Я не знаю, что чувствую сильнее: воодушевление от того, что теперь могу собирать вещи за считанные часы, или подавленность от осознания, что дело, которому я посвятил всю жизнь, стало тривиальной задачей для компьютера. Верно и то, и другое.
Я понимаю, если этот пост вас разозлил. Правда. Мне тоже не нравилось, когда люди говорили: «ИИ заменит разработчиков». Но теперь я больше не могу это игнорировать. Я могу желать, чтобы это было неправдой, но желания не меняют реальность.
Зато во всём остальном — просто делайте. Перестаньте ждать, пока у вас будут все ответы. Перестаньте пытаться понять, какое место вы займёте в мире, где ИИ стоит на первом месте. Ответ всё тот же, что и всегда: создавайте вещи. Теперь вы можете делать это быстрее, чем когда-либо могли себе представить.
Просто убедитесь, что вы знаете, где лежат ваши API-ключи.
Русскоязычное сообщество про AI в разработке
Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!
Комментарии (91)
Uolis
11.01.2026 12:17Сегодня ты не читаешь код, а завтра твоя программа, сгенерённая ИИ для постов картинок ИИ с описаниями от ИИ постит в Фейсбук детскую порнографию с прекрасным описанием, всё как ты и просил, и вдруг ты слышишь требовательный стук в дверь. Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Konard
11.01.2026 12:17Иногда читать может быть нужно, а иногда достаточно хорошо настроенного CI/CD, линтеров, тестов, чекеров безопасности и других инструментов. Чем больше автоматизации для проверки кода, тем меньше потребность его читать. А задачи от пользователей могут быть почти сразу быть направлены в разработку используя AI агентов.
Spyman
11.01.2026 12:17Бывает код вида if (time == n) { db.dropAll() }
Я конечно утрирую, но когда llm создавала граничную ситуацию там, где её нет (и не покроешь тестами) - я видел своими глазами. Не будешь же функцию с одз в long реально гонять на всех long-aх в тестах.
Dhwtj
11.01.2026 12:17Тесты как трусы: прикрывают, но не защищают.
Надо сделать невалидное состояние невозможным.
А можно пример, что там LLM накосячил?
Spyman
11.01.2026 12:17Доступа к коду этому у меня уже нет. Но упрощенно выглядело так - есть код, обрабатывающий диапазоны значений и функции для каждого из диапазонов. Условно от 1 до 10 использовать f1(x), от 11 до 20 использовать f2(x) и от 20 до 30 f3(x))
Надо было добавить пару диапазонов, LLM сделала из перекрывающимся в части диапазона (от 1 до 10 f1(x) и от 8 до 22 f2(x) ), но при этом внутрь функции f2 запихнула проверку if (x == 10 || x == 21) return;
Как итог - тесты проходили, на граничных значениях все хорошо, в центре диапазона всё хорошо, а взять значение немного у края - то сумма считается уже неправильно.
В жизни конечно код был чуть сложнее - отвечал за подсчет коммиссий. На ревью кстати было не так просто увидеть т.к. код ветвистый а изолированные функции выглядели просто и корректно. Ошибку заметили только благодаря тому, что условие проверки границ внутри функции вызывало подозрение.
MEGA_Nexus
11.01.2026 12:17Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Ахахахаха. Супер! :)
panzerfaust
11.01.2026 12:17Один нюанс: все это работает, пока антропик и прочие демпигуют, работают в минус и прожигают шальное бабло инвесторов. На чужом горбу в рай. Впрочем, ничего нового.
DmitryOgn
11.01.2026 12:17Но есть и обратная сторона - триллион на AI уже сожжен (буквально, в гигаватт-часах), чипы распаяны, ДЦ уже построены, модели уже обучены.
5% нынешней окупаемости отрасли смогут покрыть только инференс, даже в случае банкроства и распродажи ДЦ с долговых аукционов.
Т.е. в каждый момент времени можно ожидать, что уже достигнугнутый моделями уровень ниже не упадет даже с наступлением полномасштабного кризиса отрасли (на таком масштабе пузыря он неизбежно совпадет с общим финансовым кризисом).
Следствие - те, кого модели могут оставить без работы уже сейчас, они оставят без работы и в случае кризиса ИИ отрасли. Банкроство ИИ стартапов не возродит профессию переводчика текстов, например.
Исторические аналогии - банкроство железных дорог, как стартапов 19 века, не остановило железнодорожное сообщение. Построенными дорогами все равно пользовались. За исключением совсем экстремальных случаев ЖД веток в никуда.panzerfaust
11.01.2026 12:17Речь про цену данного удовольствия. Все эти пророки "новой эры" любят повторять, что "как раньше уже не будет". Хорошо, не будет. Но вся бравада строится исключительно на том, что теперь всегда будет так, как сейчас. То есть антропик теперь во веки вечные будет толкать им свой товар по 100 баксов в месяц. А если по 1000 баксов? А по 5000? Уже за 1000 баксов болтовни будет на пару порядков меньше. Какой-то вселенский закон запрещает такой исход событий? Всегда на рынке будет такая же анархия и конкуренция как сейчас? Это тоже каким-то законом предопределено?
Смотрите хотя бы опыт Яндекс такси. Сначала тоже кипятком ссали от низких цен.
xenon
11.01.2026 12:17Мне кажется, вы привели Я.Т. как пример "не в ту сторону".
ЯТ замечательно заменил бомбил и тогда и сейчас. Вы вообще часто на дороге руку поднимаете? Да, сказочно дешевый период закончился, начался просто дешевый. Он по прежнему дешевый, дешевле, чем бомбила.
А еще, мне кажется, AI отлично офшорится. Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
Wesha
11.01.2026 12:17Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
А потом решаешь зохавать какой-нибудь, например, полуостров — и обаньки...
Areso
11.01.2026 12:17На полуострове нет термальных источников. Надо взять Исландию в аренду. Там незамерзающая, но прохладная вода со всех сторон, и термальные источники. "Халявная", круглогодично-ровная генерация.
vaslobas
11.01.2026 12:17Ят монополист. Где вы видели чтобы в монополиях без контроля со стороны что-то было дешево?
DennisP
11.01.2026 12:17тут не так давно был всплеск статей (вроде и на хабре тоже было что-то) о том, что ии-ускорители выходят из строя быстрее, чем успевают окупиться, так что ДЦ сами по себе могут быть не сильно ликвидным активом.
Dhwtj
11.01.2026 12:17Это всё до появления нечётких или противоречивых требований, эдж кейсов и прочей грязи, после которой ваша сверкающая машинка быстро падает и делает громкий бум.
Только человек может выявить противоречия, сбалансировать решение, документировать для будущих изменений.
Приведенные в статье утилиты это редкое исключение когда можно делегировать LLM
Konard
11.01.2026 12:17Совсем не обязательно, у меня AI агент на нечётки и противоречивых требованиях вопросы задаёт. Но конечно если человек сам разбирается со своими противоречиями и определяет какое соотношение между крайностями дихотомий для него допустимо, то разработка идёт на порядки эффективнее.
DarthVictor
11.01.2026 12:17Я не волшебник, я только учусь, но такой подход не будет работать с чем то длиннее ТЗ в полстраницы. Ни с кремниевой нейронкой, ни с белковой. Я склонен считать, что ЛЛМки в целом уже достигли уровня человека в разработке, а вместе с этим начали воспроизводить все человеческие косяки.
Без внятного ТЗ результат ХЗ
Что вы Клод попросите реализовать, то он и реализует. Как попросите так и сделает. Из самых лучших побужденией. Откуда ей знать какой будет у вашего проекта трафик? Фрилансеру из Бангладеш хотя бы бюджет известен.
Теория разбитых окон в разработке
ЛЛМка честно пытается воспроизвести что-то похожее на то, что у вас было. При этом если было до этого 10-летнее легаси, то она по умолчанию его и выдаст. Если вы хотите, чтобы было написано иначе сформулируйте правила соответствующим образом.
Ваши договорённости с вашим джуном известны только вам и вашему джуну.
Новый джун, что нейросетевой, что мясной их знать не будет. Тем более новый джун с новым наставником. Просите его это корректно документировать и вносить в соответствующие правила. Контекст проекта не должен состоять из одного кода.
Приказ понял? Повтори как понял!
Просите нейронку объяснять как работает имеющийся код, проверяйте её объяснения, записывайте и импортируйте в AGENTS.md наиболее важные вещи. Проверяйте её объяснения, сверяйте её структуры и API.
Делегирование бывает разных уровней
Освоив работу с LLM-кой последовательно, начинайте делегировать задачи более высокоуровневым агентам. При этом вы сможете меньше проверять код из под LLM-ки, например код внутри методов (Да, бл..дь! Его всё ещё надо было поглядывать), и чуть больше успевать. Но придётся лучше формализовать уже порядок работы с нейро-джунами со стороны нейро-сениоров.
То что кто-то ошибается в 10% случае, когда вы ошибаетесь в 3%, не делает его хуже
В такой ситации значительно важнее, что его 10% и ваши 3% могут не пересекаться.Скрытый текст
Моя статистика с работы за последнюю неделю Konard
11.01.2026 12:17Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию. Даже сегодня любой ИИ агент запросто способен разбить любое ТЗ на задачи, причём так, чтобы максимизировать параллелизм в разработке, то есть планировать задачи таким образом, чтобы множество других агентов или людей могли работать над задачами параллельно, не пересекаясь по функционалу, что минимизирует конфликты.
Таким образом благодаря этому алгоритму можно добиться того, что любое ограничение контекста больше не является проблемой. А учитывая с какой скоростью ИИ агенты закрывают задачи, сколько бы потом не было багов - это можно компенсировать добавлением тестов после каждого бага, чтобы он никогда не повторялся и в итоге система будет стремиться к полному покрытию тестами и легко может разрабатываться используя в том числе исключительно AI агентов.
edta_ff
11.01.2026 12:17можно декомпозировать, можно повторять, можно написать, будет готово решение, агент способен, можно добиться, можно компенсировать, может разрабатываться.
вот бы прочитать статью о том, как все это декомпозировано, повторено, написано, решено, добыто, компенсировано и разработано?
geirby
11.01.2026 12:17Я это сделал при работе над своим agentic framework, решая тяжелую задачу в одиночку, которую пара команд не осилила за два последних года из-за плохой организации работы как раз вот в этой области: планирование, декомпозиция, гапсы и проч.
чтобы не быть голословным
Планирую за этот месяц закончить эту задачу. Без агента было бы непосильно, просто из-за количества времени на этап планирования, которое менджмент просто не одобрил бы. Но для того, чтобы его так использовать, я два месяца разрабатывал как раз фреймворк, просто plain usage какой угодно "дорогой" модели/агента это просто токены жечь.
Не уверен, что хочу писать об этом целую статью, поскольку проект фрейморка в стадии PoC, хочу убедиться, еще на паре "тяжелых" бизнес-задач, что это работает (мультиагентность и оркестрация в том числе), до промышленного внедрения еще полгода или больше. Просто поверьте, что подход разбития ТЗ на задачи агентом работает, хорошо грумит гапсы между легаси ТЗ и тем, что уже ушло дальше (бизнес-фичи поменяли codebase), хорошо раскладывает горизонтальные и вертикальные имплементации. Выявляет параллелизацию. Умеет оркестрировать.
Я не профи в использовании agentic swe, возможно, можно уйти и дальше. В чатиках пишут про бесконечные циклы решения задач от первого промпта/ТЗ до деплоя. Может, и врут, но заманчиво.
Spyman
11.01.2026 12:17любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов
Один из ключевых тезисов теории систем и системного анализа говорит о том, что свойства системы не равны сумме свойств всех её частей.
Проводя декомпозицию задачи по уровням, вы теряете контекст применения, из-за чего, конечная подзадача, на глубине нескольких подуровней, может не отражать или отражать неверно/избыточно первоначальную часть задачи.
Проблемы которые будут:
Часто - избыточная алгоритмическая сложность (квадратичный/экспоненциальный алгоритм вместо линейного например)
Редко - избыточное переусложнение кода в результате расширения одз (нужна функция решающая частные случаи, при сегментации задачи остаётся подзадача решающая все случаи)
А если делать это с помощью llm - появляется ещё одна вероятность - придумывание контекста (когда режешь задачу на подзадачи и даёшь llm узкий сценарий, она будет реализовывать решение в контексте наиболее вероятного в выборке обучения, что может сильно не совпадать с реальностью)
Так что на бумаге звучит отлично, на практике имеет ограниченную применимость
EmCreatore
11.01.2026 12:17Эмерджентность не доказана!
Пока что успехи моделирования говорят о том, что свойства систем полностью определяются свойствами ее составляющих.
Проблема только в мощности моделирующей машины. Т.е. в конечном счете в энергии.Spyman
11.01.2026 12:17Если нет математического доказательства, это не значит, что нет самой проблемы. Есть масса примеров от поведения молекул, до колоний насекомых.
Можно конечно упереться и сказать что мы недостаточно моделируем, но на примере простых задач - например знаменитой задачи трёх тел - можно заметить что далеко не всё мы можем смоделировать как минимум сейчас. Значит в практическом случае для нас все равно она есть.
В программах ситуация когда каждый блок в тестах ведёт себя корректно, а система в целом нет, не новость - когда речь про сложные асинхронные системы.
proxy3d
11.01.2026 12:17Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
def change_formants_shifts(signal, sr, formant_shifts, formants=None): """ Изменяет частоты формант в аудиофайле на фиксированное значение для каждой форманты. """ if formants: frequencies = formants["frequencies"] times = formants["voiced_times"] else: frequencies, times, _, _ = formant_frequencies(signal, sr) # Определение функции для получения новой частоты форманты def get_new_formant_freq(original_freq, formant_num): if original_freq <= 0: return original_freq return original_freq + formant_shifts[formant_num] # Создание нового объекта звука для изменённого звука modified_signal = np.copy(signal) # Итерация по каждому временно́му шагу и изменение частот формант for t_idx, t in enumerate(times): for i in range(5): # Форманты F1 до F5 original_freq = frequencies[i][t_idx] if original_freq > 0: # Убедиться, что частота форманты действительна new_freq = get_new_formant_freq(original_freq, i) # Расчёт коэффициента ресэмплинга resample_ratio = new_freq / original_freq # Регулировка значений звука вокруг частоты форманты segment_start = max(0, int(t * sr) - int(sr / 50)) segment_end = min(len(signal), int(t * sr) + int(sr / 50)) segment = signal[segment_start:segment_end] # Ресэмплинг сегмента для изменения частоты форманты resampled_segment = resample(segment, int(len(segment) * resample_ratio)) # Регулировка длины для соответствия оригинальному сегменту if len(resampled_segment) > (segment_end - segment_start): resampled_segment = resampled_segment[:segment_end - segment_start] elif len(resampled_segment) < (segment_end - segment_start): pad_width = (segment_end - segment_start) - len(resampled_segment) resampled_segment = np.pad(resampled_segment, (0, pad_width), mode='constant') # Добавление ресэмплированного сегмента к изменённым значениям modified_signal[segment_start:segment_end] = resampled_segment modified_signal = np.clip(modified_signal, -1, 1) return modified_signal, srВы хоть обложитесь сотней агентов, они не сделают.
Напишут они код? Да напишут.
Будет он делать то что нужно? Нет.
Могут в этом помочь отладчики или консоль или что-то еще? Нет.
Знают ли модели о проблемах, если начать разбирать их код? Конкретно о каждой проблеме они всегда что-то напишут.
Могут ли они сразу перечислить все возможно проблемы, чтобы учесть их? Нет.То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
Konard
11.01.2026 12:17Вероятно с этим смогут справиться будущие модели, которые добавят на вход и на выход аудио модальность. Так или иначе для таких конкретных моментов можно использовать подход human in a loop, то есть настроить с машиной взаимодействие так, что единственное на что она будет отвлекать внимание человека, это на обратную связь по аудио файлам. С другой стороны в некоторых случаях, вероятно уже есть модели с аудио модальностью и можно это решить сочетая несколько нейросетей вместе, что само по себе тоже задача, которую вероятно AI агент мог бы решить, если бы у него возникли бы сложности подсказки от человека помогли бы.
Alexsey
11.01.2026 12:17Замените пример proxy3d на любую другую не стандартную (не обязательно даже узкоспецилизированную) задачу и получите тот же результат. Так и будем надеятся на абстрактные будущие модели каждый раз?
Даже я, как человек никогда не занимавшийся rocket science, за свою карьеру делал достаточно задач, которые нейронки не осилят (или умножат время разработки на x2 и более) просто потому что это задачи редко встречающияся за пределами определенных отраслей и в случаях, близким к 100%, эти задачи не имеют готовых не-коммерческих решений на которых можно было бы обучить LLM.
Я понимаю, что большая часть работы программистов в конторах среднего звена - это перекладывание json'ов и круды и вот с этим LLM уже научились более-менее прилично справляться (и то за бездумные коммиты LLM кода я бы бил бы по рукам разрабу на код ревью), но есть и другие задачи.
Dron007
11.01.2026 12:17В этих редко встречающихся задачах что, какие-то уникальные принципы программирования используются, которые в других задачах не встречались? Не думаю. А значит LLM сможет их применить в новой предметной области.
Alexsey
11.01.2026 12:17Вам уже выше пример привели, вам мало этого?
Вы меня извините, но после комментирования в десятке статей про LLM у меня начало складыватся впечатление, что люди по другую сторону баррикад уже и чтение комментариев отдают LLM.
Dron007
11.01.2026 12:17Вообще да, мало. Одиночный пример на основе малоизвестной библиотеки, который не проверить, без промптов, без полного описания задачи совсем неубедителен. Вполне возможно, что при правильных промптах модель вполне себе сделает что нужно, к тому же с каждой версией модели новые возможности обретают. Но одни используют вполне в работе, другие - свято верят, что дальше "Hello world" модели ни на что не способны в принципе.
geirby
11.01.2026 12:17Простите, я из чистого любопытства, не обладая никаким знанием предметной области, и посредственным знанием (прикладным) Python, попытался что-то получить исходя из поставленной задачи "Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту".
Код совершенная чушь или как утверждает модель -- "другой подход"?shift_formant_in_lpc
import numpy as np def shift_formant_in_lpc(lpc_coeffs, sample_rate, formant_index, shift_hz): """ Сдвигает указанную форманту на заданное количество герц. formant_index: 0 = F1, 1 = F2, и т.д. shift_hz: на сколько сдвинуть (положительное — вверх, отрицательное — вниз) Возвращает новые LPC-коэффициенты. """ # Находим корни полинома roots = np.roots(lpc_coeffs) # Переводим в полярные координаты (частота, magnitude) angles = np.angle(roots) magnitudes = np.abs(roots) freqs = angles * sample_rate / (2 * np.pi) # Находим пары сопряжённых корней с положительной частотой # и сортируем по частоте, чтобы найти нужную форманту positive_mask = freqs > 0 positive_indices = np.where(positive_mask)[0] # Сортируем индексы по частоте sorted_indices = positive_indices[np.argsort(freqs[positive_indices])] # Фильтруем: оставляем только "настоящие" форманты (90-5000 Hz) formant_indices = [] for idx in sorted_indices: f = freqs[idx] bw = -np.log(magnitudes[idx]) * sample_rate / np.pi if 90 < f < 5000 and bw < 500: formant_indices.append(idx) # Проверяем, есть ли нужная форманта if formant_index >= len(formant_indices): # Форманта не найдена — возвращаем без изменений return lpc_coeffs # Индекс корня, который будем сдвигать root_idx = formant_indices[formant_index] # Текущая частота и новая частота old_freq = freqs[root_idx] new_freq = old_freq + shift_hz # Ограничиваем разумным диапазоном new_freq = np.clip(new_freq, 90, sample_rate / 2 - 100) # Новый угол new_angle = new_freq * 2 * np.pi / sample_rate # Модифицируем корень (сохраняем magnitude, меняем угол) roots[root_idx] = magnitudes[root_idx] * np.exp(1j * new_angle) # Находим и модифицируем сопряжённый корень # (он имеет ту же magnitude и противоположный угол) conjugate_idx = np.where( (np.abs(magnitudes - magnitudes[root_idx]) < 1e-10) & (np.abs(angles + angles[root_idx]) < 1e-10) )[0] if len(conjugate_idx) > 0: roots[conjugate_idx[0]] = magnitudes[root_idx] * np.exp(-1j * new_angle) # Пересчитываем коэффициенты из корней new_coeffs = np.real(np.poly(roots)) # Нормализуем (первый коэффициент должен быть 1) new_coeffs = new_coeffs / new_coeffs[0] return new_coeffs def shift_formant_all_frames(lpc_coeffs_all, sample_rate, formant_index, shift_hz): """ Применяет сдвиг форманты ко всем фреймам. """ new_lpc = np.zeros_like(lpc_coeffs_all) for i, lpc in enumerate(lpc_coeffs_all): new_lpc[i] = shift_formant_in_lpc(lpc, sample_rate, formant_index, shift_hz) return new_lpc # Использование audio, sr = load_audio("input.wav") frames, hop = split_into_frames(audio, sr) lpc_coeffs, gains = analyze_frames(frames, lpc_order=16) # Сдвигаем F2 на +200 Hz new_lpc_coeffs = shift_formant_all_frames(lpc_coeffs, sr, formant_index=1, shift_hz=200) # Проверяем, что форманты изменились old_formants, _ = extract_formants_from_frames(lpc_coeffs, sr) new_formants, _ = extract_formants_from_frames(new_lpc_coeffs, sr) print(f"F2 до: {np.nanmean(old_formants[:, 1]):.0f} Hz") print(f"F2 после: {np.nanmean(new_formants[:, 1]):.0f} Hz")объяснение моделью разницы между сгенерированным кодом и вашей функцией
уже достаточно поздно, поэтому я просто отложил в сторону этап глубокого изучения предметки, чтобы что-то понимать, это буквально один проход за сеанс. Но если бы передо мной стояла такая задача, то я решал бы ее как раз через создание базы решения, в том числе грумил бы вопрос относительно валидации результатов, вроде создания синтетических тестов.
Отдельно хочу указать, что я не ставил себе задачу опровержения вашего комментария, просто любопытно, где же все таки границы решения задач: в подготовке самой модели или в наших собственных руках.
-- модель opus 4.5.
Dron007
11.01.2026 12:17А вы уверены, что код верный, а то три нейросети (Claude Opus 4.5 thinking, Google Gemini 3 Pro, ChatGPT 5.2 Thinking) дружно его критикуют? Они могут ошибаться, но как правило всё-таки находят узкие места. Я не разбираюсь ни в этой библиотеке, ни в Python и не хочу быть испорченным телефоном, но всё же рекомендовал бы спросить что они думают о коде и почитать, вполне возможно что выявятся скрытые проблемы. Например, они утверждают, что это некорректный сдвиг, что будут артефакты, что есть неэффективность по производительности. Когда разные модели солидарны, это как правило признак какой-то проблемы.
okhsunrog
11.01.2026 12:17Что вам не нужно: имена переменных, форматирование, комментарии для людей или паттерны, придуманные только для того, чтобы пощадить ваш мозг.
Ну-ну. То есть, вы утверждаете, что ИИ не нужен читабельный код? Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код? Sweet summer child...
А ещё я бы не разделял код на "оптимизированный для LLM" и "оптимизированный для человека". LLM обучили работать с кодом так же, как это делает человек. Они так же юзают grep для навигации по кодовой базе, запускают тесты, линтер, читают логи, анализируют коды ошибок. Если кодовая база написана хорошо, есть тесты, правильное разбиение на модули, логирование, правильная обработка ошибок - то поддерживать это будет легко как человеку, так и нейронке. Если код изначально написан плохо - то плохо будет для обоих. Но только опытный разработчик может решить, что пора всё отрефакторить, переписать. Выкинуть старую архитектуру на определённом этапе и сделать хорошо. А нейронка будет вставлять костыли, фиксить одно, и в то же время ломая другое.
Konard
11.01.2026 12:17Для ИИ нужен так же как и для людей хороший CI/CD который гарантирует что код читается и нужного качества. И самое критичное скажем для Claude Code CLI агента, это то, что если CI/CD требует чтобы каждый файл с кодом или документацией будет меньше 1500 строк, то у Claude Code CLI будет намного больше шансов прочитать его целиком, а следовательно полностью осознанно сделать правки. Плюс такое ограничение вынуждает агента разделять код на файлы. В общем все те лучшие практики программирования которые накапливали люди за это время на текущий момент применимы так же, и иногда даже критичнее для AI чем для людей.
Cheater
11.01.2026 12:17Качество кода - это несколько более широкое понятие, чем просто разбить код на небольшие читаемые куски. Это какая же CI/CD система способна например определить, что код нарушает принцип open/close, или что там захардкожено что-то что захардкожено быть не должно, или что библиотека даёт вызывающему возможность парой вызовов апи привести данные в неконсистентное состояние? Пусть этот код даже разбит на вылизанные куски и снабжён мильоном .md документов?
EmCreatore
11.01.2026 12:17То есть, вы утверждаете, что ИИ не нужен читабельный код?
Да , так и есть.
Мне Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались), идеально разбирается в их структуре. Не требуя никаких подсказок.
Но да, иногда делает осечки.
Но это такая милая мелочь и одновременно спасительная.
Потому что не делай он их, нам бы всем уже пришел конец.okhsunrog
11.01.2026 12:17Ну, если вы работаете джейсоноукладчиком – тогда AI вполне может справиться со всеми вашими задачами.
holgw
11.01.2026 12:17Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались)
У вас сравнение сломанное. XML\JSON декларируют только структуру, но не логику. А анализ исполняемого кода это не только парсинг синтаксического дерева.
cher11
11.01.2026 12:17Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код?
На самом деле - читать вполне сможет, правда. Ради интереса скармливал исходники Java игр и приложений, восстановленные из class-файлов. То есть это как раз огромные функции, с кучей переменных
aa,bb,cc, с проблемами типизации (в Javaint aиdouble a- разные переменные и в выводе такого - дофига). Сходу человеком это не читается вообще никак.И съев эту мешанину она радостно говорит - вот, функция aB() это обработка выстрела, а переменная bC хранит здоровье, а вот в c и d - хранятся координаты блоков уровня.
Можно даже в бесплатном DeepSeek попробовать, реально работает.
Konard
11.01.2026 12:17А я благодаря Claude Opus и Claude Sonnet больше не пишу код руками, не требуется его теперь и читать тоже, так как всегда можно задавать вопросы AI агенту. Уже более 6 месяцев я разрабатываю своего бота программиста используя Claude модели, и всё это время все свои 500+ репозиториев в open-source и в общественном достоянии поддерживаю используя этого самого бота-программиста, который мне Claude и помог написать. По сути для меня это означает первый реальный шаг к автоматизации автоматизации. Ну и конечно сам бот-программист тоже с открытым кодом и в общественном достоянии. Для меня это первое ПО, которое способно писать себя самостоятельно. Так что я очень доволен что появился ИИ и из программиста я больше трансформировался в тех-лида, который теперь принимает Pull Requests от ИИ и людей. А моя разработка фактически в одиночку помогла мне догнать и обогнать продукты крупных корпораций.
Если раньше я нанимал программистов, чтобы они помогали мне разрабатывать опенсорс проекты, то теперь такой мысли вообще не возникает. AI-агент, который интегрирован с GitHub фактически заменяет человека программиста в привычном мне flow - создать issue - сделать ревью Pull Request и смержить. Теперь я могу больше сфокусироваться на планировании и архитектуре, и поддерживать куда больше опенсорсных проектов фактически в одиночку. Поэтому с приходом ИИ ощущается что за $200 подписки Claude MAX я нанял себе целую команду разработки, которая готова работать по запросу 24/7. И разрабатывает код в десятки раз быстрее чем многие junior и middle программисты. Я может быть плохой senior программист, но за 25 лет программирования я не научился писать код вручную быстрее и точнее чем это делают AI агенты. Зато если их тех-лидить получается эффективнее на порядки.
Andchir
11.01.2026 12:17больше не пишу код руками, не требуется его теперь и читать тоже
Но, думаю, Вы знаете язык программирования, на котором Claude пишет код, на довольно хорошем уровне, поэтому у Вас есть возможность ставить задачи максимально понятным языком и со всеми подробностями, необходимыми для решения задачи. Значит ли это, что программисты пока могут спать спокойно или в будущем всё-таки знание языка будет не нужно?
vaslobas
11.01.2026 12:17все свои 500+ репозиториев в open-source
Даже страшно представить что там.
Andchir
11.01.2026 12:17Зачем представлять, если можно посмотреть, а потом написать действительно полезный комментарий?
Newbilius
11.01.2026 12:17Так ссылку на эти 500+ репозиториев ни в комментарии, ни в профиле автора нет. Покажет - почитаем)
Andchir
11.01.2026 12:17В профиле есть, в разделе "Контактная информация".
P.S. Ниже даже кто-то пишет, что не смог найти ссылку на оригинал статьи, это печально.
Konard
11.01.2026 12:17
Universal problem solving algorithm Показываю:
IlyasA74
11.01.2026 12:17Картинка похожа на x в степени N, где x == 2 только в лучшем случае. Типичный комбинаторный взрыв.
bak
11.01.2026 12:17Как и ожидалось - какая-то непонятная никому не нужная хрень. Зачем на такое спускать дохулиард токенов - уму не постижиму, такую дичь можно генератором случайных чисел нагенерировать.
constXife
11.01.2026 12:17ну вот у меня тогда более понятная (и нужная мне) хрень — парольный менеджер, ибо меня не устраивал bitwarden и его экосистема + хотелось аналог hashiecorp vault, но для "маленьких". Сейчас активно всё причёсываю, думал потом может более статью написать, не про очередной "смотрите как LLM умеет", а про сам пет проджект, может кому-то тоже пригодится.
● podman-zann.service Loaded: loaded (/etc/systemd/system/podman-zann.service; enabled; preset: ignored) Active: active (running) since Tue 2025-12-30 13:06:39 +04; 1 week 5 days ago Invocation: 5f9c57b203a8480382f0a639cb9808ea Main PID: 1722521 (conmon) IP: 10.1K in, 5.9K out IO: 0B read, 180K written Tasks: 1 (limit: 18808) Memory: 608K (peak: 11.6M) CPU: 326ms CGroup: /system.slice/podman-zann.service
nin-jin
11.01.2026 12:17Я прям читал и плакал. Реальность несколько более прозаична: тривиальные изменения с 5 попытки, а сложные - проще самому сделать, чем объяснить ему, что не так.
Konard
11.01.2026 12:17Смотря у кого :)
Пока что я вижу что более 80% pull requests завершаются мержем, а не закрытием :) Как получилось, что для тебя наш бот-программист не сработал для меня пока загадка.
Alexsey
11.01.2026 12:17Сомнительный повод для гордости. Вы же понимаете что стандарты качества у набора рандомных репо на гитхабе заметно ниже, чем в любой адекватной компании?
С вероятностью, приближающейся к 100%, почти все репозитории куда приняли эти PR сделаны в стиле "хуяк-хуяк и в продакшен" людьми, прямо скажем, не очень высокой квалификации. Гордиться что у вас люди непонятной квалификации принимают любой PR пока он вроде бы что-то делает и вроде бы даже правильно - ну такое себе.
nin-jin
11.01.2026 12:17Взял первый попавшийся смерженный не совсем нетривиальный реквест: https://github.com/konard/telegram-bot/pull/8
Там два изменения: одно по теме задачи, а второе, внезапно, - какие-то адовые костыли с подавлением варнинга, вместо того, чтобы закинуть пр с фиксом в gramJS, который эти варнинги и вызывает.
Astrowalk
11.01.2026 12:17У меня голова заболела от одной попытки прочесть diff. И на это люди променяли право первородства...
Wesha
11.01.2026 12:17все свои 500+ репозиториев в open‑source
«У нас есть такие приборы!..
Но мы вампро них не расскажемих не покажем.»Konard
11.01.2026 12:17Показывал в комментарии выше https://habr.com/ru/articles/984026/comments/#comment_29367614. Рассказать могу - могу ответить на вопросы.
А вообще бот-программист, которого я делаю с его же собственной помощью вот тут: https://github.com/link-assistant/hive-mindgeirby
11.01.2026 12:17Похоже, мы работаем в одном направлении, но с абсолютно разными принципами
На мой взгляд ваша архитектура отражающая принцип, который я называю "перпетуум мобиле" имеет существенную уязвимость для промышленного решенияздесь
Скорее даже ваша архитектура противоречит вашему же манифесту в bio:
Формулировка проблемы. Этот шаг предполагает полное понимание и определение проблемы, которую необходимо решить
Issue не является "формулировкой". У вас полностью пропущен этап анализа. Либо задачи не энтерпрайз уровня, либо вы его создаете в каком-то другом флоу и формируете как issue. Мы приходим в PR непонятно с чем. С подброшенной монеткой, а не с "полным пониманием проблемы, которую необходимо решить". Может, закрыли баг с кнопкой, а может, десяток других, которые на тестах не видны, создали. Я как инженер зачем такой PR смотреть буду? Чтобы помянуть незлым тихим словом постановщика задачи?
Konard
11.01.2026 12:17Анализ нужен не всегда, и анализ может быть отдельной задачей и даже частью её как один из шагов. В целом на картинке анализ есть, и без анализа AI агент не может даже приступить к задаче, ведь ему нужно оглядеться, посмотреть что происходит и понять что ему делать, составить свой план и т.п.
Я также могу просто попросить провести анализ в issue, и как только он проведён в этом или отдельном Pull Request я могу попросить комментарием реализовать один из вариантов решений и т.п.
На текущий момент конечно же это Proof of Concept, и цель прежде всего дать возможность встроить похожую на программиста сущность в процесс разработки. Но универсальный алгоритм решения задач и проблем реализован на текущий момент не полностью. Если интересно можете посмотреть открытые issues (там можно обнаружить примерный roadmap разработки) или если хотите испытать эту систему в действии можете написать мне в личку.
Если говорить о том как я работаю то обычно это выглядит так: я ставлю задачу, и если считаю что она требует глубокого анализа то изначально задача ставится буквально так - провести анализ, а как только анализ проведён я могу либо в этом же Pull Request, либо уже в отдельном сделать само решение. Иногда бывает я ставлю задачу составить план реализации и по этому плану ставлю задачу создать все задачи с учётом зависимостей, чтобы у меня был полный план разработки с максимальным параллелизмом между задачами. Ведь одно из удобств системы в том, что можно запускать множество задач для решения одновременно.
То есть я ставлю задачи, если Pull Request нужно доработать я даю комментарии и отправляю агента дорабатывать. Для меня основное преимущество в том, что пока агент работает самостоятельно, а это обычно 15-35 минут рабочая сессия, он никак не отвлекает на себя моё внимание и я могу заниматься чем-то ещё. То есть у него достаточно времени чтобы провести свой анализ ситуации, провести эксперименты, и набросать черновик решения, иногда бывает что он справляется задачей с первого раза, иногда с 4-5 итераций обратной связи, в среднем за 2-3.
То есть я как инженер прихожу в Pull Request чтобы проверить а соответствуют ли предложенные правки требованиям заданным в задаче, соответствует ли код нужному мне уровню качества и т.п. Да, бывает я совершаю ошибки в постановке задачи, за это действительно приходится платить дополнительными комментариями к Pull Request, но так или иначе этот флоу позволяет завершить задачу до конца.
И как я уже говорил, это намного быстрее чем если ждать результата от программиста - часами или днями или что хуже студент может быть настолько занят учёбой что сделает задачу через несколько месяцев. А его ещё и обучать нужно было и даже мотивировать деньгами.В целом я предпочитаю не оценивать, поэтому словами я обычно не поминаю. Меня интересуют только факты, и результат, и способы его достижения.
Так или иначе конечно чем меньше задача - тем больше шансов что с ней AI агент справится. Но сам анализ в моём понимании это тоже задача, планирование задач это тоже задача и т.п.И лично я субъективно не вижу уязвимостей для промышленного решения, так как именно с промышленной разработкой Claude Code CLI + Claude Opus 4.5 на моём опыте и под моим управлением справлялся. А сам Hive Mind, буквально интегрируется с GitHub таким образом, чтобы в промышленный процесс разработки ПО встраиваться. И в сочетании с CI/CD настроенной для поддержки команды разработки из ИИ и людей - это работает буквально как часы или хорошо выстроенный промышленный процесс.
VM1989
11.01.2026 12:17А $2000 в месяц готовы за это отдавать? Когда владельцы Claude захотят выйти на окупаемость и поднимут цену на услуги
Dava92
11.01.2026 12:17Пост вроде должен был быть про Claude Opus 4.5 а в итоге "как я сгенерировал несколько простых приложений" - вау - вроде это можно было делать и раньше с помощью no-code платформ или для продвинутых взять из ГХ
Mox
11.01.2026 12:17Почему-то все преимущества AI оказываются "я с 0 сгенерил апп", а под этот шумок предполагается что он он также хорошо работает с многолетней кодовой базой, где куча зависимостей, ничего не случайно и ничего просто так не поменять.
Я уже много раз сталкивался с тем, что ИИ просто чуть переписывает функцииEmCreatore
11.01.2026 12:17Чес говоря, только с такими кодовым базами и работаю. Которым по 10-15 лет и больше.
Claude нормально с ними справляется.
Да, он получив 3000 файлов , отказывается прямо все просматривать. Но по частям за полчасика , вычищает любые конюшни. С одной среды разработки в другую переводит. Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д. и т.п.Dhwtj
11.01.2026 12:17Пример бы
Вероятно, у вас нет кода "так исторически сложилось, никто не знает почему именно так", где эксперты ушли и ответить не смогут, а легаси код всё же работает и вы не сможете доказать что ничего не сломается при переделке
Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д.
Сложность ниже среднего
MaxOsstin
11.01.2026 12:17На работе нужно было сделать специфичный конвертор файлов. Гемини мне сделал скрипт, но GUI не смог сделать. OPUS сделал с первой попытки, 1600 строк кода. В программировании я понимаю только как установить Python и всякие библиотеки.
xenon
11.01.2026 12:17А я вот сегодня долго мучал и встроенного гитхабовского агента в vscode, и cursor. Нужно было сделать простой тест "с подковырочкой". Скачать тестовый файл через socks5 прокси со "спуфленным" SNI/Host хидером. (оп-па, задачка простая, но не самая типовая). Задолбался, и сделал ручками.
Вот так и будет с любым ИИ проектом. Он будет блестеть и сверкать пока он простой, но как только возникает первая запердыка в нем - проще все с нуля переписать.geirby
11.01.2026 12:17Я не делал специальных тестов, но, есть ощущение, что гитхабовские модели квантитизованные. Гитхабовский sonnet "плавает" на проверке обычного симлинка (не смотрит оттуда документацию), в то время как его "оригинальный" собрат логично продолжает просмотр симлинка как директории после определения в 10 из 10 случаев.
Astrowalk
11.01.2026 12:17Но как без знания программирования прочесть сгенерированный код? Или запускаете так? Ведь ни один набор тестов не гарантирует корректность.
Konard
11.01.2026 12:17Если мы переживаем о безопасности - можно запустить в виртуальной машине. И проверять конечно же запуском, а как иначе проверять? :) И если ручной тест показывает что юнит тесты проверяют не то - значит нужно юнит тесты поправить и со всем этим Opus справляется, ему нужно только дать эту самую обратную связь о требованиях - как должно быть и как быть не должно. Тоже самое как с обычным программированием - написал код-черновик-гипотезу - запустил - проверил - понял что не то, понял почему и как не то - исправил - перезапустил.
MaxAkaAltmer
Да, хреново когда не знал, да еще и забыл...