Мой полный пайплайн разработки с AI-агентами. Как доверить код агенту?

Summary of technological concepts & pipeline (AI agents for code development)

Kirill presents a practical full development pipeline for using AI agents to implement software changes while keeping results correct, reviewable, and cost/token-efficient. He frames the core challenge as turning vague requests into controlled, testable outputs and managing agent limitations.

---

Key problems when working with AI agents

1. Context window limits (Smart Zone vs Dump Zone)

   • Agents can only handle a finite context (hundreds of thousands of tokens, not “infinite”).
   • If you dump too much into a single agent session, quality drops and the agent becomes “dumber.”
   • Solution: split large work into small tasks/tickets that fit the agent’s effective context.

2. Uncertainty from vague requirements

   • If the task isn’t specific, the agent guesses and makes decisions.
   • The agent doesn’t bear responsibility; the human does—so requirements must be precise and ambiguities resolved by the person.
   • Solution: create an explicit requirement discovery/design stage with human-in-the-loop.

3. Lack of controlled, observable results

   • Agents can generate lots of code quickly, making it hard to know what changed and whether it works.
   • Bad code can accumulate over time if quality control isn’t built into the workflow.

4. Role delineation (agent vs human)

   • Agent: reads code/docs, gathers facts, proposes, performs implementation tasks.
   • Human: makes final decisions on architecture tradeoffs, interfaces, UX, boundaries, and what ships.
   • Solution: formalize responsibilities and enforce them via pipeline structure and artifacts.

---

The proposed solution: a “pipeline” with feedback loops

Kirill describes a workflow (adapted from a GitHub repository and “skills/harnesses” concepts from an agent framework, plus his Telegram-shared setup) whose purpose is to:

• Reduce uncertainty
• Build feedback loops
• Keep work in the Smart Zone
• Transfer artifacts between sessions instead of bloating context

He emphasizes that agents should be orchestrated via structured sessions and artifacts (MD files, task tracker items, docs, PRs), rather than being left to free-form implement end-to-end.

---

Core stages and techniques in the pipeline

1) Design stage → convert intent into explicit decisions

The goal is not to ask the agent to output a giant plan passively. Instead, the agent runs a structured requirement clarification conversation (“grilling”).

“Grill” skill (human-in-the-loop requirement clarification)

• Iterative: the person participates repeatedly until decisions are explicit.
• Produces a tree of dependent decisions (a decision graph).
• Uses “Frontier questions”:
  • The agent starts with questions where context is already sufficient.
  • As decisions accumulate, it can ask deeper questions.
• Ends with a confirmed shared understanding by the human.

Variants:

• Grill with Dogs (when a codebase exists): agent research + grilling using project context.
• Grill me (when no codebase exists): grilling on the idea alone.

2) Prototype skill (interactive artifact for hard questions)

Used when answers can’t be fully resolved via text. Produces artifacts such as UI/HTML prototype options to compare interfaces or logic flows.

3) Pathfinding / Wayfinder for very large tasks

If the task is too big to grill fully at once:

• Break it into stages.
• Create tickets per stage (tickets are essentially artifacts/task tracker entries, often MD-based).
• For each stage: run grilling again to produce stage-specific decision outputs.

Results:

• A decision tree distributed across tickets, later assembled into overall specs/docs.

4) Specification stage (agreed, verifiable description)

A spec is not a “plan”; it’s a precise and testable description of:

• the problem and goals
• user stories
• implementation decisions (with rationale/source)
• out-of-scope items
• constraints and boundaries

Stored in the task tracker / MD files / documentation.

---

Tickets as the main execution unit

Ticket design requirements

Each ticket should:

• fit into one agent session (fresh context)
• include:
  • clear observable behavior goals
  • tests
  • automated agent review(s)
  • human review
  • bug fixes and reporting (as needed)

Ticket naming & slicing strategy

• Tickets are named by behavior/features, not by layers (db/api/frontend).
• Uses vertical slice / feature slice architecture:
  • A slice delivers an end-to-end feature behavior so you can test it and get feedback.
  • Avoid horizontal decomposition (db first, then api, then frontend) because it yields limited observable progress and weak feedback.

Dependencies and sequencing

• Tickets can be blocked by other tickets.
• Each ticket explicitly states what it depends on.

Two ticket types: Human-in-the-loop vs AFK

• Human-in-the-loop tickets

  • Person actively participates while the agent works.
  • Useful for architecture-level decisions, UX checks, and live behavior validation.

• AFK tickets

  • Agent can complete the ticket autonomously (including tests/reviews), with optional/minimal human involvement.
  • Useful for isolated or low-risk tasks.

---

Context management between sessions

To prevent token/context bloat:

• Artifact passing between sessions (handoff of files/MD notes/instructions/data), rather than copying full context.
• If ticket/context grows too large:
  • treat it as a sign of poor ticket splitting; ask the agent whether it fits the Smart Zone
  • otherwise use a “compact” operation to squeeze/recap session knowledge (risk of losing context, but the agent can retrieve later)

He also mentions a custom handoff skill to transfer work across agents/stages (e.g., switching model providers).

---

Feedback & verification: test-driven workflow + reviews

TDD (test-first development)

• Write tests first, then implement minimal code to make tests pass.
• Rationale:
  • If agents write tests after code, they may shape tests to match the produced code.
  • Test-first makes tests the source of desired behavior and business logic.
  • Agents can still find bugs by running tests—but the specification is grounded in test expectations.

Automated/independent agent reviews + manual testing

After code:

• Independent review by subagents checks multiple axes:
  • code style/standards consistency
  • pattern uniformity
  • compliance with ticket/spec requirements
  • deviations from existing/spec boundaries
• Then manual QA/testing:
  • human verifies behavior via interface and runs through scenarios
  • failures create a new ticket → repeat cycle

PR per ticket

• Each ticket produces a pull request.
• Human reviews PRs (Kirill avoids automatic merge requests).

---

Example artifacts used in his workflow (GitLab)

He demonstrates how a large feature (“Membership product” / closed subscription community) is managed:

• Wayfinder documents: mapping impacted parts, business logic changes, decisions, and out-of-scope items.
• Specification doc: large technical basis with user stories, boundaries, decisions.
• Tickets: vertical slice tasks like:
  • “Club entry” creation via owner UI + MCP (includes migrations/db/endpoints/integration)
  • full membership lifecycle subscription management
  • Telegram identity extension and module integration

Each ticket has:

• tests and CI pipelines
• review outcomes
• notes about what needs manual QA

He also wants to build tooling to visualize ticket dependency graphs more clearly in the terminal, since GitLab doesn’t show the graph well.

---

Tools / services mentioned (non-core but present)

• He discusses paying for multiple LLM/agent services (names as heard: Koex/Cloud/Kimi/Deepsek).
• He uses a Telegram virtual card service (Zaruup) to pay subscriptions; card issuance, topping up, and promo discount are described (separate from the development pipeline).

---

Main speakers / sources

• Speaker: Kirill (main presenter)
• Primary source for the pipeline concept: a GitHub repository he found (adapted to his own workflow)
• Framework concepts referenced: “skills” / “harnesses” (including “Grill…”, “Prototype”, “Wayfinder”, “Handoff”, “Compact”; plus his custom “handoff” and “compact” terminology)