Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 18
А кто заставляет разработчика все время крутиться около агентов? У разработчиков, которые работают в больших командах схожие проблемы - десятки непрочитанных сообщений, несколько пропущенных звонков, просроченные задачи. И как-то они с этим живут, еще и успевают обсудить посторонние темы на кухне или в курилке.
А тут пристали не живые коллеги, а какие-то бездушные агенты, и не дают понимаешь кофе попить, да идут они лесом, разработчик один, а этих безмолвных агентов можно десяток запустить. Или вырубить всех и залипнуть в телефоне.
Да в общем то нормальная работа руководителя большой команды, все от тебя чего то хотят, а за теми, кто тихо сидит, нужно присматривать особенно внимательно.
Ну разве что для команд программистов не характерна работа 24/7, но можно присмотреться к опыту какого ни будь завода например, как то там руководители справляются (делегирование и/или посменная работа).
Согласен, только разница в том, что руководителями большой команды не все становятся, и еще меньше имеют способности к эффективному управлению большой командой, а в данном случае мы говорим про среднестатистического разработчика, который может и не планировал становиться управленцем, но вышестоящее начальство обязывает.
Для среднестатистического разработчика нормально простые таски отправлять джунам и котроллировать их выполнение и качество. Не начальство обязывает, работа.
Верно, только не у всех среднестатистических разработчиков есть эти самые джуны, я говорю именно о тех, кто большую часть времени работает hands-on.
Да и в случае с джунами - природа работы с ними это не то-же самое, что отдавать работу агенту. Плюс, джун не выполняет работу с той скоростью, с которой это делает агент, и именно про это я и говорю. Пока джун пилит твой таск (день-два, зависит от задачи), ты можешь заняться чем то другим, и отдыхом в том числе. С агентом, у тебя этого "свободного" времени станет меньше, и именно про это я и говорю, нужно будет самому находить этот баланс и время на отдых. И это я еще не затрагиваю тему того, что менеджеры могут в погоне за "продуктивностью" ожидать от разраба повышения его velocity основываясь на том, что теперь у него есть агенты, которые все делают очень быстро, и теперь ему не нужно самому писать код.
По сути к этому приходим, агенты - это джуны. Внезапно у обычного разработчика стало несколько агентов. Разработчик от этого не становится руководителем, т. к. SOUL.md все же не делает из агента человека, пока во всяком случае. Разработчик становится сениором с большими требованиями к hard скилам, и от него требуется пропускать через себя очень много ревью. Но думаю это временное явление, агенты будут совершенствоваться, доверия будет к ним больше, роль разработчика будет смешаться в сторону ролей менеджера продукта и проектов.
Не совсем, как раз софт скиллы начинают обретать значимость, ведь процесс постановки задачи джуну или агенту различаются.
С джуном - ты очень часто можешь просто описать ему задачу и отправить его делать ресерч, и потом спустя время, он предоставит тебе дизайн, ты его заапрувишь, и он уйдет его пилить. То есть по сути у тебя есть большие окна на свои задачи между активным вовлечением. С агентом, эти фазы сокращаются до одной сессии, во время которой тебе нужно максимально полно и понятно донести задачу до агента, он быстро сделает ресерч, план и разобьет на таски, ты заапрувишь и он их очень быстро сделает. По сути свободного времени стало меньше.
А по поводу хард-скиллов, и требования к объему ревью - это промежуточный этап. Если работа с агентом выстроена хорошо, я имею в виду, что он не просто фиксит что-то а еще и сам себя апдейтит в плане скиллов и паттернов, то после нескольких первых сессий, достаточно будет запускать соответствующий скилл, и он сам будет себя исправлять. Плюс уже сейчас Антропики уже выкатили свой code-rewiew сервис, и в итоге, все кампании рано-или поздно внедрят себе автоматический код ревью, как это было с сервисами по статическому код анализу вроде SonarQube
Так, вроде бы никто не заставляет, но парадокс в том, что иногда тяжело самому выйти из этой петли. И если человек способен сам соблюдать этот баланс - это круто.
Но есть и еще фактор - а именно менеджеры этих самых разработчиков, им тоже важно понимать цену этой продуктивности, а вот это к сожалению, не всегда происходит.
абсолютно точный вывод на мой взгляд, на 100% согласен с автором
Мне нравится хорошая рефлексия. Я бы не сказал, что проблема вообще в какой-то из инженерных составляющих. Тактически агенты кроют живых разработчиков за счет быстрого анализа существующих решений. Реал ная проблема для разработчика - перестать разрабатывать и начать часто-часто проверять достигаемые результаты. AI легко уходит в красивые и ничего не стоящие абстракции
Думаю вам будет интересно моя статья на эту же тему и что я залопатил для себя)
https://habr.com/ru/articles/1009534/
А сейчас вот пытаюсь решить другую важную задачу: определить рамки для агента, чтобы он знал, когда остановиться. Иначе он бесконечно совершенствует.
Но в итоге решения, наоборот, деградируют) Так как он не может отказать юзеру и не знает, что считать законченным эффективным решением.
Этот ИИ никогда не научиться объяснять что и зачем он напрограммировал.
Потому что он программирует не сам, и вообще думать не умеет.
Он умеет делать из промпта шаблон запроса, ищет ответы, выбирает нужное по весам (статистике), делает из ответов шаблоны, производит над ними операции (агрегации, подстановки).
Вот и всë!
Это, действительно, удобно и эффективно, но это только вспомогательный инструмент, не голова.
И проблема не столько в отладке, сколько в поддержке, если перебарщивать с использованием агента и не проверять, не знать что в системе меняется.
И главное, многие стартапы и островы проектов, частей проекта, похожи. Такой код просто найти. Когда начинается развитие, детали, нестандартные задачи у агента начинаются галлюцинации. Ему негде найти и скопипастить.
По сути, ИИ агент это автоматизированный процесс программирования методом копипаста. Конечно оснащëнный разными крутилками и вертелками.
А не может описанная в статье проблема возникать в случае чрезмерного использования агента? Привыкая к агентскому режиму начинаешь давать ему всë подряд, даже то, что быстрее сделать самому хоткеями, чем надиктовывать и поправлять?
Стандартные вещи, особенно требующие объемной механической работы -- агенту. То, что быстрее сделать самому -- агенту не давать.
Конечно, эту границу нужно нащупать опытным потом, но стремиться к гармонии.
Я согласен, что агент не умеет думать, и так же согласен, что по сути своей это инструмент, который нужно уметь использовать. Вместе с тем, я описываю скорее тенденции внедрении AI в разработку и то что компании ожидают от разработчиков с момента интеграции агентов. А логика очень часто у них очень простая: "Все конкуренты внедрили агентов и теперь деливерят фичи х10, мы тоже так хотим. Внедряем агента, заставляем всех разработчиков переключаться на оркестрацию и все в шоколаде."
И именно про цену такой интеграции я и пишу.
Когда ты получаешь доступ в чужой «legacy» код, часто автор кода недоступен. Некого спросить, почему решение было именно таким ...
Можно тоже ai агента спросить - он с такой же точностью (низкой) и уверенностью (высокой) ответит как и про свой код 😁
Так что имхо сегодня это не "кардинально разные ситуации", а даже практически одинаковые
Нет, если работа с агентом выстроена хорошо, а под "хорошо" я имею в виду есть четкие фазы: brainstorm, research, plan, task creation, implementation, validation, и для каждой такой фазы создаются соответствующие артефакты, то у агента не будет никакой проблемы объяснить разработчику, почему было сделано так а не иначе, более того, разработчик будет частью этого процесса, и он будет направлять агента в ту или иную сторону.
Поэтому это разные ситуации. В случае с агентом, всегда будут соответсвующие документы, содержащие весь контекст и процесс принятия решений.
Нормальная эволюция технологии, ничего личного. Так было с бухгалтерами, логистами... со всеми было. Сначала все в эйфории, потом бац — стандартизация, удешевление. Кто не учится — тот... ну вы поняли. Суворов там про солдата и генерала правильно говорил, хотя это не только про армию, конечно.
Коллеги, не обижайтесь, но статья... ну читается как нытье, честно. Мы же 10 лет в масле катались, реально. А сейчас бизнес просто хочет эффективности (странно, да?), а мы почему-то воспринимаем это как личное оскорбление.
20+ лет руковожу всем этим хозяйством (на местном уровне) и вижу картину: 90% программистов (ну может не 90, но много точно) — ленивые, с завышенной самооценкой, и всё это прикрывается «творческим подходом». Ну вот так вот.
Хочется с Бали работать по 2 часа и миллионы получать? Понимаю, многие хоят) Но бизнес-то платит за результат, а не за мечты. И если нагрузка зашкаливает — может не в ИИ дело? Может к психологу сходить? Они сейчас тоже в тренде, кстати.
Бороться с ИИ... ну это как Дон Кихот, честно. Бесполезно. Лучше учиться, учиться и еще раз учиться (не зря же завещал) работать с этим, чем плакать что раньше было лучше. Раньше не лучше было, просто другое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Главная проблема vibe coding — не vibe debugging