OpenCode

OpenCode jest agentem do pracy z kodem, a nie generatorem gotowej aplikacji po jednym zdaniu. Oficjalna strona opisuje go jako narzędzie open source dostępne w terminalu, aplikacji desktopowej i IDE. To ważne dla solopreneura, bo możesz użyć go tam, gdzie naprawdę pracujesz, zamiast przenosić projekt do kolejnej zamkniętej platformy. Jego wartość zaczyna się od kontekstu: repozytorium, aktualnego celu, zasad projektu i definicji gotowości. Bez tego nawet dobry model będzie zgadywał architekturę, kopiował wzorce z niewłaściwych plików albo proponował zmianę większą niż problem.

Najbezpieczniejszy pierwszy workflow to najpierw pytanie, potem plan, na końcu zmiana. Wejdź do wersjonowanego projektu i poproś agenta o wskazanie punktów wejścia, istniejących komponentów oraz komend weryfikacji. Następnie użyj trybu planowania, który według dokumentacji nie wykonuje zmian. Dobry plan wymienia pliki, opisuje zachowanie po zmianie, ryzyka i testy. Dopiero gdy plan odpowiada realnemu zadaniu, przełącz się na implementację. Ten etap nie jest biurokracją. Pozwala zatrzymać błędne założenie, zanim agent dotknie wielu plików i zanim trudniej będzie ocenić, co właściwie zmienił.

OpenCode obsługuje wielu dostawców modeli, dlatego nie zakładaj, że każdy model poradzi sobie tak samo z każdym zadaniem. Dokumentacja opisuje konfigurację providerów i modeli, a producent oferuje też własne opcje dostępu. Wybieraj model po rodzaju pracy. Do prostego wyjaśnienia kodu może wystarczyć tańszy wariant, ale refaktor, testy lub wieloplikowa funkcja wymagają zwykle mocniejszego modelu i większej kontroli. Zawsze sprawdź aktualne zasady, limity oraz koszt po stronie wybranego dostawcy. Open source interfejsu nie oznacza automatycznie bezpłatnego użycia modeli ani bezwarunkowej prywatności całego workflow.

Największym aktywem jest plik z kontekstem projektu. OpenCode dokumentuje komendę inicjalizacji, która pomaga stworzyć AGENTS.md. Nie traktuj go jako ozdobnika. Wpisz do niego stack, strukturę katalogów, komendy testów i builda, zasady nazewnictwa, wymagania dotyczące bezpieczeństwa oraz listę rzeczy zakazanych. W projekcie marketingowym dopisz też zasady routingu, SEO, copy i deployu. Agent będzie wtedy mniej skłonny do tworzenia nowych wzorców obok istniejących. Dokument trzeba aktualizować po ważnej decyzji, bo stary kontekst jest równie groźny jak jego brak: prowadzi model pewnie w stronę nieaktualnej implementacji.

Kontrola zmian nadal należy do Ciebie. Po wykonaniu zadania obejrzyj diff, nie tylko końcowe zdanie agenta. Szukaj przypadkowych zmian w konfiguracji, sekretach, zależnościach, routingu i tekstach publicznych. Uruchom przewidziane testy, typecheck albo build, a dla strony sprawdź konkretną trasę w przeglądarce. Gdy agent nie potrafi przejść weryfikacji, nie przykrywaj problemu kolejnym poleceniem „napraw wszystko”. Zatrzymaj się, przeczytaj błąd, zawęź zadanie i poproś o wyjaśnienie przyczyny. Taki proces jest wolniejszy niż ślepa automatyzacja przez kilka minut, ale szybszy niż odzyskiwanie stabilności po złym wdrożeniu.

Bezpieczeństwo w pracy z agentem zaczyna się od minimalnego dostępu. Nie wklejaj kluczy API, tokenów klienta ani danych osobowych do promptu. Trzymaj sekrety w zmiennych środowiskowych i nie pozwalaj automatycznie wykonywać poleceń destrukcyjnych, wysyłać wiadomości ani deployować produkcji bez kontroli. Warto używać osobnej gałęzi dla większych zmian oraz oddzielić research od wykonania. OpenCode może skrócić drogę od pomysłu do działającego kodu, ale nie może przejąć odpowiedzialności za produkt. Najlepszy efekt powstaje, gdy człowiek podaje cel i granice, a agent pomaga w analizie, implementacji oraz powtarzalnej weryfikacji.