Automation · PiniShv

Claude Can Now Use Your Computer. Here's What That Actually Means.

Mon, 23 Mar 2026 14:00:00 +0200

Anthropic shipped computer use for Claude today. Not as a demo. Not as a research paper. As a feature in Claude Cowork and Claude Code, available right now for Pro and Max subscribers.

When Claude doesn’t have a direct integration for something you ask it to do, it falls back to controlling your computer like a human would. It uses the screen to navigate. It can click, scroll, open files, use the browser, and run dev tools. No setup required. It just looks at what’s on your screen and figures out how to get the task done.

This is the jump from “AI that talks about doing things” to “AI that does things.”

How it works
#

Claude reaches for the most precise tool first. If you ask it to check your calendar, it uses the Google Calendar connector. If you ask it to send a Slack message, it uses the Slack integration. But when there’s no connector for what you need, Claude controls your mouse, keyboard, and browser directly.

The permission model is explicit. Claude asks before it touches a new application. You can stop it at any point. Some apps are off-limits by default. Anthropic built in safeguards against prompt injection, automatically scanning model activations during computer use to detect adversarial behavior.

Anthropic is upfront about the limitations. Computer use is early. Claude makes mistakes. Complex tasks sometimes need a second try. Screen-based operations are slower than direct API integrations. They’re releasing it as a research preview specifically to learn where it works and where it falls short.

Mac only for now. No Windows, no Linux.

Dispatch makes this actually useful
#

Computer use by itself is interesting. Paired with Dispatch, it becomes practical.

Dispatch shipped last week. It creates a persistent conversation between the Claude mobile app and your desktop. You assign Claude a task from your phone, turn your attention to something else, then open the finished work on your computer.

With computer use, Dispatch becomes a remote control for your Mac. You’re on the train and tell Claude to pull this morning’s metrics and prepare a briefing. You’re in a meeting and tell Claude to make changes in your IDE, run tests, and put up a PR. You’re away from your desk and tell Claude to keep a long-running task moving.

The combination is the interesting part. Computer use gives Claude hands. Dispatch gives you the ability to direct those hands from anywhere.

For developers specifically
#

Anthropic is positioning this heavily toward developers, and it makes sense. Claude can now make changes inside an IDE, submit pull requests, run tests, and navigate development tools autonomously. If you’re already using Claude Code, computer use extends what the agent can reach. Instead of being limited to the terminal and file system, it can interact with any GUI application.

That said, this overlaps with what Cursor Automations does differently. Cursor triggers agents from events (Git pushes, Slack messages, PagerDuty alerts) and runs them in cloud sandboxes. Claude’s computer use runs on your actual machine, which means it has access to everything you have access to. More capability, more risk.

The security implications are obvious. An AI agent with access to your screen, keyboard, and browser is a powerful tool and a significant attack surface. Prompt injection against a computer-controlling agent is a different threat than prompt injection against a chat model. Anthropic says they’re scanning for it, but they also say not to expose sensitive data during the preview.

The bigger picture
#

Every major AI company is racing toward the same destination: AI that doesn’t just generate text but actually operates computers. OpenAI and Google are both working on similar capabilities. Anthropic got here first with a shipped product, even if it’s early.

I’ve been writing about AI agents moving from toys to tools for a while. Computer use is a clear step in that direction. The agent doesn’t need a purpose-built integration for every app. It can use the same interface you use. That dramatically expands what an agent can do without requiring every software vendor to build an API or MCP connector.

But it also means the agent inherits all the messiness of GUI-based interaction. Screens change. Buttons move. Modals pop up unexpectedly. The reliability of screen-based control will always be lower than API-based integration. Anthropic knows this, which is why Claude prefers connectors when they’re available and falls back to computer use only when needed.

The honest framing: this is a research preview. It will be unreliable for complex workflows. It will get better fast. And in six months, we’ll look back at this as the moment AI assistants stopped being confined to chat windows.

The question isn’t whether AI will control computers. It’s how fast the reliability curve catches up to the ambition.

Trying Claude’s computer use or Dispatch? I’d love to hear what tasks you’re assigning and how it handles them. Find me on X or Telegram.

Cursor Automations: Your AI Just Stopped Waiting for Permission

Mon, 23 Mar 2026 09:00:00 +0200

I wrote last year that the developer’s work didn’t change, the sequence did. AI moved context gathering and scaffolding earlier. You opened your laptop to a draft instead of a blank file.

On March 5, Cursor moved the sequence again. Automations lets AI agents trigger without you prompting them. A Slack message, a Git push, a PagerDuty alert, a cron timer. The agent spins up a cloud sandbox, follows instructions you’ve defined, uses your configured MCPs and models, and reports back via PR, Slack, or ticket.

No human in the prompt loop. That’s a different category of tool.

What it actually does
#

Three trigger types: scheduled timers (hourly, nightly, weekly), external signals (Slack, Linear, PagerDuty, GitHub webhooks), and code events (new PRs, branch pushes, test failures).

Cursor is already using this internally. Security reviews on every code push. Risk classification that auto-approves low-risk PRs. Incident response kicked off by PagerDuty alerts. Weekly repo change summaries. Bug report triage. Test coverage identification.

The agents also have a memory tool that lets them learn from past runs. So the security review agent that ran on Monday remembers context when it runs on Friday.

This isn’t an assistant waiting for your question. It’s a coworker that works a different shift.

How the others compare
#

GitHub Copilot’s coding agent is the closest competitor. It already handles tasks end-to-end: assign an issue, the agent works autonomously, opens a PR. As of March 2026, agent hooks are in public preview, letting you run custom commands at key points during agent sessions. It also reviews its own changes before opening PRs and runs security scanning automatically. The big advantage is distribution: it lives where most teams already work (GitHub, VS Code, JetBrains). The limitation is that event triggers are still more constrained than Cursor’s broad webhook and Slack integration.

Claude Code is Anthropic’s terminal-based agent. It manages files, Git, shell commands, and tests independently of any IDE. Powerful for deep, autonomous coding sessions. But it doesn’t have event-driven triggers yet. You start it, it works, it finishes. There’s no “trigger Claude Code when a PagerDuty alert fires.” That gap will likely close, but right now it’s a different paradigm: on-demand autonomy versus always-on automation.

JetBrains Air launched the same month as an agentic development environment. It orchestrates multiple agents (Codex, Claude, Gemini, Junie) running in parallel in isolated containers. It’s the closest thing to “mission control for agents.” But it’s focused on delegating tasks and monitoring progress, not on event-driven automation. You still tell Air what to do. Cursor Automations lets the system tell the agent what to do.

Amazon Q doesn’t have event-driven features yet, but analysts expect an announcement soon. Given AWS’s strength in event-driven architecture (Lambda, EventBridge, Step Functions), their version could be interesting when it arrives.

Why this matters
#

The shift from “I prompt the AI” to “the system triggers the AI” changes the organizational model for engineering teams. Security reviews can happen on every push without a human bottleneck. Triage can happen before anyone looks at their morning tickets. Maintenance tasks can run on a schedule nobody has to remember.

But it also means more code being generated and committed with less human involvement per change. If your team is already struggling with understanding what shipped (and the data suggests many are), autonomous agents running on triggers will accelerate that gap.

The teams that will get the most out of this are the ones with strong guardrails already in place: good CI, real tests, meaningful review standards, and engineers who understand the systems well enough to evaluate what the agent produced. The teams that will get burned are the ones hoping automation replaces the discipline they never built.

Cursor crossed $2 billion in annual revenue in about 18 months, roughly 20x faster than GitHub Copilot reached $100 million ARR. That’s not just hype. Engineers are voting with their wallets. Automations is the bet that the next step isn’t a better copilot. It’s an always-on agent layer that treats your codebase as a continuously monitored system.

The sequence changed again. The question is whether your engineering practices changed with it.

Using Cursor Automations or building event-driven agent workflows? I’d love to hear what triggers you’re running. Find me on X or Telegram.

OpenClaw Is Not a Chatbot. It's a Personal Agent Gateway.

Thu, 19 Mar 2026 14:00:00 +0200

Think about how you use AI right now.

You open a browser tab. You go to ChatGPT or Claude. You type something. You get a response. You close the tab. Tomorrow you open it again and start from scratch. Maybe you remember to use Projects. Maybe you don’t.

Now think about how you communicate with your actual team. WhatsApp. Telegram. Slack. Discord. You don’t open a special app to talk to people. You message them wherever you already are, and the conversation continues across devices and time zones.

OpenClaw is built on a simple bet: your AI assistant should work the same way. Not in a browser tab. In the places you already are. Always on, always reachable, always remembering what you talked about yesterday.

That sounds like a small UX difference. It’s not. It changes what an AI assistant can actually do for you.

What OpenClaw actually is
#

Let me be clear about what this is and what it isn’t. The project’s own FAQ is blunt: it is not “just a Claude wrapper.”

OpenClaw is a self-hosted gateway that connects AI agents to your messaging channels. WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, WebChat. Plus a browser Control UI and companion apps for macOS, iOS, and Android.

The GitHub repo has roughly 325k stars, which makes it one of the largest open-source AI projects out there. But the star count isn’t the interesting part. The interesting part is the architecture.

The Gateway is the single source of truth for sessions, routing, and channel connections. It embeds the Pi SDK directly instead of shelling out to a subprocess, which lets it inject custom tools, tune prompts by context, persist sessions, rotate auth profiles, and switch model providers on the fly. On top of that, ACP (Agent Communication Protocol) lets it hand work off to external coding-agent runtimes when that makes more sense.

In plain English: OpenClaw is not one model with one UI. It’s a routing and orchestration layer that sits above models, tools, channels, and state. The assistant is the product. The Gateway is the infrastructure.

Why this is different from browser-based AI
#

I wrote about Open WebUI recently. Open WebUI moves the AI interface from a vendor’s SaaS into your own self-hosted browser workspace. That’s valuable. But OpenClaw takes a different bet entirely.

Open WebUI says: “The browser is the right interface. You just shouldn’t rent it from OpenAI.”

OpenClaw says: “The browser isn’t the right interface at all.”

That’s a much bolder claim. And honestly, when you think about how people actually interact with technology throughout the day, it makes sense. You’re not sitting in front of a browser all day. You’re in WhatsApp with your family and friends, in Slack with your org, in Telegram with your communities. The browser tab is where you go when you have a dedicated task. Messaging is where you live.

An AI assistant that lives in your messaging layer can do things a browser tab can’t. It can remind you about something at 3pm without you opening an app. It can respond in a group chat where multiple people are coordinating. It can wake up on a schedule and check something for you. It’s persistent in a way that a browser session never is.

What it can actually do
#

The capability surface is broader than “AI in WhatsApp.” Five things matter.

It lives where you are. WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage. You message it like you’d message a person. It responds in the same channel. It works across devices because the Gateway is always running.

It can switch models on the fly. The docs list 35+ providers: Anthropic, OpenAI, Google, OpenRouter, Ollama, vLLM, and any OpenAI-compatible or Anthropic-compatible endpoint. You can route different conversations to different models. Need a quick answer? Local model. Need deep reasoning? Claude. Same conversation thread, different backends.

It can do things, not just answer questions. The tool inventory includes command execution, browser automation, web search, image and PDF handling, cron jobs, and device node controls. The distinction between cron jobs and heartbeat turns is important: it can both run scheduled tasks and periodically wake itself up to surface something relevant. This isn’t autocomplete. This is an agent with hands.

It remembers. Memory is Markdown files in the workspace. Daily logs in memory/YYYY-MM-DD.md, curated long-term memory in MEMORY.md, exposed through memory_search and memory_get. Sessions can be isolated per agent, workspace, peer, or channel. The fact that memory is plain files you can inspect and edit is philosophically consistent with the local-first story and way more transparent than the hidden memory layers in ChatGPT or Claude.

It can extend itself. ClawHub is the public skill registry. Skills are instruction bundles built around SKILL.md files, while tools are typed capabilities the agent gets to use. Discover, install, publish, version, update. The extension model feels like package management for agent capabilities.

How people actually use it
#

The official showcase clusters around patterns that tell you exactly what OpenClaw is good for.

Browser automation without APIs. PR review feedback delivered in Telegram. School meal and grocery ordering. Accounting intake from emailed PDFs. Slack auto-support. Infrastructure and deployment work. Health assistants. 3D printer and home automation. Voice bridges. One person built and shipped an iOS app from Telegram.

The center of gravity is not generic Q&A. It’s persistent coordination across personal and work systems.

Independent anecdotes on Hacker News point the same direction. One user described using OpenClaw to recover and rebuild a media server, diagnose drive failure, and migrate 1.5TB of data. Another said it became a useful participant in a group chat, tracking personalities and helping the group plan together. These are anecdotes, not benchmarks. But they align: the real appeal is infrastructure, automation, and ongoing conversational context.

The hard truth about running it
#

Here’s where I need to be honest, because the community is tired of puff pieces about OpenClaw and so am I.

Setup is real work. Node, API keys, permissions, channel configurations, operational judgment. This is not “download an app and start chatting.” It’s closer to setting up a production service. The people who love OpenClaw are comfortable with that. The people who bounce off it were expecting something simpler.

Local-only is possible but expensive. The docs are unusually blunt about this. OpenClaw expects large context windows and strong prompt-injection resistance. It recommends the strongest latest-generation model available. Serious local setups may require hardware on the level of multiple maxed-out Mac Studios or equivalent GPU rigs. That’s a big reality check against the “runs privately on my old laptop” narrative.

Token costs can surprise you. Users report it’s easy to accidentally create expensive workflows, especially with naive model defaults. An always-on assistant that wakes up on schedules and processes conversations across multiple channels burns tokens constantly. Without cost controls, your monthly bill can go places you didn’t expect.

The security model is honest but limited. The supported posture is one trusted operator boundary per gateway. This is not hostile multi-tenant isolation. OpenClaw ships a security audit CLI, publishes a MITRE ATLAS-based threat model with 37 identified threats (6 critical), and added VirusTotal scanning for published skills. A high-severity CVE was patched in February 2026. The project is actively fixing real vulnerabilities, which is a good sign. But the docs are explicit that none of this makes the system “secure in all respects.”

Skills are code running in your agent’s context. This is the deepest concern. Skills have access to tools and data. The project’s own security documentation explicitly lists risks: exfiltration, unauthorized commands, sending messages on your behalf, downloading external payloads. You are not installing a chatbot. You are delegating action to an always-on agent with real permissions. Treat it accordingly.

Who’s behind it
#

Peter Steinberger is the creator. The project credits Mario Zechner as the creator of Pi (the underlying agent framework) and names several core contributors. It’s MIT licensed.

There’s an interesting governance story here. Steinberger’s blog says he joined OpenAI on February 14, 2026, and that OpenClaw would move to a foundation while remaining open and independent. I found the announcement but not enough public material to treat the foundation transition as fully completed. Worth watching.

The naming history is also telling. The project went through multiple names. Anthropic asked them to reconsider the earlier “Clawd” branding. It went through “Moltbot” before landing on “OpenClaw.” That chaotic evolution says something about how fast this space moves and how young the project still is, despite its star count.

How it compares to the incumbents
#

Versus ChatGPT. ChatGPT gives you a polished hosted product with Projects, scheduled Tasks, and MCP-based custom apps. OpenClaw gives you self-hosting, provider neutrality, and an assistant that lives in your own messaging channels instead of OpenAI’s browser product. ChatGPT wins on zero-ops convenience. OpenClaw wins on control and communication surface.

Versus Claude. Claude now bundles Projects, Artifacts, Research, and Skills inside Anthropic’s managed environment. That makes it the best native Claude experience. OpenClaw is interesting when you want Claude-level intelligence inside your own channels and control plane rather than inside Anthropic’s product. Different layer, different bet.

Versus Gemini. Gemini’s advantage is ecosystem gravity. Deep Research across Search, Gmail, Drive, NotebookLM. OpenClaw’s advantage is ecosystem neutrality. It sits above many providers and your own devices instead of locking the assistant layer to Google.

How it compares to open-source alternatives
#

OpenClaw spans two categories that are usually separate, which makes direct comparisons tricky.

Open WebUI and LibreChat are stronger as self-hosted browser-based AI workspaces. They unify providers, support agents and MCP, and feel like replacements for the mainstream chat products. OpenClaw’s bet is different: move the assistant out of the browser entirely and into your messaging stack, with an always-on gateway and device nodes.

n8n sits on the other flank as an automation platform. Stronger for deterministic workflows, visual orchestration, and integration breadth. OpenClaw is stronger when you want a persistent assistant you can casually message, with memory, channel presence, and agent-like coordination. n8n automates flows. OpenClaw tries to become the thing you talk to.

What this means
#

The broader pattern is the same one I see across AI tooling right now. The model layer is commoditizing. The interface layer is where the real fight happens. And the interface layer is splitting into at least three bets:

Vendor-hosted SaaS (ChatGPT, Claude, Gemini). Maximum convenience, minimum control. The default for most teams today.

Self-hosted browser workspaces (Open WebUI, LibreChat). Same browser paradigm, but you own it. The infrastructure play.

Communication-layer agents (OpenClaw). Not a workspace at all. An assistant that lives where you already are. The most radical bet.

OpenClaw is the most ambitious of the three. It’s also the highest-maintenance, the highest-risk, and the one that requires the most trust. You’re not just self-hosting a UI. You’re running an always-on agent with real permissions inside your real communication channels.

For power users and tinkerers who are comfortable with that, OpenClaw is one of the most interesting projects in the AI space right now. For everyone else, it’s worth understanding as a signal of where AI assistants are heading. Even if you never install it, the question it raises is the right one: why does your AI assistant live in a browser tab when you don’t?

Running personal AI agents? Tried OpenClaw or something similar? I’d love to hear your setup. Find me on X or Telegram.

CLI Agent Orchestrator: When One AI Agent Isn't Enough

Wed, 05 Nov 2025 00:00:00 +0000

You’ve hit this wall before. You’re working on some complex modernization project with Claude Code or Amazon Q Developer CLI, and the agent starts losing coherence. Too much context. Too many domains. Architecture bleeding into security bleeding into performance optimization. The agent can’t maintain focus.

Your options have been to manually coordinate between separate agent sessions, copying context around like it’s 2010. Or overload one agent with everything and watch quality degrade as the context window fills up.

AWS to the rescue; they just released CLI Agent Orchestrator (CAO): multiple specialized agents working together under a supervisor. Hierarchical orchestration for your AI CLI tools.

It’s early, opinionated, and requires AWS infrastructure. But it shows where developer AI tooling is headed when single agents aren’t enough.

The Problem
#

Single agents work great for focused tasks. Refactoring? Boilerplate? Debugging? Claude Code or Amazon Q handles it.

But try modernizing a legacy mainframe application. Architecture design, security review, performance optimization, testing, data migration. That’s a project spanning multiple disciplines. Load all that context into one agent and watch quality degrade. The agent contradicts itself, forgets earlier decisions, outputs get generic.

The alternative is running separate agents manually. One for architecture. Another for security. Another for performance. Now you’re copying context between them, manually synthesizing outputs, spending more time coordinating than working. You’ve become the orchestration layer.

CAO is AWS’s answer: a supervisor agent manages specialized workers. Each focuses on its domain. The supervisor handles coordination. Configure the team once, let them collaborate.

How It Works
#

A supervisor agent delegates to specialized workers. One for architecture. One for security. One for performance. The supervisor manages sequencing and maintains context. Workers focus on their specialty and report back.

Each agent runs in its own isolated tmux session. No context pollution. The architecture agent’s history doesn’t leak into the security agent’s work. Sessions communicate through Model Context Protocol (MCP) servers, which handle local communication between the isolated sessions, running entirely on your machine.

CAO supports three patterns. Handoff (synchronous): supervisor waits for completion before proceeding. Assign (asynchronous): supervisor delegates and moves on. Send Message: supervisor checks status without blocking. All implemented through Amazon Bedrock action groups.

Example: Mainframe Modernization
#

The supervisor receives “Create a modernization plan for this COBOL banking system.” It hands off sequentially: architecture agent designs the structure, security agent reviews it, then performance and test agents work in parallel. The supervisor synthesizes outputs into a unified plan.

You could apply this to building microservices applications or migrating monoliths. In practice, you’ll iterate on prompts and intervene when agents drift. But the pattern works when configured well.

The Reality Check
#

CAO only works with Amazon Q Developer CLI and Claude Code. Nothing else has shipped despite “future plans” for other tools.

The supervisor runs on Amazon Bedrock, AWS’s managed service for foundation models. You need AWS credentials, Bedrock access, and an AWS account. It’s open source code you can’t run without AWS infrastructure. This is lock-in you should choose consciously.

Everything runs in tmux sessions. Great for transparency, but it’s another dependency with a learning curve. Running this in CI/CD adds complexity.

Multiple agents mean multiple API calls, more token usage, higher latency. For simple tasks, this is wasteful overkill. You need to be selective about when orchestration overhead is worth it.

This is infrastructure for developers comfortable with AWS, tmux, and orchestration concepts. It’s not polished. Limited early reactions on social media praise the privacy focus but flag AWS lock-in and tmux hurdles as barriers to adoption.

Why It Matters
#

The interesting part isn’t CAO specifically. It’s the shift from “AI tool as standalone assistant” to “AI tools as orchestrated teams.”

Single-agent tools hit walls. Context windows don’t solve everything. At some point, more context just means more noise. Multi-agent architectures divide cognitive labor. Each agent has a focused job. The supervisor ensures pieces fit together.

We’re seeing this everywhere. OpenAI’s Swarm. LangGraph. CrewAI. AutoGPT. The underlying idea is the same: complex tasks need coordination, not just more context. Specialization plus orchestration beats generalization with bigger context windows.

The question: does this remain infrastructure developers explicitly configure, or does it become invisible? CAO is clearly “you configure this.” But the long-term direction is probably toward tools that orchestrate automatically, with developers intervening only when defaults fail.

Getting Started
#

If you want to experiment with CAO:

You need an AWS account with Bedrock access and permissions to use Claude models. Install Amazon Q Developer CLI or Claude Code. Install tmux (brew install tmux on macOS). Clone the repo: git clone https://github.com/awslabs/cli-agent-orchestrator. The README has configuration examples and workflows.

Realistically, plan to spend an afternoon getting this working. This isn’t a tool you spin up in 10 minutes.

Should You Use This?
#

Use CAO if you’re handling complex, multi-disciplinary tasks where single agents struggle. If you’re already on AWS and Bedrock, integration is straightforward. You need comfort with tmux and orchestration concepts.

Skip it if your tasks are straightforward. If you’re not on AWS or want to avoid lock-in, skip it. If you need something polished, this isn’t it.

For most developers, single-agent tools remain the right choice. For teams tackling large-scale modernizations or complex migrations, CAO offers a pattern worth exploring.

Check out the GitHub repository and the AWS blog post.

The future of AI tooling is coordination, not just capability. CAO is AWS’s bet on how that works. Whether it becomes standard or just one experiment, the pattern it represents is where things are headed.

AI Agents for Real Productivity: What Works in 2025

Thu, 02 Oct 2025 00:00:00 +0000

The promise of AI agents is everywhere: autonomous assistants that handle your busywork, orchestrate complex workflows, and give you back hours of your day. The reality is messier.

Most AI agent demos look impressive until you try to use them for actual work. They either do too little (fancy chatbots with extra steps) or try to do too much (autonomous chaos that breaks things in creative ways).

But between the hype and the disappointment, there’s a middle ground that actually works. AI agents you build yourself, focused on specific problems, constrained by proper guardrails, and integrated into your real workflow.

This isn’t about building the next big AI product. This is about understanding what actually works so you can make smart decisions about where to invest time and resources.

What makes an agent different from a chatbot
#

The terminology is confusing because vendors use “agent” to describe everything from glorified autocomplete to autonomous systems that make irreversible decisions.

Here’s the practical distinction that matters:

A chatbot responds. You ask a question, it answers. The conversation ends. If you want something different, you ask again.

An agent decides and acts. You give it a goal, and it figures out the steps: what information it needs, what tools to use, what order to execute things in. It makes decisions dynamically based on what it learns along the way.

The key difference is agency: the ability to use tools, make decisions, and adapt based on results.

Example: You tell a chatbot “check if our API is healthy.” It might tell you how to check. An agent would actually call your monitoring API, parse the results, identify any issues, check the error logs for those specific issues, and give you a diagnosis.

That’s powerful. It’s also where things get dangerous if you build without thinking through the consequences.

Where agents actually help (and where they don’t)
#

After months of experimenting with agents for real work, I’ve seen clear patterns emerge about what succeeds and what fails.

Agents work well for:

Repetitive information gathering across multiple systems. The kind of task where you need to check five different places, correlate the data, and synthesize an answer. Agents excel at this because they don’t get bored and they’re consistent.

Example: “Analyze the last production incident - check the error logs, look at the related code changes, find similar past incidents, and summarize what happened and why.” That’s four different data sources (logs, Git, incident database, codebase) that need to be queried and connected. An agent handles it in one shot.

Workflow orchestration with clear decision points. Tasks with branching logic that depends on results. If X happens, do Y. If not, do Z. Agents can follow these flows without you manually steering each step.

Example: A code review assistant that checks style, runs security scans, looks for common anti-patterns specific to your codebase, and only escalates to human review if it finds something it can’t handle. The logic is clear, the boundaries are defined.

Data analysis and reporting. When you need to query data, transform it, apply business logic, and generate insights. As long as the queries are read-only and the logic is sound, agents can do this repeatedly without fatigue or errors.

Example: Weekly customer health reports that pull data from your database, your support system, and your usage analytics, then generate a summary with trend analysis and flagged accounts. That’s several hours of manual work that an agent can do in minutes.

Agents struggle with:

Ambiguous goals without clear success criteria. If you can’t define what “done” looks like in concrete terms, the agent will wander. Agents need specific targets.

High-stakes decisions without human oversight. Letting an agent autonomously make decisions that cost money, delete data, or affect customers is asking for trouble. Always put humans in the loop for irreversible actions.

Creative work that requires taste and judgment. Agents can generate options, but they can’t tell you which design feels right, which message resonates with your audience, or which technical trade-off aligns with your product strategy. That’s still your job.

Novel problems they haven’t seen before. Agents work best within known patterns. When they encounter something truly new, they guess, and those guesses can be confidently wrong.

The agent landscape in 2025: what’s actually worth using
#

The market has exploded with agent platforms, frameworks, and tools. Some are genuinely useful. Many are solutions looking for problems. Here’s what matters for builders.

Cloud platforms: fast to start, limited control
#

OpenAI Agents SDK (GitHub) is the easiest path to a working agent if you’re already in the OpenAI ecosystem. The Responses API handles multi-step workflows, and the Agents SDK adds tool calling, file handling, and web search. You can connect it to your systems through MCP (Model Context Protocol).

What’s good: Fast iteration. Strong model quality. Built-in safety controls. Web search and computer use features that let agents interact with browser interfaces.

What’s limited: You’re locked into OpenAI’s infrastructure. Cost control requires discipline. Less flexibility than open-source approaches.

When to use it: Rapid prototyping, proof of concepts, or production systems where convenience matters more than control.

Microsoft’s agent stack spans multiple products: (Azure AI Foundry Agent Service) for managed runtime, (Copilot Studio) for low-code multi-agent orchestration, and Semantic Kernel (GitHub) for custom development.

What’s good: Deep integration with Microsoft 365 and Azure. Enterprise governance and security built in. Computer use for automating legacy systems without APIs.

What’s limited: Complex product surface area. Licensing can get expensive. Best fit if you’re already Microsoft-heavy.

When to use it: You’re a Microsoft shop and need agents integrated with Teams, Office, or Azure services.

AWS Bedrock Agents (docs) with Guardrails for safety, plus the open-source Strands orchestration framework for multi-agent coordination.

What’s good: Scales naturally with AWS infrastructure. Strong security posture. Guardrails for Bedrock give you programmable safety controls.

What’s limited: Setup complexity is higher than other platforms. Service-specific features create lock-in.

When to use it: You’re AWS-first and want agents that integrate tightly with your existing cloud stack.

Google Vertex AI Agent Builder (docs) includes the Agent Development Kit (ADK), Agent Engine for managed runtime, and Memory Bank for stateful conversations.

What’s good: Built-in tools for code execution, search, and data access. Agent-to-agent (A2A) protocol for complex orchestrations. Strong if you’re GCP-native.

What’s limited: Newer than competitors, so some features are still in preview. Best value comes from using it with other Google Cloud services.

When to use it: You’re on GCP and need agents that work naturally with BigQuery, Cloud Storage, and other Google services.

Salesforce Agentforce (announcement) is purpose-built for customer-facing workflows. If your work lives in Salesforce CRM, Sales, or Service Cloud, Agentforce gives you pre-built templates and deep integration.

What’s good: Fast deployment for GTM and customer service use cases. Native to the Salesforce ecosystem. API and mobile SDK for custom development.

What’s limited: Best value comes from using it within Salesforce. Less general-purpose than other platforms.

When to use it: You’re a Salesforce shop and need agents for customer operations, sales workflows, or service automation.

Databricks Agent Bricks (docs) is optimized for data and analytics teams. It’s tightly integrated with Unity Catalog, MLflow, and the lakehouse architecture.

What’s good: Natural fit for data-centric agents. Strong evaluation and serving infrastructure. Enterprise governance built in.

What’s limited: Best suited for organizations already on Databricks. Less general-purpose than other frameworks.

When to use it: You’re building data or analytics agents on a lakehouse architecture.

Open-source frameworks: maximum flexibility, you run the infrastructure
#

LangGraph (GitHub) is the current leader in open-source agent orchestration. It’s built on LangChain but designed specifically for stateful, graph-based agent workflows.

What’s good: True control over behavior. Graph-based execution lets you see and debug agent reasoning. Built-in persistence, retries, and human-in-the-loop patterns. Huge ecosystem of integrations. Works with any LLM.

What’s limited: You manage the infrastructure. Steeper learning curve than managed platforms. You’re responsible for safety and guardrails.

When to use it: You need maximum flexibility, want to avoid vendor lock-in, or have requirements that managed platforms can’t meet.

LlamaIndex (GitHub) focuses on data-centric agents. If your agent needs to work with documents, databases, and complex data sources, LlamaIndex has the deepest RAG (retrieval-augmented generation) tooling.

What’s good: Excellent data connectors. AgentWorkflows for multi-agent patterns. Strong at combining structured and unstructured data.

What’s limited: Narrower focus than general-purpose frameworks. Best suited for data and knowledge work.

When to use it: Your agents primarily work with documents, databases, and knowledge bases.

CrewAI (GitHub) is opinionated about multi-agent teams. You define roles, assign skills, and CrewAI orchestrates collaboration between agents.

What’s good: Simple mental model. Fast growing community. Good for scenarios where you want specialized agents working together.

What’s limited: Less low-level control than LangGraph. Opinionated design means you work within its patterns.

When to use it: You want team-of-agents patterns without building orchestration from scratch.

Haystack (GitHub) from deepset is production-grade RAG plus agents. It’s mature, well-documented, and has clear patterns for evaluation and deployment.

What’s good: Battle-tested in production. Pipeline model is easy to reason about. Good observability and eval integration.

What’s limited: Less flexible than LangGraph for complex agent behaviors. Optimized for RAG-heavy workflows.

When to use it: You need production-ready RAG with agent capabilities, and you value stability over cutting-edge features.

Safety and observability: the unsexy stuff that matters
#

NVIDIA NeMo Guardrails (GitHub) is the most programmable safety layer. It works across different stacks and lets you define explicit policies for what agents can and can’t do.

Why this matters: Agents without guardrails will eventually do something you didn’t intend. NeMo lets you prevent that proactively with code, not hope.

LangSmith (site), Arize Phoenix (GitHub), and Weights & Biases Weave (docs) give you observability into what your agents are actually doing. Trace every step, see every tool call, measure quality and cost.

Why this matters: Agents are black boxes without instrumentation. When something goes wrong (and it will), you need to see exactly what happened. When costs spike, you need to know why.

Making the right choice for your situation
#

The landscape is crowded, but the decision framework is straightforward.

If you’re already invested in a cloud ecosystem:

Go with your cloud provider’s agent platform. The integration is easier, the security model aligns with your existing setup, and you leverage investments you’ve already made.

Microsoft 365/Azure heavy → Microsoft’s agent stack
AWS infrastructure → Bedrock Agents with Guardrails
GCP and BigQuery → Vertex AI Agent Builder
Salesforce for GTM → Agentforce
Databricks lakehouse → Agent Bricks

If you need maximum flexibility and control:

Start with LangGraph. It’s the most mature open-source orchestration framework with the largest ecosystem. Add LlamaIndex for data-intensive work, NeMo Guardrails for safety, and LangSmith for observability.

If you want to move fast with minimal setup:

OpenAI Agents SDK gets you running quickest. Strong defaults, good documentation, integrated tools. Accept the vendor lock-in as the trade-off for speed.

If you’re in a regulated industry or have strict compliance needs:

Microsoft’s agent stack or AWS Bedrock give you the enterprise controls and audit trails you’ll need. NVIDIA NeMo Guardrails works across platforms if you need programmable safety.

What matters more than the platform
#

The platform choice matters less than these fundamentals:

Clear problem definition. Vague goals produce vague results. Agents need specific, measurable success criteria.

Proper guardrails from day one. Safety isn’t something you add later. Build it in from the start.

Observability and measurement. You can’t improve what you can’t see. Instrument everything.

Realistic expectations. Agents augment human judgment, they don’t replace it. The best results come from thoughtful human-agent collaboration.

Iterative refinement. Your first agent won’t be great. That’s fine. Build, test, learn, improve.

For engineering leaders: the strategic opportunity
#

If you lead a team or organization, AI agents represent more than a productivity tool. They’re a forcing function for operational clarity.

The immediate play: Teams with well-designed agents handle more work with the same headcount, or maintain output with less burnout. The productivity gains are real and measurable.

The deeper value: Building agents forces you to clarify processes, document decisions, and standardize workflows. That organizational clarity compounds beyond just the agents themselves.

The investment thesis: Start small with focused agents solving specific problems. Build expertise through real use. Expand as you learn what works in your specific context.

The approach that works: Don’t mandate top-down. Let teams build agents for their own pain points. Provide infrastructure, guidelines, and shared learnings. The best agents emerge from people solving their own problems.

The risks to watch: Agents without guardrails. Agents without observability. Agents that automate broken processes. Teams that become dependent without understanding the underlying work.

The goal: Leveraged productivity, not maximum automation. Free your team from repetitive cognitive work so they can focus on problems requiring judgment, creativity, and expertise.

For developers: why this matters to your career
#

Building agents isn’t specialist knowledge. It’s becoming table stakes for productive developers.

The skill combination that’s valuable: Understanding both AI capabilities and production systems. How to give AI the right context without compromising security. How to design integrations that teams actually use.

What’s valuable right now:

Using existing agent frameworks effectively
Building focused agents for specific workflows
Implementing proper security and guardrails
Designing integrations that scale

What becomes more valuable:

Deep expertise in agent orchestration patterns
Domain-specific integration knowledge
Platform-level thinking about AI-system connections
Security and compliance for AI integrations

The trajectory: Developers who can build reliable agents that solve real problems are differentiating themselves. Not because it’s exotic, but because it’s practical infrastructure work that delivers measurable value.

What separates success from expensive failure
#

Most AI agent projects fail. Not because the technology isn’t ready, but because teams skip fundamentals.

They build before understanding the problem. They automate before adding guardrails. They deploy before instrumenting. They scale before validating.

The agents that work share common traits:

Focused on specific, well-defined problems
Built with clear boundaries and safety controls
Instrumented from day one with proper observability
Validated with real use before broad deployment
Maintained and improved based on actual usage patterns

The discipline required is higher than traditional development. Agents make autonomous decisions. Mistakes compound. Poor judgment scales. You need to be more thoughtful, not less.

But when done right, the leverage is real. Work that took hours happens in minutes. Repetitive cognitive tasks disappear. Context gathering becomes automatic. Teams handle more complexity with less stress.

Where to start
#

Understanding the landscape is step one. Building something real is step two.

In my next article, I’ll walk through the practical steps: picking the right first problem, setting up your tools, building a working agent in a week, and deploying it to your team. The tactical guide to actually shipping.

For now, the strategic takeaway is clear: AI agents work when they’re focused, bounded, and built for specific workflows. The platform matters less than the approach.

The teams winning with agents aren’t the ones with the best strategy. They’re the ones who started experimenting months ago and never stopped learning.

Start small. Build focused. Measure ruthlessly. The productivity gains compound faster than you’d expect.

Key resources:

LangGraph documentation for open-source agent orchestration
OpenAI Agents SDK for managed agent development
Microsoft Semantic Kernel for multi-language agent development
NVIDIA NeMo Guardrails for cross-platform safety controls
LangSmith for agent observability and debugging

The gap between AI agent demos and actual productivity is understanding what works and what doesn’t. Then building accordingly.

GitHub's Double CLI Release: How Two AI Tools Are Reshaping Development Workflows

Fri, 26 Sep 2025 00:00:00 +0000

This week, GitHub released not one but two different CLI tools for AI development. Most people are focusing on the individual features. I’m seeing something bigger: a significant step toward AI becoming development infrastructure rather than just an assistant.

Here’s what actually happened: GitHub released both an update to their regular CLI (version 2.80.0) and a completely separate standalone Copilot CLI tool. Together, they represent two different but complementary approaches to AI-powered development.

This represents a meaningful shift in how we can build and maintain software.

Two Different Tools, One Big Vision
#

Let me break down what GitHub actually released:

Tool 1: GitHub CLI 2.80.0 with Agent Tasks
#

This updates the regular gh CLI you already know with new agent-task commands:

# Start a coding agent task and track it
gh agent-task create "refactor the authentication flow"

# List all your running tasks 
gh agent-task list

# Watch it work in real-time
gh agent-task view 1234 --log --follow

This solves the “black box” problem I had with the GitHub MCP server. Before, you could trigger the coding agent but had zero visibility into what it was doing. Now you can actually see the work happening and integrate it into scripts.

For the full command reference, see GitHub CLI 2.80.0 release notes.

Tool 2: Standalone Copilot CLI
#

This is completely separate. You install it with npm install -g @github/copilot and it becomes an interactive AI partner in your terminal:

# Interactive mode - have a conversation
$ copilot
> Help me find all the CSV files in this directory recursively
AI suggests: find . -name "*.csv" -type f

# Autonomous mode - one-shot commands 
$ copilot -p "create a Python script to parse log files"
# AI writes the script, asks permission, then creates the file

The Key Difference
#

GitHub CLI agent-tasks = manage long-running coding projects (like delegating work to a team member)

Copilot CLI = interactive terminal assistance (like pair programming with AI)

Here’s where it gets interesting. You can combine both:

# Use Copilot CLI to craft the perfect task description
$ copilot -p "help me write a task description for refactoring our auth system"

# Then delegate it to the coding agent
$ gh agent-task create "$(copilot -p 'write task: refactor auth system')"

# Monitor it while doing other work
$ gh agent-task view $TASK_ID --log --follow

We just went from “AI helps me code” to “AI runs my entire development process.” That’s not an incremental improvement. That’s a category shift.

The Missing Piece: Context-Aware AI That Runs Everywhere
#

To understand why this matters, you have to think about what makes these CLI releases fundamentally different from other AI development tools. It’s not that GitHub suddenly built smarter AI. OpenAI and Anthropic probably have better raw models. What’s different is that GitHub’s AI already knows your codebase.

When you call OpenAI’s API or use Claude directly, you’re starting fresh every time. You have to explain your architecture, your patterns, your naming conventions. You’re basically teaching the AI about your project from scratch with every interaction. It’s powerful, but it’s also exhausting.

GitHub’s coding agent is different because it lives in your repository. It already understands your issues, your pull requests, your workflow patterns. It knows how your team writes code. And now, with CLI access, that context-aware intelligence can work automatically in your production workflows.

Here’s what that means practically: when your monitoring system detects a performance issue, the GitHub coding agent doesn’t just get the error message. It gets your entire codebase context, recent deployments, related issues, and team patterns. When you trigger an agent-task from your CI pipeline, it’s not running generic analysis - it’s applying intelligence that already knows your specific architecture, coding standards, and business logic.

The Model Selection Catch
#

Here’s something important I discovered while testing these tools: you can only choose which AI model to use with the standalone Copilot CLI, not with the agent-task commands.

The agent-task commands are locked to whatever model GitHub has configured for their coding agent - currently Claude 4 Sonnet as of September 2025. There’s no way to switch it to GPT-5 or any other model. The standalone Copilot CLI, on the other hand, lets you pick your model by setting an environment variable before running commands.

This creates an interesting tradeoff. The agent-tasks give you AI that truly understands your specific project context, but you’re stuck with GitHub’s model choice. The standalone CLI lets you choose between Claude or GPT-5, but each conversation starts fresh without deep knowledge of your codebase.

In practice, this means you get context or you get control, but not both. For most workflows, I’d choose context over control - having AI that knows your repository is more valuable than being able to switch models. But for complex reasoning tasks where you need GPT-5’s capabilities, the standalone CLI becomes the better choice.

What the Web Interface Doesn’t Want You to Know
#

If you read GitHub’s official documentation about Copilot coding agent limitations, you’ll see statements like “You cannot change the AI model” and “You cannot integrate with external systems.” Reading this, you’d think these are fundamental technical constraints.

But the CLI releases expose these as design choices, not technical limitations. The agent-task commands let you script everything, monitor progress in real-time, and integrate with any tool that can run shell commands. The standalone Copilot CLI gives you model selection that the web interface deliberately hides.

This reveals something important about how developer tools get designed. When companies build “user-friendly” interfaces, they often hide capabilities to avoid overwhelming users. The problem is that hiding complexity also hides possibility. The web interface trains you to think of AI as a black box you occasionally visit, rather than as programmable infrastructure you can integrate into your workflows.

The CLI approach is different - it makes AI composable. Instead of protecting you from complexity, it gives you the tools to manage complexity. That’s the difference between convenient shortcuts and real automation.

Real Examples: What You Can Build When Both Tools Work Together
#

Once you have both an interactive AI assistant and a way to manage long-running coding tasks, the possibilities get wild. Here are some workflows, from beginner to advanced:

Simple Debug Session (Beginner-Friendly)
#

#!/bin/bash
# Use both tools to debug a failing test

# First, get quick guidance from Copilot CLI
copilot -p "My test is failing with 'connection timeout'. What should I check first?"

# Based on the advice, let the agent investigate and fix
gh agent-task create "Test 'user-login-test' is failing with connection timeout. \
 Check database connection, network config, and timeout settings. \
 Fix any obvious issues you find."

# Monitor the progress
gh agent-task list

Smart Performance Monitoring (Using Both Tools)
#

#!/bin/bash
# When servers get slow, use both AIs to investigate and fix
# Note: Assumes get_cpu_usage() function is defined elsewhere

while true; do
 if [ $(get_cpu_usage) -gt 80 ]; then
 echo "CPU usage high, investigating..."

 # First, use Copilot CLI to quickly analyze what's happening
 ANALYSIS=$(copilot -p "Help me understand what might cause CPU usage of $(get_cpu_usage)% in a web app")

 # Then delegate the actual investigation to the coding agent
 TASK_ID=$(gh agent-task create "CPU is at $(get_cpu_usage)%. \
 Analysis suggests: $ANALYSIS \
 Investigate recent deployments and create a fix." \
 --model gpt-5)

 echo "Created task $TASK_ID to investigate. Monitoring progress..."

 # Watch for completion and take action
 gh agent-task view $TASK_ID --log --follow | \
 grep -i "pull request" | \
 while read pr_line; do
 echo "Performance fix ready: $pr_line"
 notify-team "AI created performance fix: $pr_line"
 done
 fi
 sleep 300
done

Intelligent Code Review Pipeline
#

#!/bin/bash
# Use both tools for comprehensive code reviews

# When a new PR is created (webhook trigger)
PR_NUMBER=$1

# First, get quick insights from Copilot CLI
REVIEW_FOCUS=$(copilot -p "What should I look for when reviewing a PR for $PR_TITLE? Give me 3 key areas to focus on.")

# Then delegate the actual review to the coding agent
gh agent-task create "Review PR #$PR_NUMBER. Focus on: $REVIEW_FOCUS. \
 Look for bugs, security issues, and maintainability problems. \
 Add review comments and create follow-up tasks for any issues." \
 --model gpt-5

Development Workflow Orchestration
#

#!/bin/bash
# Complete development workflow using both tools

# Daily maintenance routine
daily_maintenance() {
 # Use Copilot CLI to plan what needs attention
 PRIORITIES=$(copilot -p "Look at our recent commits and issues. What are the top 3 maintenance tasks I should focus on today?")

 echo "Today's AI-suggested priorities: $PRIORITIES"

 # Create agent tasks for each priority
 echo "$PRIORITIES" | while IFS= read -r task; do
 if [[ -n "$task" ]]; then
 gh agent-task create "$task - make it production ready"
 fi
 done
}

# Smart test generation from failures 
monitor_production_errors() {
 tail -f /var/log/app.log | grep ERROR | while read error; do
 # Quick analysis with Copilot CLI
 TEST_STRATEGY=$(copilot -p "How should I test for this error: '$error'?")

 # Create comprehensive tests with coding agent
 gh agent-task create "Production error: '$error'. \
 Testing strategy: $TEST_STRATEGY \
 Write comprehensive tests to prevent this." \
 --model gpt-5
 done
}

The common pattern here? We’re moving from reactive to proactive. Instead of fixing problems after they happen, we’re building systems that think ahead and improve continuously.

More importantly, we’re combining quick AI assistance with deep AI work. Copilot CLI helps you think through problems fast. The coding agent executes the actual work. Together, they create workflows that are both intelligent and thorough.

The Economics Make Sense for Both Tools
#

Here’s something interesting about the pricing: both tools use your existing Copilot subscription and count against your monthly premium request quota. The specifics matter:

Agent-task commands: Each task counts as one premium request, regardless of complexity:

# These all cost the same: 1 request each
gh agent-task create "fix typo in README"
gh agent-task create "migrate our entire codebase to Python 3.12"
gh agent-task create "do a full security audit and fix everything"

Copilot CLI: Each interaction (prompt) counts as one premium request:

# Each of these is 1 request
copilot -p "help me write a regex"
copilot -p "explain this error and suggest fixes"
copilot -p "create a complete monitoring dashboard"

Important pricing details:

Premium request quotas vary by plan (check GitHub Copilot billing docs)
You’re not charged per API call or line of code generated
Complex tasks cost the same as simple ones within each tool

This pricing model encourages ambitious automation. Don’t ration your AI usage. Don’t optimize for fewer requests. Build the automation you actually want.

Strategic insight: Use Copilot CLI for quick decisions and planning. Use agent-tasks for substantial work. This optimizes your premium request budget.

Important Limitations and Security Considerations
#

While these tools are powerful, they come with important limitations and security considerations:

Security Risks:

Copilot CLI can modify files and execute commands - only use in trusted directories
Always review AI-generated code before running it, especially in production
Agent-task outputs should be reviewed for security vulnerabilities before merging

Current Limitations:

No external integrations yet (tools work within GitHub ecosystem only)
Agent-tasks are repo-bound (no cross-repository context)
Both tools are in preview and may change significantly
Limited to GitHub’s model selection (you can’t use your own AI models)

Responsible Use:

Don’t blindly trust AI outputs - human oversight is essential
Start with non-critical tasks while you learn the tools’ behavior
Monitor your premium request quota to avoid service interruptions
Be mindful of sensitive data in prompts (logs may be retained)

We Just Crossed Multiple Lines We Can’t Uncross
#

Think about how AI coding tools have evolved, and what GitHub just delivered:

Phase 1: Autocomplete (AI suggests the next few characters)
Phase 2: Chat (AI answers questions and helps with tasks)
Phase 3: Interactive partnership (Copilot CLI becomes your terminal buddy)
Phase 4: Autonomous delegation (agent-tasks work independently on projects)

Most companies are still figuring out Phase 2. GitHub just delivered both Phase 3 and 4 at the same time.

That’s not incremental progress. That’s the difference between using AI tools and having AI colleagues.

# Interactive partnership
$ copilot
> I'm getting a weird database error. Help me debug it.
AI walks you through debugging step by step...

# Autonomous delegation 
$ gh agent-task create "Fix the database performance issues we just found"
AI goes away and comes back with a solution...

The combination is what makes this significant. You can brainstorm with one AI and delegate work to another. You can get instant feedback and long-term project execution. You can think fast and build thoroughly.

How Teams Will Actually Work
#

The most successful engineering teams are going to figure out how to split work between humans and AI effectively, and I think the division is becoming clearer.

Humans will still own the strategic decisions - architecture choices, priority setting, customer conversations. We’re also better at the ethical considerations and creative problem-solving when systems behave in unexpected ways. These require judgment, empathy, and the ability to see broader business context.

AI, on the other hand, is already excellent at maintaining consistency. It can keep code quality standards across a large codebase, write comprehensive test suites, monitor for security issues, and update documentation as code changes. These tasks require attention to detail and pattern recognition, but not creativity or judgment.

The interesting middle ground is where human expertise combines with AI execution. Code reviews will likely split this way: AI handles the mechanical checks for style violations and obvious bugs, while humans focus on logic, design decisions, and architectural implications. Planning becomes collaborative too - AI can suggest tasks based on codebase analysis, but humans decide priorities based on business needs.

Where This Is Really Heading
#

Here’s the part that gets me excited: we’re building systems that can improve themselves. Once AI can write code, test it, deploy it, monitor how it performs, and learn from the results, we’re not talking about tools anymore. We’re talking about software that evolves on its own.

# Imagine AI analyzing its own work
gh agent-task create "Look at all the code changes I've made this month. \
 Which ones worked well? Which ones caused problems? \
 Update your approach based on what you learned."

That’s a feedback loop that gets better over time. The AI learns from its successes and failures, just like a human developer would.

What You Should Do Right Now
#

Both tools are available today, though they’re still in preview status. Before you can use them, you’ll need a GitHub Copilot Pro+ subscription, and if you’re in an organization, make sure the CLI policy is enabled. Keep in mind that since these are preview features, they may change significantly without notice.

Getting started is straightforward - update your GitHub CLI to version 2.80.0 with gh --upgrade and install the standalone Copilot CLI with npm install -g @github/copilot. But the real strategy is in how you use them together.

Start with quick wins rather than trying to automate everything at once. Use the Copilot CLI for those daily terminal tasks you’re always googling - you’ll be surprised how much faster it is than switching to a browser. For agent-tasks, pick one annoying maintenance job you do weekly and delegate that first.

As you get comfortable, you’ll start to notice a natural rhythm emerging. The Copilot CLI becomes your thinking partner for quick questions and planning, while agent-tasks handle anything that takes more than fifteen minutes of sustained work. The real breakthrough happens when you start chaining them together - using insights from the interactive CLI to inform the work you delegate to the coding agent.

The teams that figure out this combination first are going to operate at a completely different level. They won’t just ship faster. They’ll build intelligent systems that improve themselves while the team focuses on innovation and strategy rather than maintenance and routine tasks.

When CI/CD Speaks Human: A Friendly Nudge to DevOps (and Developers)

Wed, 17 Sep 2025 00:00:00 +0000

I spend my days thinking about how to make engineering teams more effective. Whether it’s rolling out AI tooling that boosts developer productivity or exploring automation that eliminates the tedious parts of our workflow, I’m always looking for that next breakthrough that will let us focus on what actually matters: building great software.

That’s why GitHub Next’s Agentic Workflows project hit me like a lightning bolt. This isn’t just another automation tool, it’s a fundamental shift in how we’ll think about CI/CD, repository management, and team coordination.

What’s the idea?
#

GitHub Agentic Workflows transforms natural language markdown files into GitHub Actions that are executed by AI agents. You write automation in markdown instead of complex YAML, letting AI-powered decision making handle the details while maintaining GitHub’s native security and collaboration model.

The workflow is straightforward: install the GitHub CLI extension with gh extension install githubnext/gh-aw, describe your automation in a markdown file with frontmatter specifying triggers and permissions, then compile it to standard Actions YAML with gh aw compile. The system supports multiple AI engines (Claude, Codex, and others) and maintains security through sandboxed execution with minimal permissions.

This is explicitly a research demonstrator from GitHub Next and Microsoft Research, not a production product. The goal is to explore “Continuous AI”, the systematic, automated application of AI to software collaboration, and learn out in the open.

The design is Actions-first (familiar GitHub execution model) and engine-neutral (swap AI backends as needed). Your markdown source remains the source of truth, while the compiled YAML integrates seamlessly with existing GitHub workflows and governance.

How this will transform DevOps teams (if used carefully)
#

I’ve been watching multiple DevOps teams spend countless hours on repetitive investigative work—debugging CI failures, triaging flaky tests, writing post-mortems that follow the same patterns. Agentic Workflows could automate the tedious parts while keeping humans firmly in control.

Here’s what I’m most excited about:

Automated CI failure investigation — Think “CI Doctor” workflows that automatically investigate build failures and flakiness, then open Issues with their findings and suggested actions. No more manual time spent on repetitive post-mortem analysis. The AI does the legwork; your team makes the decisions.

Effortless status reporting — Weekly research reports and daily status updates delivered as scheduled Issues. Better visibility into what’s happening across your infrastructure without modifying a single pipeline. The information just appears where your team already looks.

Organization-specific guardrails — This is crucial. Role-based execution limits, “plan→apply” workflows with human approval checkpoints, and integrated MCP tools all running in sandboxed, network-confined environments. You get the automation benefits without losing control.

The key insight: your governance model doesn’t change. These workflows compile to standard GitHub Actions, so your existing review processes, permissions, and audit trails remain intact.

How this will supercharge Development teams
#

I’ve watched developers get buried under the administrative overhead of modern development—triaging issues, chasing missing PR details, manually updating documentation that should sync automatically. Here’s where I see Agentic Workflows making the biggest difference:

Intelligent triage that actually works — Workflows that request missing details from issue reporters, automatically categorize and label new issues, and reduce the noise that constantly interrupts focused development time. Finally, a way to maintain issue quality without developers playing 20 questions.

PR assistance with real context — Code-aware workflows that update documentation when APIs change, check dependencies for known issues, suggest fixes when PR builds fail, and identify opportunities to improve test coverage or performance. Crucially, all delivered through PRs that developers can review and approve—never silent changes to your codebase.

Continuous research and knowledge sharing — Workflows that create Issues with summaries of relevant trends, new tools, or techniques in your domain. Instead of wondering what you’re missing in the ecosystem, the information comes to you where you already work.

Here’s a simple example that captures the magic—an issue clarifier that runs when issues are opened:

---
on:
 issues:
 types: [opened]
permissions: read-all
safe-outputs:
 add-comment:
---
# Issue Clarifier
Analyze the current issue and ask for additional details if the issue is unclear.

That’s it. English instructions that compile to Actions YAML your team can review and govern.

Special caution regarding code changes
#

Here’s where I want to be crystal clear: any workflow that touches your actual codebase must go through pull requests for human review. The beauty of this system is that AI agents can suggest changes, improvements, and fixes, but they deliver them through the same PR process your team already trusts.

I’ve seen too many automation projects fail because they bypassed human oversight. The GitHub team got this right—workflows that modify code create PRs, not direct commits. This preserves your team’s ability to review, discuss, and reject changes that don’t make sense.

My pragmatic advice
#

Start small and specific. Pick one repetitive task that’s eating your team’s time—issue triage, status reporting, or CI failure investigation.
Security is non-negotiable. Use the read-only defaults, explicit tool allow-lists, and human-visible outputs. This is research-grade software; treat it accordingly.
Governance doesn’t change. Because it compiles to Actions YAML, your existing review processes, branch protections, and policies still apply. This is an authoring tool, not a permission bypass.
Keep humans in the loop. The goal isn’t to eliminate human judgment—it’s to eliminate human busy work.

Why I think this is the future
#

I’ve spent years watching teams struggle with the gap between intent and implementation. Developers know what they want their CI/CD to do, but getting there requires wrestling with YAML syntax, learning platform-specific APIs, and debugging workflows that should just work.

Agentic Workflows flips this: you describe what you want, and the system handles the how. Your DevOps team keeps control over policies, permissions, and infrastructure. Your developers get to focus on features instead of YAML archaeology.

Most importantly, everything stays auditable, reviewable, and governed through the same processes your team already trusts.

Ready to try it?
#

If you’re curious (and you should be), the quick start is genuinely quick:

Install the extension: gh extension install githubnext/gh-aw
Add a sample workflow: gh aw add weekly-research -r githubnext/agentics --pr
Set up your AI secret: gh secret set ANTHROPIC_API_KEY -a actions --body "<your-key>"
Run it: gh aw run weekly-research

Start with something low-risk—issue triage, status reports, or CI failure investigation. Keep approvals enabled, review everything the system generates, and learn what works for your team.

Key resources:

Main extension: githubnext/gh-aw
Sample workflows: githubnext/agentics

This is where engineering productivity is heading. The question isn’t whether AI will change how we automate our workflows—it’s whether we’ll be ready when it does.

From "Toys" to "Tools": The Missing Layer Developers Actually Need

Tue, 16 Sep 2025 00:00:00 +0000

I’m no longer a hands-on developer and haven’t written production code in a while. Over the last year, though, I’ve been busy rolling out AI tooling to make developers more productive. That vantage point made Idan Gazit, Head of GitHub Next, and his talk at GitHub Connect Israel really resonate: it put clean language to patterns I’ve seen on the ground.

AI coding isn’t about clever completions anymore. It’s about stitching work together so results cross the threshold from toy to tool—from interesting demos to outcomes you can trust.

Where productivity really lives
#

Idan emphasized something we often forget: most developer time isn’t typing—it’s understanding. Reading code, tracing decisions, navigating repos, connecting issues to diffs. If that’s the job, then the winning AI isn’t a “faster keyboard”; it’s a context engine. In my deployments, the largest gains came when tools reduced the time to find and trust the next action, not when they suggested a few extra lines.

Models matter; orchestration matters more
#

Idan shared that Cursor’s rise was helped by early access to strong models that GitHub Copilot didn’t yet have (e.g., Anthropic’s Claude 3.5). GitHub Copilot is catching up fast with smarter selection and repo-scale workflows. Same editor base (VS Code); different orchestration philosophies. And that’s the real race: who turns messy inputs (code, issues, docs, tests) into a clear plan with traceable steps—at a sensible latency and cost?

Two pragmatic truths follow:

Latency won’t magically vanish. Treat it as a design constraint, not a bug. Good tools keep you moving while the model works: batch related calls, prefetch likely context, stream or show partial results, and always land progress in a reviewable artifact (branch/PR/plan) instead of a spinning loader. You stay productive; the heavy lifting can finish in the background.

Cost and correctness are product features. Model choice is an economic and risk decision. The tool should make that trade-off visible (and often choose for you): fast/cheap paths for low-stakes edits; slower/more thorough paths for refactors and migrations. Show expected cost/latency, explain why a model was selected, and offer a one-click upgrade/downgrade when stakes change.

The firehose problem
#

AI didn’t reduce information; it amplified it. More suggestions, more tabs, more “help.” Without a memory of intent, this becomes context switching with extra steps. The tools that stick are the ones that carry context forward—they remember the goal, thread it through each step, and keep the evidence attached so trust can accumulate.

The gap between IDE and platform
#

This is why Idan’s hint about a technical preview in ~six weeks caught my attention: something that sits between the IDE (where you do the work) and GitHub (where you collaborate). That’s exactly the seam where productivity currently leaks. Most real tasks span files, repos, people, and tickets; the handoffs are where intent gets lost.

If I could spec that missing layer, I’d keep it simple:

Hold the intent. Start every task with a plain-English objective and keep it attached to every artifact—plan, diff, test, PR. Every change should answer: does this move us closer to the stated goal?

Prefer plans over paragraphs. Propose steps (analyze → patch → test → PR) with clear checkpoints. Humans review plans faster than prose.

Make provenance and reversibility default. Show what sources the AI used and always operate on a branch/PR so rollback is one click, not a hope.

When we rolled out AI internally, even lightweight versions of the above moved the needle more than any single “smarter” model choice.

So, will developers stop looking at code?
#

Probably not. But they’ll look at less code and more intent, diffs, and evidence. The center of gravity shifts from “type this” to “approve this change under these constraints.” For that to work, the system must preserve context, explain itself, and keep the human decisively in the loop.

I left the event convinced of one thing: the future isn’t another sidebar. It’s continuity. When tools remember what we’re trying to do and carry that memory across the workflow, AI finally feels less like a toy—and more like a tool.

Automation · PiniShv

Claude Can Now Use Your Computer. Here's What That Actually Means.

How it works #

Dispatch makes this actually useful #

For developers specifically #

The bigger picture #

Cursor Automations: Your AI Just Stopped Waiting for Permission

What it actually does #

How the others compare #

Why this matters #

OpenClaw Is Not a Chatbot. It's a Personal Agent Gateway.

What OpenClaw actually is #

Why this is different from browser-based AI #

What it can actually do #

How people actually use it #

The hard truth about running it #

Who’s behind it #

How it compares to the incumbents #

How it compares to open-source alternatives #

What this means #

CLI Agent Orchestrator: When One AI Agent Isn't Enough

The Problem #

How It Works #

Example: Mainframe Modernization #

The Reality Check #

Why It Matters #

Getting Started #

Should You Use This? #

AI Agents for Real Productivity: What Works in 2025

What makes an agent different from a chatbot #

Where agents actually help (and where they don’t) #

The agent landscape in 2025: what’s actually worth using #

Cloud platforms: fast to start, limited control #

Open-source frameworks: maximum flexibility, you run the infrastructure #

Safety and observability: the unsexy stuff that matters #

Making the right choice for your situation #

What matters more than the platform #

For engineering leaders: the strategic opportunity #

For developers: why this matters to your career #

What separates success from expensive failure #

Where to start #

GitHub's Double CLI Release: How Two AI Tools Are Reshaping Development Workflows

Two Different Tools, One Big Vision #

Tool 1: GitHub CLI 2.80.0 with Agent Tasks #

Tool 2: Standalone Copilot CLI #

The Key Difference #

The Missing Piece: Context-Aware AI That Runs Everywhere #

The Model Selection Catch #

What the Web Interface Doesn’t Want You to Know #

Real Examples: What You Can Build When Both Tools Work Together #

Simple Debug Session (Beginner-Friendly) #

Smart Performance Monitoring (Using Both Tools) #

Intelligent Code Review Pipeline #

Development Workflow Orchestration #

The Economics Make Sense for Both Tools #

Important Limitations and Security Considerations #

We Just Crossed Multiple Lines We Can’t Uncross #

How Teams Will Actually Work #

Where This Is Really Heading #

What You Should Do Right Now #