TL;DR

Copilot oferuje już trzy poziomy autonomii (Chat → Edits → Agent Mode) oraz Custom Modes/Custom Agents (persony) w IDE. Łącząc kilka prostych praktyk (wspólny kontekst w markdown + świadome przełączanie ról), możesz już dziś symulować workflow wieloagentowy.

Wkrótce: Agent‑to‑Agent (A2A) i rozbudowane łańcuchy narzędzi MCP zautomatyzują tą komunikację.

Co robić teraz: Używaj Custom Modes/Custom Agents do myślenia/planowania/recenzji; pozwól Agent Mode implementować małe, łatwe do zrecenzowania zadania; zapisuj decyzje w logach (pliki markdown), by inne tryby (QA / Cloud / Architect) mogły się do nich odwoływać.

---

1. Przełom: Od Autouzupełniania do Współpracującej Autonomii

Większość programistów nadal traktuje Copilot czy inne tego typu narzędzia AI jak zaawansowane autouzupełnianie. Rzeczywistość jest inna – narzędzie oferuje całe spektrum możliwości:

Tryb	Główne Zastosowanie	Poziom Autonomii	Sweet Spot
Chat	Q&A, eksploracja, wyjaśnianie kodu	Reaktywny	Zrozumienie kontekstu i małe fragmenty kodu
Edits	Transformacje lokalne i wieloplikowe	Kierowany	Refaktoryzacje, restrukturyzacja
Agent Mode	Iteracyjna praca zorientowana na cel	Proaktywny	Zadania o jasno określonym zakresie (testy, konfiguracja, kawałek funkcjonalności)

Model mentalny: każdy krok zwiększa inicjatywę narzędzia. Przechodzisz od wydawania instrukcji linia po linii do opisywania celów i pozwalania np. Copilot-owi na kierowanie dalszą pracą.

---

2. Custom Modes/Custom Agents: Persony w Praktyce

Custom Modes/Custom Agents pozwalają zapisać instrukcje dla persony (ton, ograniczenia, priorytety, dostęp do narzędzi). Przykłady:

• Architect: projektowanie architektury i analiza trade-offów
• QA: strategia testów, pokrycie, przypadki brzegowe
• Cloud / DevOps: infrastruktura, CI/CD, bezpieczeństwo i observability
• Language Specialists: Node, Python, itp.

Dlaczego są ważne:

1. Powtarzalność – nie musisz za każdym razem przepisywać tego samego kontekstu.
2. Przełączanie trybu myślenia – myślisz inaczej, gdy persona wymusza określoną dyscyplinę (np. "zaproponuj ryzyka przed rozpoczęciem kodowania").
3. Spójność w zespole – udostępnij .github/chatmodes/*.chatmode.md w repozytorium (w nowszym VSCode agents/*.agent.md), aby każdy korzystał z tych samych person i móc wspólnie je fine‑tunować.

Custom Agents ostatnio stały się dostępne również w chmurowym coding agencie GitHub-a (https://github.com/copilot)

Minimalna Przykładowa Struktura

.github/
  chatmodes/
    architect.chatmode.md
    qa.chatmode.md
    cloud-devops.chatmode.md
    js-ts-node.chatmode.md
    python.chatmode.md

Klucze frontmatter, których możesz użyć: description, tools, model. Treść pliku = kontrakt persony.

---

3. Praktyczny Przepływ Wielopersonowy (Dostępny Już Dziś)

Podstawowa implementacja

Dopóki nie pojawi się natywna współpraca między agentami, łącz persony ręcznie:

1. Architect Mode → tworzy: cele, ograniczenia, komponenty, szkic interfejsu, ryzyka, kamienie milowe.
2. Zapisz to jako docs/architecture-session-YYYY-MM-DD.md (lub dołącz do ADR).
3. QA Mode → czyta ten plik → proponuje strategię testów i szkieletowe pliki testów.
4. Cloud / DevOps Mode → dodaje deployment/IaC oraz zmiany w CI, odwołując się do tego samego dokumentu.
5. Agent Mode → implementuje jeden kamień milowy na raz (nigdy nie zlecaj "zbudowania całej funkcji").
6. Iteruj: po każdym zadaniu dla Agenta aktualizuj wspólny dokument (decyzje / odchylenia / otwarte pytania).

Zasada kondensowania kontekstu: wspólny kontekst w markdown = wspólna pamięć zespołu.

Zaawansowana implementacja - Pamięć Persony (Stan Zakresowy dla Tematu)

Spłaszczone, globalne pliki pamięci persony działają, ale lepiej skalują się przez przypisanie pamięci do konkretnego tematu (funkcjonalność, refaktor, migracja) i oddzielenie decyzji od perspektyw persony.

docs/
  topics/
    feature-{slug}/
      source/                   # authoritative raw artifacts (stable-ish)
        business-requirements.md
        design.md
        tests.md
        infra-notes.md          # optional if produced
      decisions/                # atomic, append-only decisions (ADR-lite) - will evolve into proper project ADRs
        2025-09-29-decide-database.md
        2025-09-29-choose-queue.md
      memory/                   # per-persona rolling synopses (summaries / deltas referencing source/)
        business.memory.md      
        architect.memory.md
        qa.memory.md
        cloud-devops.memory.md
        agent.memory.md         # (when delegating PoC / milestone execution)
      topic.summary.md          # regenerated consolidation across memory + decisions
      analytics/                # derived or generated signals from PoC(s) / CI
        coverage.json
        perf-snapshot-2025-09-29.md

Warstwy koncepcyjne:

• source: stabilne dokumenty referencyjne (wymagania biznesowe, design, testy, notatki infrastrukturalne)
• decisions: niezmienne atomowe uzasadnienia (jedna sprawa na plik)
• memory: zwięzły, ewoluujący stan per persona (delta + intencja odwołująca się do source/)
• topic.summary.md: skonsolidowane podsumowanie (stan, kamienie milowe, otwarte pytania między personami)
• analytics: wygenerowane automatycznie dane wejściowe (metryki, pokrycie, wydajność)

Zasady przewodnie:

1. Jeden folder tematu na znaczącą funkcjonalność lub inicjatywę; sprawy globalne można trzymać pod topics/platform/ itp.
2. Każda persona aktualizuje tylko swój plik pamięci; inne persony proponują zmiany przez cytowane bloki lub komentarze w PR.
3. Decyzje awansują z memory do decisions/, gdy się ustabilizują (daje to permalink i historię zmian).
4. Wpisy w pamięci są opatrzone znacznikami czasu, ograniczone rozmiarem i odwołują się do artefaktów zamiast je duplikować.
5. topic.summary.md jest regenerowany (ręcznie lub automatycznie) po każdym kamieniu milowym, by utrzymać koszty wdrożenia na minimalnym poziomie.

Dlaczego to działa:

• Zakres tematyczny zapobiega rozrostowi globalnej pamięci.
• Wyraźne rozdzielenie: decyzje vs. przemyślenia przejściowe.
• Selektywny kontekst: można wstrzykiwać tylko odpowiedni folder tematu do promptów/agentów.
• Przyszła orkiestracja A2A będzie mogła porównywać snapshoty pamięci, by wyprowadzać nowe zadania.
• Analytics na zewnątrz – zmniejsza szum w podsumowaniach pisanych przez ludzi.

Szablon Pliku Pamięci (memory/architect.memory.md)

---
persona: architect
topic: feature-{slug}
updated: 2025-09-29T09:00:00.000Z
---

## Current Intent
<concise statement>

## Key Assumptions
- ...

## Open Questions
| ID | Question | Owner | Added |
|----|----------|-------|-------|

## Decision Candidates (Unratified)
- [ ] Q1: <short label> – pending perf data

## Recently Ratified (Moving to decisions/ soon)
| Date | Decision | Rationale | Link |
|------|----------|-----------|------|

## Risks / Watch
- (<timestamp>) <risk statement>

## Signals (Imported)
- Test coverage delta: <value> (source: analytics/coverage.json)
- p95 latency: <value> (perf-snapshot-2025-09-29.md)

## Upcoming Milestones
- M<n>: <goal> (ETA, dependency)

topic.summary.md (opcjonalny agregator):

---
topic: feature-{slug}
phase: milestone-2
updated: 2025-09-29T11:30:00.000Z
---

## Snapshot
Status: Implementing milestone 2 (API gateway integration)
Next Critical Decision: choose message queue (see decisions/2025-09-29-choose-queue.md)

## Milestones
| ID | Description | State | ETA |
|----|-------------|-------|-----|

## Open Questions (Cross-Persona)
| ID | Question | Owner | Added |
|----|----------|-------|-------|

## Recent Decisions
| Date | Decision | Impact |
|------|----------|--------|

## Key Risks
- <risk>

Sugerowana kadencja aktualizacji:

• Architect memory: po zaplanowaniu/zamknięciu milestone'a lub zmianie założeń.
• QA memory: po ewolucji pakietu testów lub anomalii pokrycia.
• Cloud DevOps memory: po zmianie infrastruktury lub nowym sygnale SLO.
• Agent memory (jeśli używane): zwięzłe notatki z wykonania; często można pominąć i oprzeć się na architect + summary.
• topic.summary.md: regeneruj po milestone (możliwe do zautomatyzowania).

Przykład prompta (zakresowanego tematycznie):

"Architect Mode: Read docs/topics/feature-{slug}/memory/architect.memory.md plus topic.summary.md; reconcile differences with decisions/*. List any stale assumption candidates and refresh 'Upcoming Milestones'. Keep under 80 lines."

Ten wzorzec tworzy ograniczoną, queryowalną kapsułę stanu per funkcjonalność—łatwą w obsłudze dla ludzi teraz i agentów maszynowych w przyszłości.

---

4. Powszechne Anty-Wzorce

Anty-Wzorzec	Dlaczego Szkodzi	Jak Naprawić
Jeden gigantyczny request do Agenta („zbuduj pełną funkcję")	Rozdęte diffy, halucynowana struktura	Podziel na milestone'y wielkości jednego PR
Pomijanie trybu projektowania	Prowadzi do przeróbek i kruchej architektury	Zawsze używaj Architect Mode dla nietrywianych zadań
Pozwolenie QA mode na modyfikację kodu produkcyjnego	Rozmywa odpowiedzialność i zwiększa ryzyko	QA sugeruje testy; Agent je implementuje
Brak logu decyzji	Persony tracą kontekst i ciągłość	Utrzymuj docs/decisions.md lub ADRy
Ślepe zaufanie do AI	Fałszywa pewność	Traktuj wszystkie outputy jako drafty wymagające recenzji

---

5. Spojrzenie w Przyszłość: Agent‑to‑Agent (A2A) & MCP

Dziś: Tryby działają w izolacji – brak wspólnej trwałej pamięci.

Powstające warstwy:

• MCP (Model Context Protocol): ustandaryzowany sposób udostępniania narzędzi (Jira, systemy buildów, orkiestratory) dla Copilota.
• A2A (Wizja): agenci wymieniający się strukturalnymi zadaniami i artefaktami. Persona Architect mogłaby emitować graf zadań; QA subskrybuje zmiany w projekcie; persona Cloud automatycznie dodaje hooki observability.
• Agent Factory / Orchestrators: definiowanie, tworzenie i nadzorowanie agentów-person z określonymi granicami dostępu i zdolnościami.

Korzyści po dojrzeniu (pętla deliberacyjna A2A):

• Synteza wieloscenariuszowa: persony architect/infra/test wspólnie generują 2–4 możliwe stosy rozwiązań (z jawnymi trade-offami) przed napisaniem jakiegokolwiek kodu.
• Strukturalna pamięć odrzucenia: odrzucone podejścia są logowane (z powodem i blokującym ograniczeniem), by zapobiec powtarzaniu błędów.
• Automatyczna faza wyjaśnień: jeśli wykryto krytyczne niewiadome (ryzyko, wolumen danych, oczekiwania dot. latencji), artefakt Question Backlog jest generowany przed zaproponowaniem finalnej architektury.
• Scoring konsensusu: agenci niezależnie oceniają scenariusze (koszt, złożoność, odporność, powierzchnia zmian) → orkiestrator agreguje wyniki i podkreśla rozbieżności.
• Bramka ludzkiej akceptacji: żaden scenariusz nie przechodzi do stanu „Plan" bez wyraźnej akceptacji człowieka (output agenta pozostaje draftem do momentu zatwierdzenia).
• Selektywna konsultacja wiedzy: persony pobierają tylko odpowiednie fragmenty source/ + memory (ograniczone okna kontekstu), by ograniczyć halucynowane ograniczenia.
• Hooki policy/compliance: agenci security/governance wstrzykują uwagi veto lub wymagane kontrole do diffów scenariuszy, nie po fakcie.
• Stopniowa delegacja: agenci implementacji otrzymują podpisany micro-plan (kawałek milestone'a), nie otwarty brief funkcjonalności.
• Śledzona deliberacja: każdy zaakceptowany element linkuje z powrotem do porównania scenariuszy lub rozwiązania pytania.

Przygotuj się już teraz:

• Zdefiniuj kryteria ewaluacji (np. koszt, blast radius, wpływ na MTTR, testowalność) w wielokrotnego użytku fragmencie markdown.
• Przechwytuj odrzucone pomysły wraz z uzasadnieniem (by przyszli agenci nie powtarzali tych samych ścieżek).
• Utrzymuj Question Backlog per temat (questions.md lub w summary) ze statusem (open|answered|assumption).
• Normalizuj rekordy decyzji (timestamp, decydent, alternatywy, uzasadnienie, konsekwencje).
• Taguj artefakty stabilnymi ID dla przyszłego maszynowego cross-referencingu.

---

6. GitHub Cloud Coding Agent vs. Tryby w IDE

Aspekt	IDE Custom Modes	Cloud Coding Agent
Personalizacja persony	Tak (.chatmode.md)	Nie (tylko instrukcje w repo)
Środowisko wykonania	Twój lokalny setup	Efemeralna VM GitHub
Może autonomicznie otwierać PRy	Pośrednio (ty kierujesz)	Tak
Wieloplikowe pętle edycji	Tak	Tak
Rozszerzanie przez MCP	W rozwoju	W rozwoju
Dostępność Agent Mode	Tak	N/A (inny model)

Używaj cloud agenta do: zawartej w repo, recenzowalnej automatyzacji (tweaki konfiguracji, aktualizacje zależności, małe fragmenty funkcjonalności, drobny refaktoring) szczególnie gdy kontekst lokalnego środowiska nie jest krytyczny.

---

7. Iteracyjny Workflow Person (Diagram)

Zamiast linearnej checklisty, prawdziwy proces cyklicznie przechodzi przez: pozyskanie źródeł → syntezę pamięci specyficzną dla persony → podział planu → wykonanie → feedback → dopracowanie → finalizację (ADR / scenariusze testów / wzmocnienie infra). Diagram pokazuje, jak surowe dane wejściowe zasilają strukturalne rozumowanie przed zmianami w kodzie.

%%{init: {"flowchart": {"htmlLabels": true, "curve": "basis"}} }%%
flowchart TD
  subgraph SOURCES["Surowe Wejścia Źródłowe"]
    transcripts["Transkrypty<br/>Spotkań"]
    clientDocs["Dokumenty<br/>Klienta / Briefy"]
    domainNotes["Notatki<br/>Domenowe"]
  end
  sourcesAggregate["source/<br/>wyselekcjonowane fragmenty"]
  transcripts --> sourcesAggregate
  clientDocs --> sourcesAggregate
  domainNotes --> sourcesAggregate

  subgraph PERSONA_LOOP["Iteracja Przejścia Persony"]
    BA["Business Analyst<br/>(business.memory.md)"]
    ARCH["Architect<br/>(architect.memory.md)"]
    QA["QA<br/>(qa.memory.md)"]
    DEVOPS["Cloud DevOps<br/>(cloud-devops.memory.md)"]
  end

  sourcesAggregate --> BA --> ARCH --> QA --> DEVOPS --> PLAN["Plan Implementacji<br/>(IMPLEMENTATION_PLAN.md)"] --> SUMMARY["topic.summary.md<br/>(Skonsolidowany Snapshot)"] --> AGENT["Wykonanie Agent<br/>(krok i)"] --> REVIEW{"Recenzja &<br/>Decyzja?"}
  REVIEW -->|Zatwierdź| NEXT["Następny Krok Planu"]
  NEXT --> AGENT
  REVIEW -->|Luki Info| FEEDBACK["Feedback /<br/>Nowe Pytania"]
  FEEDBACK -.-> sourcesAggregate
  SUMMARY --> FINALIZE["Finalizuj Artefakty<br/>(ADR · Scenariusze Testów)"] --> DONE["Gotowe /<br/>Zredukowane Niewiadome"]

  classDef phase fill:#f0f6ff,stroke:#3d7ac4,stroke-width:1px,color:#1a1a1a
  classDef memory fill:#f7f2ff,stroke:#7d3fb2,stroke-width:1px,color:#1a1a1a
  classDef plan fill:#fff4e0,stroke:#e09600,stroke-width:1px,color:#1a1a1a
  classDef summary fill:#e8f9f0,stroke:#25a25a,stroke-width:1px,color:#1a1a1a
  classDef exec fill:#f2f2f2,stroke:#666,stroke-width:1px,color:#1a1a1a
  classDef review fill:#ffe7e7,stroke:#d93c3c,stroke-width:1px,color:#1a1a1a
  classDef finalize fill:#e6f3ff,stroke:#2d8fd5,stroke-width:1px,color:#1a1a1a
  classDef done fill:#d9f7e6,stroke:#1f8150,stroke-width:1px,color:#1a1a1a

  class transcripts,clientDocs,domainNotes,sourcesAggregate phase
  class BA,ARCH,QA,DEVOPS memory
  class PLAN plan
  class SUMMARY summary
  class AGENT exec
  class REVIEW,FEEDBACK review
  class FINALIZE finalize
  class DONE done

Notatki operacyjne:

1. Źródła nigdy nie są edytowane – wyselekcjonuj fragmenty do source/ (śledzone z powrotem do oryginałów lub timestampów transkrypcji).
2. Każda persona aktualizuje tylko swój plik pamięci z deltami (intencja, ryzyka, otwarte pytania) odwołującymi się do source/.
3. Plan implementacji powstaje dopiero po zbieżności głównych person (BA → Architect → QA → DevOps).
4. Podsumowania (topic.summary.md) są regenerowane po zatwierdzeniu planu i po każdym wykonanym kroku.
5. Wykonanie zatrzymuje się po każdym kroku planu dla wyraźnej recenzji; odchylenia zasilają z powrotem pamięć architect i business.
6. Finalizacja: stabilne decyzje projektowe stają się ADRami; QA formalizuje specyfikacje scenariuszy testów; notatki infra krystalizują się w IaC/pipeline PRy.
7. Pętla restartuje, gdy jakiekolwiek nowe zewnętrzne wejście (feedback klienta, odkrycie ryzyka) zmienia założenia.

Linearną wersję promptów (jeśli preferujesz wcześniejszą listę) można nadal wywieść z tego diagramu; traktuj każdą krawędź jako dyskretne, recenzowalne przekazanie między personami.

---

8. Lekka Konfiguracja MCP (Opcjonalny Starter)

Umieść w .vscode/mcp.json i trzymaj sekrety w .vscode/.env (w gitignore):

{
  "servers": {
    "jira": {
      "type": "http",
      "url": "https://jira.example.com/mcp",
      "envFile": ".vscode/.env",
      "headers": { "Authorization": "Bearer ${JIRA_TOKEN}" },
      "tools": ["search_issues", "create_issue"]
    },
    "a2a-orchestrator": {
      "type": "http",
      "url": "https://agents.example.com/a2a/mcp-bridge",
      "envFile": ".vscode/.env",
      "headers": { "X-Org": "${ORG_ID}", "Authorization": "Bearer ${A2A_TOKEN}" },
      "tools": ["delegate_task", "get_agent_status", "collect_results"]
    }
  }
}

Dodatek .gitignore:

.vscode/.env

---

9. Konkretne Wnioski do Działania

Cel	Co Zrobić Teraz
Szybszy, bezpieczniejszy design	Dodaj tryby Architect + QA
Spójna infrastruktura i bezpieczeństwo	Dodaj tryb Cloud DevOps z checklistą least-privilege
Mniej przeróbek	Dokumentuj decyzje w markdown po każdym milestone
Przygotowanie na przyszłość A2A	Utrzymuj kontrakty person + strukturalne artefakty
Mniejsze PRy	Ogranicz zadania Agenta do pojedynczego milestone z checklistą akceptacji

---

10. Wezwanie do Działania

Wypróbuj ten workflow przy następnej funkcjonalności. Podziel się z zespołem. Zostaw feedback: Czy interesują Cię głębsze zanurzenia w MCP, agentów bezpieczeństwa czy automatyczną generację testów? Twoje opinie będą kształtować przyszłe odcinki.

---

11. Zasoby

• My AI Project starter – https://github.com/DevNotes-it/ai-project-starter-kit
• Agent Mode Intro – https://github.blog/ai-and-ml/github-copilot/agent-mode-101-all-about-github-copilots-powerful-mode/
• Coding Agent Docs – https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent