Codex staje się workspace, a nie tylko agentem do kodu

spinny:~/writing $ vim codex-role-plugins-sites-workflows.md

1~
2W nowej zapowiedzi Codex najbardziej nie zostało mi w głowie słowo plugin. Ciekawsze jest to, że Codex próbuje stać się miejscem, w którym praca nabiera kształtu.
3~
4OpenAI opublikowało [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/) 2 czerwca 2026 roku. Widoczne nowości to pluginy według ról, Sites i adnotacje. Ale ważniejsze pytanie jest proste: czy agent może wziąć rozproszony kontekst firmowy i zmienić go w coś, co zespół może otworzyć, omówić i poprawić?
5~
6## Prawdziwa zmiana
7~
8Przez długi czas Codex był łatwy do opisania: pomagał developerom zmieniać kod. Ta aktualizacja sprawia, że ten opis jest zbyt wąski. Nowe pluginy mówią też do analytics, sales, product design, creative production, public equity investing i investment banking.
9~
10To znaczy, że Codex nie czyta tylko repozytorium. Może czytać dashboardy, notatki CRM, dokumenty, arkusze, briefy projektowe albo źródła finansowe i złożyć z nich artefakt pracy.
11~
12W tym miejscu robi się praktycznie. Większość zespołów nie potrzebuje kolejnej odpowiedzi na czacie. Potrzebuje strony, launch roomu, review boardu, planera, małej aplikacji wewnętrznej albo dashboardu, który każdy może otworzyć.
13~
14## Sites to część, którą bym obserwował
15~
16Sites wygląda najbardziej konkretnie. Odpowiedź z czatu ginie w przewijaniu. Site ma URL. Można go wysłać, skomentować, wrócić po kilku dniach i poprosić Codex o aktualizację tylko tego, co się zmieniło.
17~
18Widzę to przy launchach produktów, customer review, tygodniowych business review, memo dla inwestorów i wewnętrznym toolingu. Nie dlatego, że pierwsza wersja będzie idealna. Nie będzie. Wartość jest w tym, że zespół ma wspólny obiekt.
19~
20## Adnotacje zmniejszają feedback
21~
22Adnotacje też są ważne. Jeśli powiem zrób to jaśniejsze, agent może zmienić za dużo. Jeśli wskażę wykres, akapit albo sekcję, zakres pracy robi się mniejszy.
23~
24Tak działa prawdziwa edycja. Rzadko chce się przepisać wszystko. Zwykle chodzi o ostrzejsze zdanie, mniej mylący wykres, lżejszy slajd, lepiej posortowaną tabelę.
25~
26## Jak bym to sprawdził
27~
28Nie podłączyłbym wszystkich narzędzi pierwszego dnia. Wybrałbym nudny workflow z jasnymi właścicielami. Tygodniowy business review jest dobry: kilka metryk, kilka notatek, jeden wspólny output i ludzka recenzja przed wysłaniem.
29~
30Krótka lista:
31~
32- ustalić, jakie źródła Codex może czytać;
33- ustalić, co może pisać;
34- wymagać linków do ważnych źródeł;
35- nadać ownera każdemu artefaktowi;
36- archiwizować lub usuwać to, co nie jest już potrzebne.
37~
38Ryzykiem nie jest słaby pierwszy draft. Zespoły znają słabe drafty. Ryzykiem jest rozrost: dziesięć wygenerowanych stron, brak ownera, brak śladu źródeł i nikt nie wie, która wersja jest prawdziwa.
39~
40## Moja lektura
41~
42Ta zapowiedź pokazuje, że agenci wychodzą z fazy demo. Przydatne nie będą te najgłośniejsze. Przydatne będą te, które wchodzą w rytm zespołu: zbierają kontekst, robią draft, zostawiają ślad, przyjmują precyzyjny feedback i trzymają się granic.
43~
44Dla developerów to nie zmniejsza znaczenia engineeringu. Zwiększa je. Ktoś nadal musi zaprojektować uprawnienia, defaulty, punkty review i definicję done.
45~
46## Źródła
47~
48- [OpenAI: Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)
49~

NORMAL · codex-role-plugins-sites-workflows.md [readonly]49 lines · :q to close

2W nowej zapowiedzi Codex najbardziej nie zostało mi w głowie słowo plugin. Ciekawsze jest to, że Codex próbuje stać się miejscem, w którym praca nabiera kształtu.

4OpenAI opublikowało [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/) 2 czerwca 2026 roku. Widoczne nowości to pluginy według ról, Sites i adnotacje. Ale ważniejsze pytanie jest proste: czy agent może wziąć rozproszony kontekst firmowy i zmienić go w coś, co zespół może otworzyć, omówić i poprawić?

6## Prawdziwa zmiana

8Przez długi czas Codex był łatwy do opisania: pomagał developerom zmieniać kod. Ta aktualizacja sprawia, że ten opis jest zbyt wąski. Nowe pluginy mówią też do analytics, sales, product design, creative production, public equity investing i investment banking.

10To znaczy, że Codex nie czyta tylko repozytorium. Może czytać dashboardy, notatki CRM, dokumenty, arkusze, briefy projektowe albo źródła finansowe i złożyć z nich artefakt pracy.

11~

12W tym miejscu robi się praktycznie. Większość zespołów nie potrzebuje kolejnej odpowiedzi na czacie. Potrzebuje strony, launch roomu, review boardu, planera, małej aplikacji wewnętrznej albo dashboardu, który każdy może otworzyć.

13~

14## Sites to część, którą bym obserwował

15~

16Sites wygląda najbardziej konkretnie. Odpowiedź z czatu ginie w przewijaniu. Site ma URL. Można go wysłać, skomentować, wrócić po kilku dniach i poprosić Codex o aktualizację tylko tego, co się zmieniło.

17~

18Widzę to przy launchach produktów, customer review, tygodniowych business review, memo dla inwestorów i wewnętrznym toolingu. Nie dlatego, że pierwsza wersja będzie idealna. Nie będzie. Wartość jest w tym, że zespół ma wspólny obiekt.

19~

20## Adnotacje zmniejszają feedback

21~

22Adnotacje też są ważne. Jeśli powiem zrób to jaśniejsze, agent może zmienić za dużo. Jeśli wskażę wykres, akapit albo sekcję, zakres pracy robi się mniejszy.

23~

24Tak działa prawdziwa edycja. Rzadko chce się przepisać wszystko. Zwykle chodzi o ostrzejsze zdanie, mniej mylący wykres, lżejszy slajd, lepiej posortowaną tabelę.

25~

26## Jak bym to sprawdził

27~

28Nie podłączyłbym wszystkich narzędzi pierwszego dnia. Wybrałbym nudny workflow z jasnymi właścicielami. Tygodniowy business review jest dobry: kilka metryk, kilka notatek, jeden wspólny output i ludzka recenzja przed wysłaniem.

29~

30Krótka lista:

31~

32- ustalić, jakie źródła Codex może czytać;

33- ustalić, co może pisać;

34- wymagać linków do ważnych źródeł;

35- nadać ownera każdemu artefaktowi;

36- archiwizować lub usuwać to, co nie jest już potrzebne.

37~

38Ryzykiem nie jest słaby pierwszy draft. Zespoły znają słabe drafty. Ryzykiem jest rozrost: dziesięć wygenerowanych stron, brak ownera, brak śladu źródeł i nikt nie wie, która wersja jest prawdziwa.

39~

40## Moja lektura

41~

42Ta zapowiedź pokazuje, że agenci wychodzą z fazy demo. Przydatne nie będą te najgłośniejsze. Przydatne będą te, które wchodzą w rytm zespołu: zbierają kontekst, robią draft, zostawiają ślad, przyjmują precyzyjny feedback i trzymają się granic.

43~

44Dla developerów to nie zmniejsza znaczenia engineeringu. Zwiększa je. Ktoś nadal musi zaprojektować uprawnienia, defaulty, punkty review i definicję done.

45~

46## Źródła

47~

48- [OpenAI: Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)

49~