Хабр Курсы для менеджеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
Многие даже не понимают НАСКОЛЬКО! 😁😁😁
Коллеги, многие с восторгом рассказывают про этот бум!)) Но почему-то молчат про то, как Амазон после сбоев и многомиллиардных потерь начал тихо нанимать обратно наиболее квалифицированных инженеров, которых ранее сам же массово уволил))) Зачем?))) ИИ же справляется, такая крутая идея?))
Я вам отвечу на этот вопрос. Потребность в умах на наиболее критических направлениях НИКУДА НЕ ДЕЛАСЬ. Подход с ИИ кодингом имеет место быть, но применять его нужно ГРАМОТНО, иначе можно наломать ТАКИХ дров... Не один только менеджмент Амазона на это напоролся, и не стоит повторять ТАКИХ ошибок! 😁🤷
Приведу пример. Искусственный интеллект. Да, вы можете возразить. Да, напишет. Вопрос - насколько критично это будет.
Я один из тех, кто пишет ИИ нестандартно и кто обходит регулярно другие профессиональные команды, в том числе бигтехов, огромных холдингов. Да-да, тех самых, кто проходит 100500 интервью, которые я могу не пройти. Ну потому что проходить интервью и ДЕЙСТВИТЕЛЬНО РЕШАТЬ серьёзные задачи разработки - это РАЗНЫЕ навыки, и я до сих пор в шоке от этого карго культа собесов на ИИ найме! Лично мне НЕКОГДА качать этот навык, полно реальной работы, а не имитации деятельности, поймите это господа наниматели! Чаще общайтесь с нанимаемыми и учитесь оценивать с объективной позиции, а не как вам показалось, что человек должен решать задачи в области, с которой знакомы поверхностно! Ну не работает это в найме - и это не удивительно, просто вам надо это признать наконец, проанализировать и менять процедуру! Могу рассказать - я ТАК собирал эффективные ИИ команды! 😁🤝
Я к тому, что соображаю в области, поскольку по математическим критериям и многократным отзывам клиентов обхожу другие команды в профессиональной разработке. Можно оспорить, приводить кучу аргументов, но математика всё расставляет на свои места. Проекты, сделанные 1 в 1 с другими профи, делаю не на 1-2% по метрикам лучше, как обычно между профи должно быть, а на десятки процентов. Это уровень, когда КЛИЕНТ видит глазом, что другая команда ему даёт продукт, который работает откровенно хуже, приводит к потерям прибыли и времени, в то время как мой сделан быстрее, заметно выше по качеству, потребляет в разы меньше ресурсов! Другой уровень инженерии, другое образование и опыт.
Теперь, когда обозначил что понимаю в теме, перейдём к делу. МОЁ личное доверие к ИИ кодингу ломается на стадии, когда я читаю ЛОГИКУ его мышления и сопоставляю с профессиональной. Парни, вы собрались БРЕД, ОСНОВАННЫЙ НА ЗАТЫЧКАХ И ЗАПЛАТКАХ ВМЕСТО ПРОДУКТИВНЫХ ИНЖЕНЕРНЫХ ИДЕЙ, использовать для кода в критически важных продуктах? Я сейчас задаю вопрос абсолютно на релаксе и с улыбкой. Это ВАШЕ дело, хотите ли вы потом ЭТО разгребать. Тут КВАЛИФИЦИРОВАННЫЕ инженеры люди не всегда справляются))) по моим наблюдениям (метрики и визуальное качество результата для КЛИЕНТОВ, математика и НИКАКИХ понтов или фантазий) с моим уровнем эффективности примерно ОДИН на несколько тысяч ОПЫТНЫХ разработчиков. А вы хотите, чтобы обученная на миддловских репозиториях модель решала действительно сложные задачи?)) Камон! 😁🤷
У ЛЮБОГО, даже очень хорошего, инструмента есть границы применимости. Я уверен, что написанием качественного ИИ граница применимости не ограничивается, есть другие сложные области, например разработка сложной чертёжной документации.
Кстати, для любителей использовать миддлов и вайб кодеров , а также стандартные процедуры найма)) в разработке ИИ плохие новости. Если думаете, что для большинства проектов подходят обычные разрабы, по моим наблюдениям примерно в 70-80% проектов, то есть ПОДАВЛЯЮЩЕМ большинстве проектов мой подход приносит РЕАЛЬНУЮ дополнительную маржинальность, значительно меньше проектов изображают "потёмкинскую деревню" как в статье MIT (95% проектов ИИ по их данным не приносят ожидаемой прибыли!). За последние годы ВСЕ мои проекты были успешны, причём во многих случаях сделал их таковыми после других профессиональных команд, разработкой которых клиенты были недовольны, и за этими командами меня просили переделать. Это не реклама, я так живу. И пишу всё это для того, чтобы понимали - ИИ не панацея, выясняйте границы применимости и только тогда используйте. Во всяком случае, при написании им ИИ проектов я им пользовался, но без коррекций моего уровня и контроля его логики он просто всё запорол... 😊🤷
Как и не панацея уровень сеньора или лида и прохождение стандартного собеса))) Именно таких регулярно обхожу в разработке. Кто реально заинтересован в интересных сложных проектах и кому не всё равно, кто болеет за своё дело - обращайтесь. Мне очень нравятся неравнодушные и заинтересованные люди и проекты на интерес помимо только прибыли, собственно это же было важнейшими из двигателей моего прогресса, поэтому будем на одной волне. 😊🤝
P.S. Про ИИ своей разработки может показаться не в тему, но на самом деле явления связанные. На рынке не хватает КВАЛИФИЦИРОВАННЫХ разработчиков, они стоят ВСЕГДА дорого, и возникает соблазн их заменить плюс вроде пишет быстрее)) и даже знает стандарты разработки))
Реально сочувствую людям, попадающим в ловушку использования ИИ кодинга на сложных проектах сродни описанным мною и теряющим на этом средства и время, и не понимающим, что пошло не так в этой схеме. Поэтому, ищу тех, кто натолкнулся на это и готов делать интересные проекты, но уже понял, что с ИИ кодингом что-то не так. Я могу закрыть потребности в своём сегменте, поэтому обозначаю это, другие профессионалы - в своих сегментах.
Уверен, будущее за гибридным форматом. Более простое поможет делать ИИ, а квалифицированные люди будут направлять процесс, ОСОБЕННО при решении сложных задач. Давайте делать это будущее разумно и вместе. 😊🤝
Интересно. Спасибо.
Особенно заинтересовало про отмирающие IDE. Как научиться (где посмотреть живые примеры?) работе именно в таком режиме?
Да хоть на примере упомянутой Antigravity IDE. Даже если не смотреть код внимательно, какие-то .env и прочие настройки править - как я это могу в Antigravity 2.0 делать?
Скриншот JetBrains понимаю. Antigravity 2.0 активно использую - но не для кода больших проектов.
Claude Code как расширение в VS Code - супер. Как десктопное приложение в виде соседней вкладки с чатом - понимаю только для мелких задач. Как туда перелезть из IDE и зачем?
просто в консольный клаудкод, иде в целом не особо уже нужны , просто занимают лишнее место на экране и не несут пользы от слова совсем, а джетбрейнс просто профукал все полимеры. С учетом того что у них нет своей модели им теперь остается либо успеть продаться либо умереть.
Для меня консольный Claude Code идеален для задач типа "почини BGP между Mikrotik и VPS", и вот он по ssh ходит, команды посылает - супер.
Ежели у меня проект хотя бы на 100 тыс строк, я, конечно, могу его попросить написать код. И он даже это прекрасно напишет мне спецификацию и худо-бедно ее покажет. Сам я ее не правлю, прошу его внести какие-то правки. В итоге получил код. Супер.
Но дальше что? Переключаться в другое приложение, чтобы отредактировать конфиг, в третье - чтобы запустить бэкенд, смотреть, какие там логи побегут...
Тесты тестами, но прежде, чем собирать контейнер, я же глазками смотрю как минимум на изменивышиеся фичи. Видимо совсем другой пайплайн должен быть.
У меня два не маленьких проекта. Один лютое легаси устарело уже 15 лет назад. Второй тоже легаси, но не такое старое. С ноября открываю ide, чтобы кликнуть в любом месте на экране... Чтобы вызвать "открыть в sublime merge" в контекстном меню.
Все почему... Потому что на хоткей поставлено ide а не sm 😮
А все остальное промптами....
В ноябре ещё чёт лез руками делать. С февраля максимум 10 строк кода написал. Хотя pull request частые.
"Писать код" сейчас действительно удобнее в консольных агентах, а не в IDE. Но вот ревьювить его и по мелочи подчищать - всё ещё удобнее в IDE. Полностью отомрут IDE только у вайб-кодеров, которым ревьювить код не требуется.
В целом почти всё верно, исключая только идею делегировать ревью агентам - потому что на этом месте разработка превращается в вайб-кодинг и вызывает соответствующее падение качества и рост тех.долга. Причём экспоненциальное.
Лайфхак: Если не запускать 5 параллельных агентов, а ограничиться 1-2, то вернётся возможность полноценно ревьювить код.
у эксплуатации и QA было несколько десятилетий, чтобы научиться выкатывать в прод код, который они не писали и не понимают, и при этом следить, чтобы он работал
Это работает только потому, что выкатываемый ими код - рабочий. Иначе всё, что они смогут, это откатиться на предыдущую рабочую версию. Но если люди перестанут ревьювить код, то предыдущей рабочей версии может не найтись в принципе.
вызывает соответствующее падение качества и рост тех.долга
Вот хотелось бы proof's. Соблюдая навыки распределенной разработки все выглядит так же, на мой взгляд... Только ошибок на проде стало меньше. Но, может, это только ошибка выжившего из ума и применительно только к 2 известным мне проектам.
В качестве пруфов сойдёт любая статья на эту тему. Везде где пробовали вайб-кодинг в реальном проде наблюдается проблема соблюдения нефункциональных требований: проблемы с безопасностью, надёжностью, производительностью и т.п. плюс рост тех.долга (нарушения архитектуры, дублирующие реализации схожего функционала, etc.). Вайб-кодинг сегодня идеально подходит для прототипирования и экспериментов, но не для прода.
Один-два агента для рутинных правок под плотным контролем человека реально экономят кучу сил, но как только отдаешь им право мерджить без ручной вычитки, техдолг растет как на дрожжах
Я,конечно,по диагонали прочитал статью, но не совсем понятна судьба qa. Если разработчики становятся универсалами архитекторами,то что с тестерами? Все,на помойку истории? Что думаете?
Я заметил, что у руководителя пропала грань, что такое качество и почему это долго. Все привыкли к тому, что Клод за тебя напишет, ты вроде бы это глазками посмотрел и вперёд-вперёд за новыми задачами. Тестов тебе нагенерирует липовых и снова вперёд.
Вот эта строчка про LGTM — это то, что я видел еще ДО ботов, а теперь и её перестали писать.
QA на мой взгляд — это то, что мы можем легко потерять, если и дальше будем выкатывать фичи не глядя.
Чарити заметила, что у эксплуатации и QA было несколько десятилетий, чтобы научиться выкатывать в прод код, который они не писали и не понимают, и при этом следить, чтобы он работал.
Возможно, Чарити просто не слышала, что о ней говорила эксплуатация в 3-4 часа ночи.
Теперь эксплуатация скажет "Ночью звоните своим агентам, пусть они откатывают."
В основе индустрии лежит жесткая реальность настоящей инженерии. Это мир, где команды подчинены строгим бизнес требованиям и жестким рамкам SLA, где проектирование архитектуры требует точных расчетов, а каждый этап - от разработки и рефакторинга до внедрения и поддержки - сопряжен с высокой ответственностью. Здесь нет места иллюзиям: стабильность систем оплачивается круглосуточным дежурством и сложнейшим разбором инцидентов на "живом" проде.
А параллельно этому существует глянцевый IT-шоубизнес. Там, на бесконечных конференциях, благоухающие спикеры со сцены торгуют "успешным успехом", жонглируют хайповыми баззвордами и презентуют идеальные технологии, которые никогда не сталкивались с реальными пользователями.
Эти два направления неумолимо расходятся все дальше и дальше по одной простой причине: пока одни изо дня в день заняты серьезным, тяжелым и рутинным трудом, другие просто профессионально торгуют лицом и красивыми историями.
Во во, после этих строк автора
инженеры, которые перестают читать код
Я решил что дальше можно не читать, уже видно что автор не нейтральная сторона, а тянет нарратив)
У этих ребят всегда все летает в презентациях, пока они не упрутся в легаси двадцатилетней выдержки, там их десяток агентов просто передерется за блокировку таблиц
Что можно подытожить? "Мы насрали кодом, потеряв по пути контроль, качество софта упало, поэтому мы будем срать кодом больше и терять контроль дальше". Очень полезное мнение очень компетентных людей, спасибо.
На самом деле звучат две очень интересных фразы. То есть сначала говорят, что качество падает, а потом говорят, что да, технический долг растет, но мы сможем его быстро исправить, ведь нету причин мириться с тем, что нас не устраивает. То есть люди видят падение качества, понимают, что код раздувается, но при этом "да, мы быстро избавимся от технического долга". А это быстро когда наступит? Оно где-то на горизонте есть?
Не совсем понятно в чем остаётся роль инженера тогда. Задачи изначальные мы не придумываем, да и не нужно столько людей чтобы придумывать продукт. Декомпозировать задачи не нужно - этим занимается агент. Сам код не пишем и даже не проверяем. Тесты туда же, зачем вообще нужен тот самый человек с 10ю вкладками Клода из статьи становится решительно непонятно.
Инженеры действительно стали меньше писать рутинного бойлерплейта, это отрицать глупо, но проверять архитектурные стыки и граничные условия все равно приходится глазами ибо автоматическое ревью пока только штампует аппрувы на любой синтаксически верный мусор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Состояние IT-индустрии в 2026 году: что изменилось, что сломалось и что дальше