Oracle po cichu wdrożyła politykę zakazującą wnoszenia kodu generowanego przez sztuczną inteligencję do OpenJDK, platformy programistycznej Java o otwartym kodzie źródłowym, której zarządza firma. Posunięcie to, zgłoszone przez The Register, powołuje się na obawy związane z bezpieczeństwem, ochroną i własnością intelektualną, pozostaje jednak w poważnym konflikcie z wewnętrznym komunikatem Oracle na temat sposobu, w jaki tworzy oprogramowanie. W ramach bieżących najnowszych wiadomości o sztucznej inteligencji ta historia podkreśla rosnącą przepaść między ambicjami korporacyjnych dotyczącymi sztucznej inteligencji a ostrożnością inżynierów.

Zgodnie z tymi zasadami programiści mogą nadal prywatnie używać dużych modeli językowych do debugowania i przeglądania kodu. Zabrania się im jednak przesyłania materiałów wygenerowanych przez sztuczną inteligencję do repozytoriów OpenJDK, żądań ściągnięcia lub innych kanałów komunikacji projektu. Ograniczenie skutecznie wyznacza granicę pomiędzy wykorzystaniem sztucznej inteligencji jako osobistego asystenta a umożliwieniem jej tworzenia kodu, który trafia do wspólnej, długotrwałej bazy kodów.

Dlaczego Oracle wyznaczyła granicę

Powody zakazu są raczej praktyczne niż filozoficzne. Kod wygenerowany przez sztuczną inteligencję wprowadza trzy kategorie ryzyka, które po fakcie trudno wyeliminować. Po pierwsze, bezpieczeństwo: LLM mogą tworzyć kod z subtelnymi lukami w zabezpieczeniach, których weryfikatorzy mogą nie od razu wykryć, szczególnie w języku tak złożonym jak Java z jego głęboką biblioteką standardową i modelem współbieżności. Po drugie, własność intelektualna: modele wyszkolone na rozległych korpusach istniejącego kodu mogą odtwarzać licencjonowany materiał dosłownie lub w ścisłej parafrazie, potencjalnie obciążając projekt open source roszczeniami dotyczącymi praw autorskich. Po trzecie, przypisanie i odpowiedzialność: gdy kod jest generowany, a nie pisany, trudniej jest ustalić, kto jest odpowiedzialny za błędy, zobowiązania licencyjne lub problemy ze zgodnością.

OpenJDK to nie tylko projekt typu open source. Jest to referencyjna implementacja języka Java, działającego na miliardach urządzeń na całym świecie, od serwerów korporacyjnych po aplikacje na Androida. Kod oparty na OpenJDK może przez dziesięciolecia trafiać do komercyjnych produktów Oracle, dystrybucji JDK innych firm i globalnego ekosystemu Java. Pojedynczy fragment problematycznego kodu wygenerowanego przez sztuczną inteligencję może spowodować konsekwencje, które będą ciągnąć się latami.

Sprzeczność z wewnętrznym nastawieniem Oracle

Tym, co czyni tę politykę niezwykłą, jest jej kontrast z publicznymi oświadczeniami Oracle na temat własnego wykorzystania sztucznej inteligencji. Współzałożyciel Larry Ellison oświadczył niedawno, że modele sztucznej inteligencji piszą teraz kod Oracle, co pozycjonuje firmę jako lidera w tworzeniu oprogramowania opartego na sztucznej inteligencji. Współdyrektor generalny Mike Sicilia przyznał, że narzędzia sztucznej inteligencji umożliwiły mniejszym zespołom inżynieryjnym szybszą realizację zadań, sugerując, że sztuczna inteligencja ma kluczowe znaczenie w strategii produktywności Oracle.

Podział odzwierciedla szersze napięcie w branży technologicznej. Firmy chętnie reklamują kod wygenerowany przez sztuczną inteligencję jako dowód innowacyjności i efektywności swoich wewnętrznych działań, szczególnie wśród inwestorów i klientów. Ale jeśli chodzi o kod, od którego zależą inni ludzie, gdzie odpowiedzialność ma charakter zewnętrzny, a promień wybuchu błędu mierzy się w ramach globalnych wdrożeń, entuzjazm maleje. Stanowisko Oracle zasadniczo mówi, że kod wygenerowany przez sztuczną inteligencję jest wystarczająco dobry dla zastrzeżonych produktów Oracle, ale nie wystarczająco dobry dla kontrolowanego przez nią projektu open source.

OpenJDK nie jest sam w swoich wątpliwościach

Oracle nie jest pierwszym dużym projektem open source, który boryka się z tym problemem, ale jest jednym z największych i najbardziej znaczących. Kilka innych społeczności open source przyjęło lub rozważa podobne ograniczenia. Jądro Linuksa, Kubernetes i Apache Software Foundation były świadkami debat na temat tego, czy wkład generowany przez sztuczną inteligencję powinien być oznaczony etykietą, ograniczony lub całkowicie zakazany. Podstawowa obawa jest uniwersalna: licencje open source i umowy dotyczące wkładu zostały zaprojektowane wokół autorów, którzy rozumieją swój kod i biorą za niego odpowiedzialność.

Model sztucznej inteligencji nie może podpisać certyfikatu pochodzenia programisty, nie może ponosić odpowiedzialności za lukę w zabezpieczeniach i nie może odpowiadać na pytania dotyczące tego, dlaczego napisał kod w określony sposób. Kiedy człowiek przesyła kod wygenerowany przez sztuczną inteligencję jako własne dzieło, w sposób dorozumiany ręczy za coś, czego może nie do końca zrozumieć, co podważa model zaufania, od którego zależy współpraca na zasadach open source.

Tło warte 70 miliardów dolarów

Ostrożność Oracle dotycząca sztucznej inteligencji w obszarze kodu wynika z ogromnych inwestycji w infrastrukturę sztucznej inteligencji. Firma zainwestuje w tym roku około 70 miliardów dolarów w rozbudowę centrów danych w celu obsługi obciążeń AI, co stanowi jeden z największych programów wydatków kapitałowych w sektorze technologicznym. Wydatki te skłoniły agencję S&P Global Ratings do obniżenia ratingu kredytowego Oracle do BBB-, o jeden stopień powyżej statusu śmieciowego, powołując się na niepewny zwrot z ogromnej inwestycji.

Kontrast jest pouczający. Oracle jest skłonna postawić dziesiątki miliardów na infrastrukturę sztucznej inteligencji, zakładając, że zapotrzebowanie na moc obliczeniową sztucznej inteligencji uzasadni koszty. Jednak jeśli chodzi o umożliwienie AI napisania kodu działającego w jednym z najważniejszych ekosystemów programistycznych na świecie, inżynierowie firmy mówią, że jeszcze nie. Przesłanie jest takie, że infrastruktura to kwestia towaru, ale jakość kodu to kwestia reputacji, a oba niosą ze sobą bardzo różne profile ryzyka.

Co to oznacza dla programistów

Dla programistów Java współpracujących z OpenJDK ta polityka oznacza bardziej przemyślane podejście do sposobu korzystania z narzędzi AI. Korzystanie z ChatGPT lub Claude w celu zrozumienia błędu lub przejrzenia wzorca projektowego pozostaje dopuszczalne. Przesłanie kodu, który został wygenerowany głównie przez narzędzie AI, nawet w przypadku edycji dokonanej przez człowieka, nie powoduje takiej sytuacji. W praktyce granica nie zawsze jest jasna, ponieważ wielu programistów wykorzystuje obecnie sztuczną inteligencję jako partnera do współpracy przy opracowywaniu projektów i może nie być w stanie wyraźnie oddzielić własnego myślenia od sugestii modeli.

Szerszy wniosek dla branży jest taki, że pośpiech w przyjmowaniu narzędzi do kodowania AI może osiągnąć pułap dokładnie w momencie, gdy jakość kodu i odpowiedzialność mają największe znaczenie. Opiekunowie oprogramowania open source, zespoły ds. bezpieczeństwa i specjaliści ds. zgodności z przepisami coraz bardziej obawiają się kodu generowanego przez sztuczną inteligencję, nawet gdy kadra kierownicza świętuje wzrost produktywności. Zakaz Oracle dotyczący OpenJDK może być sygnałem, gdzie leży prawdziwy konsensus wśród osób faktycznie zajmujących się krytycznym oprogramowaniem.

Wyprzedź sztuczną inteligencję

Rośnie przepaść między szumem o sztucznej inteligencji a rzeczywistością inżynieryjną. Śledź najnowsze doniesienia z branży AI, aby uzyskać więcej informacji o tym, jak przedsiębiorstwa radzą sobie z przejściem na sztuczną inteligencję.

Przeczytaj więcej aktualności o sztucznej inteligencji →