Claude Code - agent w terminalu, nie autocomplete w IDE

Pozycjonowanie w stosie narzędzi #

	Claude Code	Cursor	Copilot
Forma	CLI	Fork VS Code	IDE plugin
Granularność	całe zadanie	całe pliki / projekt	linijka / blok
Tryb pracy	autonomiczny agent	agent + chat + autocomplete	autocomplete + chat
Integracja	terminal, bash, MCP	wbudowane w IDE	wbudowane w IDE
Akceptacja zmian	rezultat całego zadania	per-edit lub per-task	per-suggestion

Nie są to konkurenci, tylko narzędzia o różnej granularności. W praktyce wielu programistów ma wszystkie trzy: Copilot dla autocomplete, Cursor dla eksploracyjnego pisania, Claude Code dla zadań ze zdefiniowanym kryterium sukcesu.

Tool use - co agent może zrobić #

Pod maską Claude Code to model Claude (rodzina Opus / Sonnet) wywoływany przez API w trybie tool use. Każda akcja na systemie to wywołanie konkretnego tool-a:

Tool	Opis	Typowe użycie
Read	Czyta plik	Skanowanie repo, czytanie plików docelowych
Write	Tworzy nowy plik	Generowanie testów, scaffold
Edit	Modyfikuje istniejący plik	90% codziennej pracy - punktowe zmiany
Bash	Wykonuje shell command	Build, test, lint, git, dowolne CLI
Glob	Szuka plików po wzorcu	**/*.cs, src/**/__tests__/*
Grep	Szuka treści (ripgrep)	Znajdowanie wszystkich użyć symbolu
WebFetch	Pobiera stronę WWW	Czytanie dokumentacji, zewnętrznych specyfikacji
Agent	Spawnuje sub-agenta	Równoległe niezależne podzadania

Każdy tool zwraca strukturyzowany rezultat (treść pliku, exit code + stdout/stderr, lista paths). Model dostaje to z powrotem jako kontekst następnej iteracji.

Zgody są domyślnie restrykcyjne: pierwsze wywołanie Bash z nową komendą wymaga akceptacji. Można to konfigurować przez plik ~/.claude/settings.json:

// title: settings.json
{
  "permissions": {
    "allow": [
      "Bash(dotnet test:*)",
      "Bash(dotnet build:*)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": ["Bash(git push:*)"],
    "deny": ["Bash(rm -rf:*)"]
  }
}

allow = wykonuje bez pytania. ask = pyta za każdym razem. deny = blokuje i nie pyta.

MCP - Model Context Protocol #

MCP to otwarty standard (zaproponowany przez Anthropic, adoptowany szerzej) na podpinanie zewnętrznych narzędzi do agentów LLM. Zamiast pisać własne integracje, instalujesz MCP server, który wystawia tooly w sposób zgodny ze specyfikacją - i każdy klient MCP (Claude Code, Cursor, Continue, Zed) potrafi je wywołać.

Praktyczne MCP servery:

• @modelcontextprotocol/server-filesystem - uniwersalny dostęp do FS (zwykle wbudowany).
• @modelcontextprotocol/server-postgres - introspect schema, run queries.
• @modelcontextprotocol/server-github - issue, PR, code search.
• mcp-server-jira - tickety, opisy, komentarze.
• mcp-server-slack - wiadomości, wątki.

Konfiguracja w ~/.claude/mcp.json:

// title: mcp.json
{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_URL": "postgresql://localhost/devdb"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Po dopisaniu MCP serwera, agent dostaje jego tooly do dyspozycji. Zadaniem typu „pobierz opis ticketu PROJ-1234 i zaimplementuj” zacznie od wywołania jira.getIssue, potem przejdzie do Read / Edit / Bash.

Pętla iteracyjna - zasada ReAct #

Claude Code implementuje wariant pętli ReAct (Reason + Act) - klasyczny pattern w agentach LLM:

LOOP:
  Reason: "Co teraz wiem? Co muszę sprawdzić? Jaki jest następny krok?"
  Act: wywołaj tool (Read / Edit / Bash / ...)
  Observe: dostaję rezultat
  Update: rezultat trafia do kontekstu, model przechodzi do kolejnego Reason
UNTIL: kryterium sukcesu spełnione lub max iterations

Na poziomie API to wygląda jak ciąg tool_use → tool_result w wiadomościach. Każda iteracja to osobne wywołanie modelu z rosnącą historią.

Krytyczny moment to kryterium sukcesu. Bez jasnego kryterium model „kończy”, kiedy mu się wydaje, że napisał poprawny kod - co bywa daleko od rzeczywistości. Dlatego wymuszanie TDD-loop w CLAUDE.md jest tak skuteczne:

Task is done iff ALL of:
  - just build exits 0
  - just test exits 0 with all tests passing
  - just lint exits 0

Model nie zwraca kontroli, dopóki nie zobaczy trzech zer. Pętla domknięta deterministycznie.

Praktyczne flow #

Naprawa zepsutego CI #

# title: terminal
$ claude
> The CI on PR #234 is failing. Check the logs, identify the issue,
> fix it, push the fix.

[Agent runs: gh pr checks 234 --watch]
[Agent runs: gh run view <run-id> --log-failed]
[Agent reads stderr from failing job]
[Agent runs: git checkout pr-234-branch]
[Agent runs: just test (reproduces locally)]
[Agent identifies: Date.UtcNow vs Date.Now in test that runs in CI's UTC]
[Agent runs: Edit on src/Domain/InvoiceService.cs]
[Agent runs: just test (passes)]
[Agent runs: git add -p && git commit -m "fix: use UtcNow in invoice timestamps"]
[Agent runs: git push]

Done. PR #234 should now be green within ~3 minutes once CI re-runs.

Refactor na skalę #

# title: terminal
> Replace all uses of Console.WriteLine with our Serilog logger
> (ILogger<T> from DI). Skip code under tests/.

[Agent: Glob "**/*.cs" excluding tests/]
[Agent: Grep "Console\\.WriteLine" → 47 occurrences in 23 files]
[Agent: Read each file to determine class context]
[Agent: For each file → Edit (add ILogger field if missing,
        replace Console.WriteLine with _logger.LogInformation)]
[Agent: just build → 0 errors]
[Agent: just test → all green]

47 replacements across 23 files. All tests pass. Diff in your editor.

Onboarding #

# title: terminal
> Trace the path from clicking "Pay now" on the frontend to the
> payment record being persisted in DB. Write summary in docs/payment-flow.md.

[Agent: Glob "**/PayButton.tsx" or similar]
[Agent: Read PayButton, find onClick handler]
[Agent: Trace API call → finds POST /api/payments]
[Agent: Read PaymentsController]
[Agent: Trace through MediatR handler, domain service, repo]
[Agent: Find Insert SQL]
[Agent: Write docs/payment-flow.md with mermaid diagram + file references]

Anty-wzorce #

• Brak zaufanego kryterium sukcesu. Agent uznaje zadanie za skończone, choć rzeczywiste zachowanie aplikacji jest popsute. Zawsze podpinaj testy lub jakieś verify w pętli.
• Za szerokie permissions. Bash(*) to zaproszenie do kłopotów. Zawsze whitelistuj konkretne komendy.
• Pomijanie diff review. Po zakończeniu zadania git diff w git status -s mówi ci, gdzie naprawdę zaszły zmiany. Czytanie tego trwa kilka minut, ale ratuje od silent regressions.
• Wielowątkowe zadania bez sub-agentów. Jak prosisz o trzy niezależne rzeczy w jednym promptcie, model to serializuje. Lepiej trzy osobne sesje albo explicit prośba o spawn sub-agentów.
• Brak CLAUDE.md. Bez kontraktu agent improwizuje. Im większy projekt, tym bardziej CLAUDE.md ratuje czas.

Skrótowo #

Claude Code to klient API Claude w trybie tool use, działający jako autonomiczny CLI agent. Tooly: Read/Write/Edit/Bash/Glob/Grep/WebFetch/Agent + dowolne MCP. Pętla ReAct z kryterium sukcesu domyka zadanie deterministycznie. Najlepiej działa, gdy ma jasne testy/lint/build jako kryteria. Anty-wzorce to brak kryterium, za szerokie permissions, pominięte review diffa.