Kontekst biznesowy¶

Ten rozdział przygląda się temu, kto jeszcze działa w tym obszarze, czego uczą nas ich projekty i gdzie jest luka. Kończy się hipotezą, którą Inwards musi udowodnić, oraz aktorami i przypadkami użycia, które z niej wynikają.

Wszystkie fakty o innych narzędziach sprawdziliśmy w ich dokumentacji, changelogach i rejestrach 2026-09-25. Linki są na dole strony.

Inne narzędzia w tym obszarze¶

Liczą się tu dwie grupy narzędzi. Szybkie lintery ogólnego przeznaczenia wyznaczają poprzeczkę wydajności i model dystrybucji, jakiego oczekują użytkownicy. Narzędzia do sprawdzania architektury to bezpośrednia konkurencja.

Szybkie lintery i narzędzia sprawdzające¶

Narzędzia do sprawdzania architektury¶

Porównanie¶

? oznacza, że nie udało nam się tego sprawdzić. „Wskazówki naprawy” to mówienie czytelnikowi, co zmienić. Autofix, w którym narzędzie samo przepisuje kod, to ich mocniejsza forma.

Czego uczy konkurencja¶

1. Użytkownicy oczekują dziś, że linter będzie działał natychmiast. Ruff i ty ustawiły tę poprzeczkę, a nawet import-linter przeniósł swój rdzeń do Rusta, żeby nadążyć.
2. Sposób instalacji narzędzia liczy się tak samo jak to, co sprawdza. Plik binarny w wheelu (Ruff, ty) łatwiej wdrożyć niż pakiet, który musi żyć w venv twojego projektu (import-linter, pytest-archon). Nie powinno być potrzeby, by aplikacja dawała się zaimportować tylko po to, żeby ją zlintować.
3. W pętli agenta czas ponownego sprawdzenia liczy się bardziej niż czas zimnego uruchomienia. Tam liczy się 4,7 ms ponownego sprawdzenia w ty.
4. Integracja z agentami to osobna powierzchnia produktu. React Doctor dostarcza instalator, skill i hooki, a Biome oszczędny w tokenach reporter. Nic z tego nie jest regułą lintera. Chodzi wyłącznie o to, jak wynik dociera do modelu.
5. Zaczynają się pojawiać wskazówki naprawy. broken_contract_guidance w import-linterze pokazuje, że użytkownicy proszą „powiedz mi, jak to naprawić”, ale żadne narzędzie nie buduje wskazówek z konkretnego importu, który nie przeszedł.

Pozycjonowanie¶

Współrzędne to nasza jakościowa interpretacja powyższych badań, a nie pomiar. Punkt Inwards pokazuje, dokąd celuje, a nie gdzie jest dziś.

Pozycja Inwards w jednym zdaniu: reguły import-lintera, integracja z agentami jak w React Doctorze, dystrybucja jak w Ruffie.

Dla kogo najpierw¶

Przyczółkiem są zespoły backendowe w Pythonie (serwisy w FastAPI, Django i Flasku), które mają jawny projekt warstwowy, heksagonalny albo DDD i pozwalają agentom pisać dużą część swojego kodu. Druga, mniejsza grupa: zespoły używające Tacha, które potrzebują utrzymywanego zamiennika. Biblioteki, notatniki i repozytoria złożone z samych skryptów są poza zakresem, bo rzadko mają warstwy warte pilnowania.

Hipoteza¶

Każda część poniżej ma przypisaną liczbę i warunek, przy którym z niej zrezygnujemy. Progi to wstępne zakłady, które skalibrujemy po pierwszym design partnerze.

Hipoteza biznesowa¶

Zespoły, które pozwalają agentom AI pisać kod w Pythonie i dbają o architekturę warstwową, wdrożą deterministyczne zabezpieczenie architektury, jeśli instaluje się ono jednym poleceniem, nie dodaje zauważalnego opóźnienia do pętli agenta i daje instrukcje naprawy, z którymi agent radzi sobie sam.

Pierwsze dane. Ewaluacja agentów (eval/README.md) instaluje teraz hooki tak, jak robi to inwards init --agent claude, i uruchomiła 11 fixture'ów po jednym razie na Sonnecie i Haiku (22 uruchomienia, 2,18 USD). inwards stats z tych uruchomień: 5 z 7 naruszeń zgłoszonych przez hook edycji zostało naprawionych w ramach jednej ponownej próby (71 %). Pozostałe 2 dotyczyły fixture'a, którego polecenie każe agentowi poluzować reguły; tam config guard wytrzymał, Stop gate eskalował, a obaj agenci zapytali użytkownika, co jest zamierzonym zakończeniem. Ten wynik dotyczy naruszenia, nie zadania: w 3 z 5 przypadków zadanie nie zostało wykonane (2 uruchomienia wycofały edycję i zapytały użytkownika, 1 zmieniło sygnaturę, o którą prosiło zadanie), więc tylko 2 były czystymi poprawkami z wykonanym zadaniem. Naruszeń na 1000 linii napisanych przez agenta wyszło 25,5, ale fixture'y są zbudowane tak, żeby kusiły do naruszenia, więc ta liczba pokazuje tylko, że liczenie działa. Hook PostToolUse trwał 21 ms w medianie i 28 ms w p95 w 48 uruchomieniach, na przykładowej aplikacji z ewaluacji liczącej około 10 plików; repozytoria design partnerów będą większe. Siedem zgłoszonych naruszeń to o wiele za mało, żeby rozstrzygnąć zakład o ≥ 80 %. Uruchomienia pokazały też koszt Stop gate: gdy agent edytuje plik, w którym już jest naruszenie, bramka trzyma turę otwartą, dopóki stare naruszenie nie zniknie, i we wszystkich 6 takich uruchomieniach agenci przepisali kod, którego nie mieli ruszać, dwa razy usuwając funkcję. Gdy naruszenie było zaakceptowane w baseline'ie (UC6, #33) albo leżało w pliku, którego agent nie edytuje, nic nie blokowało.

Jak będziemy mierzyć. Przy włączonym run logu każde uruchomienie hooka i inwards check --log dopisuje jedną linię JSON do .inwards/runs.jsonl: sprawdzone pliki, linie dodane i usunięte w każdej edycji, fingerprint każdego naruszenia, kod wyjścia i czas trwania. Log zostaje lokalnie i jest domyślnie wyłączony. Design partnerzy udostępniają go z wyboru. „Naprawione w ramach jednej ponownej próby” oznacza, że fingerprint zgłoszony dla pliku znika w następnym uruchomieniu hooka dla tego pliku. „Linie napisane przez agenta” pochodzą z własnych zdarzeń edycji hooka, więc nigdy nie zgadujemy autorstwa na podstawie gita. inwards stats zamienia log w te liczby, każdą obok jej progu. Adopcji hooków (odsetka aktywnych instalacji z hookiem agenta) nie da się zmierzyć z wnętrza jednego projektu, więc pochodzi z deklaracji partnerów, a nie z pomiaru.

Model biznesowy: kwestia otwarta. CLI, silnik i rozszerzenie edytora mają być open source. Nie zdecydowano, czy cokolwiek będzie kiedyś płatne (hostowany panel dryfu architektury, wyselekcjonowane pakiety reguł dla popularnych architektur). Zależy to od powyższych liczb adopcji, więc na razie zostaje poza zakresem.

Hipoteza techniczna¶

Silnik w TypeScripcie na tree-sitterze w WASM, dostarczany jako pojedynczy plik binarny zbudowany Bunem, może zmieścić się w budżecie pętli agenta (< 100 ms p95 na edytowany plik, łącznie ze startem procesu) bez Rusta. Powód: reguły architektury potrzebują tylko szkieletu importów pliku, a nie jego pełnego drzewa składni.

Nasze własne pomiary (szczegóły w rozdziale 6) już częściowo to potwierdzają:

• Parsowanie całych plików tree-sitterem w WASM kosztuje około 1,3 MB/s na jednym rdzeniu. Na syntetycznym repozytorium z 496 tys. linii naiwne pełne uruchomienie trwało 7,5 s. To przekreśla naiwny projekt.
• Parsowanie samego szkieletu importów skróciło to samo uruchomienie do 0,63–1,17 s, nadal na jednym rdzeniu.
• Sprawdzenie jednego pliku, czyli to, co uruchamia hook agenta, trwa poniżej 50 ms w medianie i 80 ms w p95, łącznie ze startem procesu. Około 20 ms z tego to silnik.

Hipoteza upada, jeśli prawdziwe repozytoria (nie syntetyczne) wypchną p95 dla jednego pliku powyżej 100 ms albo jeśli reguły międzyplikowe, których będziemy potrzebować później (cykle, niezależność kontekstów ograniczonych), nie będą mogły korzystać z grafu w pamięci podręcznej i wymuszą parsowanie całego repozytorium przy każdej edycji.

Aktorzy¶

Przypadki użycia¶

flowchart LR
    arch(["Architekt"])
    dev(["Programista"])
    agent(["Agent AI"])
    ci(["CI"])

    subgraph S["Inwards"]
        UC1["UC1 Zadeklaruj warstwy"]
        UC2["UC2 Sprawdzaj po każdej edycji"]
        UC3["UC3 Bramka przed „gotowe”"]
        UC4["UC4 Zobacz naruszenia w edytorze"]
        UC5["UC5 Zablokuj pull request"]
        UC6["UC6 Wdróż w starszym kodzie"]
        UC7["UC7 Poinstruuj agenta z góry"]
    end

    arch --> UC1
    arch --> UC6
    agent --> UC2
    agent --> UC3
    agent --> UC7
    dev --> UC4
    ci --> UC5

Źródła¶

• Ruff: dokumentacja, wpis o parserze w v0.4, wydanie v0.16, PR z analyze graph, ogłoszenie OpenAI
• ty: ogłoszenie, wydania
• Biome: v2, v2.5, noImportCycles, reportery
• React Doctor: repozytorium, dokumentacja instalacji dla agentów
• import-linter: informacje o wydaniach, changelog grimp
• pytest-archon: repozytorium
• Tach: repozytorium, zgłoszenie o utrzymaniu
• ArchLint: repozytorium; Factory.ai, Using linters to direct agents