Portfolio inżyniera AI: co pokazać

Twoje portfolio inżyniera AI nie jest galerią. To dowód. Rekruter i lead techniczny patrzą na nie z jednym pytaniem w głowie: „czy ta osoba dowiozła coś, co działa pod obciążeniem prawdziwych danych i prawdziwych użytkowników, czy tylko sklejała tutoriale?”. W 2026 roku każdy potrafi wywołać API modelu. Różnicę robi inżynieria wokół tego wywołania: ewaluacje, obserwowalność, decyzje, kompromisy. Rynek pracy przy AI wypełnił się w ostatnich latach kandydatami, którzy ukończyli ten sam kurs i wrzucili to samo demo. Twoim zadaniem jest wyjść poza ten szum w pierwszej minucie czytania. Ten tekst jest o tym, co konkretnie pokazać i — równie ważne — czego nie pokazywać.

Trzy do czterech archetypów projektu, które realnie sygnalizują umiejętności

Nie potrzebujesz dziesięciu projektów. Potrzebujesz trzech, może czterech, które razem pokrywają różne osie kompetencji. Powtarzanie tego samego typu projektu (kolejny chatbot, kolejny „chat z PDF”) nie dodaje sygnału — mnoży szum.

• Aplikacja RAG z ewaluacjami. Nie samo „wgraj dokument, zadaj pytanie”. Pokaż chunking, wybór embeddingów, reranking, i — co kluczowe — zestaw ewaluacyjny: 30–50 par pytanie–odpowiedź z metrykami faithfulness, context recall, answer relevance. To jeden projekt, który oddziela inżyniera od osoby klejącej kod z tutoriala.
• Agent, który wykonuje prawdziwe zadanie. Nie demo „agent rozmawia z agentem”. Coś użytecznego: triage zgłoszeń, automatyczne PR-y z fixami, research z cytowaniami. Pokaż pętlę narzędziową, obsługę błędów narzędzi, limity (max kroków, budżet tokenów) i to, co dzieje się, gdy agent utknie.
• Fine-tune albo harness ewaluacyjny. Albo dostroiłeś mniejszy model do wąskiego zadania i pokazujesz, że bije baseline na twoim zbiorze, albo zbudowałeś narzędzie do ewaluacji, które porównuje modele/prompty na zdefiniowanych metrykach. Jedno albo drugie pokazuje, że rozumiesz, jak się mierzy jakość, a nie tylko jak ją deklarować.
• Wdrożony produkt z użytkownikami. Nawet mały. Nawet dziesięciu użytkowników. Liczy się to, że żyje w produkcji: ma domenę, monitoring, kontrolę kosztów, i historię tego, co się zepsuło i jak to naprawiłeś. Jeden taki projekt waży więcej niż pięć projektów, które nigdy nie wyszły poza localhost. Produkcja wymusza decyzje, których lokalny notebook nigdy nie wymusi: co zrobić, gdy dostawca modelu ma awarię, jak ograniczyć nadużycia, ile naprawdę kosztuje obsłużenie jednego użytkownika.

Dlaczego „wrappery” wciąż się liczą, jeśli inżynieria jest prawdziwa

Krąży snobizm: „to tylko wrapper na API OpenAI”. Ignoruj go. Większość wartości produktowej AI w 2026 to właśnie warstwa wokół modelu. Pytanie nie brzmi „czy to wrapper”, tylko „czy inżynieria w wrapperze jest prawdziwa”.

Prawdziwa inżynieria w wrapperze to: warstwa ewaluacji, która łapie regresje promptów; cache’owanie i fallbacki między dostawcami; kontrola kosztów per request; obsługa rate limitów i retry z backoffem; walidacja wyjścia modelu zanim trafi do użytkownika; logowanie tracenia dla każdego wywołania. Jeśli to pokazujesz, „wrapper” jest mocnym sygnałem inżynierskim. Jeśli twój kod to trzy linijki wywołania bez żadnej z tych rzeczy — to wtedy słusznie nazwą go demem.

Inny często pomijany sygnał to świadomy wybór, kiedy nie używać większego modelu. Pokazanie, że dla prostej klasyfikacji wystarczył mniejszy, tańszy model, a duży zostawiłeś do trudnych przypadków, mówi więcej o dojrzałości inżynierskiej niż wpięcie najnowszego modelu wszędzie. Koszt i latencja to też wymagania — traktuj je jak każdy inny wymóg produktowy.

README, które pokazuje decyzje i kompromisy

README to najważniejszy plik w repozytorium z punktu widzenia rekrutacji. Czytający spędza tam pierwsze trzydzieści sekund i na ich podstawie decyduje, czy w ogóle otworzy kod. README „jak uruchomić” jest konieczne, ale niewystarczające. Dodaj sekcję decyzji.

• Problem i kontekst. Dwa zdania: co to rozwiązuje i dla kogo. Bez tego czytający nie wie, czy patrzy na zabawkę, czy na narzędzie.
• Decyzje architektoniczne. „Wybrałem pgvector zamiast dedykowanej bazy wektorowej, bo skala to dziesiątki tysięcy wektorów, a jedna baza mniej do utrzymania.” To zdanie mówi więcej niż diagram.
• Kompromisy, których świadomie nie zrobiłeś. „Nie dodałem rerankingu, bo na moim zbiorze ewaluacyjnym podniósł recall o 2% kosztem 300ms latencji.” To pokazuje, że mierzyłeś, a nie zgadywałeś.
• Co byś zrobił z większym czasem. Krótka sekcja „next steps” pokazuje, że widzisz granice własnego rozwiązania.

Demonstracja ewaluacji i obserwowalności

To jest dziś najrzadszy i najmocniejszy sygnał. Większość portfoliowych projektów AI nie ma ani jednej liczby. Jeśli twój ma, jesteś natychmiast w innej lidze.

• Zbiór ewaluacyjny w repozytorium. Plik z przypadkami testowymi (wejście, oczekiwane zachowanie, metryka). Nawet trzydzieści przypadków wystarczy, żeby pokazać, że myślisz w kategoriach pomiaru.
• Metryki, nie wrażenia. „Faithfulness 0.87 na zbiorze 40 pytań” zamiast „działa całkiem dobrze”. Frazuj liczby jako wynik na konkretnym zbiorze, nie jako uniwersalną prawdę.
• Obserwowalność. Pokaż, że logujesz tracenia (np. przez narzędzie typu Langfuse albo własny logger): koszt per request, latencja p95, liczba tokenów, wersja promptu. Screenshot dashboardu w README wart jest tysiąca słów.
• Test regresji promptów. Pokaż, że zmiana promptu odpala zbiór ewaluacyjny w CI. To rzadkość, która krzyczy „ta osoba pracowała z LLM-ami na poważnie”.

Higiena GitHuba

Profil GitHub to twoja wizytówka, zanim ktokolwiek przeczyta CV. Trzy rzeczy psują wrażenie najszybciej: zapchane node_modules w repo, sekrety w historii commitów, i dwadzieścia repozytoriów-szkieletów bez README. Posprzątaj.

1. Przypnij 3–4 najlepsze repozytoria. Reszta niech będzie prywatna albo zarchiwizowana.
2. Commity opisowe, nie „wip” ×40. Historia commitów to dowód procesu myślowego.
3. Zero sekretów w historii. Przeskanuj repo (np. gitleaks) zanim je upublicznisz. Klucz API w git log to czerwona flaga rekrutacyjna.
4. .gitignore, licencja, czysty README — podstawowa higiena.
5. Profil README z jednym akapitem: kim jesteś i nad czym pracujesz teraz.

Strona osobista oraz pisanie i nauczanie jako mnożnik

Strona osobista nie musi być dziełem sztuki. Musi w trzydzieści sekund odpowiedzieć: kim jesteś, co zbudowałeś, jak się skontaktować. Lista projektów z jednym zdaniem opisu i linkiem do repozytorium oraz dema. Tyle wystarczy.

Mnożnikiem jest pisanie i nauczanie. Jeśli opiszesz, jak zbudowałeś zbiór ewaluacyjny dla swojego RAG-a, albo dlaczego porzuciłeś fine-tune na rzecz lepszego promptu — pokazujesz głębię, której samo repozytorium nie odda. Jeden dobry techniczny wpis na blogu albo jeden wątek z realnym wnioskiem inżynierskim jest wart więcej niż dziesięć „przemyśleń o AI”. To także sygnał, że potrafisz komunikować — umiejętność, za którą zespoły płacą premię.

Pisanie ma jeszcze jedną zaletę: zmusza cię do uporządkowania własnych decyzji. Kiedy próbujesz wyjaśnić komuś, dlaczego wybrałeś dane podejście, często odkrywasz luki we własnym rozumowaniu, których repozytorium nigdy by nie ujawniło. Najlepsi kandydaci, których widziałem, nie pisali dużo — pisali jeden tekst, ale taki, po którym czytający wiedział, że ta osoba realnie zmierzyła się z problemem, a nie tylko go opisała.

Anty-wzorce, które zabijają portfolio

• Klony tutoriali. Jeśli da się rozpoznać kurs, z którego pochodzi projekt, sygnał jest zerowy albo ujemny. Weź pomysł z tutoriala, ale zmień domenę, dodaj ewaluacje i wdróż — wtedy staje się twój.
• Brak metryk. Projekt AI bez ani jednej liczby to deklaracja „nie wiem, czy to działa”. To największy pojedynczy błąd w portfoliach AI.
• Brak wdrożenia. „Działa lokalnie” znaczy „nie zmierzyłem się z kosztem, latencją, sekretami i rate limitami”. Wdróż przynajmniej jeden projekt.
• Tylko notebooki. Stos plików .ipynb bez żadnej aplikacji sugeruje eksperymentatora, nie inżyniera. Zamień przynajmniej jeden notebook w usługę.
• Przerost README nad kodem. Długi, generowany README na pustym projekcie czyta się natychmiast jako pozory. Mniej obietnic, więcej działającego kodu.

Konkretna checklista

1. 3–4 projekty pokrywające różne osie: RAG z ewaluacjami, agent, fine-tune/harness, wdrożony produkt.
2. Każdy projekt ma zbiór ewaluacyjny w repo i przynajmniej jedną metrykę z liczbą.
3. Przynajmniej jeden projekt żyje w produkcji pod własną domeną.
4. Każde README ma sekcję decyzji i kompromisów, nie tylko instrukcję uruchomienia.
5. Obserwowalność widoczna: koszt per request, latencja, wersjonowanie promptów.
6. Profil GitHub posprzątany: 3–4 przypięte repo, zero sekretów, opisowe commity.
7. Strona osobista z listą projektów i jasnym kontaktem.
8. Przynajmniej jeden techniczny wpis opisujący realną decyzję inżynierską.
9. Zero klonów tutoriali rozpoznawalnych po nazwie.

TL;DR

Portfolio inżyniera AI w 2026 to dowód, nie galeria. Pokaż 3–4 projekty na różnych osiach: RAG z ewaluacjami, agent robiący realne zadanie, fine-tune lub harness ewaluacyjny, i przynajmniej jeden wdrożony produkt. „Wrappery” się liczą, jeśli mają prawdziwą inżynierię wokół wywołania modelu. README ma pokazywać decyzje i kompromisy. Najmocniejszy i najrzadszy sygnał to ewaluacje i obserwowalność — liczby zamiast wrażeń. Posprzątaj GitHub, postaw prostą stronę, napisz jeden dobry wpis techniczny. Unikaj klonów tutoriali, braku metryk i braku wdrożenia.