Rola inżyniera ds. wdrożeń bezpośrednich w OpenAI
Co robimy, jak pracujemy i jak rozwiązujemy najtrudniejsze problemy przedsiębiorstw, by przynosić realne korzyści.
Autor: Colin Jarvis, szef zespołu inżynierii wdrożeń bezpośrednich w OpenAI
Gdy pojawił się Codex, ktoś z zespołu zapytał mnie: „Co zrobimy, gdy Codex będzie potrafił za jednym podejściem rozwiązywać problemy, nad którymi pracowaliśmy przez ostatnie miesiące?”
To pytanie trafia w sedno roli inżyniera ds. wdrożeń bezpośrednich w OpenAI. Pracujemy ramię w ramię z klientami, by zrozumieć ich najtrudniejsze problemy i tworzyć rozwiązania, na których mogą polegać. Zdobyta wiedza pomaga kształtować nasze produkty i dostarcza zespołowi badawczemu konkretnych problemów do rozwiązania.
Na tym polega postęp. Jeśli co kilka miesięcy sprawiamy, że przestajemy być potrzebni, nasz zespół inżynierów ds. wdrożeń bezpośrednich dobrze wykonuje swoją pracę.
Założyłem ten zespół na początku 2025 r., by zniwelować to, co nazywamy „luką wdrożeniową”: różnicę między tym, co modele wydają się potrafić, a tym, z czego ludzie mogą niezawodnie korzystać w pracy.
Możliwości modeli rozwijają się szybciej niż systemy i procesy potrzebne do ich wykorzystania. Czasem brakującym elementem jest produkt. Czasem model wypada dobrze w teście porównawczym, ale nie radzi sobie z zadaniem przy rzeczywistych zmiennych i ograniczeniach.
Skupiamy się na najtrudniejszych problemach klientów. Tam, gdzie nasze modele już dziś potrafią wykonać zadanie, współpracujemy z zespołem produktowym i klientem, by rozwiązanie można było wdrażać wielokrotnie. Tam, gdzie nie dają rady, wspólnie z klientami i zespołem badawczym określamy braki i wprowadzamy usprawnienia. Chcemy, by każdy projekt dawał następnemu klientowi lepszy punkt wyjścia. Jeśli podniesiemy poziom bazowych możliwości tak, że przy kolejnym problemie tego typu klienci nie będą potrzebowali inżynierów ds. wdrożeń bezpośrednich, dobrze wykonaliśmy swoją pracę.
Wyzwaniem dla John Deere, firmy z branży rolniczej o 200‑letniej historii, było zapewnienie spersonalizowanego doradztwa rolnikom na dużą skalę.
Przykładem jest See & Spray — technologia precyzyjnego zwalczania chwastów, która wykorzystuje kamery i uczenie maszynowe do rozpoznawania i opryskiwania chwastów zamiast całych pól, zmniejszając zużycie środków chemicznych nawet o 70%.
Osiągnięcie tych korzyści zależy jednak od tego, czy rolnicy wiedzą, jak skonfigurować technologię, zaplanować sezon i dostosowywać metody pracy do zmieniających się warunków.
Firma John Deere wdrożyła interfejsy API OpenAI, aby zapewnić takie spersonalizowane wsparcie na dużą skalę.
AI może odpowiadać na pytania rolników, używając naturalnego języka, i udzielać dopasowanych wskazówek dotyczących konfiguracji i zaleceń, a także rozpoznawać sytuacje, w których sprzęt nie wykorzystuje pełni swoich możliwości, oraz pomagać rolnikom zrozumieć korzyści płynące z technologii.
Potencjał wykracza poza pojedyncze interakcje: chodzi o dostarczanie trafnych wskazówek na każdym etapie relacji z klientem, aby rolnicy mogli lepiej wykorzystywać sprzęt, zwiększać efektywność i działać w sposób bardziej zrównoważony.
Właśnie takie wyzwania podejmują inżynierowie ds. wdrożeń bezpośrednich w OpenAI: pomagają organizacjom przekładać możliwości AI na systemy przynoszące praktyczne korzyści w złożonych, rzeczywistych warunkach.
Problemy są jednak często słabo zdefiniowane, może brakować wiarygodnego punktu odniesienia i nie ma gotowego schematu działania. Każdy chce zbudować coś, co nigdy wcześniej nie istniało. Mniej osób chce zrobić wszystko, co konieczne, by to osiągnąć.
Poszukiwanie utalentowanych inżynierów ds. wdrożeń bezpośrednich przy jednoczesnym podnoszeniu poprzeczki tego, co uznajemy za „wystarczająco dobre”, wymagało ciągłego eksperymentowania i sprawdzania pomysłów w praktyce.
Na początku każdego spotkania zespołu inżynierów ds. wdrożeń bezpośrednich pokazuję slajd z jedną kluczową zasadą: „Zacznij od rezultatów, zrób to, co konieczne, by odnieść sukces, a potem zwiększaj skalę”.
Efektowne demo może długo robić wrażenie, zanim ktokolwiek zapyta, czy działa w rzeczywistych warunkach.
Naszym zadaniem jest rozwiązać problem klienta w sposób, za który możemy wziąć odpowiedzialność w środowisku produkcyjnym.
W połowie 2025 r. około 15 naszych inżynierów ds. wdrożeń bezpośrednich pracowało z dużym klientem z branży półprzewodników nad ponad 10 zastosowaniami. Celem było oparcie procesu weryfikacji na AI, z uwzględnieniem:
Generowania testów ukierunkowanych
Analizy przyczyn źródłowych i debugowania
Asystenta wspierającego projektowanie architektury
W tej branży weryfikacja może pochłaniać około 70% nakładu pracy nad projektem. Potencjał był ogromny, a możliwych punktów wyjścia — wiele.
Niektórzy inżynierowie ds. wdrożeń bezpośrednich dołączyli do OpenAI zaledwie kilka dni wcześniej i nigdy nie pracowali w branży półprzewodników. Włączyli się w pracę zespołu weryfikacji klienta, w wolnym czasie poznawali projektowanie układów scalonych, a wspólnie z inżynierami tworzyli testy oceniające, czy AI potrafi generować użyteczne testy i poprawnie diagnozować usterki układów.
Równolegle do zdobywania tej wiedzy tworzyliśmy otoczenia operacyjne dostosowane do poszczególnych zastosowań. W ciągu pierwszych 3–6 miesięcy wszystkie rozwiązania trafiły do środowiska produkcyjnego i zaczęli z nich korzystać pierwsi użytkownicy. Nagrodą były widoczne wyniki:
Około 48% oszczędności czasu dzięki generowaniu testów ukierunkowanych za pomocą AI.
Mediana poprawy wydajności na poziomie 22% dzięki optymalizacji kerneli.
Tygodnie debugowania skrócone do godzin
Gdy przedstawiliśmy te wyniki, dyrektor ds. sprzętu zapytał: „Czy zanim tu przyszliście, pracowaliście jako projektanci układów scalonych?”
Nasi inżynierowie ds. wdrożeń bezpośrednich nie muszą znać branży już pierwszego dnia, ale mają obowiązek ją poznać.
Gdy asystenci programowania przyspieszają tworzenie oprogramowania, zrozumienie działalności klienta staje się jeszcze ważniejsze. Tworzymy zespoły łączące osoby o szerokich kompetencjach z ekspertami dziedzinowymi.
Potrzebna jest wiedza pozwalająca trafnie oceniać sytuację oraz ciekawość, która skłania do kwestionowania założeń dotyczących obecnego stanu rzeczy.
Na przykład w naukach o życiu przygotowanie naukowe naszych inżynierów ds. wdrożeń bezpośrednich pomaga im zdobywać zaufanie badaczy zajmujących się przedklinicznym odkrywaniem leków, w tym walidacją i priorytetyzacją celów terapeutycznych, analizą ekspresji genów oraz odtwarzaniem ścieżek syntezy chemicznej. Ta wiedza pozwala im rzetelnie oceniać, jak można usprawnić te procesy.
Pokazaliśmy, że te procesy mogą przynosić korzyści, ale wdrożenie każdego z nich w kolejnym zespole nadal wymagało zbyt wielu indywidualnych prac integracyjnych. Kolejnym wyzwaniem było zachowanie tych wyników przy jednoczesnym ułatwieniu wdrażania i utrzymania oprogramowania.
Do tego czasu możliwości Codex znacznie wzrosły. Jeden z inżynierów ds. wdrożeń bezpośrednich przetestował przebudowę aplikacji w oparciu o Codex, a następnie wspólnie z zespołem przeniósł poszczególne zastosowania do wspólnego otoczenia operacyjnego z Codex w centrum.
Niestandardowe aplikacje przekształcono we wtyczki i umiejętności oparte na wspólnych podstawowych komponentach Codex. Codex stał się też interfejsem, co pozwoliło nam wycofać osobne interfejsy terminalowe i wiersza poleceń, które napisaliśmy dla poszczególnych zastosowań.
Udało nam się usunąć około 90% niestandardowego kodu z każdego projektu. Zmieniło to sposób, w jaki tworzyliśmy, utrzymywaliśmy i skalowaliśmy te procesy:
Mogliśmy korzystać z centralnie wprowadzanych usprawnień Codex, ograniczając ilość kodu integracyjnego potrzebnego dla każdego zastosowania
Kluczowe funkcje zebrano w umiejętności i wtyczki, co ułatwiło ich udostępnianie między zespołami oraz centralne zarządzanie nimi przez centrum kompetencji AI. Dzięki temu rozszerzenie rozwiązania na kolejny zespół mogło sprowadzać się do podłączenia nowych konektorów lub serwerów MCP, przygotowania nowych testów ewaluacyjnych — do czego również mieliśmy umiejętność — i uruchomienia całości.
W jednym z przykładów z sierpnia 2026 r. pierwsze wdrożenie trwało dwa miesiące. Rozszerzenie rozwiązania na drugi zespół zajęło jeden dzień. Wraz ze wzrostem skali kolejne zespoły wdrażały się coraz szybciej. Ten trend się utrzymał: w jednym z zastosowań z sierpnia 2026 r. wdrożenie w drugim zespole zajęło 1 dzień, podczas gdy pierwsze trwało 2 miesiące.
To jeden ze sposobów, w jaki sprawiamy, że przestajemy być potrzebni. Prace prowadzące do uruchomienia produkcyjnego pozwoliły ustalić, co naprawdę ma znaczenie. W miarę rozwoju bazowego produktu mogliśmy zastąpić znaczną część naszej niestandardowej implementacji, zachowując korzyści, które zapewniała.
Właśnie dlatego kolejność ma znaczenie. Modele LLM pozwalają nam tworzyć szybko. Wykorzystaj tę szybkość, by oddać użytkownikom coś wartościowego, sprawdzić, co działa w praktyce, a następnie zwiększać skalę sprawdzonych rozwiązań.
Ta sama zasada obowiązuje we wszystkich projektach.
OpenAI Presence, nasz produkt do wdrażania korporacyjnych agentów głosowych i do czatu, wyrósł z prawdziwych wdrożeń klientów. Praca rozpoczęła się od Swarm(otwiera nowe okno) i rozwijała się poprzez interfejs Agents API, a obecnie jeden z klientów obsługuje ponad połowę połączeń za pomocą sztucznej inteligencji.
Wdrożenie tych rozwiązań w środowisku produkcyjnym nauczyło nas, które problemy wymagają niestandardowego rozwiązania i z jakich bloków konstrukcyjnych mogą korzystać inne zespoły. Wprowadziliśmy te podstawowe elementy do Presence, ułatwiając programistom automatyzację przepływów pracy objętych regulacjami bez konieczności budowania od nowa podstawowej infrastruktury. Każde wdrożenie pomogło ukształtować produkt i zapewniło kolejnemu klientowi lepszy punkt wyjścia.
We współpracy z Thrive Holdings inżynierowie ds. wdrożeń bezpośrednich i naukowcy OpenAI pracowali wraz z inżynierami i księgowymi, aby zbudować Tax AI dla firm księgowych należących do Crete. Podczas pilotażu Tax AI przetworzyła 7000 deklaracji podatkowych i zwiększyła przepustowość o około 50%.
Jednym z najtrudniejszych wyzwań była automatyzacja przygotowywania zeznań podatkowych dotyczących wynajmowanych nieruchomości, co wymagało sześciu tygodni pracy inżynierów i weryfikacji przez specjalistów, aby osiągnąć 90% precyzji i kompletności. W wyniku tej pracy stworzono wzorce wielokrotnego użytku, które ułatwiły rozszerzenie Tax AI na inne złożone załączniki do zeznań podatkowych.
Zespoły stosują teraz to samo podejście w zakresie księgowości, audytu i wsparcia IT — tworzą systemy, które udoskonalają się dzięki opiniom specjalistów i praktycznemu wykorzystaniu.
Czasem lepszy produkt pozwala uprościć to, co zbudowaliśmy, ale czasem sam model nie potrafi jeszcze wykonać zadania.
Jeśli będziemy tworzyć tylko to, na co pozwalają dzisiejsze modele, nie odkryjemy braków w ich możliwościach, którymi zespół badawczy powinien zająć się w następnej kolejności. Dlatego wiele naszych ważnych projektów zaczyna się właśnie na granicy tych możliwości, a klient, inżynierowie ds. wdrożeń bezpośrednich i zespół badawczy zobowiązują się wspólnie ją przekroczyć.
Wspólnie z dużym klientem z branży telekomunikacyjnej opracowaliśmy już platformę obsługi klienta, którą chciał on rozszerzyć o obsługę głosową.
Rozmowy głosowe stanowiły około 90% kontaktów z jego działem obsługi klienta. Automatyczna obsługa tych spraw była droższa niż obsługa na czacie i wiązała się z nowymi wyzwaniami technicznymi: obsługą akcentów, tonem głosu oraz osiągnięciem opóźnień i dokładności odpowiednich do użytku produkcyjnego. Skuteczne rozwiązanie tych problemów przyniosłoby firmie znaczące korzyści.
Na etapie ustalania zakresu prac nasz model osiągał około 60% w kluczowych testach oceniających jego gotowość do pracy w środowisku produkcyjnym. Dotarliśmy do granic jego możliwości. Wywołanie funkcji i wykonywanie instrukcji w scenariuszach obsługi klienta wymagały usprawnień.
Wyjaśniliśmy to klientowi i włączyliśmy do prac zespół badawczy. Inżynierowie ds. wdrożeń bezpośrednich współpracowali z klientem nad budową platformy i określeniem zadań modelu. Zespół badawczy pracował nad uzupełnieniem brakujących możliwości, a kolejne wersje modelu pozwalały nam sprawdzać postępy względem wymagań klienta.
W ciągu sześciu miesięcy wyniki kluczowych testów wzrosły z około 60% do 80%, a następnie przekroczyły 90%, osiągając poziom wymagany do użytku produkcyjnego.
Powstały w ten sposób model głosowy obsługuje dziś wdrożenie tego klienta, inne niestandardowe wdrożenia w obsłudze klienta oraz wdrożenia zarządzane za pośrednictwem Presence. Problem napotkany w działalności jednego klienta pomógł wskazać usprawnienia, z których mogło skorzystać wielu innych.
Każdy element miał znaczenie. Klient zobowiązał się pracować nad problemem, którego model nie potrafił jeszcze rozwiązać. Inżynierowie ds. wdrożeń bezpośrednich byli wystarczająco blisko klienta, by zdefiniować problem, zbudować platformę i poprowadzić projekt od początku do końca. Zespół badawczy udoskonalił możliwości modelu stanowiącego podstawę rozwiązania.
To drugi sposób, w jaki sprawiamy, że przestajemy być potrzebni: pomagamy przekształcić problem, którego dzisiejsze modele nie potrafią rozwiązać, w możliwość dostępną w przyszłych modelach. Korzyści z naszej pracy wykraczają poza godziny spędzone z pojedynczym klientem.
Dołączyłem do OpenAI, by pomóc uczynić AI użyteczną w codziennej pracy ludzi. To nadal wyznacza kierunek działań zespołu. Często mówię zespołowi, że w pracach nad LLM w większości przypadków sprawdza się brzytwa Ockhama — najprostsze rozwiązanie jest najlepsze. W firmie, której tożsamość wyznaczają pionierskie badania, i w branży pełnej przesadnych deklaracji chcemy tworzyć rozwiązania, które działają niezawodnie i na których można polegać w codziennej praktyce.
Celem jest, by każdy projekt usprawniał kolejne: dawał produkt łatwiejszy do wdrożenia, model zdolny wykonać trudniejsze zadanie lub ograniczał zakres indywidualnych prac dla następnego klienta.
Jeśli masz trudny problem do rozwiązania, chętnie podejmiemy współpracę. Jeśli chcesz pomagać w rozwiązywaniu takich problemów, zapraszamy do naszego zespołu.
Co więc robimy, gdy Codex potrafi wykonać zadania, do których przez miesiące budowaliśmy rozwiązania?
Szukamy trudniejszego problemu.
