AI w developmencie e-commerce coraz mocniej wchodzi do codziennej pracy zespołów developerskich. Pomaga generować kod, pisać testy, analizować istniejące rozwiązania, tworzyć dokumentację czy szybciej poruszać się po nieznanym fragmencie projektu. W przypadku rozwoju platform e-commerce brzmi to szczególnie atrakcyjnie. Projekty są złożone, backlogi długie, a czas developerów kosztowny. Jeżeli część pracy można wykonać szybciej z pomocą AI, naturalnie pojawia się pytanie: czy sztuczna inteligencja może realnie skrócić czas developmentu, a w konsekwencji również czas i koszt wdrożenia e-commerce?
Może, ale nie dzieje się to automatycznie.
Samo wygenerowanie kodu szybciej nie oznacza jeszcze szybszego dostarczenia dobrej funkcjonalności. Rozwiązanie trzeba zrozumieć, zweryfikować, przetestować i utrzymywać. Musi też pasować do architektury całego systemu oraz logiki biznesowej, która w złożonym e-commerce B2B czy B2C potrafi być daleka od standardowej.
W których elementach developmentu AI rzeczywiście oszczędza czas, a gdzie brak kontroli może sprawić, że dzisiejsza oszczędność stanie się jutrzejszym długiem technologicznym?
Potencjał AI w developmencie nie rozkłada się równo na wszystkie zadania.
Najwięcej można zyskać tam, gdzie problem jest dobrze opisany, istnieje określony kontekst, a rezultat można stosunkowo łatwo zweryfikować. Im mniej jednoznaczne są wymagania i im większy wpływ decyzji na architekturę całego systemu, tym ważniejsza staje się rola doświadczonego developera.
W projekcie e-commerce powstaje wiele elementów, które są potrzebne, ale nie za każdym razem wymagają tworzenia rozwiązania od początku.
Mogą to być formularze, operacje CRUD, podstawowe endpointy, elementy panelu administracyjnego czy inne powtarzalne fragmenty aplikacji.
Jeżeli projekt ma jasno określone konwencje, AI może przygotować dużą część takiego kodu znacznie szybciej niż developer piszący każdy element ręcznie.
Kluczowe jest jednak właśnie „jeżeli projekt ma jasno określone konwencje”. Model musi wiedzieć, jak w danym projekcie organizowany jest kod, jakie wzorce są stosowane, jak wyglądają zależności i czego nie powinien robić. W przeciwnym razie szybkość generowania kodu może oznaczać równie szybkie tworzenie kolejnych, niespójnych sposobów rozwiązania tego samego problemu.
AI wykorzystujemy między innymi do implementacji kodu na podstawie przygotowanych i zweryfikowanych scenariuszy behatowych oraz do generowania testów. Dzięki temu możemy pozwolić sobie na szersze sprawdzanie kodu. Większą rolę w naszym procesie odgrywają dziś Deptrac i PHPAT, a dodatkowo wprowadziliśmy testy elementów JavaScript, które wcześniej, ze względu na profil naszych projektów, nie były u nas standardem. AI pomaga nam również w refactoringu i porządkowaniu kodu. Entropia z czasem pojawia się nawet w projektach, w których mocno dbamy o jakość. Możliwość równoległej pracy z AI sprawia, że częściej możemy przebudować fragment projektu tak, aby odpowiadał regułom i zależnościom odkrytym w trakcie jego rozwoju.
AI może skracać czas potrzebny na zrozumienie składni, API, biblioteki czy fragmentu stacku, z którym developer nie pracuje na co dzień. Nie zastępuje znajomości architektury ani doświadczenia, ale może ograniczyć czas spędzany na przeszukiwaniu dokumentacji, szukaniu właściwego przykładu czy rozwiązywaniu prostych problemów wynikających z nieznajomości składni.
To samo dotyczy pracy z istniejącym, często dużym i długo rozwijanym projektem. Zrozumienie zależności, znalezienie odpowiedzialnego za problem fragmentu kodu, analiza istniejącej implementacji czy przygotowanie dokumentacji zmiany – to zadania, w których AI może wspierać developera równie dobrze jak przy pisaniu nowego kodu.
Tutaj obowiązuje ta sama zasada: AI pomaga szybciej dotrzeć do odpowiedzi. Developer musi ocenić, czy ta odpowiedź jest prawidłowa w kontekście całego systemu.
AI może przyspieszać również przygotowanie testów, szczególnie gdy developer ma już jasno określone zachowanie, które powinno zostać sprawdzone. Może pomagać w tworzeniu pierwszych wersji scenariuszy dla nowych funkcjonalności.
Nie oznacza to jednak automatycznego wzrostu jakości.
Testy wygenerowane przez AI również mogą być niepełne albo sprawdzać kod w sposób, który nie odpowiada rzeczywistemu procesowi biznesowemu. W e-commerce ma to szczególne znaczenie przy takich obszarach jak ceny, rabaty, płatności, dostępność produktów, zamówienia czy integracje z systemami zewnętrznymi.
Dlatego AI może skrócić czas przygotowania elementów weryfikacyjnych, ale nie przejmuje odpowiedzialności za określenie, co i dlaczego powinno zostać sprawdzone.
Sami stosujemy się do tych zasad, choć dokładny proces zależy od projektu. Przykładowe flow zaczynamy od wygenerowania z pomocą AI scenariuszy Behat, które pełnią jednocześnie rolę testów akceptacyjnych i specyfikacji funkcjonalności. AI wykorzystujemy również do generowania testów architektury i analizy statycznej, testów jednostkowych oraz funkcjonalnych. Rozszerzyliśmy też nasze podejście o testowanie modułów JavaScript, które wcześniej nie było standardowym elementem naszego procesu.
Największe ryzyko pojawia się wtedy, gdy szybkość generowania kodu zaczynamy utożsamiać z szybkością developmentu.
Developer może z pomocą AI stworzyć rozwiązanie w kilkanaście minut. Jeżeli jednak kod nie pasuje do architektury, powiela istniejącą logikę, tworzy niepotrzebne zależności albo nie uwzględnia przypadków brzegowych, zespół będzie płacił za tę oszczędność później.
Równie ważne jest rozpoznanie własnych ograniczeń i obszarów, w których brakuje nam wiedzy. Samo wykorzystanie AI w developmencie nie daje nam kompetencji potrzebnych do oceny rozwiązania w dziedzinie, której wcześniej nie znaliśmy.
Dobrym przykładem jest Open Mercato. Gdy do projektu dołączyła designerka, odkryła, że w systemie funkcjonowały aż 324 odcienie czerwieni. Wcześniej żaden z developerów nie zidentyfikował tego jako problemu. Podczas generowania kodu nie zostały też jasno określone zasady dotyczące spójności kolorów i miejsca ich definiowania. Niektóre odcienie były zapisywane bezpośrednio w modułach zamiast w CSS, dlatego kolejne iteracje stopniowo dokładały do projektu dług technologiczny.
Płynie z tego prosta zasada: jeżeli nie znamy się na danym obszarze, użycie AI nie sprawia automatycznie, że zaczynamy się na nim znać. Bez kompetencji pozwalających zweryfikować rezultat możemy jedynie szybciej wprowadzić do projektu rozwiązania, których konsekwencji nie potrafimy właściwie ocenić.
Problem jest szczególnie istotny w e-commerce, gdzie pojedyncza funkcjonalność rzadko działa w izolacji. Zmiana sposobu obliczania ceny może wpływać na promocje, koszyk, checkout, integrację z ERP czy raportowanie. Błędna decyzja architektoniczna może więc oddziaływać na znacznie większą część systemu, niż sugeruje rozmiar wygenerowanego fragmentu kodu.
W złożonym e-commerce jednym z najtrudniejszych elementów nie jest napisanie kodu, ale zrozumienie biznesu i właściwe odwzorowanie jego reguł w systemie.
Który system odpowiada za cenę? Gdzie powinien znajdować się stan magazynowy? Czy dana reguła należy do platformy e-commerce, ERP czy innego komponentu? Co dzieje się w przypadku wyjątku? Jak rozwiązanie będzie rozwijane za dwa lata?
Model może zaproponować odpowiedź. Nie zna jednak automatycznie pełnego kontekstu organizacji ani konsekwencji decyzji, które podejmuje.
Dlatego wybory dotyczące modelowania domeny, granic odpowiedzialności systemów czy kluczowych elementów architektury nadal wymagają świadomej decyzji zespołu.
AI może przyspieszyć implementację decyzji architektonicznej. Nie powinno zastępować procesu, w którym ta decyzja jest podejmowana.
To paradoks AI-assisted development.
Im szybciej powstaje kod, tym większe znaczenie mają code review, testy, standardy i spójność architektury.
Jeżeli developer akceptuje kolejne propozycje modelu bez ich pełnego zrozumienia, początkowe przyspieszenie może prowadzić do większej liczby zależności, duplikacji, niespójnych wzorców i kodu, którego później nikt nie chce zmieniać.
To właśnie tutaj AI i dług technologiczny zaczynają się łączyć.
Nie dlatego, że kod generowany przez AI jest z definicji zły. Problem pojawia się wtedy, gdy organizacja zwiększa tempo jego powstawania, ale nie zwiększa jednocześnie dyscypliny dotyczącej architektury, testowania i review.
Warto przy tym pamiętać, że nie każdy problem wymaga takiego samego poziomu kontroli i zrozumienia. Przeniesienie przycisku, zmiana koloru czy implementacja prostej reguły biznesowej wiążą się z innym poziomem ryzyka niż zmiana dotycząca płatności, cen czy innych krytycznych elementów systemu.
Im większe potencjalne konsekwencje błędu, tym ważniejsze stają się jasne zasady, precyzyjnie określone oczekiwania i świadoma weryfikacja rezultatu pracy AI. Zespół powinien więc nie tylko wiedzieć, jak korzystać z AI, ale również potrafić ocenić, które zadania można mu delegować z większą swobodą, a które wymagają znacznie większej kontroli człowieka.
I właśnie tutaj dochodzimy do najważniejszego warunku odpowiedzialnego wykorzystania AI w developmencie: model musi pracować w środowisku, które jasno określa zasady, kontekst i granice jego działania. Samo dodanie Codexa, Claude'a czy innego narzędzia do procesu developerskiego tego nie zapewnia.
AI może wygenerować kod bardzo szybko. Problem w tym, że w dużym projekcie e-commerce nie wystarczy, żeby kod działał.
Musi jeszcze pasować do istniejącej architektury, wykorzystywać przyjęte wzorce, respektować granice pomiędzy modułami, prawidłowo obsługiwać dane i dać się bezpiecznie rozwijać przez kolejnych developerów i kolejne lata.
Dlatego wraz ze wzrostem wykorzystania AI rośnie znaczenie czegoś, co na pierwszy rzut oka może wydawać się paradoksalne: im więcej kodu pomaga tworzyć AI, tym bardziej uporządkowane musi być środowisko, w którym pracuje.
Model potrzebuje kontekstu. Powinien wiedzieć nie tylko, co ma zbudować, ale również: jak zorganizowany jest projekt, jakie konwencje obowiązują w kodzie, z których komponentów powinien korzystać, czego nie powinien zmieniać, jak wygląda oczekiwany rezultat i jakie warunki musi spełnić kod, żeby można było uznać zadanie za zakończone.
Najlepsze rezultaty uzyskujemy jednak wtedy, gdy zasady obowiązujące w projekcie są nie tylko opisane, ale również wykonywalne i możliwe do automatycznego sprawdzenia. Dlatego tam, gdzie jest to możliwe, warto je skodyfikować i włączyć bezpośrednio w proces wytwarzania oprogramowania, między innymi jako część pipeline'u CI/CD.
Istotne jest również, aby takie mechanizmy można było łatwo uruchomić z poziomu CLI. Dzięki temu te same reguły są dostępne na wyciągnięcie jednej komendy zarówno dla developera, jak i dla agenta AI. Zasady przestają być wtedy wyłącznie deklaracją, o której trzeba pamiętać, a stają się elementem procesu, który można rzeczywiście egzekwować i weryfikować.
Bez tego dwa podobne zadania mogą zostać rozwiązane na dwa różne sposoby. Każde z osobna będzie działać, ale z czasem projekt zacznie tracić spójność.
To dlatego odpowiedzialny AI-assisted development nie zaczyna się od wyboru modelu. Zaczyna się od przygotowania środowiska, w którym model może działać według jasno określonych zasad.
Jedną z istotnych zmian w sposobie pracy z AI jest przejście od prostego promptowania do pracy opartej na specyfikacji.
Polecenie: „Dodaj możliwość zatwierdzania zamówienia przez managera” może wydawać się wystarczająco precyzyjne. W rzeczywistości pozostawia wiele pytań.
Które zamówienia wymagają akceptacji? Kto jest managerem? Czy istnieje kilka poziomów akceptacji? Co dzieje się po odrzuceniu? Kto otrzymuje powiadomienie? Czy akcję można cofnąć? Gdzie zapisywana jest historia decyzji?
Developer potrzebowałby odpowiedzi na te pytania. Agent AI również.
Dlatego w podejściu spec-first development najpierw rozpracowujemy z agentem oczekiwane zachowanie i ograniczenia rozwiązania, a dopiero później przechodzimy do implementacji.
AI może dzięki temu pracować na znacznie lepiej określonym problemie. Nie eliminuje to potrzeby myślenia. Wręcz przeciwnie. Przesuwa część wysiłku z ręcznego pisania kodu na precyzyjne definiowanie tego, co właściwie powinno powstać.
Sama specyfikacja mówi agentowi, co ma zrobić. Potrzebuje on jednak również informacji, jak powinien pracować w konkretnym codebase.
Tutaj pojawiają się instrukcje projektowe dla agentów, takie jak AGENTS.md czy CLAUDE.md. Taki plik może dostarczać agentowi informacji dotyczących między innymi struktury repozytorium, obowiązujących konwencji, sposobu uruchamiania testów czy zasad wprowadzania zmian.
To pozornie niewielka rzecz, ale rozwiązuje jeden z podstawowych problemów generowania kodu z AI: model nie powinien za każdym razem odgadywać zasad projektu od początku.
Trzeba jednak uważać, żeby taki plik nie stał się zbyt rozbudowany. Jego zawartość trafia do kontekstu przekazywanego modelowi, więc im więcej miejsca zajmują ogólne instrukcje, tym mniej zostaje go na właściwe zadanie, kod i informacje potrzebne do jego wykonania.
W kontekście AI w developmencie e-commerce ma to szczególne znaczenie. Platforma może być rozwijana przez lata, mieć wiele modułów, integracji i zależności, a poszczególne decyzje technologiczne mogą wynikać z konkretnych wymagań biznesowych. Agent musi poruszać się w tych ramach, zamiast tworzyć własne przy każdym kolejnym zadaniu.
Trzecim filarem odpowiedzialnego wykorzystania AI jest human-in-the-loop.
Nie każda operacja powinna być wykonywana automatycznie tylko dlatego, że technicznie jest to możliwe. Szczególnie istotne jest to wtedy, gdy agent nie tylko przygotowuje propozycję kodu, ale może również wykonać operację powodującą rzeczywistą zmianę w systemie.
W takich sytuacjach potrzebny jest wyraźny punkt kontroli. Człowiek powinien mieć możliwość zobaczenia, co AI zamierza zrobić, na jakich danych pracuje i jaki będzie efekt operacji, zanim zostanie ona zatwierdzona.
To ważna różnica pomiędzy automatyzacją a autonomią. Celem nie musi być stworzenie systemu, który podejmuje wszystkie decyzje samodzielnie. Znacznie bardziej wartościowe może być zbudowanie procesu, w którym AI wykonuje dużą część pracy, a człowiek zachowuje kontrolę nad operacjami wymagającymi odpowiedzialności.
Dobre wykorzystanie AI nie polega na usunięciu człowieka z procesu. Polega na ograniczeniu pracy, której człowiek nie musi wykonywać, i pozostawieniu mu kontroli tam, gdzie jego decyzja rzeczywiście ma znaczenie. To właśnie te trzy filary – spec-first development, jasne konwencje dla agentów i human-in-the-loop – odróżniają dokładanie AI do gotowego procesu od projektowania procesu developmentu z założeniem, że AI będzie jego częścią, czyli od podejścia AI-native. Dokładnie z tych założeń wyrasta Open Mercato – framework, który ma je wbudowane w architekturę.
Te założenia można opisywać na poziomie architektury, ale znacznie ciekawsze jest pytanie, co dzieje się, gdy zespół rzeczywiście próbuje w ten sposób pracować.
Podczas hackathonu Open Mercato Łukasz Chruściel razem z zespołem, którego wcześniej nie znał, miał około półtora dnia na zbudowanie działającego rozwiązania. Powstał system wspierający obsługę zgłoszeń serwisowych.
AI nie pełniło w nim roli efektownego dodatku. Miało konkretne zadanie w procesie. System mógł analizować treść zgłoszenia i pomagać wyodrębnić informacje potrzebne do dalszej obsługi, takie jak charakter problemu, lokalizacja czy priorytet. Człowiek pozostawał natomiast odpowiedzialny za dalsze planowanie pracy.
To dobrze pokazuje, gdzie AI jest szczególnie wartościowe: tam, gdzie trzeba szybko przejść od nieustrukturyzowanej informacji do danych, na których można oprzeć dalszy proces.
Sam hackathon był jednak również testem sposobu developmentu. Zespół korzystał z narzędzi AI dla developerów, takich jak Codex i Claude, a Łukasz wchodził w projekt bez wcześniejszego doświadczenia z Open Mercato i TypeScriptem. Mimo to rozwiązanie udało się w krótkim czasie doprowadzić do działającej formy.
Najważniejsza lekcja pokrywa się z tezą tego artykułu. AI w dużej mierze zniwelowało bariery wynikające z nieznajomości składni i środowiska, ale nie zdjęło z zespołu klasycznych problemów inżynierskich: jakości rozwiązania, sensownej architektury i dobrych decyzji projektowych. Te nadal zostały po stronie ludzi.
Z perspektywy CTO nie jest szczególnie istotne, z jakich konkretnie narzędzi AI dla developerów korzysta zespół: Codexa, Claude'a czy innego. Sam fakt używania AI nie mówi jeszcze nic o jakości procesu developerskiego.
Znacznie ważniejsze jest to, czy wykorzystanie AI przekłada się na krótszy czas dostarczenia funkcjonalności bez obniżenia jakości, bezpieczeństwa i możliwości dalszego rozwoju platformy.
To rozróżnienie ma znaczenie również podczas porównywania ofert software house'ów i wyboru partnera technologicznego. Deklaracja „wykorzystujemy AI w developmencie” może oznaczać bardzo różne rzeczy: od sporadycznego generowania fragmentów kodu po proces, w którym agenci pracują na przygotowanych specyfikacjach, mają określone zasady działania, a wygenerowany kod przechodzi review i testy.
Dlatego CTO nie powinien pytać wyłącznie „czy korzystacie z AI?”. Znacznie więcej można dowiedzieć się, pytając, w których etapach developmentu wykorzystywane jest AI, jak kontrolowany jest rezultat jego pracy i w jaki sposób mierzony jest rzeczywisty wpływ na czas oraz jakość dostarczanego oprogramowania.
| Pytanie | Dlaczego warto je zadać? |
|---|---|
| Do jakich zadań wykorzystujecie AI? | Pozwala odróżnić konkretne zastosowania od ogólnej deklaracji „pracujemy z AI”. |
| Jak przygotowujecie zadanie, zanim trafi do agenta? | Pokazuje, czy zespół pracuje na specyfikacji i kontekście, czy polega głównie na promptowaniu. |
| Jakie zasady projektu otrzymuje agent? | Pozwala ocenić, czy generowany kod ma szansę zachować spójność z architekturą i konwencjami projektu. |
| Kto odpowiada za code review kodu wygenerowanego z pomocą AI? | Odpowiedzialność za kod powinna pozostawać jasno określona niezależnie od sposobu jego powstania. Kod wspierany przez AI nie powinien podlegać łagodniejszym standardom niż pisany ręcznie – jak to sprawdzić, pokazuje audyt jakości i wydajności. |
| Jak testujecie kod powstały z wykorzystaniem AI? | Szybsze generowanie kodu nie powinno oznaczać rezygnacji z kontroli jakości. |
| Których decyzji nie powierzacie AI? | Dojrzały zespół powinien potrafić wskazać nie tylko możliwości, ale również granice wykorzystania AI. |
To jedno z najważniejszych pytań z perspektywy firmy inwestującej w nową platformę.
Nie ma wątpliwości, że AI obniżyło koszt generowania kodu i sprawiło, że część projektów, które wcześniej były zbyt kosztowne względem swojej wartości biznesowej, stała się bardziej dostępna.
Samo wytwarzanie kodu nigdy nie było jednak jedynym ani najważniejszym wyzwaniem w rozwoju oprogramowania e-commerce – z AI czy bez niego. Równie istotne są zrozumienie potrzeb, wydestylowanie reguł biznesowych, podjęcie właściwych decyzji architektonicznych oraz odpowiedzialność za dostarczenie, a później utrzymanie rozwiązania.
I właśnie tutaj pojawia się granica, której AI na razie nie usuwa: model może wygenerować rozwiązanie, ale nie ponosi odpowiedzialności za jego konsekwencje. Odpowiedzialność nadal pozostaje po stronie człowieka i zespołu, który decyduje, czy dane rozwiązanie można bezpiecznie wdrożyć i rozwijać.
Dlatego na pytanie o wpływ AI na koszt developmentu nie ma prostej odpowiedzi.
Jeżeli developer wykonuje określone zadanie szybciej, może to ograniczyć liczbę godzin potrzebnych do jego realizacji. Nie oznacza to jednak, że każda firma korzystająca z AI będzie automatycznie realizowała projekty taniej. Koszt developmentu zależy również od zakresu projektu, architektury, integracji, jakości wymagań, testów i modelu rozliczenia z software house'em.
Warto więc oddzielić produktywność developmentu od ceny projektu. AI może poprawić pierwszą. To, jak wpłynie na drugą, zależy od sposobu organizacji i rozliczania konkretnego projektu.
Z perspektywy CTO ważniejszym rezultatem może być zresztą nie tylko niższy koszt, ale również krótszy time-to-market, możliwość wykonania większego zakresu w tym samym budżecie albo więcej czasu zespołu na problemy, które rzeczywiście wymagają doświadczenia i myślenia architektonicznego.
Jeżeli organizacja chce sprawdzić, czy nowe podejście do developmentu rzeczywiście przyniesie wartość w jej przypadku, nie zawsze musi zaczynać od dużego projektu.
Jedną z możliwości jest ograniczony Proof of Concept, w którym zespół bierze konkretny problem biznesowy lub techniczny i sprawdza, jak szybko oraz z jaką jakością można przygotować działające rozwiązanie.
Kluczowy jest jednak właściwy wybór problemu. Dobry PoC nie powinien skupiać się na czymś trywialnym ani na funkcjonalności, którą łatwo odtworzyć za pomocą standardowych rozwiązań dostępnych na rynku. Taki test niewiele mówi o tym, czy wybrana architektura lub platforma poradzi sobie z rzeczywistymi wyzwaniami projektu.
Znacznie większą wartość daje podejście, w którym zespół bierze na warsztat najbardziej złożony, ryzykowny albo trudny do zreplikowania element planowanego rozwiązania. Innymi słowy: zamiast omijać najtrudniejszy problem, warto zmierzyć się z nim już na etapie PoC.
Jeżeli uda się potwierdzić wykonalność właśnie tego elementu, PoC odpowiada na najważniejsze pytanie: czy ten kierunek technologiczny rzeczywiście ma sens dla naszego projektu?
W takim podejściu warto z góry określić kryteria sukcesu. Nie tylko „czy udało się coś zbudować”, ale również: ile czasu zajęła realizacja, jaka część pracy została wykonana przy wsparciu AI, ile pracy wymagała późniejsza weryfikacja, czy rozwiązanie spełnia wymagania jakościowe i czy można je dalej bezpiecznie rozwijać. W projektach na Open Mercato taki test ma formę warsztatu AI-PoC, podczas którego działający prototyp powstaje przy wsparciu AI w ciągu kilku dni.
Tak, AI przyspiesza development, ale tylko w części zadań – szczególnie tych dobrze zdefiniowanych, powtarzalnych lub wymagających pracy z istniejącym kodem i dokumentacją. Nie oznacza to jednak automatycznego skrócenia całego projektu. Efekt zależy od jakości wymagań, architektury, sposobu wykorzystania AI oraz procesu weryfikacji wygenerowanego kodu.
Może, jeśli wzrost szybkości generowania kodu nie idzie w parze z kontrolą architektury, testami i code review. Samo wykorzystanie AI nie musi prowadzić do długu technologicznego. Ryzyko pojawia się wtedy, gdy zespół akceptuje rozwiązania bez wystarczającej weryfikacji albo pozwala agentom tworzyć niespójne wzorce w różnych częściach projektu.
Samo korzystanie z narzędzia AI oznacza przede wszystkim dodanie kolejnego wsparcia do pracy developera. W podejściu AI-native cały proces i środowisko developmentu są projektowane z założeniem, że agenci będą głównym, bądź nawet jedynym sposobem wytwarzania kodu. Wymaga to między innymi odpowiedniego kontekstu, specyfikacji, konwencji, mechanizmów kontroli oraz jasno określonych granic odpowiedzialności.
AI może pomagać w implementacji logiki biznesowej, ale samo nie powinno decydować, jak ta logika ma wyglądać. W złożonym e-commerce reguły dotyczące cen, zamówień, uprawnień, integracji czy procesów B2B wynikają z konkretnego modelu biznesowego. Najpierw trzeba je prawidłowo zrozumieć i zaprojektować, a dopiero później wykorzystać AI do wsparcia implementacji.
Warto zapytać, do jakich zadań wykorzystywane jest AI, jak przygotowywany jest kontekst dla agentów, kto weryfikuje wygenerowany kod, jakie testy musi on przejść oraz które decyzje pozostają po stronie człowieka. Dojrzały partner powinien potrafić wskazać zarówno korzyści, jak i ograniczenia swojego podejścia.
Decyzja o migracji do Sylius 2 to dopiero początek. W praktyce powodzenie upgrade'u zależy dużo bardziej od przygotowani...
Czytaj więcej →
Upgrade z Sylius 1 do Sylius 2 może być dobrą decyzją, ale nie w każdym projekcie będzie najlepszym kierunkiem. Zanim za...
Czytaj więcej →
Jeszcze kilka lat temu budowa customowego CRM-a, ERP-a czy systemu operacyjnego oznaczała miesiące pracy nad fundamentam...
Czytaj więcej →
