Bitbucket chce być centralą dla agentów w CI/CD. Codex to dopiero druga wtyczka

Atlassian dorzucił do Bitbucket Pipelines obsługę agenta Codex od OpenAI, czyli tego samego agenta do pisania kodu, którego część deweloperów odpala dziś u siebie na komputerze, w terminalu. Teraz ten sam sposób pracy można przenieść do pipeline'u, czyli do automatu, który firma uruchamia po scaleniu zmian do kodu, po nieudanym buildzie albo po komentarzu pod pull requestem. Brzmi jak kolejna integracja, jakich w narzędziach dla deweloperów pojawia się co tydzień. Ciekawszy jest sposób, w jaki Atlassian to opakowuje.

Wystarczy jedna linijka w pliku konfiguracyjnym bitbucket-pipelines.yml: wpisujesz provider: codex i to wszystko, agent w pipelinie rusza na Codeksie. Bez tej linijki Bitbucket sięga domyślnie po własnego agenta, Rovo Dev, czyli agenta do kodu, którego Atlassian rozwija samodzielnie. Kilka tygodni temu w ten sam sposób doszedł Claude od Anthropica, więc Claude był drugi, a Codex dochodzi teraz jako trzeci. Trzy różne agenty, jeden parametr, ta sama definicja pipeline'u. Atlassian buduje wokół tego konkretną tezę: to ty decydujesz w jednym miejscu, w pliku konfiguracyjnym, którego agenta uruchomić, kiedy i do czego, a wymiana modelu nie wymaga przebudowywania całego procesu.

To jest realna obietnica dla zespołów, które już dziś żonglują kilkoma agentami. Jeden agent bywa lepszy do jednego zadania, drugi do innego, a wybór potrafi się zmieniać z tygodnia na tydzień. Dotąd przesiadka oznaczała grzebanie w konfiguracji i klejenie wszystkiego od nowa, a tutaj wystarczy podmienić nazwę dostawcy, bo reszta pipeline'u zostaje na miejscu: dostęp do kodu, do sekretów, do zmiennych środowiskowych i do serwerów MCP, przez które agent dosięga zewnętrznych narzędzi, na przykład bazy danych albo systemu zgłoszeń. Dla kogoś, kto utrzymuje kilka agentów lokalnie, to mniej tarcia.