Software Architecture · PiniShv

When AI Writes 90% of Your Code, What Are You Actually Doing?

Fri, 17 Oct 2025 00:00:00 +0000

At the Salesforce Dreamforce conference last week, Anthropic CEO Dario Amodei dropped a number that’s been making waves: “I made this prediction that, you know, in six months, 90% of code would be written by AI models. Some people think that prediction is wrong, but within Anthropic and within a number of companies that we work with, that is absolutely true now.”

Ninety percent. That’s not a demo. That’s how one of the world’s leading AI companies actually builds software today.

The immediate reaction: developers are done, engineering teams will shrink, why hire software engineers when AI can write the code?

But when Salesforce CEO Marc Benioff asked if that means Anthropic needs fewer engineers now, Amodei’s answer was the opposite of what people expect.

The 10% That Actually Matters
#

Amodei was clear: “If Claude is writing 90% of the code, what that means, usually, is, you need just as many software engineers. You might need more, because they can then be more leverage. They can focus on the 10% that’s editing the code or writing the 10% that’s the hardest, or supervising a group of AI models. And so what happens is, you know, you just end up being 10 times more productive.”

Ninety percent AI-written code doesn’t mean fewer developers. It means developers doing fundamentally different work.

This isn’t about replacement. It’s about “rebalancing,” as Amodei put it. The job is changing to focus on what actually requires human judgment.

I’ve been saying this for months, and this statement from someone at the bleeding edge confirms what I’ve been seeing: writing code was never the bottleneck. Understanding what to build, how to architect it, and how to guide AI safely were always the hard parts. AI just made that reality impossible to ignore.

What Does That 10% Actually Include?
#

When AI writes 90% of your code, what are you doing with your time?

You’re making architectural decisions that ripple across the entire system. You’re catching edge cases that AI misses. You’re supervising the AI’s output architecturally. Does this approach scale? Is this secure? Does this follow our patterns? You’re debugging the weird stuff when production behavior doesn’t make sense. You’re making trade-off decisions based on business context, team capabilities, and long-term strategy.

This is what I wrote about in hiring developers in the age of AI: the developers who thrive aren’t the ones who can write code fastest. They’re the ones with systems thinking, architectural reasoning, and problem decomposition skills.

The Productivity Multiplier Nobody Talks About
#

Here’s what gets lost in the “AI will replace developers” narrative: if your developers can be 10 times more productive, you don’t need one-tenth the headcount. You build 10 times as much with the same team.

The companies winning aren’t firing developers. They’re building faster than competitors while others argue about whether AI is good enough. But this only works if your developers can actually operate at that level, with deep systems understanding and architectural thinking.

I wrote about this pattern in what’s holding you back from succeeding in the AI era. The developer I called Marcus shipped 247 commits in a month using AI. Impressive numbers. But when I asked him to explain the architecture of a feature he’d shipped, he couldn’t. Three days later, production incident. He’d implemented decisions he didn’t understand.

Marcus isn’t alone. This is the risk nobody’s talking about when they celebrate AI writing 90% of code.

The Divide Between AI Operators and AI-Augmented Engineers
#

Not all developers are getting 10x more productive with AI. Some are getting 10x faster at shipping code they don’t understand.

The ones succeeding use AI to accelerate work they already know how to do. They recognize when AI suggestions are headed down the wrong path and can evaluate trade-offs without running the code. They’re using AI as a thinking partner for implementation while they focus on design and edge cases.

The ones struggling use AI as a crutch for things they never learned properly. They can ship fast but can’t debug what they shipped because they never built the mental models.

This is what I meant when I wrote about being pro-AI while worried about our next senior engineers. The gap between these two types of developers is widening fast. The scary part? They can have nearly identical output metrics for six months. The difference only becomes obvious when things break.

What This Means for Engineering Teams
#

If Anthropic needs the same number of engineers (or more) even with 90% AI-generated code, what should engineering leaders be doing differently?

Stop optimizing for typing speed. Invest in architectural skills and systems thinking. Create oversight mechanisms that review architectural decisions, not individual lines. Measure production incidents per feature, not commit counts. Develop deep expertise in distributed systems, security, and architecture.

This aligns with what I wrote about AI security being a culture problem. You can have the best AI tools, but if your culture treats “works on my machine” as good enough, you’ll have problems.

The Junior Developer Problem
#

If AI writes 90% of code today, how do junior developers build the expertise to be valuable tomorrow?

The teams doing it right are being extremely intentional. Junior developers don’t just accept AI output. They’re required to explain architectural decisions, walk through how features handle edge cases, and defend trade-offs. They use AI to move faster, but must understand everything they ship.

The teams doing it wrong measure productivity by output volume. Junior developers prompt AI, ship code, move to the next ticket. Fast velocity, zero learning.

Six months from now, the first group will have developers who can architect features independently. The second group will have “AI operators” who panic when AI fails.

What About The Other 10%?
#

Amodei said 90% of code is AI-written “for most teams at Anthropic.” Not all teams. That 10% human-written code isn’t random. It’s the hardest stuff: novel algorithms, performance-critical paths, security-sensitive logic, the architectural foundation everything else builds on.

That 10% is where all the leverage comes from. Get that 10% right, and AI can generate the other 90% reliably. Get it wrong, and you’re building on a broken foundation.

This matches what I’ve seen with developer work not changing, just the sequence. The actual job didn’t disappear. What changed is when those activities happen and how much implementation detail developers handle personally.

The Uncomfortable Truth for Developers
#

If you’re a developer whose primary value was writing clean, working code quickly, you’re in trouble. That skill is being commoditized right now.

If your value is understanding complex systems, architecting for scale, catching subtle bugs, making informed trade-offs, and guiding AI to produce maintainable solutions, you’re more valuable than ever.

The uncomfortable part: many developers thought they were the second type, but were actually the first. AI is exposing that gap brutally.

The good news: these skills can be learned. But you have to be intentional. You won’t build them by accident while prompting AI to generate features.

Rebalancing, Not Replacing
#

Amodei’s point about “rebalancing” is the right frame. The work didn’t disappear. It shifted.

Less time writing boilerplate, more time on architecture. Less time debugging syntax errors, more time designing systems that are debuggable. Less time on mechanical tasks, more time on judgment calls.

This is a better job. More interesting, more impactful, more creative. But only if you have the skills to operate at that level.

What Comes Next
#

I keep coming back to something I wrote in from toys to tools: most developer time isn’t typing, it’s understanding. AI writing 90% of code doesn’t eliminate that understanding requirement. If anything, it makes it more critical.

The winning developers aren’t the ones who resist AI or blindly trust it. They’re the ones who use AI to handle implementation details while they focus on the parts that actually require human judgment.

That’s what Amodei is describing. That’s what I’m seeing in successful teams. And that’s where software development is headed.

The question isn’t whether AI will write most of your code. It already does at leading companies, and the rest will follow within months.

The question is whether you’re building the skills to be valuable in that world. To operate at the architectural level. To guide AI effectively. To catch the edge cases. To make the trade-offs. To be the 10% that makes the 90% possible.

Because that’s the job now.

The Agentic Commerce Protocol: We Just Gave Every LLM the Ability to Buy Things

Mon, 29 Sep 2025 00:00:00 +0000

When OpenAI announced Instant Checkout in ChatGPT, I thought it was just another feature. Then I looked deeper and realized what actually happened: we just got a new protocol.

Not a product. Not a platform feature. A protocol.

OpenAI and Stripe built the Agentic Commerce Protocol (ACP) and released it as open source under Apache 2.0. It’s a standard way for AI agents to discover products, negotiate checkout, and complete purchases with any business that implements the spec.

This means ChatGPT can buy things. Siri could buy things. Gemini could buy things. Any LLM that implements this protocol can now transact on behalf of users.

We need to talk about what that actually means.

Why This Is a Protocol Moment
#

We’ve had protocol moments before. HTTP made information universally accessible. OAuth made authentication portable. SMTP made email interoperable. Each time, the protocol was the infrastructure that enabled an entire ecosystem to form.

ACP is the protocol for AI commerce. It defines how agents and businesses talk to each other about products, prices, payments, and fulfillment. It’s the missing vocabulary that was keeping AI stuck at recommendation without transaction.

The technical design is straightforward: merchants expose ACP endpoints (REST or MCP), agents call those endpoints with structured requests, and the protocol handles the entire flow from product discovery through payment to fulfillment. The spec is public, the reference implementation is live in ChatGPT, and any AI platform can adopt it.

But here’s what makes this different from previous protocol moments: we’re not just enabling information exchange or authentication. We’re enabling autonomous spending.

What This Enables: The Good
#

Let’s start with the obvious benefits, because they’re real:

Frictionless commerce actually becomes frictionless. No more context switching between conversation and checkout. No more finding your credit card. No more filling out forms. You tell your AI what you need, it finds it, you confirm, it’s done. For accessibility, this is transformative. For convenience, it’s a quantum leap.

High-intent moments convert immediately. When you’re talking to an AI about a problem and it suggests a solution you can buy, the path from “I need this” to “I have this” collapses to seconds. That’s powerful for users and merchants.

Discovery gets smarter. Instead of keyword search and filter hell, you describe what you actually want. The AI understands context, preferences, constraints. You don’t search for “running shoes men size 10 blue under $100 with arch support.” You say “I need running shoes for my flat feet, budget is $100” and the AI does the translation.

Small merchants get found. If you implement ACP, you’re discoverable by every AI that speaks the protocol. You don’t need to be on page one of Google or pay for ads. You just need to be relevant to what the buyer actually needs.

This is genuinely valuable infrastructure. But we need to talk about the other side.

What Could Go Wrong: The Risks
#

Here’s where it gets uncomfortable. When you give LLMs the ability to transact, you’re not just enabling convenience. You’re enabling persuasion at scale.

The deliberation tax disappears. Right now, buying something takes effort. You have to navigate to a site, add items to cart, enter payment info, review your order. That friction is annoying, but it’s also a built-in pause. It gives you time to think “do I actually need this?” When that friction vanishes, so does the pause.

Recommendation becomes indistinguishable from advertising. Today, when ChatGPT suggests something, you assume it’s optimizing for your needs. But what happens when merchants can pay to influence those recommendations? The protocol doesn’t prevent this. It’s a business model question, not a technical one. And the pressure to monetize will be enormous.

Dark patterns scale effortlessly. We’ve spent years fighting misleading “low stock” warnings and fake urgency in web interfaces. Now imagine those patterns embedded in natural conversation. “I found a great option for you, but there’s only one left at this price and three other people are looking at it right now.” Is that true? How would you know?

Impulse purchases become conversational. The best salespeople don’t feel like they’re selling. They feel like they’re helping. LLMs are incredibly good at sounding helpful. When your AI assistant casually mentions “by the way, that book you were talking about yesterday is on sale, want me to grab it?” the psychological barriers to impulse buying collapse.

The merchant of record matters more than you think. ACP keeps merchants as the merchant of record, which sounds good. But it also means liability, returns, disputes, and customer service stay with merchants who may have never directly interacted with the customer. When something goes wrong, who do you blame? The AI that recommended it? The merchant who fulfilled it? The platform that enabled it?

We’re optimizing for conversion, not satisfaction. The entire protocol is designed to reduce friction in the purchase flow. That’s great for merchants and platforms. But what about buyer welfare? Lower friction means more purchases means more returns means more waste means more regret. We’re building infrastructure for speed, not for good decisions.

I’m not saying ACP is inherently bad. I’m saying we need to think hard about the incentives this protocol enables before every LLM adopts it.

How the Protocol Actually Works
#

Let’s talk about the technical design, because it reveals what the creators were trying to solve (and what they weren’t).

The core handshake: Merchants expose ACP endpoints (REST or MCP). AI agents call those endpoints with structured requests. The protocol handles product discovery, checkout initiation, payment delegation, and order fulfillment. Everything is defined in the open spec.

The agent shares a narrowly scoped, single-use payment payload with the merchant’s PSP
The PSP validates and returns a token constrained by amount and expiration
Settlement, chargebacks, and payment operations stay with the merchant and PSP

Stripe’s Shared Payment Token is the first implementation. It passes payment credentials and risk signals without exposing raw card data. The token is time-bounded to the transaction.

Security is baked into the foundation. Payment credentials are never shared raw with AI agents. Token scope and allowances keep exposure minimal. This is smart design.

Merchant control: The protocol preserves merchants as the merchant of record. They keep customer relationships, control what products are available, decide how they’re presented, and can accept or decline transactions on a per-agent or per-order basis. They also handle fulfillment, returns, and support.

Open source and extensible: ACP is Apache 2.0 licensed and maintained publicly on GitHub. It supports REST and MCP, works with existing commerce backends, and handles physical goods, digital goods, subscriptions, and asynchronous purchases.

The technical design is solid. The concerns I have aren’t about the protocol itself. They’re about what happens when it gets widely adopted.

ChatGPT Is Live, Others Will Follow
#

ACP isn’t theoretical. It’s already powering Instant Checkout in ChatGPT. Live with Etsy merchants now, Shopify coming soon, U.S. only for the moment with expansion planned.

OpenAI says discovery is “organic and relevance-ranked” with no boost for enabling Instant Checkout. That’s the right answer. Whether it stays that way when revenue pressure increases is a different question.

Merchants provide a Product Feed to make their catalog searchable in ChatGPT. Even without Instant Checkout, you get direct links to your site. With Instant Checkout enabled, the purchase happens in the conversation.

But here’s what matters: ChatGPT is just the reference implementation. The protocol is open. Siri, Gemini, Alexa, every AI assistant can adopt this. Apple has been working on making Siri more capable. Google wants Gemini in every product. Amazon already has your payment info and shipping address.

When they all speak ACP, every conversation with an AI becomes a potential transaction. That’s the world we’re heading into.

What Questions We Should Be Asking
#

The protocol is here. The reference implementation is live. More platforms will adopt it. Instead of debating whether this will happen, we should be asking how it happens responsibly.

How do we keep recommendation separate from advertising? OpenAI claims ChatGPT’s product suggestions are relevance-based, not paid placement. That’s good. But the economic pressure to monetize discovery is real. We need transparency about what influences ranking. Not just “we use relevance” but “here’s how we define and audit relevance.”

What’s the disclosure model? When an AI suggests a product, is it getting a commission? Is the merchant paying to be suggested? Is there a business relationship between the platform and the merchant? Users deserve to know. The protocol doesn’t require disclosure, but platforms should.

How do we audit persuasion tactics? Traditional web interfaces are visible. You can screenshot dark patterns. You can share them. You can shame companies into fixing them. But conversational AI is ephemeral. When an AI uses urgency tactics or social proof or scarcity claims, how do we verify them? How do we hold platforms accountable?

What’s the refund and dispute process? When you buy through an AI agent and something goes wrong, who’s responsible? The merchant fulfilled the order, but the AI made the recommendation. If the AI misrepresented the product, is that the merchant’s fault? The protocol keeps merchants as the merchant of record, but the liability questions are messy.

How do we handle vulnerable users? Elderly users, kids, people with impulse control issues, people in financial distress. LLMs are persuasive. Conversational commerce removes friction. The combination is powerful and potentially harmful. What guardrails should platforms implement? What responsibility do they have?

What about competition? If Apple integrates ACP into Siri, Amazon into Alexa, Google into Gemini, we get a handful of gatekeepers deciding which merchants get suggested. That’s not better than Google search monopoly. It’s worse, because the suggestions feel personal and trustworthy instead of commercial.

These aren’t hypothetical concerns. They’re questions we need answers to before this becomes infrastructure.

What to Build If You’re a Merchant
#

Despite my concerns, I think merchants should pay attention to ACP. Not because it’s perfect, but because it’s happening.

Start with a product feed. Get your catalog into ChatGPT’s shopping search even if you’re not ready for Instant Checkout. If your products don’t show up when buyers ask for them, you’re invisible. The feed spec is straightforward, and you keep control over what products are discoverable.

Implement ACP endpoints incrementally. You don’t need to expose your entire catalog. Start with your best-selling, lowest-support-burden products. Learn how AI agents discover and purchase them. Expand as you understand the patterns.

Pick your payment path carefully. If you’re on Stripe, the Shared Payment Token is ready. If you’re not, talk to your PSP about their ACP roadmap. Don’t rush to support every possible payment method. Start with what’s proven.

Build internal controls for per-agent approvals. The protocol lets you accept or decline transactions based on which agent is making the request. Use that. If you see concerning patterns from a particular platform, you can stop transactions before they become problems.

Monitor return rates and customer satisfaction. AI-driven purchases might have different return patterns than traditional web purchases. Track that. If certain products have high return rates when purchased through AI, that’s a signal.

What This Actually Changes
#

Here’s the uncomfortable truth: ACP makes AI commerce infrastructure. Just like HTTP made information accessible and OAuth made authentication portable, ACP makes transactions automatic.

When a capability becomes infrastructure, it becomes invisible. People stop questioning it. It just works. That’s the danger and the opportunity.

The danger is that we normalize AI-driven purchasing before we’ve figured out the ethics, the disclosure requirements, the consumer protections, and the competitive dynamics. We build the infrastructure first and deal with the consequences later.

The opportunity is that we have a moment, right now, while this is still new, to ask hard questions and demand better answers. To push for transparency, disclosure, and user control. To build the norms before the infrastructure becomes locked in.

The protocol moment is when we set the rules, not just the interfaces. What we accept now becomes the baseline for everything that follows.

What I’m Watching For
#

I’ll be paying attention to a few things:

How OpenAI handles monetization. They say rankings are organic. When they introduce revenue-sharing with merchants (and they will), does that change? How transparent are they about it?

How other platforms adopt ACP. Does Apple prioritize Apple Pay merchants? Does Google prioritize Shopping advertisers? Does Amazon prioritize FBA sellers? The protocol is neutral, but implementations won’t be.

What PSPs beyond Stripe implement the spec. If we end up with a Stripe monopoly on ACP payments, that’s not neutral infrastructure. We need multiple PSPs implementing the Delegated Payment Spec.

What regulatory attention this gets. Consumer protection agencies should be looking at this. If they’re not, someone needs to make them aware.

What merchant discovery looks like. The protocol doesn’t define how AI agents find ACP-enabled merchants. Whoever builds that discovery layer has enormous power.

The Protocol Is Here
#

We just gave LLMs the ability to buy things. The Agentic Commerce Protocol is solid technical infrastructure. The payment security is well designed. The merchant controls are thoughtful.

But infrastructure isn’t neutral. The capabilities it enables depend on how it’s used, who controls access, and what incentives it creates.

ChatGPT can buy things now. Siri, Gemini, and Alexa could be next. Every conversation becomes a potential transaction. That’s powerful and concerning in equal measure.

The question isn’t whether this will happen. It’s already happening. The question is whether we’ll demand transparency, accountability, and user protection as it scales, or whether we’ll realize what we’ve built after it’s too late to change it.

Learn more:

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.

The Context Engine: What Comes After We've Solved Code Generation

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

We’ve largely won the context war. RAG systems seamlessly ingest our documentation. Tools like Cursor and GitHub Copilot understand entire codebases. Error monitoring platforms like Sentry now provide AI-powered root cause analysis. The basic infrastructure for AI-powered development is here, deployed, and working.

But here’s what I’m seeing in organizations that have moved beyond the “wow, AI can write code” phase: the real opportunity isn’t building better context engines—it’s using them to fundamentally reshape how we approach software development.

The question is no longer “How do we make AI understand our code?” It’s “Now that AI understands our code better than most humans, what becomes possible?”

The answer is a shift from reactive to predictive development. From managing technical debt to preventing it. From architectural drift to architectural evolution. Let me show you what this looks like.

The Architectural Evolution Engine
#

With context engines in place, we can now tackle something that’s been impossible until now: real-time architectural evolution. Instead of letting architecture drift and then scrambling to fix it, AI can now guide architectural decisions as they happen.

The New Reality: Your AI assistant doesn’t just understand your current architecture—it understands the intent behind it. When a developer is about to introduce a new dependency or pattern, the AI can say: “This breaks the bounded context principle we established for the payment service. Here are three alternatives that maintain architectural integrity.”

Beyond Code Review: Traditional code review catches syntax and logic errors. AI-powered architectural review catches conceptual errors. It can detect when a change violates domain boundaries, introduces circular dependencies, or creates coupling that will cause problems six months from now.

The Impact: Architecture becomes a living, enforced discipline rather than a document that gets outdated. Teams can move fast while maintaining long-term system health.

The Technical Debt Prevention System
#

Here’s where it gets interesting. With full codebase understanding, AI can now predict technical debt before it accumulates. Instead of paying down debt, we can prevent it from accruing in the first place.

Debt Pattern Recognition: AI systems can now identify the early warning signs of technical debt: duplicated logic patterns, growing function complexity, increasing coupling between modules. But more importantly, they can suggest refactoring before the debt becomes painful.

The Compound Interest Problem: Technical debt compounds like financial debt. A small architectural inconsistency today becomes a major refactoring effort next year. AI can now calculate the “interest rate” of technical decisions and surface this to developers in real-time.

Proactive Refactoring: Instead of waiting for code to become unmaintainable, AI can suggest micro-refactorings during normal development. “I notice this function is growing complex and similar logic exists in three other places. Would you like me to extract a shared utility?”

The Impact: Teams spend less time fighting legacy code and more time building new features. Technical debt becomes a managed, predictable cost rather than a surprise that derails projects.

The Predictive Operations Layer
#

This is where the future gets really exciting. With operational data flowing back into our context engines, we can move from reactive incident response to predictive system health management.

Performance Regression Prevention: AI can now analyze code changes against historical performance data and predict: “This database query pattern caused a 40% slowdown in the user service last month. The current change introduces a similar pattern in the payment service.”

Failure Pattern Recognition: Instead of waiting for systems to fail, AI can recognize the precursor patterns. “CPU usage is trending upward in a pattern that preceded the last three outages. The common factor appears to be this background job that was modified two weeks ago.”

Capacity Planning as Code: AI can now predict resource needs based on code complexity and usage patterns. “The new feature you’re building will likely increase database load by 30% based on similar features. Here’s the infrastructure scaling plan.”

The Impact: Operations becomes predictive rather than reactive. Teams prevent incidents instead of responding to them. System reliability improves while operational overhead decreases.

The Development Paradigm Shift
#

We’re standing at an inflection point. The basic infrastructure for AI-powered development is largely solved. The question now is: what do we do with this unprecedented capability?

The organizations that will thrive in the next phase are those that use AI not just to write code faster, but to fundamentally rethink how software is built and maintained:

From reactive to predictive: Instead of fixing problems, prevent them.
From debt management to debt prevention: Instead of paying down technical debt, avoid accruing it.
From architectural drift to architectural evolution: Instead of letting systems decay, guide their growth.
From incident response to system health: Instead of reacting to failures, predict and prevent them.

This isn’t about better tools—it’s about better practices enabled by AI that understands our systems as well as we do.

The future of software development isn’t just AI that can code. It’s AI that can think architecturally, predict operationally, and evolve systematically. The context engine was just the beginning.

Software Architecture · PiniShv

When AI Writes 90% of Your Code, What Are You Actually Doing?

The 10% That Actually Matters #

What Does That 10% Actually Include? #

The Productivity Multiplier Nobody Talks About #

The Divide Between AI Operators and AI-Augmented Engineers #

What This Means for Engineering Teams #

The Junior Developer Problem #

What About The Other 10%? #

The Uncomfortable Truth for Developers #

Rebalancing, Not Replacing #

What Comes Next #

The Agentic Commerce Protocol: We Just Gave Every LLM the Ability to Buy Things

Why This Is a Protocol Moment #

What This Enables: The Good #

What Could Go Wrong: The Risks #

How the Protocol Actually Works #

ChatGPT Is Live, Others Will Follow #

What Questions We Should Be Asking #

What to Build If You’re a Merchant #

What This Actually Changes #

What I’m Watching For #

The Protocol Is Here #

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 #