Jak przygotować zadanie, zanim przekażesz je agentowi kodującemu w chmurze

Dlaczego zadanie w chmurze potrzebuje czegoś więcej niż promptu

W sesji interaktywnej inżynier zauważa złą drogę i ją koryguje. Agent w chmurze pracuje sam w zdalnym środowisku, więc każde otwarte pytanie zostaje rozstrzygnięte zgadywaniem, a to zgadywanie wraca później jako gotowy pull request. Poradnik GitHuba dla jego agenta chmurowego mówi to wprost: traktuj przypisane zgłoszenie jak prompt i daj mu jasny opis, kompletne kryteria akceptacji i wskazówki, które pliki zmienić.

Poradnik Anthropic o ewaluacji agentów podsuwa test, który dobrze się przenosi: dobre zadanie to takie, przy którym dwóch ekspertów niezależnie wyda ten sam werdykt zaliczone albo niezaliczone, a wszystko, co sprawdzają testy, jest zapisane w zadaniu. Opis, który spełnia ten warunek, recenzent może też ocenić bez odtwarzania sesji.

Opis zadania w ośmiu częściach

Ten szablon sprawdza się przy każdym agencie w chmurze, który czyta zgłoszenie albo prompt. Wypełniony przykład jest hipotetyczny.

## Goal
GET /v1/invoices returns CSV when the client sends Accept: text/csv.

## Context
- Read src/api/invoices/list.ts and its tests first
- Column order is defined in docs/exports.md

## Scope
- CSV output for this endpoint, with the same filters as JSON

## Non-goals
- Other endpoints, streaming, spreadsheet formats, UI changes

## Acceptance checks
- pnpm test:unit passes, with new tests for CSV output
- Accept: text/csv returns the documented columns in order
- Existing JSON tests pass unchanged

## Environment
- Tests use fixtures in test/fixtures/invoices; no database, no secrets

## Stop and ask before
- Adding a dependency, changing the shared serializer, editing CI

## Hand back
- Pull request: what changed, commands run with results,
  anything not verified, open questions

Najwięcej uwagi wymagają wyłączenia z zakresu i lista punktów zatrzymania. Nazywają prawdopodobną dodatkową pracę, którą agent mógłby podjąć, i zmiany, o których musi zdecydować człowiek.

Trzy pytania przed delegowaniem

• Czy recenzent, który nie pisał opisu, oceniłby, czy wynik jest gotowy?
• Czy środowisko agenta uruchomi sprawdzenia odbioru bez udziału człowieka, łącznie z usługami i danymi testowymi?
• Czy zadanie obywa się bez danych produkcyjnych, poświadczeń i nieodwracalnych działań?

Odpowiedź nie na którekolwiek oznacza pracę interaktywną albo mniejsze zadanie. Lista GitHuba z zadaniami, które lepiej zostawić ludziom, jest z tym zgodna: szeroki refaktoring wymagający wiedzy z wielu repozytoriów, głęboka logika domenowa, problemy krytyczne dla produkcji, praca dotycząca bezpieczeństwa, danych osobowych albo uwierzytelniania, reagowanie na incydenty i wszystko z niejasnymi wymaganiami.

Dużą pracę nadal można przekazać agentowi w fazach. Przepis z cookbooka OpenAI o iteracyjnej pracy z Codex opisuje pliki faz, z których każda jest na tyle mała, by dało się ją niezależnie zrealizować i sprawdzić, z obserwowalnymi kryteriami akceptacji, punktem zatwierdzenia i jawnym warunkiem zatrzymania.

Ustal, gdzie agent się zatrzymuje

Lista punktów zatrzymania w opisie to instrukcja, a agent może ją źle zrozumieć. Ten sam przepis z cookbooka trzyma commity, pushe, wdrożenia, poświadczenia i zapisy do systemów zewnętrznych za osobnym, jawnym zatwierdzeniem. Artykuł OpenAI o Codex jako platformie opisuje ten sam podział od strony systemu: aplikacja nadrzędna decyduje, gdzie działa agent, z jakich narzędzi może korzystać, które działania wymagają zatwierdzenia i jak wyniki wracają do systemu źródłowego.

W praktyce opis mówi, kiedy się zatrzymać, a środowisko to wymusza: poświadczenia ograniczone do zadania, pushe tylko na własny branch agenta i ochrona branchy, która zostawia merge ludziom.

Co wraca i kto to przejmuje

Inżynier, który delegował zadanie, odpowiada za wynik i czyta go pierwszy. Pull request, który mówi, co się zmieniło, jakie komendy uruchomiono i z jakim wynikiem, czego nie zweryfikowano i co pozostaje otwarte, pozwala mu szybko zdecydować, czy przekazać go do review, odesłać czy dokończyć ręcznie. Zatwierdzające review robi ktoś inny.

Gdy wynik mija się z opisem, najpierw ustal, co opis zostawił otwarte. Potem wybierz między kilkoma celnymi komentarzami w review a nowym uruchomieniem z precyzyjniejszym opisem i dopisz brakujące elementy do opisu, żeby stał się wzorem dla kolejnego podobnego zadania. Na GitHubie zebranie komentarzy w jedno review pozwala Copilotowi zająć się wszystkimi naraz, a nie komentarz po komentarzu.

Przewodnik po spec-driven developmentOchrona branchy dla pull requestów agentów