Praca z AI / przykłady z moich produktów

Jak pracuję z AI przy własnych produktach.

Rozwijam FolwarkOS, sposób organizowania pracy agentów przy moich produktach. Pokazuję tu podział ról, moje decyzje i cztery konkretne zmiany w kodzie Kurników, Gołębiarza oraz Folwark HQ.

Claude Code Codex

FolwarkOS

Jak organizuję pracę agentów.

Określam role agentów, ich źródła danych i zakres samodzielności. Oceniam propozycje i decyduję, które przechodzą do realizacji.

Kontekst pochodzi z repozytoriów i danych Folwark HQ. Czytnik przygotowuje brief z gotowych metryk, zachowuje informację o brakujących danych i domyślnie pomija konta demonstracyjne.

Przebieg pracy pod moim nadzorem. Role dobierane do zadania.
  1. Punkt wyjścia

    Dane i problem

    Brief HQ, kod produktu lub zgłoszenie wymagające sprawdzenia.

  2. Praca agentów

    Analiza i propozycja

    Możliwe przyczyny, warianty rozwiązania i ocena ryzyka.

  3. Moja odpowiedzialność

    Decyzja i zakres

    Wybieram priorytet i zakres. Wdrożenie oraz zmiana znaczenia metryki wymagają mojej decyzji.

  4. Po decyzji

    Realizacja i wnioski

    Zmiana, sprawdzenie efektu i zapis lekcji przydatnej w kolejnych zadaniach.

Trzy role, różne pytania.

Każda ma określony zakres odpowiedzialności i granice samodzielności.

CEO
Co jest teraz najważniejsze dla produktów i którą propozycję warto przedstawić mi do decyzji?
Architekt
Jak zmiana wpłynie na pozostałe moduły, integracje i wspólne zasady danych?
Krytyk
Które założenie może być błędne i czego brakuje w gotowej propozycji?
Z praktyki: podłączenie Gołębiarza do HQ

Historia inicjatywy z września 2026 r.

  1. Sygnał z briefu

    HQ nie otrzymywało danych Gołębiarza. Analiza repozytorium pokazała, że kod integracji już istniał. Propozycja dotyczyła jej podłączenia i pierwszej synchronizacji.

  2. Sprawdzenie podczas realizacji

    Podłączenie ujawniło dodatkową przeszkodę w komunikacji między systemami. Odczyt danych wzbudził też moje podejrzenie, że część kont powstała automatycznie i wymaga klasyfikacji.

  3. Decyzja i lekcja

    Wstrzymaliśmy wysyłkę do czasu sprawdzenia kont. W karcie inicjatywy zapisaliśmy wniosek: przed podłączeniem źródła trzeba ocenić wiarygodność danych, które mają z niego napłynąć.

Wspólne instrukcje i biblioteka lekcji w HQ zachowują te ustalenia na kolejne zadania. Dzięki temu do następnej analizy można dołączyć również to, co wcześniej wymagało korekty.

01Kurniki

Przedłużenie z datą w przeszłości.

Jeden warunek wpływał na dostęp, wiadomość do użytkownika i analitykę.

Użytkownik potwierdzał adres e-mail po zakończeniu pełnego okresu próbnego. Aplikacja informowała o przedłużeniu, choć wyliczona data końca już minęła. Wychodził też mail i zdarzenie marketingowe.

Co zrobiliśmy z AI

Zleciłem naprawę tego błędu. Poprawka sprawdza, czy nowy termin rzeczywiście jest w przyszłości. Testy obejmują dwa momenty powrotu użytkownika i sprawdzają także treść odpowiedzi oraz wysyłkę maili.

Scenariusze sprawdzane w testach
5. dzień
Potwierdzenie udostępnia pozostałą część pełnej próby.
20. dzień
Adres zostaje potwierdzony. Próba pozostaje zakończona.
Zobacz poprawkę i test

Warunek przed zapisaniem nowego terminu

if pelna <= now:
    return None

pelna to koniec pełnej próby liczony od rejestracji. Gdy termin minął, funkcja kończy się bez ogłaszania przedłużenia.

Fragment testu powrotu po 20 dniach

assert body["user"]["is_email_verified"] is True
assert body["trial_extended"] is False
assert body["trial_started"] is False
assert response.get_json()["message"] == "Adres został potwierdzony."
assert _sent(app, "trial_extended", to_email=email) == []
assert _sent(app, "trial_started", to_email=email) == []

Test sprawdza potwierdzenie adresu bez fałszywej informacji o nowej próbie. W dalszej części weryfikuje, że plan pozostaje nieaktywny.

02Kurniki

Kto może zobaczyć finanse fermy?

Ograniczenia dostępu obejmują odczyt i zapis danych.

Właściciel fermy może udostępnić pracownikowi wybrane moduły. To ustawienie musi działać również wtedy, gdy ktoś wywoła API bezpośrednio, z pominięciem menu aplikacji.

Od wymagania do sprawdzenia

Zmiana objęła kontrolę uprawnień na serwerze. Testy przygotowane w projekcie sprawdzają ograniczenia dla siedmiu modułów, osobno dla odczytu i dostępnych operacji zapisu. Właściciel zachowuje dostęp, a istniejące konta bez ograniczeń działają jak wcześniej.

Ten sam moduł, różne uprawnienia w teście
403
Pracownik z wyłączonym dostępem do modułu: odmowa.
200
Właściciel tej samej fermy: dostęp do danych.
Zobacz test uprawnień

Odczyt jako pracownik

read_path, write = MODULE_ENDPOINTS[module]
response = client.get(read_path, headers=worker)
assert response.status_code == 403, response.get_data(as_text=True)

Zapis jako pracownik i odczyt jako właściciel

if write is not None:
    method, path = write
    response = getattr(client, method)(path, json={}, headers=worker)
    assert response.status_code == 403, response.get_data(as_text=True)

# Właściciel tej samej fermy ma dostęp bez zmian.
assert client.get(read_path, headers=owner).status_code == 200

To fragment jednego testu uruchamianego dla produkcji, stada, magazynu, sprzedaży, finansów, raportów i abonamentu. Przed tymi wywołaniami test odbiera pracownikowi dostęp do sprawdzanego modułu.

03Folwark HQ

Co właściwie oznacza zero?

Definicja metryki jest częścią rozwiązania.

Produkt może mieć rejestracje i płatności, ale jeszcze nie mieć podłączonej analityki ruchu. Pokazanie zera wejść sugerowałoby wynik, którego nikt nie zmierzył.

Reguła wspólna dla kodu i AI

W Folwark HQ brak pomiaru ma osobną reprezentację i podany powód. Zmierzone zero pozostaje zerem. Ta zasada jest zapisana w słowniku metryk, instrukcjach dla agentów i testach, dzięki czemu można sprawdzić obie sytuacje.

Dwa przypadki sprawdzane osobnymi testami
Pomiar działa.
Zarejestrowano zero sesji.
0
Brak podłączonego GA4.
Wynik jest niedostępny.
Brak danych
Zobacz dwa przypadki w testach

Brak podłączonej analityki

assert top["key"] == "sessions"
assert top["value"] is None
assert "GA4" in top["reason"]

Zmierzone zero sesji

assert top["value"] == 0
assert top["available"] is True

W Pythonie brak wartości reprezentuje None, a w odpowiedzi JSON jest to null. Powód niedostępności pozwala wyjaśnić, czego brakuje do pomiaru.

04Gołębiarz

Premium, które wyglądało na aktywne.

Od podejrzenia do ustalenia przyczyny.

Zgłosiłem podejrzenie, że testowy plan Premium nie wyłącza się po terminie. Konto nadal wyglądało na aktywne w panelu administracyjnym.

Co wykazała analiza z AI

Pole plan przechowywało nazwę Premium także po wygaśnięciu. Faktyczny dostęp wyznaczała osobna reguła, effective_plan. Panel korzystał z surowej nazwy i wliczał wygasłe konta do Premium.

Poprawka objęła licznik oraz oznaczenie wygasłego planu. Test zestawia trzy konta: po terminie, nadal aktywne i bez daty końca.

Rozróżnienie, które wyjaśniło problem

Zapisana nazwaplan = "premium"

Faktyczny dostępUwzględnia termin ważności planu.

Zobacz test panelu

Etykiety dla trzech kont testowych

assert 'Plan wygasł' in wiersz('po-trialu@example.com')
assert 'Plan wygasł' not in wiersz('w-trialu@example.com')
assert 'Plan wygasł' not in wiersz('dozywotnie@example.com')

Funkcja wiersz wybiera wiersz danego konta z HTML-a panelu. Test sprawdza również, że licznik Premium wynosi dwa. Adresy w tym fragmencie to dane testowe.

Porozmawiajmy o szczegółach.

Chętnie pokażę szerszy kontekst tych zmian i działające produkty.

Przejdź do kontaktu na stronie głównej