Від автоматизації до автономності: як оновлення GitHub, Google та Oracle змінюють робочий процес розробника

У березневому випуску технічних новин High Bar Journal Макс Березанський, Tech Lead у Keiki (Genesis), аналізує зміну парадигми в інструментах розробки. GitHub Copilot виходить за межі редактора і починає самостійно закривати задачі в Jira, а Perplexity пропонує інфраструктуру для створення власних ШI-агентів «під ключ».

Паралельно з цим великі гравці спрощують роботу з даними та кодом: Google впроваджує крос-регіональні запити в BigQuery без зайвих ETL-процесів, а Oracle через Project Detroit стирає кордони між Java, Python та JavaScript. 

GitHub підключив Copilot до Jira. Тепер ШI може закривати задачі й створювати PR

GitHub інтегрував Copilot із Jira, дозволивши командам передавати задачі безпосередньо ШI-агенту і отримувати готові pull request у репозиторії. Тепер достатньо призначити issue на Copilot або згадати його в коментарях, і агент прочитає опис, врахує контекст і самостійно виконає зміни в коді. Працює він у захищеному середовищі GitHub Actions, а результатом стає draft PR, який проходить стандартний процес рев’ю, CI і апрувів, як і будь-який інший код.

Інтеграція стала частиною великого оновлення Copilot: GitHub перевів code review на агентну архітектуру, додав self-review і вбудоване security-сканування. Також підключив нову модель GPT-5.4 для складніших задач. У результаті Copilot поступово виходить за межі IDE і стає повноцінним учасником розробки, який може закривати типові задачі: від багфіксів до тестів і документації.

Для команд, які активно працюють із Jira, подібна інтеграція виглядає практичним розширенням робочого процесу: частину задач можна фактично делегувати агенту й отримувати готові pull request ще до того, як розробник встигає до них дійти. Водночас інтеграція підсвічує критичну залежність від якості постановки задач: чим точніше опис у Jira, тим передбачуваніший результат роботи агента.

Практичний ефект доволі прямий: команди отримують більше PR за той самий час, але вузьким місцем стає рев’ю і пропускна здатність на етапі валідації. Тобто ШI не прибирає обмеження в розробці, він просто зміщує їх у наступний етап пайплайну.

Google додав у BigQuery підтримку SQL-запитів між регіонами без ETL

Google Cloud запустив у preview нову можливість для BigQuery. Це виконання SQL-запитів одразу по даних, які зберігаються в різних регіонах, без попереднього копіювання чи побудови ETL-пайплайнів. Раніше для цього потрібно було переносити дані в одну локацію або будувати складну інфраструктуру для агрегації. Тепер система сама розподіляє запит між регіонами, обробляє його частинами й об’єднує результати.

Під капотом BigQuery визначає, які частини запиту і де виконувати, запускає їх локально в кожному регіоні, після чого переносить результати в обрану локацію і формує фінальний результат. Це спрощує роботу з розподіленими датасетами й дозволяє отримувати аналітику швидше. Хоча й додає latency через передачу даних між регіонами. Також з’являються додаткові витрати і обмеження, пов’язані з data residency, наприклад, у деяких випадках дані не можна переміщати між регіонами взагалі.

Для компаній, які вже зберігають дані в BigQuery у кількох регіонах, це виглядає як доволі практичне спрощення інфраструктури, бо можна відмовитися від частини ETL і працювати напряму через SQL. Утім, подібний сценарій сам по собі не є масовим: у невеликих і середніх продуктах дані рідко розподіляють різними регіонами без серйозної причини. Тому найбільше користі від цього підходу отримають великі компанії або команди зі специфічними вимогами до зберігання даних і комплаєнсу.

Функція наразі доступна у preview і вимагає явного увімкнення, а також окремої конфігурації для доступу до даних у різних регіонах. Для data-інженерів це ще один крок у бік спрощення аналітичної архітектури, але з компромісами у вартості, затримках і контролі за розміщенням даних.

Perplexity відкрив API для створення ШI-агентів

Perplexity розширив свою API-платформу і представив новий набір інструментів для розробників: Embeddings API, Agent API та Sandbox API. Ключова зміна в тому, що тепер розробники можуть працювати не з окремими моделями чи сервісами, а з повноцінним orchestration-рівнем. Він керує пошуком, інструментами, виконанням коду та взаємодією між моделями.

Agent API фактично бере на себе весь цикл роботи агента: від retrieval і вибору інструментів до виконання задач і fallback між моделями. Embeddings API дозволяє працювати з власними даними через векторний пошук, а Sandbox API дає ізольоване середовище для виконання коду (Python, JavaScript, SQL) із контрольованими ресурсами. У результаті замість того, щоб збирати стек із кількох провайдерів, усе це можна підключити через один API.

Для розробників, які будують складні agentic-системи, це виглядає як спроба зняти значну частину інженерної «обв’язки» навколо ШI: менше glue-коду, менше інтеграцій і швидший старт. Подібний підхід особливо релевантний у сценаріях, де агент має працювати з кількома джерелами даних, інструментами і моделями одночасно. У подібних кейсах потреба в уніфікованій точці входу стає критичною. Бо замість того, щоб збирати інфраструктуру частинами, з’являється можливість працювати з уже зібраним orchestration-рівнем.

Нові API вже частково доступні (Embeddings і Agent вже у продакшені, Sandbox у бета-режимі) і відображають загальний тренд: ШI-агенти поступово переходять із рівня окремих інструментів у повноцінну інфраструктуру, яка закриває весь цикл роботи: від даних до виконання задач.

VS Code прискорює релізи та дає більше свободи ШI-агентам

Microsoft перевів Visual Studio Code на новий ритм релізів. Тепер стабільні оновлення виходитимуть щотижня замість щомісячних. Перші версії, випущені в такому форматі, вже демонструють основний вектор розвитку: більше уваги до ШI-інструментів і менше потреби виходити за межі редактора під час роботи.

Одне з ключових оновлень — вбудований браузер для дебагу. Тепер вебзастосунок можна відкрити прямо у VS Code і працювати з ним так само, як у звичайному браузері: ставити breakpoint, перевіряти змінні і покроково проходити код без перемикання між вікнами.

Паралельно розширюють можливості ШI-агентів. З’явився контроль над тим, наскільки самостійно вони можуть діяти, інструменти для аналізу їх поведінки, а також підтримка роботи з різними типами файлів, включно із зображеннями та бінарними даними. Це дає змогу використовувати агентів не лише для генерації коду, а й для ширших задач у процесі розробки.

Водночас Microsoft поступово відмовляється від старих підходів, до прикладу, Edit Mode уже оголосили застарілим і планують повністю прибрати в наступних версіях. Це ще один сигнал, що редактор рухається в бік нової моделі роботи, де частину задач можна передавати ШI.

У підсумку VS Code усе більше перетворюється з класичного редактора на повноцінне робоче середовище, де ШI є частиною щоденного процесу. А перехід на щотижневі релізи означає, що такі зміни будуть з’являтися значно швидше.

Oracle відроджує Project Detroit — Java зможе напряму працювати з Python і JavaScript

Oracle повертає до життя Project Detroit. Це ініціатива, яка дозволяє використовувати Java разом із Python і JavaScript в одному середовищі. Проєкт планують офіційно представити в межах OpenJDK, а деталі мають показати на JavaOne.

Йдеться про більш тісну інтеграцію мов: замість окремих сервісів або складних обхідних рішень розробники зможуть напряму викликати код на Python або JavaScript із Java. Для цього використовують реальні рантайми — CPython і V8, що дозволяє працювати з бібліотеками цих мов без переписування під Java.

Практичний сенс у цьому доволі очевидний: можна залишати бізнес-логіку на Java, але підключати, наприклад, Python-бібліотеки для роботи з ШI або JavaScript для окремих задач, не будуючи окрему інфраструктуру під кожну мову. Це спрощує архітектуру та зменшує інтерфейсні прошаркм між сервісами.

Схожі підходи вже використовувалися раніше, але Project Detroit намагається зробити це частиною самої платформи Java. У перспективі планують додати підтримку й інших мов.

Фактично це ще один крок до того, щоб зробити Java менш ізольованою і краще інтегрованою із сучасним стеком, де різні мови часто використовуються разом.