Tutorial

Getting Started with ADLC

6 min read • Aug 10, 2026

Ready to try ADLC? This guide walks you through your first task, from intent capture through review. We'll assume you're using GitHub and Linear; the concepts apply to other tools as well.

Step 1: Access the Workspace

Visit the ADLC workspace at adlc-9e72f.web.app. You can authenticate with a personal Google account or your organization's identity.

Note: The workspace is public for read-only access. To create and run tasks, you need to be added to an organization by an admin.

Step 2: Connect Your Tools

Before creating a task, configure your integrations:

Settings → Repositories: Connect your GitHub or GitLab account. Grant the requested permissions (read and write access to repositories).
Settings → Tracking: Connect Linear, Jira, or Asana. ADLC will read and create tickets in these systems.
Settings → Models: Choose your LLM provider (Anthropic, OpenAI, local Ollama, etc.) and add your API keys.

Security: API keys are stored encrypted in a per-organization vault. They never appear in logs or agent containers. The egress proxy injects them securely.

Step 3: Create Your First Task

Click the "New Task" button in the workspace. You'll see:

Intent input: Describe what you want to build. Be specific: "Fix the checkout latency issue by optimizing the SQL query in cart.ts" vs. "Make checkout faster."
Source context: Optionally attach relevant code, design docs, or previous incidents. ADLC will use this to make better plans.
Policy constraints: If your org has policies, you can flag them here: "This must not modify authentication logic" or "Must maintain 80%+ test coverage."
Repository and branch: Select which repo and target branch (usually main or dev).

Example:
Intent: "Add API endpoint to fetch user billing history for the past 3 months. Include pagination and sorting by date. Return CSV and JSON formats."
Context: [Attach the existing billing API docs and schema]
Constraints: "Must use the audit log for all data access. No direct database queries."

Step 4: Review the Plan

After you submit, ADLC's planning agent kicks off. It:

Researches your codebase for similar features.
Breaks the feature into implementable tasks.
Defines acceptance criteria for each task.
Flags any risky assumptions or dependencies.

The plan appears in the workspace within a few minutes. You can:

Approve: The plan looks good. Proceed to implementation.
Request changes: "Add a caching layer to reduce database load" or "Remove the CSV format requirement—JSON only."
Reject: "This doesn't match the intent. I only asked for billing history, not a full dashboard."

What you're looking at: Task decomposition, acceptance criteria, estimated effort, dependencies, and research notes. Everything the implementation agent will use.

Step 5: Implementation Begins

Once you approve the plan, the coder agent takes over. It:

Clones the repository into an isolated workspace.
Creates a feature branch.
Works through each task sequentially (or in parallel if they don't depend on each other).
Commits changes and runs tests as it goes.

You can watch progress in real-time in the workspace. You'll see:

Commits being created.
Test results streaming in.
The agent's review workpad (notes on design decisions).
Any errors or need for human help.

Step 6: Verify and Test

As the coder finishes each task, ADLC's testing agent runs:

Unit tests (do the new functions work?).
Integration tests (does it work with the rest of the system?).
Linting and type checking (is the code clean?).
Policy checks (does it follow your org's standards?).

Results appear in the workspace with full output. If any tests fail, the implementation agent loops back to fix them.

Step 7: Human Review

Once all tasks are complete and tested, the workspace shows you:

The full code diff (organized by task).
Test coverage metrics and results.
The implementation agent's review notes.
Any policy violations or warnings.

You can:

Approve: ADLC creates a pull request and merges (or deploys, depending on your setup).
Request changes: Leave specific comments. The implementation agent will see them and revise the code.
Reject: If the result doesn't match the original intent, start over.

Step 8: Delivery and Learning

If approved, ADLC merges the PR and (optionally) deploys to production. The workspace records:

Merge timestamp and PR link.
Deployment status and any errors.
Customer feedback and usage metrics.
Cost breakdown (planner time, coder time, LLM API calls).

This data is searchable by future planning agents. The next time someone asks "Has anyone built a billing feature?", ADLC can show what was learned.

Pro Tips

Be specific in intents: Vague requests lead to mediocre plans. "Optimize database queries in the user service" → results. "Make things faster" → confusion.
Attach source context: If you paste the current code or link to relevant docs, ADLC makes better decisions.
Use policy constraints strategically: Don't restrict everything. Flag only the areas that truly matter for your org.
Review the plan carefully: This is your last chance to catch misunderstandings before coding starts. If the plan is wrong, reject it.
Watch the real-time stream: If the agent gets stuck or does something unexpected, you can pause and add guidance.

Next Steps

Once you've completed your first task:

Explore the workspace history to see past tasks and outcomes.
Read the governance article to understand how to set up approval gates and policies.
Check the integration guide to add more tools or LLM providers.
Review the full brief for a complete conceptual overview of ADLC.

Ready to try? Open the workspace →

Back to blog: All posts