githubAug 11, 2026

From coder to orchestrator: How agents shift the role of a developer (opens in new tab)

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

continuous-integrationai-agentmodel-context-protocolgithub-copilot+4

githubAug 4, 2026

Turn one giant AI-generated pull request to a reviewable stack (opens in new tab)

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

continuous-integrationgithubapi-designcoding-agents+2

tossAug 3, 2026

How DS and MLE Work Together (opens in new tab)

The post explains how Toss Bank improved collaboration between Data Scientists (DS) and ML Engineers (MLE) by progressively formalizing their responsibilities. What began as manually transferring notebooks evolved into standardized Python files and finally into installable model packages built around explicit interfaces. The result was faster deployments, consistent observability, and clearer ownership, while AI-generated code introduced a new need to standardize coding style as well. ## Problems with Notebook-Based Handoffs Initially, DS built models and inference code in Jupyter notebooks, then handed them to MLE. - MLE had to recreate the serving code from scratch. - Dependencies, configuration files, and source code were often missing or difficult to reproduce. - Preprocessing logic could be interpreted differently by DS and MLE. - “It works in the notebook” did not guarantee that it would work in production. - As the number of models increased, communication and rework grew rapidly. This approach separated people, not code, so the division of responsibility remained unclear. ## Phase 1: Separating Logic into `.py` Files The team next moved the collaboration boundary from people to files. - DS kept notebooks for experimentation and training. - Core inference logic was extracted into `.py` files. - MLE reviewed these files and validated them through CI. - DS’s intended model behavior was preserved more reliably. - Communication costs decreased. However, the files lacked a standardized structure. - Models used inconsistent function names such as `predict()`, `run()`, and `inference()`. - Code still required modifications when moved into the serving environment. - Global configuration changes in one model could affect other models sharing the same process. - Logging, metrics, and error handling could not be applied consistently across models. ## Phase 2: Defining an Interface Contract The team ultimately standardized the boundary through the `commons-ml-model` package. - A base abstraction defines a common model structure. - DS implements three methods: - `pre_process` - `inference` - `post_process` - The base class handles shared concerns such as: - Logging - Metrics - Tracing - Timing and request tracking - DS packages the implementation as a reusable library. - MLE installs the package with `pip install` and deploys it without rewriting the model. This turns the division of work into a code-level contract. DS focuses on model behavior, while MLE owns serving infrastructure and operational concerns. Updating the base abstraction can also add observability features to every model at once. ## Monorepo Collaboration The team manages the abstraction package and individual model packages in a single monorepo using `uv` workspaces. - Changes to the abstraction and affected models can be reviewed in one pull request. - DS and MLE review the same code in the same repository. - CI, release, and versioning policies are centralized. - Switching from Poetry to `uv` improved build speed by three to five times. The tradeoff is that changes to shared packages can affect many models, and the repository becomes heavier as more packages accumulate. ## Standardizing AI-Generated Code AI-assisted development created a separate collaboration problem: consistent structure did not guarantee consistent coding style. The team introduced `pfmls-stylepack` to encode team conventions for AI tools. - Naming conventions are standardized. - Exception-handling patterns are prescribed. - Rules determine when to use enums instead of hard-coded strings. - Hooks apply conventions while code is being generated. - AI-generated code can explain when a particular rule influenced its implementation. The team therefore distinguishes between: - **Structural consistency:** interfaces define what each role implements. - **Style consistency:** shared rules define how code should be written. Both are necessary for smooth reviews. ## Lessons from the Evolution - The hardest decision is choosing the right collaboration boundary: excessive structure limits flexibility, while insufficient structure recreates inconsistency. - Documentation and early DS–MLE pairing reduce the learning curve for the package-based workflow. - Shared libraries are a double-edged sword: one change can cause broad impact, but one fix can also benefit every model. - In the age of AI-generated code, teams must standardize not only responsibilities and interfaces but also implementation style. The practical recommendation is to make collaboration contracts executable: define stable interfaces, package model code for reuse, centralize shared serving behavior, and enforce coding conventions automatically.

continuous-integrationmachine-learningpythonapi-design+4

githubJul 27, 2026

GitHub Copilot app for Beginners: Getting started (opens in new tab)

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

continuous-integrationai-agentgithubgithub-copilot+3

gitlabJul 16, 2026

Forrester Consulting: GitLab Duo Agent Platform delivers 400% ROI (opens in new tab)

GitLab-commissioned Forrester research found that organizations using GitLab Duo Agent Platform could achieve a 400% three-year ROI, $7.5 million in net present value, and payback in under six months. The study argues that agentic coding creates the greatest business value when integrated across the software lifecycle—not merely used to generate code. Benefits included faster onboarding, shorter migrations, quicker security remediation, and more developer time for feature work. ## Study Scope and Financial Model - Forrester interviewed four organizations across financial services, software, entertainment, and insurance. - Their experiences were modeled as a composite global company with: - $3 billion in annual revenue - 3,000 employees - GitLab Duo Agent Platform adoption growing from 150 to 250 users - Three-year risk-adjusted costs totaled approximately $1.9 million: - $1.3 million in consumption credits - $589,000 for implementation, training, support, and internal labor - Quantified benefits reached $9.4 million, producing: - 400% ROI - $7.5 million net present value - Payback in less than six months ## Problems Before Adoption - Manual processes and ad-hoc knowledge sharing slowed development. - New developers depended heavily on senior engineers for context and troubleshooting. - Security fixes waited in queues for specialists with the necessary expertise. - Code review was often a larger bottleneck than writing code. - Senior engineers were repeatedly interrupted to unblock other team members. ## Quantified Benefits - **80% faster developer onboarding** - Agentic chat in IDEs and repositories helped new hires understand unfamiliar codebases independently. - Estimated savings: $582,000. - **75% shorter migration timeline** - A migration from on-premises GitLab to GitLab SaaS finished in two months instead of eight. - Agents helped diagnose pipeline failures and resolve issues during the migration. - Estimated labor savings: $157,000. - **40% more time for security and QA engineers** - Contextual explanations and suggested fixes reduced remediation effort and reliance on senior staff. - Estimated three-year savings: $1.3 million. - **20% more developer capacity for feature work** - Agents supported code review, testing, and troubleshooting. - Estimated combined benefit: $7.4 million. - Additional unquantified benefits included reduced need for overlapping AI tools, improved developer satisfaction, and stronger knowledge sharing. ## Broader Impact on Software Delivery The study found that organizations shipped features in days rather than weeks, resolved vulnerabilities more quickly, onboarded staff faster, and compressed major infrastructure work. Its central conclusion is that AI productivity gains compound when agentic coding is connected to infrastructure supporting the entire software delivery lifecycle. The findings are based on interviewed organizations and a composite financial model, so actual results will vary. Companies evaluating agentic development should use the study as a framework for estimating benefits across productivity, security, onboarding, and operational efficiency—not as a guaranteed ROI.

continuous-integrationai-agentdevsecopscode-review+3

lineJun 25, 2026

What If AI Agents Debated Each Other? Redesigning the Development Process Through Multi-Agent Collaboration (opens in new tab)

AI coding’s main bottleneck is no longer code generation but the human coordination surrounding it: clarifying intent, validating assumptions, testing implementations, and preparing trustworthy pull requests. LY Corporation proposes an AI-native pipeline in which specialized “proposer” and “challenger” agents debate across three stages—specification, build, and delivery—while an orchestrator decides whether to revise, escalate, or proceed. The goal is for AI to substantiate its own work before human engineers review and approve it. ## Human Coordination as the Bottleneck - Traditional AI-assisted development speeds up individual tasks but leaves handoffs between requirements, implementation, verification, and review to humans. - Engineers still need to: - Write or refine specifications - Review AI-generated drafts - Transfer failed tests and feedback between steps - Inspect diffs - Prepare PR descriptions - Decide whether the result is trustworthy - The proposed solution is not to remove human judgment, but to automate repetitive coordination while preserving human ownership and final approval. ## Proposer–Challenger Collaboration - AI responsibilities are divided between two opposing groups: - **Proposers** develop specifications, implementations, and delivery materials. - **Challengers** validate them from specialized perspectives. - The separation prevents one general-purpose assistant from combining design, implementation, testing, and review into a single unchallenged response. - Specialized roles may include: - `requirements-synthesizer` - `security-analyst` - `test-coverage-reviewer` - `technical-writer` - `evidence-verifier` - An **orchestrator** mediates disagreements, redirects discussions, resolves deadlocks, and determines whether to revise, escalate, or advance. ## The Spec–Build–Deliver Pipeline ### Specification - The specification acts as a contract for all later stages. - It records: - Goals and constraints - Interpreted requirements - Explicit assumptions - Open questions - Proposed approach - Definition of done - Agents use evidence from the workspace and external sources such as Jira, Confluence, design documents, APIs, tests, dependencies, and existing conventions. - Ambiguous but low-risk and reversible issues can be documented as assumptions. - Unsafe, destructive, externally constrained, or hard-to-reverse uncertainties are escalated instead of guessed. ### Build - The approved specification is converted into a test-first verification plan before production code is changed. - The proposer identifies expected behavior, edge cases, required tests, and execution commands. - Challengers can dispute the verification design before or during implementation. - Proposers must support rejected objections with concrete evidence such as: - Execution paths - Compiler or linter output - Failing tests - Other workspace evidence - This prevents a simple green CI result from hiding missing or inadequate validation. ### Delivery - The final output is a review-ready PR package rather than merely a diff summary. - It explains: - What changed - Where reviewers should look first - Which checks passed - Remaining risks - Which challenges were already investigated - At this stage, the orchestrator acts more like a jury, judging whether sufficient evidence exists for release. ## Structured Debate Protocol - Each agent receives stage-specific context and returns structured JSON rather than a free-form essay. - Agents do not share one live context window. Shared state consists of: - Workspace files - Generated artifacts - The orchestrator’s accumulated transcript - Each round includes a proposer response, challenger response, and orchestrator decision. - The protocol distinguishes manageable uncertainty from blocking risk. - Consistent schemas make agent outputs easy to parse, compare, and feed into subsequent rounds. - For example, a challenger can identify an unclear scope boundary, explain why it matters, assign severity and confidence, and indicate whether user input is required. ## Overall Impact - Issues move through a continuous chain: debated specification, branch, tested implementation, and review-ready PR. - Humans intervene mainly to define intent, approve the final result, or resolve explicitly escalated decisions. - The central leverage comes not from generating code faster, but from requiring AI to explore, challenge, verify, and package its work before asking engineers to pay attention. The practical recommendation is to redesign AI development around explicit artifacts, specialized adversarial roles, evidence-based decisions, and automated handoffs. Human engineers should remain the final decision-makers, while AI handles the intermediate coordination and proof-building work.

continuous-integrationai-agentcode-reviewjson+3

awsJun 17, 2026

AWS DevOps Agent adds release management capabilities to assess code changes before production (preview) | Amazon Web Services (opens in new tab)

AWS DevOps Agent’s new preview release-management features extend its role from post-deployment incident response to pre-production review and testing. It evaluates code changes against production requirements, organizational standards, dependency risks, and access-control practices, then performs targeted tests in isolated or production-like environments. The goal is to help teams safely handle the growing volume of AI-generated code without sacrificing review quality or delivery speed. ## Release Readiness Reviews - Reviews changes for: - Production and dependency risks - Cross-repository impacts - AWS access-control changes and Well-Architected best practices - Compliance with organization-specific standards - Teams can provide standards in plain English, such as: - Encryption and network-access rules - Logging and observability requirements - Sensitive-data classification practices - Without custom instructions, the agent applies general best practices. - It runs lightweight user-journey tests in an AWS-managed isolated environment to confirm that the software builds, runs, and passes basic functional checks. - Findings are available in: - The AWS DevOps Agent console - GitHub or GitLab pull-request comments - IDE workflows through the Kiro power or Claude Code plugin ## Autonomous Release Testing - Generates test plans based on the specific code change rather than relying only on static test suites. - Tests web and API applications in customer-provisioned, production-like environments before merging. - Covers: - Functional correctness - Behavioral regressions - Integration scenarios - Produces structured artifacts for every run, including metrics, logs, traces, and execution summaries. ## Configuring and Running Reviews - At least one GitHub or GitLab repository must be connected to an AWS DevOps Agent Space. - The agent indexes connected code and builds a knowledge graph of cloud and cross-repository dependencies. - Reviews can be triggered by: - Submitting a pull request - Starting an on-demand chat request, such as “Perform a production risk analysis on my repository branch” - The target can be specified using a branch name, pull-request number, or commit SHA. - Reviews can also be initiated from supported development environments. ## Reviewing Results - The **Changes** section lists review executions and supports filtering by category or status. - The **Timeline** records the agent’s tools, consulted dependencies, observations, and timestamped reasoning steps. - The **Report** includes: - Recommended action: **BLOCK**, **Proceed with Caution**, or **Safe to Release** - Number of critical issues - Commit revision and changed-file count - Evidence supporting the recommendation - Severity-ranked findings - Actionable remediation steps - A file-by-file summary of modifications - Developers can ask follow-up questions about affected downstream consumers, impacted files and line numbers, and recommended fixes. AWS DevOps Agent’s preview release-management capabilities provide an automated layer of change analysis and targeted testing before production. Teams should configure organization-specific instructions, connect their repositories, and use the generated reports and test artifacts as an additional safety gate for AI-assisted development.

continuous-integrationobservabilitygitlabgithub+4

gitlabJun 10, 2026

Introducing GitLab Orbit (opens in new tab)

GitLab Orbit is a public-beta, queryable graph that connects code with merge requests, pipelines, deployments, vulnerabilities, incidents, and ownership. GitLab argues that this unified context makes AI agents faster, more accurate, and capable of answering cross-system questions that traditional file search or RAG cannot. In testing, Orbit improved code-review accuracy while reducing agent runtime, token use, and hallucinations. ## The Problem with Code-Only Agents - Agents often struggle to understand the systems surrounding code: - Related files and dependencies - Tests and pipelines - Deployments and environments - Vulnerabilities and ownership - Work items and merge requests - In large or multi-repository codebases, agents can waste tokens exploring irrelevant paths, miss dependencies, or run out of context. - This can produce code that appears correct but is later reverted or requires substantial human correction. ## Results from Compare the Market - Compare the Market tested four context-retrieval approaches across 79 real merge requests. - An Orbit-grounded AI reviewer: - Placed accurate inline comments about 70% of the time. - Outperformed RAG, which achieved roughly 58%. - Produced slightly better summaries of key changes: 68% versus 66%. - RAG performed worse than the other tested approaches, including using no additional context. ## Faster and More Efficient Coding Agents - Claude Code and other agents can connect to Orbit through the Model Context Protocol (MCP). - Instead of crawling a repository to infer relationships, an agent can query the graph directly for: - Where code is located - What depends on it - Which tests and pipelines cover it - GitLab reports up to: - 11× faster execution - 4.5× lower token usage - 45× fewer hallucinations ## Cross-System Engineering Workflows Orbit enables agents on the GitLab Duo Agent Platform to investigate relationships beyond source code. - **Pipeline failure triage** - Agents can identify merge requests associated with a failing job. - They can find other projects and in-flight changes likely to encounter the same failure. - This can help teams resolve shared incidents centrally rather than repeating investigations. - **Vulnerability blast-radius analysis** - Queries can trace vulnerable components through services, pipelines, environments, and owning teams. - Security teams can produce assigned remediation plans shortly after a CVE is discovered. - **Engineering metrics** - Teams can query relationships between cycle time, pipeline failure rates, and deployment frequency without waiting for custom dashboards or SQL analysis. - **Migration planning** - Orbit identifies dependent services, jobs, environments, and owners. - This reduces the risk of discovering hidden dependencies late in a migration. ## Architecture and Access - Orbit ingests lifecycle data through change-data capture into ClickHouse. - It parses code in 12 languages, including Ruby, Java, Python, TypeScript, Rust, Go, C#, C++, and PHP. - GitLab reports indexing more than: - 40,000 projects - 500 million nodes - 2 billion edges - The graph can be queried through: - A Cypher-like query language - MCP - REST - The GitLab CLI - An event-driven engine keeps the graph current as changes occur. - Indexing runs separately from GitLab, so query traffic does not burden the GitLab instance. - Authorization follows existing GitLab permissions, limiting agents to data their users can access. - Queries pass through validation, planning, optimization, and security stages before reaching the database. ## Engineer-Facing Data Explorer - The Data Explorer provides direct access to the same graph without an AI agent. - Engineers can use it to: - Investigate incidents - Trace dependencies across services - Diagnose recurring CI failures - GitLab positions it as a way to answer open-ended system questions in seconds rather than reconstructing the answer manually across multiple tools. GitLab Orbit is best suited to organizations where code, CI/CD, security, and ownership data are spread across large repositories or many projects. Its main recommendation is to use one permission-aware graph as shared context for both AI agents and engineers, rather than relying on repository search or disconnected tool calls.

continuous-integrationai-agentmodel-context-protocolgraph-database+3

dropboxMay 28, 2026

Beyond code generation: rethinking engineering productivity in the age of AI agents (opens in new tab)

AI coding agents have increased Dropbox’s code production, but they have also exposed bottlenecks in review, testing, release coordination, and operations. The central argument is that engineering productivity must be measured by end-to-end product velocity and customer impact—not code or pull-request volume alone. Dropbox is responding with agent platforms, stronger workflow infrastructure, broader quality metrics, and training that helps engineers adapt to new responsibilities. ## From Copilots to Agents - Copilots assist with explanations, snippets, and questions within existing workflows. - Agents can take scoped tasks, inspect repositories, edit files, run tests, fix failures, and return changes for human review. - Engineers remain responsible for intent, architecture, quality, and release decisions. - Increased parallel work and code output create new pressure on: - Code review systems - CI and testing infrastructure - Validation workflows - Release processes - Production operations - More code and pull requests do not necessarily create more customer value. ## Nova as Dropbox’s Agent Platform - Nova runs AI coding agents in controlled environments with relevant codebase context and internal engineering practices. - Its value comes from the surrounding platform—safe execution, workflow integration, guardrails, and human review—not only from the underlying model. - Nova generates approximately one in twelve Dropbox pull requests. - It supports both feature work and maintenance tasks, including: - Migrations - Flaky-test remediation - Bug investigation - Dependency updates - Other high-effort engineering work - The intended workflow is structured: define the task, let the agent work within constraints, validate the result, and require human approval before production. ## Measuring Product Velocity and Impact - Pull-request throughput was useful when implementation speed was the main constraint, but it is insufficient as AI increases output. - Dropbox evaluates whether the broader engineering system can absorb additional work efficiently. - Its four-stage measurement model tracks: - **Fuel:** Whether engineers use AI tools - **Adoption:** How teams change their workflows - **Output:** Whether AI contributes to production work - **Impact:** Whether products reach customers faster and create greater value - Quality and trust metrics include review turnaround time, first-run test pass rate, defect ratio, and rework rate. - Productivity improvements must not come at the expense of reliability or customer trust. ## Evolving Engineering Workflows - Engineers increasingly focus on defining intent, framing problems, reviewing changes, and making architectural and quality decisions. - Adoption requires more than tools; Dropbox uses hands-on learning, hackathons, bootcamps, workflow examples, and peer-led training. - Teams should adopt agents at different speeds based on risk, context, and readiness. - The goal is not to automate every workflow, but to make agentic development safe, useful, measurable, and repeatable. ## Broader Lessons - AI does not remove bottlenecks; it shifts them downstream. - Organizations must invest in validation, orchestration, governance, workflow integration, and measurement alongside code generation. - Competitive advantage will come less from access to common foundation models and more from the systems built around them: internal context, safeguards, quality controls, and integrated engineering workflows. Dropbox’s experience suggests that companies should treat AI agents as a change to the entire software delivery system, not merely as faster coding tools. The strongest results will come from improving the full path from idea to validated production impact.

continuous-integrationai-agentcode-reviewworkflow-automation+3

dropboxMay 21, 2026

Introducing Nova, our internal platform for coding agents (opens in new tab)

Nova is Dropbox’s internal cloud platform for running coding agents across the software development lifecycle. Rather than building separate tools for coding, CI debugging, migrations, and operational tasks, Dropbox created a shared platform that supports interactive sessions and autonomous workflows within its monorepo and infrastructure. The platform grounds agent changes in real builds and tests, making AI assistance more reliable and easier to integrate into engineering workflows. ## The Case for a Shared Platform - Engineering work includes repetitive but important tasks such as: - Debugging CI failures - Updating dependencies - Improving test coverage - Fixing flaky tests - Managing migrations and operational work - Different tasks require different interaction models: - Interactive chat for developer-driven work - Asynchronous workflows for long-running remediation and automation - Dropbox’s environment has specialized requirements: - A large monorepo - Bazel for builds and tests - Caching and remote execution - On-premises infrastructure - Dropbox-specific validation workflows - Off-the-shelf coding agents were designed primarily for local development and did not naturally fit this environment. ## How Nova Runs Coding Sessions - Each session runs in an isolated environment using a specific snapshot of the codebase. - Callers provide: - The repository commit - A task description - Optional validation commands - Iteration limits and branch settings - Nova can run builds and tests after an agent proposes a change. - If validation fails, the results are sent back to the agent so it can continue troubleshooting. - This creates a feedback loop of: - Propose a change - Validate it in the real environment - Correct failures - Repeat as needed - Nova supports multiple coding agents behind a common interface. - Engineers can access it through: - A web interface - A command-line client - An API - Internal scripts and services - The platform also provides prompt evaluation, observability, feedback collection, skills, plugins, and MCP integrations for accessing systems such as logs and monitoring tools. ## Deterministic Code Publication - Nova keeps code publication outside the agent. - Each session is limited to a single branch. - This makes active work and publication status predictable. - It avoids the complexity of agents creating and managing multiple branches. - The deterministic model simplifies automation such as: - Running tests - Rebasing onto the main branch - Tracking which changes belong to each session ## Engineering Workflows Using Nova ### Developer-Driven Sessions - Engineers use Nova’s web interface for quick fixes and prototypes without disrupting local work. - Validation commands can use Bazel selectivity tools to target the relevant compile and test dependencies. - Slack discussions can be carried into Nova sessions, preserving context and reducing manual setup. ### Flaky Test Remediation - Dropbox built Deflaker, a durable workflow connected to Athena, its flaky-test detection system. - Deflaker gathers examples of a test passing and failing. - It sends the associated logs to Nova. - The agent analyzes the evidence, identifies a likely cause, and proposes a fix. - This demonstrates how Nova can combine investigation, context gathering, and code changes in a longer-running automated process. ## Practical Takeaway Dropbox’s experience suggests that coding agents are most useful when embedded in existing engineering systems rather than treated as isolated code-generation tools. A shared platform like Nova can support many workflows while preserving consistent execution, validation, context, and observability.

continuous-integrationobservabilityslackmcp+4

gitlabMay 21, 2026

Transform MRs from manual tasks to an automated workflow (opens in new tab)

GitLab 19.0 expands Developer Flow from generating merge requests to managing much of their entire lifecycle. Its AI agent can respond to reviews, investigate codebases, resolve conflicts, and split oversized MRs, while automation handles rebasing and merging. The result is less manual effort between opening and merging an MR, with developers supervising rather than executing every step. ## Developer Flow Across the MR Lifecycle - Can be triggered from: - An issue via **Generate MR** - An issue or MR assigned to the **Duo Developer** service account - Any issue or MR discussion using the new **@mention** trigger - Continues working on the same MR instead of creating separate changes to reconcile. - Handles: - Multiple rounds of reviewer feedback - Merge conflicts on long-running branches - Codebase research and technical evaluations - Oversized MR splitting - New feature implementation - Uses a single agentic loop with tools such as `read`, `grep`, file editing, and command execution. - Reads `AGENTS.md` for project conventions and operational guidance. - Uses `agent-config.yml` to configure dependencies, tooling, tests, and pre-commit hooks. These capabilities are available through GitLab Duo Agent Platform on Premium and Ultimate plans. ## Autonomous Merge Conflict Resolution - The beta **Resolve with Duo** button is available on the MR conflict page and merge checks widget. - The agent: - Reviews the MR’s intent and both branches - Selects a resolution strategy - Edits conflicting files - Commits and pushes the resolution - It leaves a summary comment explaining the conflict and resolution path. - If it cannot resolve the conflict safely, it reports that rather than guessing. ## One-Click Rebase and Merge - The beta feature combines rebasing and merging into one action. - It is designed for teams using semi-linear or fast-forward merge methods. - It is available on Free, Premium, and Ultimate tiers. ## Reducing Manual MR Work GitLab distinguishes between AI-driven judgment and mechanical automation: - AI handles code changes, reviewer feedback, and conflict resolution. - Automation handles tasks such as rebasing before merge. - Together, these features reduce the time developers spend on repetitive MR maintenance while preserving human oversight for steering, reviewing, and final decisions. Developers can try Developer Flow through a GitLab Duo Agent Platform trial. Existing Premium and Ultimate users with the platform can use it on merge requests, while older GitLab versions may require manually configuring the mention trigger.

continuous-integrationai-agentgitlabdevsecops+4

spotifyMay 18, 2026

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify | Spotify Engineering (opens in new tab)

Spotify argues that AI has shifted software development’s main constraint from writing code to coordinating people, systems, and decisions. Years of investment in standardized platforms, automation, and developer experience enabled Spotify to adopt AI coding tools at extraordinary scale. The company’s experience suggests that consistent infrastructure and strong feedback loops are essential for making both human developers and coding agents effective. ## Rapid AI Adoption - More than 99% of Spotify engineers use AI coding tools weekly. - 94% report improved productivity. - Pull request frequency has increased by 76%, with most PRs created by developers working alongside AI agents. - Adoption accelerated sharply after the release of Claude Opus 4.5. ## Fleet Management Before AI Agents - Spotify’s codebase was growing seven times faster than its engineering workforce. - Developers increasingly spent time on dependency upgrades, API migrations, and vulnerability fixes. - Fleet Management automated changes across hundreds or thousands of components. - Its orchestration system, Fleetshift, has merged more than 2.5 million maintenance PRs, most without human intervention. - This approach reduced migrations from work taking weeks or months across many teams to centrally managed operations. ## Honk: A Background Coding Agent - Deterministic scripts struggled with complex refactoring and the edge cases found across large codebases. - Spotify created Honk, a background coding agent powered by Claude through the Agent SDK. - Honk runs in Kubernetes pods, allowing many coding sessions to execute concurrently. - It can use trusted tools and run builds in CI across multiple operating systems. - Fleetshift identifies targets, schedules work, and tracks PRs, while Honk performs the code changes. - A recent Java migration across Spotify’s backend services took three days. - Engineers can invoke Honk through Slack, where it uses conversation context to create and return PRs. - Honk v2 adds shared sessions, team projects, and agent orchestration through Chirp. ## Standardization Improves Agent Performance - Spotify’s principle of limiting the number of technologies it supports reduces decisions and improves collaboration. - Consistent service architectures and design patterns also give AI agents better reference material. - Agents perform worse in fragmented codebases with inconsistent conventions. - Backstage provides a unified internal developer portal and catalog for software components. - Spotify exposes Backstage capabilities to agents through MCP integrations and command-line tools. - Agents can discover component ownership, read documentation, and contact responsible teams. ## Guardrails Through Backstage - Backstage’s Soundcheck and “golden state” define recommended technologies and practices. - Teams can assess their components against these standards. - Static analysis and linting provide immediate feedback when developers or agents use unsuitable patterns. - This creates a feedback loop that helps agents correct their work and drives consistency across the organization. Spotify’s experience indicates that scaling AI development requires more than giving engineers access to models. Organizations should invest in standardized platforms, searchable component metadata, automated fleet-wide workflows, and strong validation systems so agents can operate reliably at team scale.

continuous-integrationk8sai-agentslack+4

dropboxMar 25, 2026

Reducing our monorepo size to improve developer velocity (opens in new tab)

Dropbox’s server monorepo grew to 87GB, making full clones take over an hour and threatening GitHub’s 100GB limit. The root cause was inefficient Git delta compression of internationalization files, not unusually large source files. By changing how the repository was repacked, Dropbox reduced it to about 20GB and cut clone times to under 15 minutes. ## Repository Size and Developer Velocity - The monorepo contains backend services and libraries used across Dropbox. - AI feature development often requires coordinated changes across ranking, retrieval, evaluation, and UI systems. - A full clone exceeded one hour at 87GB, slowing onboarding and affecting CI jobs that start from fresh clones. - Internal synchronization systems also processed more data, increasing timeout and reliability risks. - The repository grew by roughly 20–60MB per day, with occasional increases above 150MB. - At that rate, Dropbox expected to hit GitHub Enterprise Cloud’s 100GB hard limit within months. ## How Git Compression Caused the Growth - Git normally reduces storage by representing similar file versions as deltas rather than complete copies. - Its default file-matching heuristic considers only the final 16 characters of a path. - Dropbox’s i18n files used paths such as: - `i18n/metaserver/[language]/LC_MESSAGES/[filename].po` - Because the language component appears early in the path, Git often compared files from different languages instead of related versions of the same language. - Translation updates consequently produced oversized deltas and disproportionately large pack files. ## Testing `--path-walk` - Dropbox tested Git’s experimental `--path-walk` option during a local repack. - The option considers the full directory structure when selecting delta candidates. - A local repack reduced the repository from the low-80GB range to the low-20GB range, confirming that packing—not data volume—was the main issue. - GitHub could not use this approach because it conflicted with server-side optimizations such as bitmaps and delta islands. ## Why Server-Side Repacking Was Necessary - Local optimization cannot permanently change the packs GitHub generates for clones and fetches. - GitHub dynamically constructs transfer packs based on what each client needs. - Dropbox’s mirror experiment showed that an aggressive repack could reduce the repository from 84GB to 20GB: - `git repack -adf --depth=250 --window=250` - The repack took approximately nine hours. - Dropbox worked with GitHub Support to apply a compatible server-side solution. - Larger `window` and `depth` values make Git search more thoroughly for compression opportunities, trading increased repack time for smaller storage and transfer sizes. ## Results - Repository size fell from 87GB to approximately 20GB—a 77% reduction. - Clone time dropped from more than an hour to under 15 minutes. - The work reduced pressure on GitHub’s repository size limit and improved the performance of developer and CI workflows. Dropbox’s experience shows that monorepo growth can result from repository layout interacting poorly with Git’s compression heuristics. When large repositories exhibit abnormal growth, teams should inspect pack-file behavior and consider server-side repacking rather than focusing only on removing large files.

continuous-integrationdatabase-designgithubgit+4

githubFeb 27, 2026

From idea to pull request: A practical guide to building with GitHub Copilot CLI (opens in new tab)

GitHub Copilot CLI helps developers move from an idea to reviewable code without leaving the terminal. The recommended workflow is to begin with intent, let Copilot propose plans and scaffolding, validate changes through tests and diffs, then move to an IDE for refinement and GitHub for collaboration. Copilot accelerates development but does not replace design judgment, code review, or user approval. ## What Copilot CLI Is—and Isn’t - It is a GitHub-aware coding agent that operates in the terminal. - Developers can describe goals in natural language and use `/plan` or `Shift + Tab` planning mode. - It proposes commands, file changes, and diffs for review before execution. - It can generate files, modify code, and explain failures. - It does not silently run commands or eliminate the need for careful design and review. ## Start with Intent - Begin by describing the application or feature rather than choosing a framework or copying a template. - For example, ask Copilot to create a small web service with a JSON endpoint and tests. - Copilot may suggest a technology stack, file structure, and setup commands. - Review these suggestions before deciding what to execute. ## Scaffold Only What You Own - Once the direction is clear, ask Copilot to create a minimal project structure. - It can generate directories, configuration, test runners, and README files. - Generated scaffolding should be treated as a starting point, not an unquestioned design. - Developers remain responsible for reviewing, editing, or discarding the result. ## Iterate from Real Failures - Run tests directly within the CLI and use the resulting output as context. - Ask Copilot to explain a failure or propose a fix with a reviewable diff. - The recommended loop is: run a command, inspect the output, ask for help, and review the proposed change. - Use `explain` when understanding is the goal and `suggest` when seeking a concrete proposal. ## Handle Mechanical Repository-Wide Changes - Copilot CLI is effective for clearly scoped, repetitive work such as renaming symbols across a repository. - It can update related tests and provide a concrete diff. - Mechanical changes are relatively easy to inspect, revert, and validate. ## Move to the IDE for Precision - The terminal is best for fast exploration, planning, scaffolding, and low-ceremony changes. - Move to an editor or IDE when refining APIs, handling edge cases, and making design decisions. - A practical division is: - **CLI:** plan, generate diffs, and move quickly. - **IDE:** refine logic and shape the implementation. - **GitHub:** commit, open pull requests, review, and collaborate. ## Finish by Shipping on GitHub - Copilot CLI can help add descriptive commits, push changes, and create pull requests. - Pull requests make the work durable through teammate review, CI testing, and asynchronous collaboration. - The workflow can also add Copilot as a reviewer. - The ultimate value comes from reaching commits and pull requests, not merely generating suggestions. Copilot CLI is most effective as a momentum tool: use it to turn intent into concrete, testable changes, while retaining human control over design, approval, and review.

continuous-integrationgithub-copilotgithub-copilot-clinode.js+3

spotifyFeb 19, 2026

Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3) | Spotify Engineering (opens in new tab)

Spotify argues that unsupervised coding agents become reliable only when surrounded by strong, automated feedback loops. Its “Honk” system uses component-specific verifiers, mandatory pre-PR checks, and an LLM judge to catch build failures, test failures, scope creep, and functionally incorrect changes. The conclusion is that constrained, sandboxed agents with rich verification are more predictable than flexible agents operating independently. ## Failure Modes at Scale - Agents may fail to produce a pull request, which is inconvenient but usually manageable. - They may produce PRs that fail CI, leaving engineers to repair incomplete work. - Most seriously, they may produce PRs that pass CI but are functionally wrong and potentially reach production. - These failures are more likely when components lack tests, agents modify code beyond the prompt, or agents cannot correctly run builds and tests. - Reviewing invalid or nonsensical PRs can become a significant engineering time sink. ## Verification Loops - Honk uses independent verifiers that provide incremental feedback while the agent works. - Verifiers activate automatically based on the repository contents; for example, a Maven verifier runs when a root-level `pom.xml` is present. - The agent sees an abstract MCP tool rather than the implementation details of Maven, test runners, or build systems. - Verifiers handle formatting, compilation, testing, and output parsing, returning concise error messages instead of consuming the agent’s context with raw logs. - All applicable verifiers run before a PR is opened. In Claude Code, this is enforced with a stop hook. - If verification fails, the PR is blocked and the user receives an error. ## An LLM as a Judge - Deterministic checks cannot detect every problem, especially when an agent makes unnecessary refactors or disables flaky tests. - Honk therefore sends the original prompt and proposed diff to a separate LLM judge. - The judge runs after the regular verifiers and can veto changes that exceed the requested scope. - Across thousands of sessions, the judge rejects roughly one quarter of proposed changes. - Agents successfully correct about half of the vetoed changes. - Spotify has not yet built formal evaluations for the judge, but observed that scope violations are its most common reason for rejection. ## Constrained Agents and Sandboxing - The agent has limited responsibilities: inspect the relevant code, edit files, and invoke verification tools. - Surrounding infrastructure handles prompt creation, pushing code, and user communication through systems such as Slack. - Restricting the agent’s capabilities improves predictability and provides security benefits. - Agents run in heavily sandboxed containers with limited permissions, few installed binaries, and almost no access to surrounding systems. - Spotify reports that agents solve increasingly complex tasks reliably when these feedback loops are present, but often produce unusable code without them. ## Future Expansion - Spotify plans to support more hardware and operating systems. - Current verifiers run only on Linux x86, limiting support for systems that require macOS, such as iOS applications, or ARM64 environments. - The company also intends to integrate Honk more deeply with existing CI/CD pipelines. The practical recommendation is to treat autonomous coding as an infrastructure and verification problem, not merely a prompting problem: keep agents narrowly scoped, isolate them securely, and require layered automated checks before accepting their changes.

continuous-integrationllmai-agentmodel-context-protocol+4