Tiden: sprawdzaj kod AI względem wymagań produktu

Do czego służy Tiden? Proste wyjaśnienie

Tiden pomaga zespołom programistycznym ustalić, czy agent wykonał rzeczywiście zleconą funkcję. Produkt Qase, Inc. łączy specyfikacje, sesje agentów, testy oraz dowody potrzebne do decyzji o wydaniu.

Przykład: API ma zwracać status 429 po przekroczeniu limitu i podawać czas ponowienia. Samo skompilowanie kodu nie potwierdza obu wymagań. Tiden pokazuje ich powiązanie z testami i ujawnia miejsca, w których brakuje potwierdzenia.

Pierwszy przepływ: wymaganie, test, wynik

Oficjalny przewodnik opisuje kolejne kroki:

1. Utwórz organizację lub dołącz do niej, a następnie dodaj produkt w obszarze roboczym.
2. Zainstaluj CLI na macOS, Linux lub Windows. Uruchom tiden setup, autoryzuj dostęp i powiąż repozytorium, a potem wykonaj tiden config verify.
3. Połącz aplikację GitHub Tiden z wybranymi repozytoriami i sprawdź uprawnienia.
4. Dodaj specyfikację, także z pliku Markdown, utwórz test i powiąż go z wymaganiem.
5. Wykonaj sprawdzenia i otwórz Traceability. Stany verified, not_run i no_test rozróżniają potwierdzenie, brak aktualnego wykonania i brak testu.
6. Zainstaluj hooki poleceniem tiden intent install i sprawdź ich stan. Przejrzyj gałęzie utworzone z sesji.

Najpierw wybierz zachowanie o jednoznacznym wyniku. Dopiero potem rozszerzaj model na kolejne części produktu.

Testowanie zaczyna się od oczekiwanego zachowania

Tiden czyta kod, tworzy mapę specyfikacji i wskazuje te bez testów. Specyfikacje są edytowalnym Markdownem; mogą zawierać źródła, komponenty, priorytety i historię zmian. Ułatwia to sprawdzenie, skąd wynika reguła.

Przechwytywanie intencji zapisuje decyzje z sesji programowania i przekształca je w gałęzie do przeglądu. Proces pokazany na stronie śledzi zobowiązania wynikające z umowy roboczej. Człowiek ocenia proponowane zmiany specyfikacji i testów przed ich scaleniem. Wartość testu zależy więc nadal od trafności jego asercji.

Co oznacza decyzja bramki jakości?

Bramki analizują pokrycie specyfikacji, wyniki testów, ryzyko komponentów, aktualność dowodów i dostępne problemy produkcyjne. Mogą ocenić główny stan, gałąź albo wydanie. Wynik to przejście, blokada lub zaakceptowane ryzyko.

tiden gate check --product-id <product-id> zwraca niezerowy kod przy blokadzie lub oczekującej ocenie ryzyka. Śledzenie błędów wykonania pozwala łączyć zgłoszenia z wydaniami i środowiskami. Pozytywna decyzja odnosi się do zapisanych wymagań i kontroli, a nie gwarantuje braku wszystkich błędów.

Integracje, odbiorcy i dostęp do danych

Tiden jest przeznaczony dla programistów, QA i liderów technicznych regularnie dostarczających kod agentów. Strona wymienia Claude Code, Cursor, Copilot i Codex. CLI, publiczne REST API i lokalny serwer MCP udostępniają specyfikacje, testy, gałęzie i decyzje. CLI oraz MCP należy aktualizować razem.

Aplikacja GitHub czyta autoryzowane repozytoria. Kontroluj zakres uprawnień i chroń tokeny API. Telemetrię można filtrować przez beforeSend. Politykę prywatności należy czytać wraz z umową: sprawdzone materiały nie ustanawiają powszechnej gwarancji wyłącznie lokalnego przetwarzania ani wykluczenia całego kodu klientów z treningu. Self-hosting Enterprise jest płatnym dodatkiem.

Okres próbny i sposób naliczania opłat

Stan na 15 października 2026 r.: publiczny cennik miesięczny podaje 49 USD za Starter oraz 199 USD za produkt w Team. Starter obejmuje jeden produkt, do trzech repozytoriów i 25 zweryfikowanych zmian miesięcznie. Team zawiera 100 na produkt i nieograniczone repozytoria. Oba plany mają 14 dni próby; przy kontynuacji opłaty ruszają w dniu 15.

Zweryfikowana zmiana to scalony pull request z pozytywną bramką jakości, naliczany raz. Ponowienia, nieudane zmiany i commity botów są bezpłatne. Team może doliczać nadmiarowe zmiany i telemetrię. Dowody są przechowywane trzy miesiące w Starter i dwanaście w Team. Sprawdź aktualny cennik i kalkulator; nie jest to końcowa oferta w PLN z podatkami.

Częste pytania

Czy Tiden zastępuje ludzkie code review?

Nie. Agenci proponują gałęzie, a człowiek przegląda i scala zaakceptowane zmiany. Tiden dostarcza powiązane dowody.

Czy zielone testy potwierdzają spełnienie wymagań?

Tylko w zakresie sprawdzanych zachowań. Trzeba także ocenić przypisanie do specyfikacji, luki pokrycia i aktualność wyników.

Jak zacząć w istniejącym repozytorium?

Utwórz produkt, autoryzuj repozytorium i skonfiguruj CLI. Powiąż jedną konkretną specyfikację z testem i sprawdź Traceability.

Oficjalne materiały

• Repozytorium MCP: adapter i instrukcje dla programistów.
• Historia zmian: aktualizacje produktu.
• Kontakt z Tiden: wdrożenia Enterprise i ocena bezpieczeństwa.