Jeśli chcesz, żeby coś było zrobione dobrze, zrób to sam. Z AI.

Jeśli strona Twojej firmy działa wolno, trudno ją aktualizować lub każda drobna zmiana wymaga pomocy programisty, problem wykracza poza technologię. Utrudnia dzielenie się pomysłami, przedstawianie usług i reagowanie na potrzeby klientów.

Podobnie jak wiele małych i średnich firm, zlecaliśmy rozwój i utrzymanie strony zewnętrznym wykonawcom. W końcu powolne ładowanie stron i aktualizacje trwające tygodniami lub miesiącami skłoniły mnie do samodzielnego zajęcia się przebudową.

Na przykładzie strony naszej własnej firmy dzielimy się doświadczeniami z przebudowy witryny małej firmy przy pomocy AI: co zmieniliśmy, co przyspieszyło i gdzie nadal niezbędny był nadzór człowieka. Na rozwój i weryfikację poświęciłem około 60 godzin, korzystając z Codex, Next.js, Payload CMS oraz projektów naszego projektanta w Figma.

Problem nie dotyczył tylko strony

Przez mniej więcej rok tolerowałem problemy z naszą stroną — zarówno techniczne, jak i organizacyjne.

Większym problemem było jednak to, jak trudno było przekazywać naszą wiedzę i pomysły bezpośrednio potencjalnym klientom.

Jako właściciel i założyciel firmy regularnie rozmawiam z klientami, badam ich potrzeby, śledzę trendy w Salesforce i CRM oraz wymieniam się pomysłami technicznymi z naszymi inżynierami.

Możemy na przykład rozmawiać wewnętrznie o Salesforce Data 360, jego architekturze czy potencjalnych zastosowaniach i dojść do ciekawych wniosków technicznych.

Coś, czym inżynier mógłby podzielić się bezpośrednio, musiało przejść przez kilka osób, zanim mogło zostać opublikowane.

Częściowo wynikało to z tego, że niewiele inwestowaliśmy w stronę. Jej utrzymaniem i aktualizacją zajmował się freelancer pracujący dla nas w niepełnym wymiarze, ale ten model się nie sprawdzał.

Wtedy zacząłem myśleć o znanym powiedzeniu:

Jeśli chcesz, żeby coś było zrobione dobrze, zrób to sam.

Myślę, że to powiedzenie jest szczególnie trafne w kontekście bezpośredniego kontaktu z klientem.

Często nie dostrzegamy bowiem, ile etapów, osób i procesów dzieli klientów od ludzi, którzy faktycznie wykonują pracę.

Przez ile etapów pośrednich przechodzi problem klienta, zanim dotrze do inżyniera? I przez ile kolejnych, zanim wiedza lub rozwiązanie tego inżyniera trafi do klienta?

Każdy dodatkowy etap zwiększa dystans między ludźmi, którzy doświadczają problemów, a tymi, którzy potrafią je rozwiązać.

Uważam, że AI jest właśnie tą technologią, która może pomóc skrócić ten dystans.

Nie przez zastępowanie inżynierów, opiekunów klientów czy innych specjalistów, lecz przez eliminowanie zbędnych etapów pośrednich i rutynowej pracy.

Dzięki temu osoby faktycznie świadczące usługi mogą pracować bliżej klientów, bezpośrednio poznawać ich potrzeby i problemy oraz reagować bez przechodzenia przez wiele warstw komunikacji.

AI powinno przybliżać realizację usług do klienta, a nie tworzyć między nimi kolejną warstwę.

I właśnie to chciałem osiągnąć dzięki naszej stronie.

Przejęcie odpowiedzialności, mimo PHP

Postanowiłem odłożyć na bok wcześniejsze obawy o mikrozarządzanie i sam zająć się stroną.

Jest tylko jeden problem.

Moje doświadczenie w inżynierii oprogramowania praktycznie nie obejmowało PHP.

Zawsze starałem się go unikać, jak tylko mogłem. Dla mnie to coś w rodzaju herezji czy bluźnierstwa. Moim zdaniem to nawet nie jest język programowania.

Oczywiście przesadzam. Wiele osób uwielbia PHP i jest on powszechnie używany do tworzenia stron.

Ale chyba jestem po prostu za młody na problemy z PHP. W tworzeniu aplikacji internetowych zawsze bliżej mi było do Node.js lub stosu .NET.

Mimo to postanowiłem przyjrzeć się temu, co mamy.

Pierwsza próba: naprawmy to, co już mamy

Prace nad przebudową strony rozpocząłem 1 października 2026 roku.

Pierwszy pomysł był prosty: uporządkować istniejącą stronę, zrefaktoryzować kod, usunąć zbędne duplikacje i poprawić wydajność.

Nie byłem jednak w stanie napisać tak dużej ilości kodu w krótkim czasie, więc postanowiłem skorzystać z Codex.

Przejrzałem kod PHP i zauważyłem, że niemal każdy szablon strony miał poważne problemy z powielaniem kodu.

Podobne sekcje tworzyły różne osoby, stosując różne podejścia i mając różne wyobrażenia o tym, jak wszystko powinno działać.

Ten sam problem dotyczył wyglądu. Komponenty służące temu samemu celowi wyglądały inaczej na różnych stronach, z niespójnymi kolorami, obramowaniami i odstępami.

Wraz z naszym projektantem postanowiliśmy ujednolicić style i komponenty strony. Najpierw jednak chciałem doprowadzić istniejący kod do rozsądnego stanu.

Dzięki Codex mogłem wydzielić komponenty wielokrotnego użytku, wyeliminować powielanie kodu między stronami, zmniejszyć ilość kodu i poprawić wydajność.

Co ciekawe, prompty były całkiem proste.

Na przykład:

Weź tę sekcję, [podaj identyfikator sekcji z wyrenderowanej strony HTML], i zastąp ją, wydzielając komponent wielokrotnego użytku. Sprawdź wszystkie pozostałe strony witryny i zastąp na nich dotychczasową implementację nową. Następnie usuń cały stary i nieużywany kod oraz zweryfikuj swoją pracę.

W zasadzie tyle.

Po drodze znalazłem sporo innych problemów.

Na przykład niektóre ikony menu nawigacyjnego wyświetlane w rozmiarze 32 pikseli były w rzeczywistości plikami graficznymi ważącymi około jednego megabajta każdy.

Wyobraź sobie ładowanie obrazu o wielkości jednego megabajta tylko po to, żeby wyświetlić maleńką ikonę nawigacji.

Poprosiłem więc Codex:

Weź [obraz], przeanalizuj go, w razie potrzeby zwiększ rozdzielczość i przekonwertuj do formatu WebP. Zoptymalizuj go pod kątem szybkości ładowania strony, dopasuj do rzeczywistych wymiarów wyświetlania (na przykład 32 × 32 piksele) i maksymalnie zmniejsz rozmiar pliku bez pogarszania jakości obrazu.

Powtórzyliśmy to w całej witrynie, zastępując niepotrzebnie duże grafiki i porządkując kod.

I to zadziałało.

To robiło całkiem spore wrażenie.

Nad pierwszym etapem pracowałem od 1 do 10 października, poświęcając około czterech godzin w każdy dzień roboczy, z wyłączeniem weekendów.

W sumie było to około 28 godzin porządkowania kodu PHP i optymalizacji naszej istniejącej strony na WordPress.

W tym momencie myślałem, że zmiany techniczne są już zakończone.

Pozostało poczekać, aż nasz projektant ukończy nowe style, i mogliśmy ruszać dalej.

Zrobiłem więc przerwę od aktywnego programowania.

Ale sytuacja niespodziewanie się pogorszyła.

14 października: strona przestała działać

Od 10 do 14 października nie pracowałem aktywnie nad stroną, ale od czasu do czasu sprawdzałem wskaźniki serwera.

Początkowo sądziłem, że mogły to spowodować moje ostatnie zmiany.

Zacząłem więc szukać przyczyny i skorzystałem też z ChatGPT, aby przeanalizować istniejącą stronę i konfigurację serwera.

Z ustaleń wynikało, że problem najwyraźniej nie był spowodowany moimi zmianami w kodzie.

Utrzymywaliśmy stronę na serwerze z 2 GB RAM i dwoma procesorami, co moim zdaniem powinno wystarczyć dla naszej witryny.

Nie twierdzę przy tym, że GTranslate jest złym produktem.

Problem prawdopodobnie wynikał z połączenia kilku czynników w naszej infrastrukturze. Wtyczka wymagała z naszej strony bieżącego utrzymania i dostosowywania konfiguracji, aby wszystko działało poprawnie.

Nasz zespół aktualizował listy dozwolonych adresów IP, dostosowywał konfigurację sieci i stosował inne doraźne poprawki.

Nie rozwiązywało to jednak problemu na dłuższą metę.

Szczerze mówiąc, nie chciałem dalej utrzymywać infrastruktury podporządkowanej wtyczce do tłumaczeń.

W pewnym momencie stało się to tak irytujące, że chyba dostałem jakiejś psychozy i postanowiłem odtworzyć całą stronę od podstaw.

Zamiast naprawiać kolejną wtyczkę WordPress, postanowiłem zastąpić sam WordPress.

A wraz z nim PHP.

Przebudowa z Node.js, Next.js, React i Payload CMS

Tak więc 14 października zacząłem przebudowywać stronę.

Chciałem ograniczyć zależność od wtyczek i stworzyć spójną platformę z systemem zarządzania treścią, zintegrowanymi tłumaczeniami i strukturą, nad którą miałbym kontrolę.

Dobrze znam JavaScript i Node.js, a wcześniej zrealizowałem z ich użyciem kilka projektów.

Dlaczego Payload CMS?

Ponieważ opiera się na Next.js, a Next.js wydawał mi się całkiem dobrym wyborem.

Chciałem rozwiązania, które pozwoli mi pracować ze znanym stosem technologicznym, zamiast wprowadzać kolejny zestaw narzędzi i zależności.

Payload i Next.js zapewniły nam też rozsądną podstawę architektoniczną, więc nie musiałem wymyślać wszystkiego od zera.

Tak, kusiło mnie, żeby po prostu powiedzieć agentowi:

Przepisz całą stronę WordPress, używając wybranego przeze mnie stosu Node.js, Next.js, React i Payload CMS. Zrób to poprawnie, zrób to dobrze, wszystko zweryfikuj, użyj subagentów i nie zawracaj mi głowy.

Musiałem jednak podejść do tego inaczej.

Pierwsza wersja alfa była zasadniczo migracją jeden do jednego, z wyjątkiem bazy danych.

Wprowadziliśmy kilka nowych encji i przeorganizowaliśmy zarządzanie treścią. Chciałem, żeby korzystanie z CMS przypominało bardziej Pipedrive lub HubSpot, z nawigacją po lewej i treścią po prawej.

Migracja istniejącej strony

Warto zaznaczyć, że nie tworzyliśmy całej strony od zera.

Mieliśmy już treści, struktury stron, pomysły projektowe i lata wcześniejszej pracy.

To prawdopodobnie już czwarta duża wersja naszej witryny.

W 2019 roku zaczęliśmy od motywu Flaton dla WordPress. Mieliśmy wtedy nawet inne logo.

Później stworzyliśmy własny motyw, aktualizowaliśmy go i dalej ulepszaliśmy interfejs.

Nasz projektant pracował też nad najnowszym systemem projektowym, zanim rozpoczęła się migracja.

Była to więc pełna migracja techniczna i przebudowa struktury istniejącej strony, a nie tworzenie całkowicie nowego produktu od podstaw.

Na potrzeby migracji treści wyeksportowaliśmy wszystko z WordPress i za pomocą agenta AI odwzorowaliśmy te dane w nowym modelu bazy danych Payload CMS.

Agent pomógł przekształcić treści tak, aby pasowały do nowej struktury, zamiast po prostu kopiować wszystko do innej bazy danych.

Agentów użyliśmy również do wdrożenia nowej strony, przełączenia ruchu z implementacji PHP oraz usunięcia starych plików PHP i konfiguracji z serwera.

Czy było to najbardziej eleganckie podejście?

Prawdopodobnie nie.

Ale dla nas był to najszybszy sposób, żeby wszystko przenieść i uruchomić.

Naprawianie tego, co nie przetrwało przepisywania

Po zakończeniu pierwszego przepisywania patrzyłem na praktycznie tę samą stronę, tylko z niewielkimi różnicami.

Wtedy zacząłem naprawiać błędy.

Gdzieś przestał działać slider. Gdzieś rozjechał się układ. Niektóre komponenty nie zachowywały się dokładnie tak jak wcześniej.

Podczas naprawiania tych problemów zauważyłem, że nie wszystkie komponenty zostały prawidłowo zastąpione.

Niektóre szablony stron nadal zawierały surowy HTML, a inne miały nowo utworzone komponenty, które tylko trochę przypominały te wielokrotnego użytku, które już mieliśmy.

Zacząłem więc identyfikować i katalogować te miejsca, a następnie poprawiać je jedno po drugim.

Prompt brzmiał mniej więcej tak:

Hej, oto sekcja [podaj nazwę lub identyfikator sekcji]. Zastąp ją istniejącym komponentem wielokrotnego użytku [podaj nazwę komponentu]. Zachowaj taką samą lub podobną semantykę i zachowanie, usuń starą implementację i wyczyść nieużywany kod.

Dalej zastępowałem stare implementacje, ulepszałem renderowanie po stronie serwera, wprowadzałem buforowanie i optymalizowałem komponenty.

Od 14 do 23 października poświęcałem na ten drugi etap około czterech godzin w każdy dzień roboczy — w sumie mniej więcej 32 godziny.

Jeden agent tworzy, drugi sprawdza, a człowiek decyduje

Innym ciekawym aspektem była organizacja prac programistycznych i wdrożenia.

Nie pracowałem z jednym agentem, który robił wszystko.

Korzystałem z kilku agentów do różnych zadań i tworzyłem zestawy instrukcji wielokrotnego użytku (skills) do wdrażania strony.

Zestawy te zawierały instrukcje dotyczące skryptów wdrożeniowych, testów do uruchomienia i sposobu realizacji poszczególnych etapów procesu.

Podczas prac agenci tworzyli też narzędzia i skrypty do testowania oraz wdrażania strony.

Zamiast więc za każdym razem wyjaśniać całą procedurę wdrożenia, mogłem ponownie wykorzystywać te same instrukcje i procesy.

Przy weryfikacji w dużym stopniu polegałem na Git, aby śledzić zmiany i sprawdzać, co faktycznie dzieje się w kodzie.

Analizując różnice w Git i przeglądając zmiany plik po pliku, mogłem wykrywać zduplikowany kod, powtarzające się wzorce, zbędne rozgałęzienia czy skomplikowane instrukcje if-else.

Gdy tylko zauważałem coś takiego, prosiłem agenta o poprawkę.

Podejście architektoniczne w dużej mierze wyznaczały Payload CMS i Next.js, więc chciałem, żeby agenci trzymali się istniejących konwencji tych frameworków, zamiast wymyślać całkiem nową architekturę.

Zlecałem też osobnym agentom przegląd implementacji.

Proces był dość prosty:

Jeden agent tworzy, drugi sprawdza, a człowiek decyduje, co jest dobre, a co nie.

A człowiek zwraca uwagę na samą stronę, nie tylko na kod.

Ręcznie sprawdzałem interfejs, sposób renderowania stron, testowałem komponenty i szukałem problemów wizualnych, które mogły nie być oczywiste przy samym przeglądaniu kodu.

W tym przypadku pełniłem funkcje programisty, recenzenta kodu, testera manualnego i osoby odpowiedzialnej za zapewnienie jakości.

Około 30% czasu poświęciłem na przegląd kodu, sprawdzanie implementacji i weryfikację rezultatów.

Wprowadziłem też dodatkowe kontrole wykonywane przez agentów przed wdrożeniem, aby wykryć pozostałe problemy i usunąć kod pozostawiony po kolejnych iteracjach.

Bo AI generuje ogromne ilości kodu.

Jeśli nikt nie zwraca uwagi na to, co powstaje, łatwo po prostu zastąpić stary dług techniczny nowym.

Tłumaczenie strony za pomocą agentów AI

Kolejną ważną częścią wdrożenia były tłumaczenia.

Wcześniej korzystaliśmy z GTranslate do tłumaczenia treści w czasie rzeczywistym.

Tym razem chciałem obsługiwać tłumaczenia bezpośrednio w naszej platformie.

Wykorzystaliśmy agenta AI do przetłumaczenia angielskich treści na wszystkie pozostałe wersje językowe strony.

Prompt brzmiał:

Tłumaczysz treści z języka angielskiego na [język docelowy].

Przeanalizuj angielską wersję treści i zidentyfikuj nazwy marek, terminy specyficzne dla danej technologii, nazwy produktów i inne nazwy własne.

Przed tłumaczeniem upewnij się, że rozumiesz pierwotną intencję i dokładne znaczenie treści. Zachowaj je w tłumaczeniu możliwie najwierniej, przestrzegając jednocześnie zasad języka określonego jako [język docelowy].

W stosownych przypadkach zachowaj nazwy marek, produktów i terminologię specyficzną dla danej technologii.

Po przetłumaczeniu zweryfikuj swoją pracę: upewnij się, że znaczenie zostało zachowane, język brzmi naturalnie i nie pominięto żadnej treści.

Przetłumacz wszystkie treści, w tym tytuł artykułu, nagłówki, tekst główny i wszystkie powiązane metadane.

Nie chodziło jedynie o tłumaczenie słów. Chciałem, żeby treści były zgodne z zasadami danego języka i brzmiały naturalnie dla lokalnych odbiorców.

Oddzieliliśmy też informacje specyficzne dla marek od treści do tłumaczenia, aby nazwy firm, produktów i inne ważne terminy nie były tłumaczone błędnie.

Teraz możemy zarządzać tłumaczeniami bezpośrednio w naszym CMS, bez polegania na wtyczce tłumaczącej wszystko w czasie rzeczywistym.

Oczywiście tłumaczenia AI nie są idealne, zwłaszcza w przypadku treści technicznych dotyczących Salesforce, CRM i inżynierii oprogramowania.

Jeśli więc odwiedzicie naszą stronę w swoim języku i zauważycie, że coś brzmi nienaturalnie, jest źle napisane albo nie ma sensu, po prostu wyślijcie mi wiadomość prywatną.

Zajmę się tym.

Kiedy Figma, Codex i GPT-6 połączyły siły

W międzyczasie nasz projektant ukończył nowy system projektowy w Figma. I wtedy zaczęło się robić ciekawie.

Figma obsługuje integrację przez MCP, a my już korzystamy z OpenAI w połączeniu z Salesforce i innymi platformami. Połączyłem więc Figma ze swoim kontem OpenAI.

Dzięki temu mogłem wziąć link do węzła w Figma — przycisku, sekcji czy innego komponentu — i przekazać go do Codex działającego z modelem GPT-6. Codex pobierał projekt i wdrażał go bezpośrednio na naszej stronie.

Dzięki wcześniejszej pracy nad wydzielaniem komponentów wielokrotnego użytku mógł zastosować nowy system projektowy na wielu stronach, zamiast wdrażać te same zmiany wszędzie osobno. Zamiast ręcznie pisać CSS i dopasowywać każdy odstęp wewnętrzny, promień zaokrąglenia czy układ komponentu, mogłem wykorzystać pracę projektanta z Figma i zlecić jej wdrożenie w kodzie.

Oczywiście nie było to całkowicie automatyczne. Nadal musiałem sprawdzać kod, strukturę HTML, zachowanie komponentów i miejsca, w których OpenAI mogło pójść na skróty lub źle zrozumieć wymagania.

Średnio każdy komponent wymagał około dwóch iteracji.

I na tym skupiałem najwięcej uwagi.

Co rzeczywiście osiągnęliśmy

Dzięki nowej implementacji w Node.js, buforowaniu, renderowaniu po stronie serwera i innym optymalizacjom strony ładują się teraz średnio w mniej niż sekundę, w porównaniu z około pięcioma lub sześcioma sekundami przed przebudową.

Analizowaliśmy wskaźniki wydajności w przeglądarce, w tym renderowanie stron, Largest Contentful Paint i przesunięcia układu, a audyty Semrush wykorzystywaliśmy do oceny kondycji witryny, dostępności dla robotów, nawigacji i innych kwestii technicznych.

Ale oceniałem też wydajność w znacznie prostszy sposób.

Na starej stronie faktycznie widziałem opóźnienia, zarówno na telefonie, jak i na komputerze. Strony potrzebowały czasu na załadowanie, a korzystanie z nich nie było szczególnie wygodne.

Po nowym wdrożeniu różnica była widoczna od razu.

Strona po prostu sprawia wrażenie znacznie szybszej.

Oczywiście subiektywne wrażenie nie zastępuje pomiarów technicznych, ale było dla mnie ważnym wskaźnikiem, bo właśnie tego doświadczają prawdziwi użytkownicy.

Kolejną ważną poprawą było zmniejszenie liczby problemów technicznych.

We wrześniu i październiku Semrush zgłaszał około 2 000 problemów, a w szczytowych momentach ich liczba zbliżała się do 3 000.

Teraz mamy około 400 problemów, z czego mniej więcej 200 wynika z tego, że mechanizm ochrony adresów e-mail Cloudflare jest zgłaszany jako niedziałające linki wewnętrzne.

Nadal jest co poprawiać, ale w porównaniu z punktem wyjścia sytuacja wygląda zupełnie inaczej.

Od utrzymania strony do treści trafiających bezpośrednio do klienta

Wydajność nie była jedyną poprawą.

Osiągnęliśmy też coś być może jeszcze ważniejszego: znacznie wygodniejszy sposób tworzenia treści i zarządzania nimi.

Wcześniej zmiana strony wymagała, aby ktoś ręcznie zaktualizował szablony, dostosował treści i zajął się pracą techniczną.

Zamiast angażować wiele osób w przekształcanie naszych doświadczeń w treści na stronę, większość rutynowej pracy możemy wykonać za pośrednictwem platformy.

Inżynier nie musi zostawać copywriterem. Opiekun klienta nie musi zostawać programistą. A osoba, która ma pomysł, nie powinna czekać miesiącami, aż ktoś wdroży go na stronie.

I nie oznacza to produkowania bezwartościowych, sztucznych treści generowanych przez AI.

Weźmy choćby ten artykuł.

W rzeczywistości nie jest pisany ręcznie. Pomysły i przemyślenia są dyktowane, zamieniane na tekst, a następnie dopracowywane.

Możemy powiedzieć na przykład: „Przeredaguj to, popraw brzmienie tej części, usuń zbędne słowa, użyj uprzejmiejszego języka”.

Ale pomysły, doświadczenia i opowieść nadal są nasze.

AI pomaga nam zamienić myśli w czytelny tekst, podobnie jak pomogło przełożyć projekt i wymagania techniczne na działający kod.

I właśnie o taki sposób pracy nam chodziło.

To samo podejście może sprawdzić się w artykułach technicznych, historiach sukcesu klientów, opisach usług i innych treściach, którymi chcemy się dzielić.

Wcześniej w dużym stopniu polegaliśmy na copywriterach i administratorach strony, którzy zamieniali kilka słów ekspertów technicznych w pełne artykuły.

Ekspert techniczny przez kilka minut wyjaśnia, co zrobił, a copywriter zamienia to potem w tysiące słów.

Obszerne, efektowne artykuły z mnóstwem tekstu, wyjaśnień i — dość często — lania wody.

Tymczasem sam inżynier prawdopodobnie opisałby ten sam projekt w kilku zdaniach:

„Tak, zrobiliśmy to. Było łatwo. Było ciekawie. Było fajnie”.

Może przy okazji wspomni o korzyściach biznesowych. Chociaż to opiekun klienta powinien umieć wyjaśnić je znacznie lepiej.

Chcemy, żeby nasi inżynierowie krótko wyjaśnili, co było ciekawego we wdrożeniu, co stanowiło wyzwanie techniczne i co było użyteczne, a potem wrócili do innej interesującej pracy.

Zamiast spędzać godziny na opisywaniu wszystkiego komuś, kto ostatecznie zamieni to w artykuł.

Właśnie taką rutynową pracę chcieliśmy wyeliminować.

To także mam na myśli, mówiąc o przybliżaniu realizacji usług do klienta.

AI może pomóc usunąć rutynową pracę pomiędzy tymi osobami, aby wiedza trafiała znacznie bardziej bezpośrednio od tych, którzy ją mają, do tych, którzy jej potrzebują.

Nakład pracy i koszty

Oczywiście nie oznacza to, że cała przebudowa strony kosztowała €245.

Ta kwota nie obejmuje mojego czasu, pracy naszego projektanta, infrastruktury ani lat wcześniejszych inwestycji w stronę.

Rozwijamy i ulepszamy naszą stronę od 2019 roku: zmieniamy motywy, odświeżamy projekty, tworzymy treści i dostosowujemy strukturę.

Podczas ostatniej migracji ponownie wykorzystaliśmy dużą część tej pracy.

Ciekawe jest jednak to, ile udało mi się osiągnąć przy około 60 godzinach własnego zaangażowania, wykorzystując AI do programowania, refaktoryzacji, testowania, wdrażania i przeglądu kodu.

Co zmieniło się w praktyce

Poniższe porównanie dotyczy czasu realizacji wdrożenia przy współpracy z programistą freelancerem, a nie budżetów projektowych ani bezpośredniego porównania liczby roboczogodzin.

Na przykład przygotowanie strony może wymagać około 40 godzin pracy programistycznej, rozłożonych na kilka tygodni pracy i bieżących ulepszeń.

Te szacunki dotyczą etapu po zdefiniowaniu pomysłu i wymagań. Opracowanie koncepcji i wymagań to ważne, odrębne etapy, których tutaj nie uwzględniamy.

Co dalej?

Podstawy techniczne są już gotowe.

Mamy platformę, którą możemy utrzymywać bez ręcznego edytowania każdej rzeczy na stronie.

Oczywiście nadal możemy edytować wszystko bezpośrednio, jeśli chcemy. Teraz jednak możemy po prostu powiedzieć agentowi utrzymującemu naszą stronę:

Hej, dodaj [artykuł], użyj [obrazów], utwórz na podstawie tej treści infografiki lub tabele i opublikuj ją jako [studium przypadku lub artykuł blogowy].

To samo dotyczy aktualizowania istniejących stron.

Na przykład:

Weź tę stronę [podaj adres URL lub tytuł strony], znajdź tę sekcję [podaj nazwę, tytuł lub identyfikator sekcji] i ją zaktualizuj. Zastąp obraz, popraw lub rozbuduj tekst zgodnie z moimi instrukcjami i upewnij się, że wszystko jest zgodne z naszym istniejącym systemem projektowym. Zachowaj funkcjonalność komponentu i zweryfikuj zmiany.

Niezależnie od tego, czy chcemy wymienić obraz, rozbudować opis usługi, opublikować artykuł czy zaktualizować całą sekcję, możemy wyjaśnić cel, sprawdzić rezultat i w razie potrzeby wprowadzić poprawki.

To oszczędza godziny rutynowej pracy, które możemy przeznaczyć na rozwijanie pomysłów, badanie potrzeb klientów i tworzenie użytecznych treści.

Tak, teraz sytuacja wygląda znacznie lepiej pod niemal każdym względem.

Infrastruktura jest gotowa. Platforma jest łatwa w utrzymaniu. Wystarczy jasno powiedzieć, czego potrzebujesz, a agent może dodać to w kilka minut. Łatwiej publikujemy treści i mamy znacznie większą kontrolę nad działaniem strony.

Teraz możemy skupić się na pomysłach zamiast na kwestiach technicznych.

Ważniejsza zmiana dotyczy jednak tego, jak możemy pracować z klientami.

Zamiast oddzielać inżynierów, opiekunów klientów, marketing i administratorów strony licznymi etapami i procesami, możemy znacznie usprawnić bezpośrednią wymianę wiedzy.

Osoby rozumiejące problemy klienta mogą dzielić się wiedzą, a osoby tworzące rozwiązania mogą usłyszeć, czego klienci naprawdę potrzebują.

Technologia nigdy nie miała być problemem, na którego rozwiązywanie poświęcamy większość czasu.

Miała pomagać nam przekazywać nasze pomysły klientom.

I wreszcie technologia przestała być utrapieniem.