Нет, если работа с агентом выстроена хорошо, а под "хорошо" я имею в виду есть четкие фазы: brainstorm, research, plan, task creation, implementation, validation, и для каждой такой фазы создаются соответствующие артефакты, то у агента не будет никакой проблемы объяснить разработчику, почему было сделано так а не иначе, более того, разработчик будет частью этого процесса, и он будет направлять агента в ту или иную сторону. Поэтому это разные ситуации. В случае с агентом, всегда будут соответсвующие документы, содержащие весь контекст и процесс принятия решений.
Я согласен, что агент не умеет думать, и так же согласен, что по сути своей это инструмент, который нужно уметь использовать. Вместе с тем, я описываю скорее тенденции внедрении AI в разработку и то что компании ожидают от разработчиков с момента интеграции агентов. А логика очень часто у них очень простая: "Все конкуренты внедрили агентов и теперь деливерят фичи х10, мы тоже так хотим. Внедряем агента, заставляем всех разработчиков переключаться на оркестрацию и все в шоколаде." И именно про цену такой интеграции я и пишу.
Не совсем, как раз софт скиллы начинают обретать значимость, ведь процесс постановки задачи джуну или агенту различаются. С джуном - ты очень часто можешь просто описать ему задачу и отправить его делать ресерч, и потом спустя время, он предоставит тебе дизайн, ты его заапрувишь, и он уйдет его пилить. То есть по сути у тебя есть большие окна на свои задачи между активным вовлечением. С агентом, эти фазы сокращаются до одной сессии, во время которой тебе нужно максимально полно и понятно донести задачу до агента, он быстро сделает ресерч, план и разобьет на таски, ты заапрувишь и он их очень быстро сделает. По сути свободного времени стало меньше. А по поводу хард-скиллов, и требования к объему ревью - это промежуточный этап. Если работа с агентом выстроена хорошо, я имею в виду, что он не просто фиксит что-то а еще и сам себя апдейтит в плане скиллов и паттернов, то после нескольких первых сессий, достаточно будет запускать соответствующий скилл, и он сам будет себя исправлять. Плюс уже сейчас Антропики уже выкатили свой code-rewiew сервис, и в итоге, все кампании рано-или поздно внедрят себе автоматический код ревью, как это было с сервисами по статическому код анализу вроде SonarQube
Верно, только не у всех среднестатистических разработчиков есть эти самые джуны, я говорю именно о тех, кто большую часть времени работает hands-on. Да и в случае с джунами - природа работы с ними это не то-же самое, что отдавать работу агенту. Плюс, джун не выполняет работу с той скоростью, с которой это делает агент, и именно про это я и говорю. Пока джун пилит твой таск (день-два, зависит от задачи), ты можешь заняться чем то другим, и отдыхом в том числе. С агентом, у тебя этого "свободного" времени станет меньше, и именно про это я и говорю, нужно будет самому находить этот баланс и время на отдых. И это я еще не затрагиваю тему того, что менеджеры могут в погоне за "продуктивностью" ожидать от разраба повышения его velocity основываясь на том, что теперь у него есть агенты, которые все делают очень быстро, и теперь ему не нужно самому писать код.
Согласен, только разница в том, что руководителями большой команды не все становятся, и еще меньше имеют способности к эффективному управлению большой командой, а в данном случае мы говорим про среднестатистического разработчика, который может и не планировал становиться управленцем, но вышестоящее начальство обязывает.
Так, вроде бы никто не заставляет, но парадокс в том, что иногда тяжело самому выйти из этой петли. И если человек способен сам соблюдать этот баланс - это круто. Но есть и еще фактор - а именно менеджеры этих самых разработчиков, им тоже важно понимать цену этой продуктивности, а вот это к сожалению, не всегда происходит.
И тут как гром среди ясного неба прилетает письмо со следующей темой «Action Required: Your app is not compliant with Google Play Policies (Аудиокниги — Торрент)» (Требуется действие: Ваше приложение не соответствует политике Google Play)
Я правильно понимаю, что ты создал своего рода агрегатор торренов для аудио книг?
Если да, тогда какие претензии могут быть к настоящим правообладателям?
Я понимаю, что тоже самое можно скачать и напрямую через трекер, но почему правообладатели должны давать возможность облегчать жизнь пиратам?
Тебе, как автору приложения не было обидно, что его взломали и выложили в общий доступ, что сильно понизило возможные доходы от рекламы?
Правильный подход: Перед тем как начинать работу над проектом, хорошо подумайте, что Вы хотите сделать, и к чему это может привести.
Не согласен. Если бы в начале своего пути ты так глубоко задумался и начал все просчитывать, то скорее всего ты бы не начал с этим проектом.
Ты можешь сделать базовый рабочий прототип, чтобы проверить жизнеспособность своей идеи. И когда она заработает или нет, тогда уже можно притормозить и подумать о направлении в котором хочешь проект зэразвивать.
И такие остановки, чтобы подумать, нужно делать почаще.
Странно, сейчас уже точно не скажу, т.к. последний раз писал на реакте около года назад, но точно помню, что года 2 мы точно такую конструкцию не использовали.
По моему, там нужен специальный proposal-dependеncy в package.json добавлять.
И мы почти полностью перешли на функциональные компоненты
По поводу анимаций, рекомендую посмотреть в сторону библиотеки GSAP.
На собственном опыте столкнулся со сложностями анимации компонентов,
Эта библиотека вкупе с правильным использованием лайфхуков компонентов помогла решить большинство проблем
Нет, если работа с агентом выстроена хорошо, а под "хорошо" я имею в виду есть четкие фазы: brainstorm, research, plan, task creation, implementation, validation, и для каждой такой фазы создаются соответствующие артефакты, то у агента не будет никакой проблемы объяснить разработчику, почему было сделано так а не иначе, более того, разработчик будет частью этого процесса, и он будет направлять агента в ту или иную сторону.
Поэтому это разные ситуации. В случае с агентом, всегда будут соответсвующие документы, содержащие весь контекст и процесс принятия решений.
Я согласен, что агент не умеет думать, и так же согласен, что по сути своей это инструмент, который нужно уметь использовать. Вместе с тем, я описываю скорее тенденции внедрении AI в разработку и то что компании ожидают от разработчиков с момента интеграции агентов. А логика очень часто у них очень простая: "Все конкуренты внедрили агентов и теперь деливерят фичи х10, мы тоже так хотим. Внедряем агента, заставляем всех разработчиков переключаться на оркестрацию и все в шоколаде."
И именно про цену такой интеграции я и пишу.
Не совсем, как раз софт скиллы начинают обретать значимость, ведь процесс постановки задачи джуну или агенту различаются.
С джуном - ты очень часто можешь просто описать ему задачу и отправить его делать ресерч, и потом спустя время, он предоставит тебе дизайн, ты его заапрувишь, и он уйдет его пилить. То есть по сути у тебя есть большие окна на свои задачи между активным вовлечением. С агентом, эти фазы сокращаются до одной сессии, во время которой тебе нужно максимально полно и понятно донести задачу до агента, он быстро сделает ресерч, план и разобьет на таски, ты заапрувишь и он их очень быстро сделает. По сути свободного времени стало меньше.
А по поводу хард-скиллов, и требования к объему ревью - это промежуточный этап. Если работа с агентом выстроена хорошо, я имею в виду, что он не просто фиксит что-то а еще и сам себя апдейтит в плане скиллов и паттернов, то после нескольких первых сессий, достаточно будет запускать соответствующий скилл, и он сам будет себя исправлять. Плюс уже сейчас Антропики уже выкатили свой code-rewiew сервис, и в итоге, все кампании рано-или поздно внедрят себе автоматический код ревью, как это было с сервисами по статическому код анализу вроде SonarQube
Верно, только не у всех среднестатистических разработчиков есть эти самые джуны, я говорю именно о тех, кто большую часть времени работает hands-on.
Да и в случае с джунами - природа работы с ними это не то-же самое, что отдавать работу агенту. Плюс, джун не выполняет работу с той скоростью, с которой это делает агент, и именно про это я и говорю. Пока джун пилит твой таск (день-два, зависит от задачи), ты можешь заняться чем то другим, и отдыхом в том числе. С агентом, у тебя этого "свободного" времени станет меньше, и именно про это я и говорю, нужно будет самому находить этот баланс и время на отдых. И это я еще не затрагиваю тему того, что менеджеры могут в погоне за "продуктивностью" ожидать от разраба повышения его velocity основываясь на том, что теперь у него есть агенты, которые все делают очень быстро, и теперь ему не нужно самому писать код.
Спасибо, интересная статья, подумаю, что можно переиспользовать.
Согласен, только разница в том, что руководителями большой команды не все становятся, и еще меньше имеют способности к эффективному управлению большой командой, а в данном случае мы говорим про среднестатистического разработчика, который может и не планировал становиться управленцем, но вышестоящее начальство обязывает.
Так, вроде бы никто не заставляет, но парадокс в том, что иногда тяжело самому выйти из этой петли. И если человек способен сам соблюдать этот баланс - это круто.
Но есть и еще фактор - а именно менеджеры этих самых разработчиков, им тоже важно понимать цену этой продуктивности, а вот это к сожалению, не всегда происходит.
А вообще статья хорошая!
И твой посыл очень правильный.
А можно поподробнее? Почему не клеятся?
Я правильно понимаю, что ты создал своего рода агрегатор торренов для аудио книг?
Если да, тогда какие претензии могут быть к настоящим правообладателям?
Я понимаю, что тоже самое можно скачать и напрямую через трекер, но почему правообладатели должны давать возможность облегчать жизнь пиратам?
Тебе, как автору приложения не было обидно, что его взломали и выложили в общий доступ, что сильно понизило возможные доходы от рекламы?
Не согласен. Если бы в начале своего пути ты так глубоко задумался и начал все просчитывать, то скорее всего ты бы не начал с этим проектом.
Ты можешь сделать базовый рабочий прототип, чтобы проверить жизнеспособность своей идеи. И когда она заработает или нет, тогда уже можно притормозить и подумать о направлении в котором хочешь проект зэразвивать.
И такие остановки, чтобы подумать, нужно делать почаще.
По моему, там нужен специальный proposal-dependеncy в package.json добавлять.
И мы почти полностью перешли на функциональные компоненты
Сразу уточню. Apollo graphql client использует redux под капотом — уже нет. с версии 2 Apollo перестали использовать Redux под капотом
На собственном опыте столкнулся со сложностями анимации компонентов,
Эта библиотека вкупе с правильным использованием лайфхуков компонентов помогла решить большинство проблем