Pull to refresh
4
Феликс Косолапов@ratnik

Инженер, архитектор, технический лидер

Send message

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

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

Мы приближаемся к ситуации, когда проекты, занимавшие годы, будут делаться за недели, а огромное количество привычных программ и SaaS-сервисов потеряет смысл. Особенно показателен здесь замысел Macrohard: Маск хочет не просто создать ещё одного помощника для программиста, а воспроизвести работу целой софтверной компании силами ИИ. Одни агенты будут писать и проверять код, другие - пользоваться программами через экран, мышь и клавиатуру, как это делает человек. По сути, речь идёт о полностью машинном производстве софта.

Даже если именно Macrohard не выстрелит, направление уже обозначено. Следующий шаг - исчезновение программ как постоянных продуктов. Вместо покупки CRM, редактора или бухгалтерской системы агент будет за минуты собирать одноразовое приложение под конкретного человека и конкретную задачу. Возможно, потеряют актуальность и современные языки программирования: зачем агентам код, удобный для чтения человеком, если можно создать низкоуровневый язык, оптимальный исключительно для машин?

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

Я бы начал с оригинального кейса авторов Agent Orchestrator.
https://composio.dev/blog/the-self-improving-ai-system-that-built-itself

Там интереснее смотреть не на громкие цифры, а на сам процесс: как агентам раздавали отдельные задачи, как их работа проходила через pull request и CI, как ошибки и замечания возвращались обратно агенту и где всё-таки подключался человек.

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

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

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

То есть нейросети, возможно, не отменяют правило «быстро, качественно или дёшево», а заметно поднимают планку. Теперь можно получить больше по всем трём направлениям, но новые проблемы проявляются позже - на этапе поддержки, развития и контроля системы.

Главное прозрение в том, что сильный агент без инфраструктуры - это не разработчик, а очень быстрый источник правдоподобных ошибок. Ему нужны внешняя память, независимая проверка, ограничения прав и формальные условия остановки. Иначе рост скорости ничего не даёт: система просто начинает быстрее производить технический долг, уязвимости и решения, за которые никто не успел осознанно взять ответственность.

Information

Rating
Does not participate
Location
Ростовская обл., Россия
Date of birth
Registered
Activity

Specialization

Фронтенд разработчик, Фулстек разработчик
Ведущий
JavaScript
TypeScript
React
Node.js
Next.js
Ruby on Rails
PostgreSQL
Создание архитектуры проектов
C++