Спасибо за статью, заставляет задуматься. Сценарий с собеседованием в 2035 году выглядит пугающе реалистичным.
По сути, это повторение истории со смартфонами и интернетом, только с более высокой ставкой. Когда-то говорили «зачем учить формулы, если есть калькулятор», но калькулятор не генерировал смыслы. Если доступ к фронтирным моделям станет определяющим фактором продуктивности, то «арендованный ум» превратится в имущественный ценз: есть деньги на флагманский тариф — ты востребованный специалист, нет — выпадаешь на обочину рынка труда.
Да, агент с радостью закоммитит красивейший вызов стороннего сервиса внутри распределённой транзакции и даже напишет на это зелёный тест. Нарисовать синтаксис — это 5% задачи, а вот понимать, что произойдёт, когда на половине пайплайна моргнёт сеть и прилетит дубль события — это как раз то, почему архитекторов пока рано отправлять на пенсию.
Главный фактор — бюджет. Доступ к моделям Google сейчас получается кратно дешевле топовых альтернатив, если брать длительный план (про на 18 месяцев), а для моих текущих объёмов этого пока достаточно. Сравнить качество «в лоб» не смогу — другие связки и IDE просто не гонял, поэтому опираюсь только на свой опыт в Antigravity.
Мы прошли похожий путь: начинали с копипасты между веб-интерфейсом ChatGPT и классическим VS Code, а сейчас перебрались в Antigravity. Разница в скорости и автономности колоссальная, но иллюзий не осталось: без чёткого понимания архитектуры проекта вся эта агентская мощь — просто шаг в никуда. Если ты не понимаешь, какие модули за что отвечают и как устроены потоки данных, агент сгенерирует идеальный по синтаксису коммит, который развалит систему на следующем шаге. Базовая инженерная насмотренность никуда не делась — просто фокус окончательно сместился с набора кода на архитектурный контроль.
Спасибо за структурированный материал и матрицу сбоев!
Разделение прав доступа на уровне кода — абсолютная база, но интересно ваше мнение по поводу human-in-the-loop: когда мы подвешиваем критическую запись на аппрув человека, как лучше разруливать долгие паузы (async waiting)? Если аппрув висит часами, держать thread в памяти/state тяжело, а при полной гидратации контекста заново модель иногда теряет изначальные нюансы reasoning'а. Как вы у себя решаете баланс между полным снапшотом контекста и лаконичной передачей задачи?
Спасибо за статью, заставляет задуматься. Сценарий с собеседованием в 2035 году выглядит пугающе реалистичным.
По сути, это повторение истории со смартфонами и интернетом, только с более высокой ставкой. Когда-то говорили «зачем учить формулы, если есть калькулятор», но калькулятор не генерировал смыслы. Если доступ к фронтирным моделям станет определяющим фактором продуктивности, то «арендованный ум» превратится в имущественный ценз: есть деньги на флагманский тариф — ты востребованный специалист, нет — выпадаешь на обочину рынка труда.
Да, агент с радостью закоммитит красивейший вызов стороннего сервиса внутри распределённой транзакции и даже напишет на это зелёный тест. Нарисовать синтаксис — это 5% задачи, а вот понимать, что произойдёт, когда на половине пайплайна моргнёт сеть и прилетит дубль события — это как раз то, почему архитекторов пока рано отправлять на пенсию.
Главный фактор — бюджет. Доступ к моделям Google сейчас получается кратно дешевле топовых альтернатив, если брать длительный план (про на 18 месяцев), а для моих текущих объёмов этого пока достаточно. Сравнить качество «в лоб» не смогу — другие связки и IDE просто не гонял, поэтому опираюсь только на свой опыт в Antigravity.
Мы прошли похожий путь: начинали с копипасты между веб-интерфейсом ChatGPT и классическим VS Code, а сейчас перебрались в Antigravity. Разница в скорости и автономности колоссальная, но иллюзий не осталось: без чёткого понимания архитектуры проекта вся эта агентская мощь — просто шаг в никуда. Если ты не понимаешь, какие модули за что отвечают и как устроены потоки данных, агент сгенерирует идеальный по синтаксису коммит, который развалит систему на следующем шаге. Базовая инженерная насмотренность никуда не делась — просто фокус окончательно сместился с набора кода на архитектурный контроль.
Спасибо за структурированный материал и матрицу сбоев!
Разделение прав доступа на уровне кода — абсолютная база, но интересно ваше мнение по поводу human-in-the-loop: когда мы подвешиваем критическую запись на аппрув человека, как лучше разруливать долгие паузы (async waiting)? Если аппрув висит часами, держать thread в памяти/state тяжело, а при полной гидратации контекста заново модель иногда теряет изначальные нюансы reasoning'а. Как вы у себя решаете баланс между полным снапшотом контекста и лаконичной передачей задачи?