1. L'Impatto: 1 Milione di Pull Request in 5 Mesi (Octoverse 2025)

L'Octoverse 2025 ha registrato una metrica che ha sorpreso anche GitHub stessa: il Copilot Coding Agent, in general availability dal 24 settembre 2025, ha generato oltre 1 milione di pull request nei primi 5 mesi di vita.

Per mettere in prospettiva: nel 2023, gli sviluppatori utilizzavano GitHub Copilot per suggerimenti inline e completamenti di codice. Nel 2024, Copilot Workspace permetteva multi-file editing in una sessione temporanea (technical preview). Nel 2025, l'azienda ha completato il salto verso autonomous development agents che prendono issue GitHub, analizzano il repository, scrivono codice, eseguono test, e aprono pull request completamente autonome.

Questo rappresenta una disruption fondamentale del SDLC (Software Development Lifecycle):

• Antes (2024): developer apre IDE, scrive codice, testa, committe. Tempo: 2-8 ore per feature media.
• Adesso (2025): developer crea issue descrittiva, assegna @copilot, agent runs in background sandboxed GitHub Actions, approva PR draft. Tempo: 15-45 minuti (user time), 5-15 minuti (agent execution).

2. Da Copilot Workspace a Coding Agent: Perché Workspace Non È Stato Abbandonato

Una domanda legittima: se il Coding Agent è il nuovo paradigma, che fine ha fatto Copilot Workspace (technical preview, annunciato maggio 2024)?

La risposta è elegante dal punto di vista di product management. Workspace non è stato abbandonato: è stato trasformato e integrato nel Coding Agent come strumento interno.

Timeline:

• Maggio 2024: Copilot Workspace annunciato (technical preview). Workflow: developer apre issue → click "Open in Workspace" → sessione temporanea con multi-file editor + AI chat. Output: diff non salvato finché developer non lo approva e copia in IDE locale.
• 30 maggio 2025: Copilot Workspace technical preview sunset. GitHub ufficialmente dichiara: "Workspace experience è stata incorporata nel Coding Agent".
• 24 settembre 2025: Copilot Coding Agent general availability. Ora l'agent esegue internamente il workflow di Workspace (analisi → planning → editing) in ambiente sandboxed GitHub Actions, senza UI browser. Outcome: PR aperta automaticamente.

In pratica, Workspace era il UI interattivo per lo stesso paradigma di "spec → plan → code" che guida il Coding Agent. Con l'agent, quel paradigma diventa completamente automatizzato, senza richiedere un UI o iterazione umana.

3. Come Funziona il Coding Agent: Anatomia di un Workflow Issue → PR

Quando assegni un'issue al Copilot Coding Agent, ecco cosa accade dietro le quinte:

Fase 1: Trigger e Setup (secondi 0-10)

• GitHub Actions scheduler rileva l'assegnazione di @copilot all'issue
• Avvia job in sandbox GitHub Actions environment (ubuntu-latest container, isolato da internet eccetto GitHub API)
• Agent riceve: issue title, body, repository code (clone shallow con history), .github/copilot-instructions.md

Fase 2: Research (minuti 1-3)

• Agent legge repository structure, lingue di programmazione, test framework
• Interroga GitHub API per: PR history, issue history correlate, branch protections, codeowners
• Analizza .github/copilot-instructions.md per: coding style, test requirements, deployment constraints
• Output: "research summary" (struttura repo, tecnologie, convenzioni identificate)

Fase 3: Planning (minuti 3-5)

• Agent crea un piano di implementazione strutturato: file da creare/modificare, test da scrivere, considerazioni architetturali
• NEW (1 aprile 2026): Plan è esposto al developer per revisione. Developer può: approvare, richiedere modifiche, aggiungere vincoli
• Se developer approva, agent procede. Se developer nega, task si ferma

Fase 4: Code Generation (minuti 5-10)

• Agent generates code for all files identified in the plan
• Apply style guides and conventions from the repository
• Write unit tests automatically (if test framework detected)
• Generate commit messages according to conventional commits

Phase 5: Test & Validation (10-12 minutes)

• Run local test commands (npm test, mvn test, pytest)
• If test fails: agent retry, change code, re-test up to 3 times
• If linting/formatting fails: auto-fix (prettier, black, etc.)
• Validate that no secrets are hardcoded (basic SAST scan)

Phase 6: PR Creation (minute 12)

• Agent opens PR draft on repository with: auto-generated branch, title, description, link to the original issue
• PR is immediately subject to: branch protections, required reviews, CI/CD checks
• Developer receives notification, review and merge (or requests changes)

Total timeline: 12-15 minutes, completely asynchronous. Developer doesn't have to wait.

4. .github/copilot-instructions.md: The File That Decides How the Agent Develops

The most important file for the Coding Agent is .github/copilot-instructions.md (o .copilot-instructions.md in the root).

What it contains: Repository-specific guidelines that the agent must follow. Think of this file as a "contract specification" between the repository and Copilot.

Format and Recommended Sections:

# Copilot Instructions for federicocalo.dev

## Repository Overview
- **Stack:** Spring Boot 3.4 backend, Angular 21 SSR frontend, FastAPI Python ML service
- **Architecture:** Microservizi → Clean Architecture 4-layer (domain, application, infrastructure, presentation)
- **Primary Language:** Java 21, TypeScript, Python 3.12
- **Main Branch:** master
- **Test Framework:** JUnit 5 (backend), Jasmine (frontend), pytest (ML)

## Coding Standards

### Backend (Java/Spring)
- Use records for DTOs (immutability)
- Clean Architecture layers strictly (domain → application → infrastructure)
- Dependency injection via constructor
- Exception handling: custom exceptions (InvalidRequest, NotFound, RateLimit)
- Code review checklist: no mutations, functions <50 lines, files <800 lines

### Frontend (TypeScript/Angular)
- Standalone components ONLY (no modules)
- OnPush change detection strategy
- Proper RxJS subscription management with takeUntilDestroyed()
- i18n: Add i18n markers, run ng extract-i18n, sync XLF

### Python/FastAPI
- Type hints on all functions
- Pydantic models for validation
- Async/await for I/O operations
- Mock external API calls in tests

## Testing Requirements
- **Minimum coverage:** 80%
- **Unit tests:** Every service, component, utility function
- **Integration tests:** API endpoints, database operations
- **Backend:** Use Testcontainers for PostgreSQL/Redis
- Test must pass before PR merge: `mvn test`, `npm test`, `pytest`

## Security Checklist
- [ ] No hardcoded secrets
- [ ] All user inputs validated
- [ ] SQL injection prevention (parameterized queries)
- [ ] XSS prevention (sanitized HTML)
- [ ] CSRF protection enabled
- [ ] Authentication/authorization verified
- [ ] Rate limiting on all endpoints

## Deployment & Environment
- **Development:** Local nativo (PostgreSQL 16, Redis 7)
- **Production:** VPS Hetzner (systemd services)
- **Database:** PostgreSQL 16 migrations via Flyway (backend/src/main/resources/db/migration/)
- **CI/CD:** GitHub Actions (test on push)

## Notes for AI Agent
- When creating REST endpoints: use @RestController, @GetMapping/@PostMapping, clean layer separation
- When modifying database schema: add Flyway migration, NEVER modify existing migrations
- When adding new features: update docs/01_foundation/, commit message with `feat:` prefix
- When fixing bugs: include regression test
- When changing dependencies: update pom.xml (backend) or package.json (frontend), commit lock files

Practical impact: With this file in place, when the agent receives an "Add JWT refresh token endpoint" issue, it automatically knows:

• Writing Java (not Python)
• Use Spring Boot patterns (RestController, service layer)
• Create JUnit 5 tests
• Don't violate Clean Architecture
• Write Flyway migration if pattern changes
• Reach 80% coverage

5. Agent Skills (18 December 2025): Reusable Behaviors

An important innovation from December 18, 2025 is the concept of Agent Skills. These are micro-behaviors of the Coding Agent that can be defined once and automatically reused.

Anatomy of an Agent Skill:

• Instructions: Natural description of what to do (e.g. "Generate unit tests for each new Java service")
• Triggers: When to apply the skill (e.g. label on issue, file path, commit message pattern)
• Scripts/Resources: Tool or template to use (e.g. test generation script, test template)
• Scopes: Organization-wide or repository-specific

Practical Example: "Java Spring Test Generator" Skill

# File: .github/copilot-skills/java-spring-test-generator.md

name: Java Spring Test Generator
trigger:
  - labels: ["needs-tests"]
  - file-pattern: "src/main/java/**/*.java"

instructions: |
  When this skill is triggered:
  1. Analyze the Java file (class, methods, public API)
  2. Generate JUnit 5 tests covering:
     - Happy path (normal operation)
     - Edge cases (empty input, null, boundary)
     - Error cases (exception handling)
     - Integration with Spring (if applicable)
  3. Use Mockito for external dependencies
  4. Ensure test naming follows convention: Test{ClassName}
  5. Include @DisplayName annotations for clarity

test-command: "mvn test -Dgroups='unit'"
coverage-target: 80

templates:
  - name: "spring-service-test.java"
    path: "templates/spring-service-test.java"
  - name: "spring-controller-test.java"
    path: "templates/spring-controller-test.java"

How it works: If an issue on this repository is tagged with "needs-tests", the Coding Agent automatically applies the "Java Spring Test Generator" skill. The agent reads the source code (e.g. new UserService.java), generates JUnit 5 tests from the template, runs the tests, validates 80% coverage.

Difference vs Claude Code Agent Skills: GitHub Copilot Agent Skills are specific to the asynchronous Coding Agent in GitHub Actions. Claude Code Agent Skills (in my environment) are skills that the Claude Code agent (CLI tool) can execute locally. However the philosophy is similar: "reusable behaviors".

6. Workflow Phased Research → Plan → Code (1 April 2026)

An important feature announced on April 1, 2026 is the ability to display the intermediate floor of the agent to the developer before code generation.

Scenario: Developer creates issue "Fix race condition in caching layer". Assign @copilot. Agent performs research, identifies the problem, creates two possible solutions:

• Approach A: Use Redis distributed lock + retry logic (safer, +5KB code)
• Approach B: Use AtomicReference + CAS loop (minimal, livelock risk)

With the April 1 feature, Agent shows both approaches in the PR draft comment and asks, "Which do you prefer?" Developer responds in the comment, agent modifies the plan and proceeds with code generation.

Workflow:

• Phase 1-2: Research + Planning (agent does everything)
• Phase 3: Interactive pause - agent comments on the PR draft with the plan
• Phase 3b: Developer approves/modifies plan via comment
• Phase 4-5: Code generation + Test (agent does everything)

This significantly changes the workflow because it allows human architectural input in the middle of the autonomous process.

7. Self-Hosted Runner Support (ARC): Run the Agent in Private Infrastructure

For many enterprise teams, the GitHub Actions Coding Agent sandbox isn't enough. They have needs of:

• Access to internal dependencies (private registry package, internal tools)
• Compliance: code must not leave the corporate firewall while running
• Performance: Local runners faster than the cloud sandbox

Solution: Actions Runner Controller (ARC) (Universe 2025 announced, GA Feb 2026).

ARC allows you to:

• Register Kubernetes cluster (or VM) as a custom runner for the Coding Agent
• Integrate the Coding Agent to use that runner (instead of GitHub-hosted runner)
• The generated code remains in the private cluster while running + testing

ARC setup (simplified):

# Installa ARC controller nel cluster Kubernetes
helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
helm install actions-runner-controller \
  actions-runner-controller/actions-runner-controller \
  -n actions-runner-system \
  --create-namespace

# Configura GitHub token per authentication
kubectl create secret generic controller-manager \
  -n actions-runner-system \
  --from-literal=github_token=$GITHUB_TOKEN

# Crea runner scale set per Copilot Coding Agent
cat <
    

Benefits:

• Accessing private npm package (@internal/my-lib)
• Access to internal databases for integration tests
• Zero code egress during build
• GDPR/PCI-DSS/SOC2 compliant

8. Real End-to-End Example: JWT Refresh Token Endpoint from My Project

Let's take a real case from my portfolio project (Spring Boot + Angular SSR).

Context: I have a login endpoint that generates JWT access token (1 hour TTL). But the refresh token endpoint is missing.

Step 1: I create the issue

Title: Add JWT refresh token endpoint

Body:
Currently, AuthController has POST /auth/login that returns:
{
  "accessToken": "...",
  "refreshToken": "...",
  "expiresIn": 3600
}

But there's no POST /auth/refresh endpoint to exchange refreshToken for a new accessToken.

Requirements:
- Endpoint: POST /auth/refresh
- Input: { "refreshToken": "..." }
- Output: { "accessToken": "...", "expiresIn": 3600 }
- Should validate refreshToken in Redis (check if revoked)
- Should rate-limit to 5 requests per hour per user
- Should log refresh events for audit
- Add JUnit 5 test with 80%+ coverage
- Follow JWT best practices (no sensitive data in token, short TTL)

Stack: Spring Boot 3.4, JPA, Redis, Bucket4j

Step 2: Check @copilot

I click "Assign" → I assign to @copilot. GitHub Actions scheduler activates.

Step 3: Copilot runs (in ~12 minutes)

The agent reads my repository, finds:

• .github/copilot-instructions.md (which I prepared)
• AuthController.java and JwtService.java exist
• Test suite in backend/src/test/java/
• The build passes (mvn test, mvn build)

Agent creates the plan:

## Plan: JWT Refresh Token Endpoint

### Files to Create/Modify:
1. **AuthController.java** (existing)
   - Add @PostMapping("/auth/refresh") method
   - Accept RefreshTokenRequest DTO
   - Return AuthResponse DTO

2. **RefreshTokenRequest.java** (new)
   - Field: refreshToken (String, not null)

3. **AuthService.java** (existing, enhancement)
   - Add refreshAccessToken(String refreshToken) use case
   - Validate refreshToken in Redis
   - Check if revoked (blacklist check)
   - Generate new access token with same user claims
   - Add rate limit check via Bucket4j

4. **RateLimitingAspect.java** (existing enhancement)
   - Add @RateLimited annotation for "/auth/refresh"
   - Config: 5 requests per hour per user_id

5. **AuthControllerTest.java** (existing, add tests)
   - Test: refresh with valid token → 200 OK
   - Test: refresh with expired token → 401 Unauthorized
   - Test: refresh with invalid token → 401 Unauthorized
   - Test: refresh 6 times in 1 hour → 429 Too Many Requests
   - Test: token claims are preserved in new token

### Architecture:
- Follows Clean Architecture (domain → application → infrastructure)
- No mutations, immutable DTOs via records
- Proper error handling (InvalidRequest, NotFound exceptions)
- Rate limiting via Bucket4j + Redis
- Audit logging via AuthAuditLogger

Agent asks for approval (April 1, 2026 feature). I approve the plan via comment.

Step 4: Code Generation

The agent generates the code:

// AuthController.java - NUOVO METODO
@PostMapping("/auth/refresh")
public ResponseEntity refresh(@Valid @RequestBody RefreshTokenRequest request) {
    return ResponseEntity.ok(authService.refreshAccessToken(request.refreshToken()));
}

// AuthService.java - NUOVO METODO
public AuthResponse refreshAccessToken(String refreshToken) {
    // Validate refresh token signature and expiration
    JwtClaims claims = jwtService.validateRefreshToken(refreshToken);

    // Check if revoked in Redis
    String revocationKey = "revoked_refresh_token:" + claims.getSubject();
    if (redisTemplate.hasKey(revocationKey)) {
        throw new InvalidRequestException("Refresh token has been revoked");
    }

    // Extract user ID and generate new access token
    String userId = claims.getSubject();
    UserEntity user = userRepository.findById(userId)
        .orElseThrow(() -> new NotFoundException("User not found"));

    String newAccessToken = jwtService.generateAccessToken(user);

    // Log for audit
    authAuditLogger.logRefresh(userId, "success");

    return new AuthResponse(
        newAccessToken,
        refreshToken,  // Refresh token unchanged
        jwtService.getAccessTokenExpirationSeconds()
    );
}

// AuthControllerTest.java - NUOVI TEST
@Test
@DisplayName("Should refresh with valid token")
void testRefreshWithValidToken() {
    String refreshToken = jwtService.generateRefreshToken(testUser);
    RefreshTokenRequest request = new RefreshTokenRequest(refreshToken);

    var response = mockMvc.perform(post("/auth/refresh")
        .contentType(APPLICATION_JSON)
        .content(objectMapper.writeValueAsString(request)))
        .andExpect(status().isOk())
        .andExpect(jsonPath("$.accessToken").isNotEmpty())
        .andReturn();

    String responseBody = response.getResponse().getContentAsString();
    AuthResponse authResponse = objectMapper.readValue(responseBody, AuthResponse.class);
    assertThat(authResponse.accessToken()).isNotNull();
    assertThat(authResponse.expiresIn()).isEqualTo(3600);
}

@Test
@DisplayName("Should reject expired refresh token")
void testRefreshWithExpiredToken() {
    String expiredToken = jwtService.generateExpiredRefreshToken(testUser);
    RefreshTokenRequest request = new RefreshTokenRequest(expiredToken);

    mockMvc.perform(post("/auth/refresh")
        .contentType(APPLICATION_JSON)
        .content(objectMapper.writeValueAsString(request)))
        .andExpect(status().isUnauthorized());
}

@Test
@DisplayName("Should enforce rate limit (5 requests/hour)")
void testRefreshRateLimit() {
    String refreshToken = jwtService.generateRefreshToken(testUser);
    RefreshTokenRequest request = new RefreshTokenRequest(refreshToken);

    // First 5 requests should succeed
    for (int i = 0; i < 5; i++) {
        mockMvc.perform(post("/auth/refresh")
            .contentType(APPLICATION_JSON)
            .content(objectMapper.writeValueAsString(request)))
            .andExpect(status().isOk());
    }

    // 6th request should be rate limited
    mockMvc.perform(post("/auth/refresh")
        .contentType(APPLICATION_JSON)
        .content(objectMapper.writeValueAsString(request)))
        .andExpect(status().isTooManyRequests());
}

Step 5: Test & Validation

The agent runs:

• mvn test - All tests pass (including 5 new tests)
• mvn -Psonar sonar:sonar - Coverage: 87% (80% target reached)
• Linting: spotbugs, checkstyle - zero warnings
• Security: no hardcoded secrets, no SQL injection risk

Step 6: Open PR

The agent opens a PR draft:

## [Copilot] feat: Add JWT refresh token endpoint

### Description
Implements POST /auth/refresh endpoint to exchange refresh token for new access token.

### Changes
- **AuthController.java**: New @PostMapping("/auth/refresh")
- **RefreshTokenRequest.java**: New DTO (record)
- **AuthService.java**: New refreshAccessToken(String) use case
- **AuthControllerTest.java**: 5 new test cases (rate limit, expiration, revocation)

### Testing
- All tests pass: `mvn test` ✓
- Coverage: 87% (target 80%)
- Spotbugs: 0 issues
- Checkstyle: 0 issues

### Related
Closes #1234 (JWT refresh token endpoint)

### Checklist
- [x] Code follows Clean Architecture
- [x] No mutations (immutable DTOs via records)
- [x] Error handling comprehensive
- [x] Rate limiting via Bucket4j
- [x] Audit logging implemented
- [x] 80%+ test coverage
- [x] No hardcoded secrets
- [x] Follows copilot-instructions.md

---

**Agent Notes:**
- Refresh token invalidated on logout via Redis key expiration
- Access token has 1-hour TTL, refresh token has 30-day TTL
- Rate limit: 5 refresh requests per hour per user_id
- User must re-authenticate if refresh token expired

Total time: 12 minutes (agent execution), 2 minutes (my review), 1 minute (merge).

Without the agent: I would have written all the code manually (1-2 hours), created the tests (1 hour), debugged (30 min). Total: 2.5-3.5 hours.

9. Enterprise AI Controls + Agent Control Plane (GA February 2026)

For enterprise organizations, GitHub has introduced Enterprise AI Controls (preview November 2025, GA February 2026).

Capabilities:

• Policy enforcement: Admin can specify which LLM model the agent uses (e.g. "GPT-4 only", "Claude only"), which LLM vendor (GitHub Models, Anthropic, OpenAI, Azure)
• Audit logging: Each PR generated by the agent is logged with: who assigned it, which model used, which approved plan, which output result
• BYOK (Bring Your Own Key) - preview November 2025: Use your own API keys for Copilot Coding Agent (instead of the GitHub key). Important for: data sovereignty, compliance, cost control
• Rate limiting for org: Admin can limit how many PRs the agent can generate per hour/day
• Scope restriction: Admin can restrict the agent to specific repositories or teams

Configuration (Enterprise Settings):

Organizzazione → Copilot Settings → AI Control Plane

[AI Model Selection]
☑ Restrict to approved models only
  ☐ GitHub Models (default)
  ☐ Claude 3.5 Sonnet (via Anthropic)
  ☐ GPT-4 Turbo (via OpenAI)
  ☐ Azure AI (via Azure OpenAI Service)

[BYOK Configuration]
☑ Use organization API keys
  API Provider: Anthropic
  API Key: sk-ant-... (stored in org secrets)
  Model: claude-3-5-sonnet-20241022

[Audit & Logging]
☑ Log all Copilot Coding Agent activities
  Destination: GitHub Audit Log
  Retention: 90 days

[Rate Limiting]
Max PR generated per day: 100
Max concurrent jobs: 10
Max execution time per job: 30 minutes

[Repository Scope]
Allowed repositories: [list or *]
Blocked repositories: [sensitive repos]
Allowed teams: [list or all]

This is critical for organizations that have compliance requirements (HIPAA, PCI-DSS, SOC2).

10. Limitations and Best Practices: When NOT to Use the Coding Agent

The Coding Agent is powerful, but it is not suitable for everything.

✅ GOOD USE CASE:

• Well defined bug fixes (issue contains stack trace, repo state is known)
• Standard CRUD features (e.g. "Add user profile endpoint")
• Test generation for existing code
• Structural refactoring (rename class, extract method)
• Upgrade dependency with test
• Auto-generated documentation (docstring, JSDoc)

❌ BAD USE CASES:

• Architectural decisions: Choosing between database A vs B, framework X vs Y. Requires understanding trade-offs, future limitations, skill teams.
• Security-sensitive: Auth, crypto, rate limiting. Agent could generate vulnerabilities (e.g. weak random, timing attack).
• Performance critical: O(n^2) algorithms when O(n log n) is necessary. Agent has no visibility into profiling.
• Ambiguous requirements: “Make it faster” without metrics. Agent will generate code but probably in the wrong direction.
• Multi-service orchestration: Modify 5 services atomically. Agent does not coordinate PR across multiple repositories.

BEST PRACTICES:

11. Comparison: Copilot Coding Agent vs Claude Code Agent

To the question "Copilot Coding Agent or Claude Code Agent?", the answer is: Different tools, different purposes.

My advice: If you're on a team that wants asynchronous SDLC automation (issue → PR generated overnight), use Copilot Coding Agent. If you are an individual developer who loves rapid interactive iteration, use it Claude Code Agent.

Conclusion: The Era of Autonomous Development Has Begun

The Copilot Coding Agent represents a tipping point in the software development cycle. It's not hype: the numbers (1 million PRs in 5 months, 23% of all PRs in public repos) say that developers have adopted the technology because it works.

Key takeaways:

• Autonomous agents don't replace developers, they replace repetitive and well-defined tasks
• The future critical skills will be: issue description, code review, architecture decision, prompt engineering
• The tools (Copilot, Claude, DeepSeek) will continue to evolve. In Q2 2026, aspects Agent Skills composition, multi-model orchestration, live environment testing
• Compliance and governance become critical. Enterprise AI Controls are the new "access control" of software development

The next session will cover: Agent Orchestration (coordinate multiple agents in complex workflows), Integration with non-GitHub CI/CD (GitLab, Gitea), and Advanced Prompt Engineering for Issue Description.

References and Recommended Readings

• GitHub Press Release - Copilot Coding Agent GA (September 24, 2025)
• Octoverse 2025 - GitHub report on AI adoption (1M PR metric)
• Official GitHub Copilot Coding Agent documentation
• GitHub Changelog December 2025 - Agent Skills announcement
• GitHub Changelog April 2026 - Phased research-plan-code workflow
• Documentation Actions Runner Controller (self-hosted agent support)
• Community Discussion - Best practices Copilot Coding Agent