Обновить

300 дней с AI-агентами: от руководителя к Full Cycle Engineer

Уровень сложностиПростой
Время на прочтение19 мин
Охват и читатели17K
Всего голосов 35: ↑24 и ↓11+15
Комментарии17

Комментарии 17

скоро актуальнее будут статьи для экстремалов типа - 300 дней без ИИ

Возможно, но это уже будут статьи для хабов "Сделай сам" или "Старое железо" ) Точно не про промышленную разработку.

типа как использовать старый гугл поиск

или для любителей антиквариата - документацию

Кстати, про поиск и документацию — это уже происходит.

Google сам заменяет результаты поиска AI-ответами. Perplexity даёт готовый ответ вместо десяти ссылок. Логичное изменение пользовательского опыта.

С документацией то же самое. На сайте Cursor, например, в разделе документации встроен диалоговый режим — не обязательно читать, чтобы получить ответ на свой вопрос - можно сразу спросить. И получить ответ со ссылками на разделы в документации.

Раньше узкое место было — написание кода. Теперь оно смещается в сторону постановки задач. Документация, поиск, код — всё трансформируется в одном направлении.

Статью не читал, это оффтоп комментарий, что-то наболело уже... извините.

На Хабре есть функционал подписаться на тег для ленты. А есть где-нибудь функция чтобы отписаться от тега? Сделать так, чтобы статьи с определенным тегом не показывались в ленте.

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

ps: как же этот слоп достал

Очень вдохновляет ваш путь! Как студент, начинающий во фронтенде, ценю такой опыт. Жду подробностей о практиках работы с ИИ

26 декабря 2025 года Андрей Карпатый — сооснователь OpenAI, экс-директор AI в Tesla, автор термина "vibe coding" — написал в Twitter:

"I've never felt this much behind as a programmer"

На следующий день ответил Борис Черный — создатель Claude Code, Principal Engineer:

"In the last thirty days, I landed 259 PRs. Every single line was written by Claude Code. The last month was my first month as an engineer that I didn't open an IDE at all."

Создатель одного из самых успешных AI-инструментов в истории — перестал открывать IDE и писал код самостоятельно.

Оба твита набрали 20 миллионов просмотров и активно обсуждались в сообществах.

И вот что еще интересно:

«Newer coworkers and even new grads that don't make all sorts of assumptions about what the model can and can't do — are able to use the model most effectively.»

Ну, Claude Code - это обычная CLI утилита, которая API дергает, нет там такого кода, который был бы невероятно сложен, от того даже бездушная LLM может с ним спокойно справиться)

А в остальном, это ж чисто продуктовые твиты, которые нацелены на маркетинг, ибо оба человека работают в среде ИИ и им невыгодно, чтобы эта тема умерла :)

Можете кидать камнями, но не вижу я ничего кайфого в том, чтобы просто работать PM для LLM и отходить от всего технического, тем самым не расширяя свои знания и кругозор. А про то что TODO-листы надо составлять для LLM и стараться по спеке работать - так это и до LLM было)

---

P.S. А вообще, если честно, наскучила вся эта тема с ИИ. Не узнал ничего нового из статьи. Было б даже интересней следить за тем, как бы вы без LLM за 300 дней выучили технологии, да сделали бы пару проектов, сейчас уже наверное каждая вторая статья на хабре - повторение документации Claude Code и AGENTS.md без каких-либо интересных моментов

P.S.S. Ну и термин "Full Cycle Engineer" вы конечно интересно подобрали. Можно было бы гордиться, если бы вы это всё без LLM могли, а так можно себя называть "Full Cycle Prompter", от инженерии тут мало что есть

Несколько мыслей по вашему комментарию.

Про Claude Code как "обычную CLI-утилиту"

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

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

Про "маркетинговые твиты"

Оба автора имеют огромную репутацию в инженерном мире. Им не надо создавать хайп вокруг своей деятельности.

Про "PM для LLM" и технические знания

Бизнесу и пользователям не важно, как происходит процесс написания кода, в блокноте или современной IDE, руками или LLM. Им важно, чтобы продукты создавались быстро, качественно и решали их задачи.

10 лет назад скорость доставки повышали через Agile и DevOps. Сейчас — через AI-инструменты. Это просто следующий шаг той же эволюции. Использовать все доступные средства для повышения эффективности — это и есть инженерный подход.

Про "Full Cycle Prompter"

В статье я упоминал: я более 20 лет в ИТ, работал на всех ролях. Инженер по образованию. Именно эта насмотренность и позволяет эффективно применять инструменты.

Промпт — это способ взаимодействия. Инженерия — это понимание что строить, зачем и как. Одно другому не противоречит.

человек у руля работает в 5-10 раз производительнее среднестатистического разработчика

Среднестатистический разработчик работает с Enterprise-решениями, которые кратно больше CLI-утилиты, контекст там сложнее, код там сложнее и зачастую сама кодовая база кратно больше, соответственно и сломать что-то проще, поэтому сравнение некорректное. CLI-утилиты и 4o мог писать без проблем (и даже упаси боже GPT-3.5), если вы видите прорыв в том, что теперь вывод LLM сразу в файл идет - то я тут прорыва не вижу.

А если говорить про число пользователей, то в Yandere Simulator тоже много людей играло, но все ужаснулись, когда заглянули внутрь. Количество пользователей - не показатель, у нас и до ИИ было куча систем на коленке, которыми пользовались люди, но все эти системы держались на соплях.

Им не надо создавать хайп вокруг своей деятельности.

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

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

Мы слышали о том, как ИИ ускоряет скорость разработки 1000 раз от самых разных лиц, но мы почему-то до сих пор не видим массового перехода по всему миру. Бигтехи всюду кричат о том, что ИИ ускоряет и мобилизует разработку, однако, потом почему-то возвращают людей назад, ибо сокращения были слишком необоснованными и под косу пошли люди, на которых действительно держались системы, которые и без ИИ способны выполнять работу как "10x инженер"

Им важно, чтобы продукты создавались быстро, качественно и решали их задачи.

Быстро? Да, действительно быстрее. Качественнее? Сомнительно. Гляньте на последние новости, в ПО начинает появляться куча дыр, AWS/Cloudflare падает раз через раз, у Next появляется уязвимость с помощью которой можно пролезть в шелл на хост (React2Shell). У разработчиков падает насмотренность и пропадает навык написания и понимания кода, многие из-за дедлайнов не проверяют код за нейронкой и на прод выкатывается черт пойми что. Если вы это называете качеством - то у нас с вами разное мировоззрение.

Да и к тому же, есть первые наблюдения (важно, что это наблюдение, а не целое исследование, ибо оно реализовано на достаточно малой выборке), исходя из которых разработчики с ИИ становятся медленнее (тык), потому что код:

  1. Сложнее проверять, нежели писать

  2. Сложнее фиксить, нежели написать нормально с чистого листа

Я искренне радуюсь за всех PM, которые теперь могут KPI по задачам закрыть, но мне не сильно интересно что у них там за KPI, у меня есть работа и я хочу делать её хорошо. Я использую LLM, но точечно, когда это оправдано, а не забиваю кувалдой гвозди.

Это просто следующий шаг той же эволюции

Если вы 20 лет в IT, то вы должно быть так же радовались Low-Code, No-Code решениям, конструкторам и прочей чепухе. Повторюсь: для того чтобы инженеры поддерживали продукт, они должны знать как он работает, а не слепо верить выводу LLM. Эволюция в технических отраслях предполагает детерминированный результат, а не "запущу 3 git worktree и выберу вариант от Claude, который выглядит менее болезненно"

Промпт — это способ взаимодействия. Инженерия — это понимание что строить, зачем и как. Одно другому не противоречит.

Инженерия это также способность понять что уже построено и анализировать текущую систему. Приходя к столь желаемому подходу "от реализации к архитектуре" вы упускаете одну очень важную деталь - знание того как работает построенная система начинает пропадать, просто потому что при увеличении скорости написания кода - вы не можете столь же эффективно анализировать происходящее.

---

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

Вайб-код - прекрасное решение для пет-проектов, но для продуктовых систем - слишком рискованное и опасное

От себя добавлю я бы не хотел, чтобы аппарат ИВЛ или самолет имел ПО написанное при помощи ИИ.

Я тут поработал над гос.проектом...

Для того чтобы реализовать проект к сроку, набирали ребят вообще не умеющих кодить. Да, это отчасти проект с low-code, отчасти нужно писать js, xml и java.

Вы бы видели какой они писали код... Без ревью. Проект федерального значения...

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

Ну, и если пройти исторический путь развития разработки, от перфокарт и ассемблера до условной Java. Насколько упал скил разработчиков которые кодят на Java по сравнению С-разработчиками? Умеют ли они управлять памятью так же эффективно или этот навык атрофировался за ненадобностью?

А дока в том же репо что и код ?

Спасибо. Прямо статью с кончика пера сняли )) У меня похожий опыт, только с акцентом на дизайн и фронт-разработку, а не управление. И, конечно, пока не настолько эффективный, но вполне вдохновляющий.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации