“The person who communicates the best will be the most valuable programmer in the future. The new scarce skill is writing specifications that fully capture your intent and values,” Sean Grove from OpenAI said recently at the AI Engineer conference.

Specifications, not prompts or code, Grove says, are becoming the fundamental unit of programming, and writing specs is the new superpower.

As AI makes it easier than ever to generate code, two things have become clear. The first is that generating more code with AI does not remove complexity from software engineering; it just abstracts it away to debugging, testing and deployment pipelines. And that writing code was never the bottleneck.

Writing Code Isn’t the Bottleneck

The bottleneck is knowing what to build, gathering requirements, knowing why to build it, and, ultimately, knowing if it has been built correctly and achieved its intentions. Engineering organizations are going to feel that squeeze the more advanced the AI models get, Grove points out.

Design alignment across teams, resolving conflicting requirements, eliminating tech debt, bringing rigor to code reviews and preserving institutional knowledge when senior engineers leave are listed as the fundamental challenges that make building software difficult in Amazon’s announcement for its AI IDE and the concept of spec-driven development.

The main thing that determines whether an agent succeeds or fails is the quality of the context it’s given. And, if we want agents to succeed not only at vibe coding cool apps from scratch, but in messy, brownfield enterprise codebases, giving agents the right context — or context engineering — is the missing piece to make it happen.

But getting context is hard. Even as large language models’ (LLMs’) context windows are increasing, we already know that providing larger context to LLMs actually drops the quality. The secret is the quality of the provided context.

Specs are “refined context” that provides just enough information to the LLMs to be effective without being overwhelmed.

What Is Spec-Driven Development?

Spec-driven development is the practice of writing specifications before writing code — or asking an AI tool to write code. Instead of just trying your luck with prompts, no matter how carefully crafted, and then prompting for fixes, spec-driven development starts with clear and structured documents that capture requirements, intentions and constraints.

In the AI coding era, a specification acts as a guide for AI agents, something they can reference, validate their work against and use to stay oriented. It’s a North Star that enables agents to take on larger, more complex tasks without losing track of intent.

Spec-driven development replaces the chaos of ad hoc, prompt-driven vibe coding with a structured, durable way for programmers to express their goals. It allows developers to be more specific about particular details, and for the agent to communicate its plan ahead of time.

A specification becomes a kind of version-controlled, human-readable super prompt.

How Does Spec-Driven Development Work?

If you simply prompted AI to “implement user permissions,” it might create a standard role-based access control (RBAC) system with admin and user roles. On the surface, the code might look polished and production-ready. But it won’t stop to ask if you need fine-grained permissions, temporary access windows or hooks into an existing identity provider. The generated code looks professional and complete, masking the fact that it solves the wrong problem.

Spec-driven development requires engineers to slow down, think clearly about what they’re building and communicate in a clear and structured way about:

• Specific input/output formats and data types.
• Explicit business rules and edge cases.
• Integration constraints and existing system dependencies.
• Performance requirements and expected scale.
• Error handling and validation rules.
• Security and compliance requirements.

From there, the agents create a task list of things to do to build the code according to the specifications. Engineers can still interact with agents via prompts and steer them.

From Developer-Agent Collaboration to Multiplayer Coding

Building software with AI agents isn’t a solo sport, especially in larger engineering organizations. Modern projects often span multiple repositories, microservices, prompts and specs. Imagine adding a “Share” button to your specs to share expertise across your team and delegate execution.

That’s where Runbooks come in. A concept we’ve been developing is to turn AI-assisted coding from a single-player activity into a multiplayer one. Runbooks give teams a shared space to collaborate on prompts, align on execution workflows and maintain a clear audit trail of decisions.

Think of Runbooks as the missing link between product specifications and code. A runbook isn’t just documentation, it’s a living knowledge base that others can pick up, extend and adapt. You can build on top of someone else’s Runbook, transfer context across repositories or code paths, draft your own specs and get feedback, or bring stakeholders and coding agents together in a single, structured session.

Try Runbooks and turn AI coding from individual experiments into team-wide engineering projects.

The post Spec-Driven Development: The Key to Scalable AI Agents appeared first on The New Stack.

At Docker, open source is not just something we support; it’s a core part of our culture. It’s part of our DNA. From foundational projects like Docker Compose (35.5k stars, 5.4k forks) and Moby (69.8k stars, 18.8k forks) to our continued code contributions, we remain committed to strengthening the open-source ecosystem.

Today, we are announcing a new milestone in that journey: an official partnership between Docker and the Cloud Native Computing Foundation (CNCF). This partnership brings more than just resources for open-source projects. It also reflects the CNCF’s recognition of Docker as the leading distribution platform for containerized software and as a trusted partner in modern software supply chain security.

Why this Partnership Matters

This partnership reflects CNCF’s support of Docker as an industry leader and a strategic partner, trusted to deliver the scale, visibility, and security that today’s cloud-native ecosystem demands.

Docker Hub is the most widely used container registry in the world, serving over 22 billion image downloads per month and hosting more than 14 million images. For CNCF projects, using Docker is a natural choice, offering a trusted, reliable distribution platform with unmatched reach and adoption across the developer community.

For Docker, this partnership is a reinforcement of our commitment to the open source community.  We are also excited by the opportunity to deepen collaboration with the maintainers and developers building the future of cloud-native software. For maintainers, it’s an opportunity to gain access to premium infrastructure and support tailored to the needs of open-source projects.

Maintainers: Unlock Full Access to DSOS Benefits

Figure: Docker Captain James Spurin providing a talk on Docker.

During the following days, all CNCF projects will have direct access to a dedicated bundle of Docker services through the Docker Sponsored Open Source (DSOS) program. Some of the key benefits of the program are:

• Unlimited image pulls
• Sponsored OSS status for increased trust and discoverability
• Access to Docker usage metrics and engagement insights
• Streamlined support through Docker’s open-source channels

These benefits help you scale your project, grow your community, and ensure reliable access for your users.

What the Partnership Offers CNCF Projects

Docker: Official CNCF Project Services Provider

As part of this collaboration, Docker will be listed as an official service provider on the CNCF Project Services page. This showcasing enhances the discoverability of Docker’s tools and services for CNCF maintainers, reinforcing Docker’s role as a trusted infrastructure partner. For projects, it means easier access to vetted, high-impact resources already recognized and recommended by the CNCF community.

Security with Docker Scout

CNCF projects now have unlimited access to Docker Scout, our image analysis and policy evaluation tool. Scout is a critical security layer aligned with modern supply chain practices, helping projects detect vulnerabilities, enforce policies, and maintain healthy, secure containers.

Automated Builds

CNCF projects can streamline their development pipelines with Docker autobuilds, enabling automated image creation directly from source code.

OSS Status

All participating projects receive a Sponsored OSS badge on Docker Hub, increasing trust and visibility among users.

Unlimited Image Pulls

DSOS members benefit from unrestricted public image pulls, ensuring reliable access for users and reducing friction for project adoption.

Docker Usage Metrics

Access to pull data and adoption metrics provides deeper visibility into community engagement and image usage trends.

Support and Communication Channels

DSOS projects receive priority support through Docker’s open-source outreach channels.

Reinforcing Docker’s Role in the Open-Source Supply Chain

Security and trust are foundational to sustainable open source. Docker’s continued investment in secure tooling, developer experience, and supply chain integrity reflects our long-term commitment to supporting the infrastructure that open-source projects and their users rely on. Through tools like Docker Scout, now available to all CNCF projects, Docker is helping maintainers adopt secure development practices in a way that integrates naturally into their existing workflows.

Also the recent launch of Docker Hardened Images, curated, security-enhanced base images, has drawn intense interest from both the open-source community and enterprise users. 

By continuing to invest in security, reliability, and open collaboration, Docker aims to help the ecosystem move forward with confidence.

Moving Forward

This partnership with CNCF is more than a program expansion. It is a signal that Docker Hub is the preferred distribution platform for the projects that matter most in the cloud-native ecosystem. It enables us to collaborate more deeply with maintainers, deliver better tools, and ensure open-source infrastructure is built on a strong, secure foundation.

If you’re a CNCF maintainer, now is the time to make sure your project is fully supported.

In the following days, your project will feature the DSOS badge on Docker Hub. If not, contact the CNCF Service Desk to get started. In case you don’t want to become part of the DSOS program, you can also use the same method of contact.

We’re proud to support the projects powering the modern internet, and we’re just getting started.

Learn More

• Apply to the Docker Sponsored Open-Source Program
• Learn about Docker’s Open Source tools
• Read the CNCF blog about the partnership

cagent is a new open-source project from Docker that makes it simple to build, run, and share AI agents, without writing a single line of code. Instead of writing code and wrangling Python versions and dependencies when creating AI agents, you define your agent’s behavior, tools, and persona in a single YAML file, making it incredibly straightforward to create and share personalized AI assistants.

Figure 1: cagent is a powerful, easy to use, customizable multi-agent runtime that orchestrates AI agents with specialized capabilities and tools, and the interactions between agents.

cagent can use OCI registries to share and pull agents created by the community, so not only can you elegantly solve the agent creation problem, but also the agent distribution problem. 

Let’s dive into what makes cagent special and explore some real-world use cases.

What is cagent?

At its core, cagent is a command-line utility that runs AI agents defined in cagent.yaml files. The philosophy is simple: declare what you want your agent to do, and cagent handles the rest. 

There are a few features that you’ll probably like for authoring your agents. 

• Declarative and Simple: Define models, instructions, and agent behavior in one YAML file. This “single artifact” approach makes agents portable, easy to version, and easy to share.
• Flexible Model Support: You’re not tied to a specific provider. You can run remote models or even local ones using Docker Model Runner, ideal for privacy reasons. 
• Powerful Tool Integration: cagent includes built-in tools for common tasks (like shell commands or filesystem access) and supports external tools via MCP, enabling agents to connect to virtually any API. 
• Multi-Agent Systems: You’re also not limited to a single agent. Cagent allows you to define a team of agents that can collaborate and delegate tasks to one another, with each agent having its own specialized skills and tools. 
  

Practical use cases for agent

I’ve lived with and used cagent for a few weeks now, and in this article, I want to share two of my practically useful agents that I actually use. 

A GitHub Task Tracker

Let’s start with a practical, developer-centric example. While tracking GitHub issues with AI might not be revolutionary, it’s surprisingly useful and demonstrates cagent’s capabilities in a real-world workflow. 

There’s no shortage of task tracking solutions to integrate with, but one of the most useful for developers is GitHub. We’ll use a repository in GitHub and issues on it as our to-do list. Does it have the best UX? It doesn’t actually matter; we’ll consume and create issues with AI, so the actual underlying UX is irrelevant. 

I have a GitHub repo: github.com/shelajev/todo, which has issues enabled, and we’d like an agent that can, among other things, create issues, list issues, and close issues. 

Figure 2

Here’s the YAML for a GitHub-based to-do list agent. The instructions for the agent were generated with the agent new command, and then I refined the instructions it generated by manually asking Gemini to make them shorter. 

YAML

version: "2"

models:
  gpt:
    provider: openai
    model: gpt-5
    max_tokens: 64000

agents:
  root:
    model: gpt
    description: "GitHub Issue Manager - An agent that connects to GitHub to use a repo as a todo-list"
    instruction: |
      You are a to-do list agent, and your purpose is to help users manage their tasks in their "todo" GitHub repository.

      # Primary Responsibilities
      - Connect to the user's "todo" GitHub repository and fetch their to-do items, which are GitHub issues.
      - Identify and present the to-do items for the current day.
      - Provide clear summaries of each to-do item, including its priority and any labels.
      - Help the user organize and prioritize their tasks.
      - Assist with managing to-do items, for example, by adding comments or marking them as complete.

      # Key Behaviors
      - Always start by stating the current date to provide context for the day's tasks.
      - Focus on open to-do items.
      - Use labels such as "urgent," "high priority," etc., to highlight important tasks.
      - Summarize to-do items with their title, number, and any relevant labels.
      - Proactively suggest which tasks to tackle first based on their labels and context.
      - Offer to help with actions like adding notes to or closing tasks.

      # User Interaction Flow
      When the user asks about their to-do list:
      1. List the open items from the "todo" repository.
      2. Highlight any urgent or high-priority tasks.
      3. Offer to provide more details on a specific task or to help manage the list.

    add_date: true
    toolsets:
      - type: mcp
        command: docker
        args: [mcp, gateway, run]
        tools:
          [
            "get_me",
            "add_issue_comment",
            "create_issue",
            "get_issue",
            "list_issues",
            "search_issues",
            "update_issue",
          ]

It’s a good example of a well-crafted prompt that defines the agent’s persona, responsibilities, and behavior, ensuring it acts predictably and helpfully. The best part is editing and running it is fast and frictionless, just save the YAML and run: 

cagent run github-todo.yaml 

This development loop works without any IDE setup. I’ve done several iterations in Vim, all from the same terminal window where I was running the agent. 

This agent also uses a streamlined tools configuration. A lot of examples show adding MCP servers from the Docker MCP toolkit like this: 

  toolsets:
      - type: mcp
        ref: docker:github-official

This would run the GitHub MCP server from the MCP catalog, but as a separate “toolkit” from your Docker Desktop’s MCP toolkit setup.

Using the manual command to connect to the MCP toolkit makes it easy to use OAuth login support in Docker Desktop. 

Figure 3

Also, the official GitHub MCP server is awfully verbose. Powerful, but verbose. So, for the issue-related agents, it makes a lot of sense to limit the list of tools exposed to the agent: 

 tools:
          [
            "get_me",
            "add_issue_comment",
            "create_issue",
            "get_issue",
            "list_issues",
            "search_issues",
            "update_issue",
          ]

That list I made with running: 

docker mcp tools list | grep "issue"

And asking AI to format it as an array. 

This todo-agent is available on Docker Hub, so it’s a simple agent pull command away: 

cagent run docker.io/olegselajev241/github-todo:latest

Just enable the GitHub MCP server in the MCP toolkit first, and well, make sure the repo exists.

The Advocu Captains Agent

At Docker, we use Advocu to track our Docker Captains, ambassadors who create content, speak at conferences, and engage with the community. We use Advocu to track their information details and contributions, such as blog posts, videos, and conference talks about Docker’s technologies.

Manually searching through Advocu is time-consuming. For a long time, I wondered: what if we could build an AI assistant to do it for us? 

My first attempt was to build a custom MCP server for our Advocu instance: https://github.com/shelajev/mcp-advocu

It’s largely “vibe-coded”, but in a nutshell, running

docker run -i -rm -e ADVOCU_CLIENT_SECRET=your-secret-here olegselajev241/mcp-advocu:stdio

will run the MCP server with tools that expose information about Docker Captains, allowing MCP clients to search through their submitted activities. 

Figure 4

However, sharing the actual agent, and especially the configuration required to run it, was a bit awkward. 

cagent solved this for me in a much neater way. Here is the complete cagent.yaml for my Advocu agent:

YAML

#!/usr/bin/env cagent run
version: "2"

agents:
  root:
    model: anthropic/claude-sonnet-4-0
    description: Agent to help with finding information on Docker Captains and their recent contributions to Docker
    toolsets:
      - type: mcp
        command: docker
        args:
          - run
          - -i
          - --rm
          - --env-file
          - ./.env
          - olegselajev241/mcp-advocu:stdio
    instruction: You have access to Advocu - a platform where Docker Captains log their contributions. You can use tools to query and process that information about captains themselves, and their activities like articles, videos, and conference sessions. You help the user to find relevant information and to connect to the captains by topic expertise, countries, and so on. And to have a hand on the pulse of their contributions, so you can summarize them or answer questions about activities and their content

With this file, we have a powerful, personalized assistant that can query Captain info, summarize their contributions, and find experts by topic. It’s a perfect example of how cagent can automate a specific internal workflow.

Users simply need to create a .env file with the appropriate secret. Even for less technical team members, I can give a shell one-liner to get them set up quickly. 

Now, everyone at Docker can ask questions about Docker captains without pinging the person running the program (hi, Eva!) or digging through giant spreadsheets. 

Figure 5

I’m also excited about the upcoming cagent 1Password integration, which will simplify the setup even more.  

All in all, agents are really just a combination of:

• A system prompt
• An integration with a model (ideally, the most efficient one that gets the job done)
• And the right tools via MCP
  

With cagent, it’s incredibly easy to manage all three in a clean, Docker – native way. 

Get Started Today!

cagent empowers you to build your own fleet of AI assistants, tailored to your exact needs.

It’s a tool designed for developers who want to leverage the power of AI without getting bogged down in complexity.

You can get started right now by heading over to the cagent GitHub repository. Download the latest release and start building your first agent in minutes. 

Give the repository a star, try it out, and let us know what amazing agents you build!

Meta is going to let apps access the vision and audio capabilities of its smart glasses thanks to a new Wearable Device Access Toolkit for developers.

“Our first version of the toolkit will open up access to a suite of on-device sensors— empowering you to start building features within your mobile apps that leverage the hands-free benefits of AI glasses,” Meta says. “With our toolkit, you’ll be able to leverage the natural perspective of the wearer and the clarity of open-ear audio and mic access.”

The company has highlighted a few examples of how early testers are thinking about the toolkit: Twitch will let creators livestream from their glasses, and Disney’s Imagineering R&D team is working on prototypes to let people visiting Disney parks access tips while they’re wearing Meta’s smart glasses, according to a blog post.

It seems like this toolkit is super early, though. Developers can now get on a waitlist to be notified when a preview of the toolkit is available later this year. Actually publishing experiences that use the toolkit will “be available to limited audiences in the preview phase,” Meta says, and the company notes in an FAQ that it expects that general availability of publishing won’t be available until 2026. But given how popular the Ray-Ban Meta glasses have been and how promising Meta’s new smart glasses with a display seem, there could be a lot of appetite from developers to try this toolkit out.