DEV Community: joshua dyson

What's the Real Per-Seat Cost of GitHub Copilot Once Enterprise Cloud and AI Credit Overages Are Included?

joshua dyson — Thu, 23 Jul 2026 10:36:14 +0000

GitHub Copilot has quickly become one of the most widely adopted AI coding assistants. For many developers, it's become a daily tool for generating code, writing tests, explaining unfamiliar functions, and speeding up repetitive work.

When evaluating Copilot, though, many teams focus on one number: the monthly license fee per developer.

In practice, that's only part of the picture.

Once you roll Copilot out across an engineering organization, you'll also need to think about GitHub Enterprise, governance, security, AI usage limits, onboarding, and the operational workflows surrounding software delivery.

Here's a framework I use when thinking about the real cost of GitHub Copilot.

The License Is Just the Starting Point

The advertised subscription price is easy to compare.

The harder question is:

What does one productive Copilot user actually cost your organization?

For most engineering teams, the answer includes much more than the AI assistant itself.

Typical costs include:

GitHub Enterprise licensing (where applicable)
Copilot subscription
AI premium request or usage overages (depending on your plan and usage patterns)
Security and compliance reviews
Developer onboarding and enablement
Internal documentation and governance
Time spent reviewing AI-generated code

The exact numbers will vary by organization, but these factors often matter more than the headline subscription price.

Hidden Cost #1: Enterprise Platform Costs

Many larger organizations already use GitHub Enterprise Cloud for features such as:

SAML/SSO
Organization policies
Audit logs
Enterprise security
Centralized administration
Compliance controls

If you're evaluating Copilot as part of an enterprise rollout, it's worth considering the overall GitHub platform investment rather than looking at Copilot in isolation.

Hidden Cost #2: AI Usage Isn't Always Unlimited

As GitHub expands Copilot's capabilities—from chat and coding assistance to more advanced AI-powered workflows—some plans include usage limits or AI request allocations for premium features.

That means highly active engineering teams should understand:

What's included in the subscription
Which AI capabilities consume premium usage
How additional usage is billed
Whether certain workflows generate higher AI consumption

For small teams this may never become an issue.

For hundreds of developers using AI throughout the day, it becomes an important budgeting consideration.

Hidden Cost #3: AI Still Requires Human Review

Copilot can generate impressive code.

It cannot guarantee that the generated code is:

Correct
Secure
Compliant
Performant
Appropriate for your architecture

Every AI-generated change still requires engineering judgment.

Many organizations underestimate the review time that continues after AI writes the first draft.

The goal isn't eliminating review—it's making reviews more efficient.

Hidden Cost #4: Governance

As AI becomes part of everyday development, platform teams also need to define:

Which models developers can use
Data handling policies
Security controls
Prompt management
Code ownership
Audit requirements

These aren't licensing costs, but they're real operational costs that accompany enterprise AI adoption.

Hidden Cost #5: Software Delivery Doesn't Stop at Code

Even if Copilot generates a pull request in minutes, the engineering work continues.

The change still needs to move through:

CI/CD pipelines
Infrastructure validation
Security scanning
Deployment approvals
Observability
Incident monitoring

These activities often consume more engineering time than writing the original code.

That's why many platform engineering teams are investing not only in AI coding assistants, but also in AI-powered software delivery.

Thinking Beyond the IDE

One trend I've noticed is that AI is gradually moving beyond code generation.

Instead of only helping developers write code, newer tools are beginning to assist with:

Pull request summaries
CI/CD failure analysis
Infrastructure changes
Deployment risk assessment
Automated rollback recommendations
Production incident investigation

Rather than replacing coding assistants, these tools complement them by addressing the operational work that happens after a pull request is opened.

Platforms such as GitHub itself are expanding AI capabilities across the developer workflow, while AI-native software delivery platforms like Revolte are exploring how AI can simplify CI/CD, infrastructure automation, observability, and governance from pull request to production.

So, What's the Real Per-Seat Cost?

The answer isn't a single dollar amount.

It's better thought of as:

Per-Seat Cost = Software License + Platform Costs + AI Usage + Governance + Operational Overhead

For many teams, the biggest expense isn't the Copilot subscription.

It's everything required to safely turn AI-generated code into production-ready software.

Final Thoughts

GitHub Copilot has changed how developers write software, and for many teams it's an easy productivity win.

But if you're evaluating it for an entire engineering organization, don't stop at the subscription price.

Look at the complete engineering workflow.

The organizations that see the highest return aren't simply buying AI licenses—they're redesigning how software moves from idea to production. AI coding assistants improve developer productivity, while modern platform engineering and AI-native delivery tools help reduce the operational work surrounding every release.

When you measure the real cost of AI, it's worth measuring the real value the same way.

AI Agents Inside CI/CD: How We Automated PR Triage and Reduced Review Bottlenecks

joshua dyson — Thu, 23 Jul 2026 09:39:33 +0000

Over the past few months, I've been exploring how AI agents can fit into a modern CI/CD pipeline—not to replace engineers, but to eliminate repetitive work that slows teams down.

Here's what worked well:

✅ Automatically categorized incoming pull requests
✅ Flagged potential security and dependency issues
✅ Suggested fixes for linting and test failures
✅ Generated review summaries for faster code reviews
✅ Reduced context switching for reviewers

The biggest lesson? AI is most valuable before the human review begins.

The Problem

Every engineering team eventually runs into the same issue.

Developers submit pull requests faster than reviewers can process them.

A typical PR often goes through several repetitive steps:

CI builds
Unit tests
Linting
Dependency checks
Security scanning
Style comments
Reviewer assignment
Documentation validation

None of these tasks require deep architectural thinking, yet they consume valuable engineering time.

I started wondering:

What if an AI agent handled the first round of triage automatically?

The Workflow

Instead of waiting for a human reviewer, the pipeline lets an AI agent inspect every pull request immediately after CI starts.

Developer
│
▼
Pull Request Created
│
▼
CI Pipeline Starts
│
▼
AI Agent
├── Analyze changed files
├── Review commit summary
├── Detect risky changes
├── Check coding standards
├── Explain failing tests
├── Suggest fixes
└── Generate PR summary
│
▼
Human Review

By the time a reviewer opens the PR, much of the routine analysis is already complete.

Example GitHub Actions Workflow

A simplified workflow might look like this:

name: AI Pull Request Review

on:
pull_request:
types: [opened, synchronize]

jobs:
ai-review:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - name: Run Tests
    run: npm test

  - name: Run Linter
    run: npm run lint

  - name: AI PR Analysis
    run: ./scripts/ai-review.sh

The AI step can analyze:

Test failures
Lint violations
Changed files
Security findings
Dependency updates

before publishing a review comment.

Example AI Output

Instead of showing raw CI logs, the agent can produce something more useful:

Summary

• 12 files modified
• 1 failing test
• 2 lint issues
• Medium-risk dependency update

Suggested Fixes

✓ Replace deprecated API usage
✓ Remove unused imports
✓ Update failing snapshot
✓ Consider pinning dependency version

This gives reviewers context immediately instead of asking them to sift through build logs.

Auto-Triaging Pull Requests

One feature I found surprisingly useful was automatic categorization.

For example:

Frontend
Backend
Infrastructure
Security
Documentation
Dependencies
Performance
Tests

Based on the files changed, the agent can apply labels automatically.

That makes routing reviews much easier, especially in larger engineering teams.

Handling Common Failures

Many failed builds aren't complex engineering problems.

They're things like:

Formatting
Missing imports
Broken snapshots
Dependency version conflicts
Typographical mistakes
Simple test failures

These are often fixable without human intervention.

Instead of merely reporting the issue, an AI agent can suggest a patch—or even open a follow-up commit for review, depending on your team's policies.

Keep Humans in Control

One lesson became clear very quickly.

AI should assist reviews—not approve production code on its own.

For our experiments, the guardrails were straightforward:

AI never merged pull requests
AI never bypassed branch protection
Security approvals remained manual
Production deployments still required human approval

That balance preserved trust while still saving time.

Where AI Added the Most Value

The biggest improvements weren't in writing code.

They were in reducing repetitive operational work.

The agent consistently helped by:

Explaining CI failures
Summarizing pull requests
Highlighting risky files
Surfacing security findings
Suggesting obvious fixes
Reducing reviewer context switching

Those small improvements compound over dozens of pull requests each week.

Looking Ahead

I don't think the future of CI/CD is simply "AI writes more code."

I think it's AI removing friction throughout the software delivery lifecycle.

That includes:

Smarter pull request triage
Intelligent deployment validation
Automated rollback recommendations
Infrastructure change analysis
Security-aware code reviews
Context-rich incident summaries

Several engineering platforms—including GitHub, GitLab, Harness, and newer AI-native platforms like Revolte are moving in this direction by embedding AI deeper into software delivery workflows rather than treating it as a standalone coding assistant.

Final Thoughts

The most successful AI workflows I've seen don't try to replace engineers.

They remove the repetitive work that slows engineers down.

If an AI agent can save reviewers from digging through CI logs, identifying obvious issues, and manually categorizing pull requests, that's time the team can spend on architecture, design, and solving customer problems.

For me, that's where AI belongs inside CI/CD—not making every decision, but helping engineering teams move faster with better context and fewer interruptions.

How is your team using AI in CI/CD today? Is it limited to code generation, or have you started automating PR reviews, triage, and delivery workflows?

Platform-as-Code vs Infrastructure-as-Code

joshua dyson — Thu, 23 Jul 2026 07:20:32 +0000

Platform-as-Code vs Infrastructure-as-Code: What's the Difference?

Infrastructure-as-Code automated servers. Platform-as-Code is trying to automate the entire developer experience.

When I first heard the term Platform-as-Code (PaC), my reaction was:

"Isn't that just Infrastructure-as-Code with a new name?"

After working with platform engineering teams, I realized the answer is no.

The two ideas are related, but they solve different problems.

If you're already using Terraform, Pulumi, or AWS CloudFormation, you probably have Infrastructure-as-Code (IaC). That doesn't necessarily mean you have Platform-as-Code.

Let's break it down.

Infrastructure-as-Code (IaC)

Infrastructure-as-Code is exactly what it sounds like:

Define infrastructure in code instead of clicking through cloud consoles.

Instead of manually creating a Kubernetes cluster or a VPC, you write configuration files.

For example:

resource "aws_instance" "web" {
ami = "ami-123456"
instance_type = "t3.medium"
}

Now your infrastructure becomes:

Version controlled
Repeatable
Automated
Easy to recreate

Popular IaC tools include:

Terraform
Pulumi
AWS CloudFormation
Azure Bicep

The goal is simple:

Provision infrastructure consistently.

What IaC Doesn't Solve

Imagine a new developer joins your team.

Infrastructure already exists.

Now they need to:

Create a service
Configure networking
Add monitoring
Set up CI/CD
Configure secrets
Register ownership
Add security policies
Create dashboards
Configure alerts

Infrastructure-as-Code doesn't usually handle this entire workflow.

Developers still jump between:

GitHub
Terraform
Kubernetes
ArgoCD
Prometheus
Grafana
Jira
Internal documentation

Everything works…

…but the experience isn't unified.

Enter Platform Engineering

Platform engineering asks a different question.

Instead of:

"How do we automate infrastructure?"

It asks:

"How do we make building software easier?"

That's a much bigger problem.

A platform team cares about:

Golden paths
Self-service
Templates
Security guardrails
Deployment workflows
Observability
Documentation
Developer experience

Infrastructure is only one piece.

Platform-as-Code

Platform-as-Code takes those platform capabilities and makes them programmable.

Instead of manually creating platform workflows, they're defined as reusable code.

Think of it like this:

Developer

  │

  ▼

Create Service

  │

  ▼

Platform automatically:

✔ Repository
✔ CI/CD
✔ Infrastructure
✔ Secrets
✔ Monitoring
✔ Logging
✔ Dashboards
✔ Security Policies
✔ Ownership
✔ Documentation

The developer asks for a service.

The platform assembles everything consistently.

Another Way to Think About It

Imagine building a house.

Infrastructure-as-Code gives you:

Bricks
Concrete
Steel
Electrical wiring

Everything you need to build.

Platform-as-Code gives you:

The blueprint
Building rules
Approved materials
Inspection process
Utility connections
Maintenance documentation

One provisions resources.

The other standardizes how those resources are used.

Why This Matters

As engineering teams grow, consistency becomes harder.

Different teams:

choose different deployment patterns
use different observability stacks
create different CI/CD pipelines
configure security differently

Eventually every service looks slightly different.

That's expensive.

Platform engineering tries to reduce that variability.

Platform-as-Code makes those standards repeatable.

Where AI Changes the Picture

Recently, another layer has started to appear.

AI isn't just writing application code anymore.

It's helping developers:

create services
generate deployment pipelines
explain infrastructure
troubleshoot production issues
review pull requests

For that to work well, AI needs context.

Not just source code.

It needs to understand:

infrastructure
deployment pipelines
observability
security policies
organizational standards

That's why many newer platforms are combining Platform-as-Code with AI-native workflows.

Instead of treating AI as an IDE feature, they're giving it visibility into the broader software delivery platform.

Platforms like Revolte are exploring this direction by bringing AI, platform engineering, deployment automation, and operational context together. Whether that becomes the long-term standard is still evolving, but it reflects where many engineering organizations are experimenting today.

When Should You Think About Platform-as-Code?

You probably don't need it if:

You're a solo developer
You're building a small MVP
Everyone knows the infrastructure

You'll likely benefit when:

Multiple teams deploy services
Onboarding takes weeks
Every team has different deployment practices
Platform engineers spend their days answering the same setup questions
Governance becomes difficult

That's usually the point where organizations start investing in internal developer platforms—and increasingly, Platform-as-Code.

Final Thoughts

Infrastructure-as-Code changed how we provision infrastructure.

Platform-as-Code changes how developers interact with that infrastructure.

One automates cloud resources.

The other automates the engineering experience.

As software delivery becomes more automated—and increasingly AI-assisted—I expect Platform-as-Code to become just as important as Infrastructure-as-Code, especially for organizations building internal developer platforms.

Because the goal isn't simply to automate servers.

It's to make shipping reliable software easier.

If you found this useful...

How does your team define the boundary between Infrastructure-as-Code and Platform-as-Code?

Do you think they're separate disciplines, or just different layers of the same platform?

I'd love to hear how your organization approaches it.

Factory.ai vs Devin: Stop Comparing Features. Compare How They Change Software Delivery.

joshua dyson — Wed, 22 Jul 2026 13:38:12 +0000

A few weeks ago, someone asked me a simple question:

"Should I use Factory.ai or Devin?"

My first instinct was to compare features.

Autonomous coding.

Pull requests.

Terminal access.

Repository understanding.

Issue tracking.

The usual checklist.

But the more I looked into both platforms, the more I realized something.

They're often grouped into the same category, yet they encourage very different ways of working.

And I think that's a more useful conversation than asking which one has the longer feature list.

Two Different Ideas of an AI Engineer

Both Factory.ai and Devin aim to reduce the amount of manual engineering work.

Both can understand repositories.

Both can generate code.

Both can run tests.

Both can work across multiple files.

From a distance they look similar.

But once you understand how they're designed, their philosophies begin to separate.

Devin Feels Like Delegation

The easiest way I describe Devin is this:

It feels like assigning work to another engineer.

Instead of asking:

"Help me write this function."

You're asking:

"Take this ticket and come back with a pull request."

Devin investigates the codebase, plans the implementation, writes the code, runs tests, and iterates toward a completed task with relatively little intervention. That's what makes it feel less like an assistant and more like a teammate for well-defined engineering work.

The interaction changes.

You stop thinking about individual edits.

You start thinking about outcomes.

That shift is surprisingly significant.

Factory.ai Feels Like an Engineering Platform

Factory.ai approaches the problem differently.

Instead of centering everything around one autonomous engineer, it introduces Droids—agents that can work across the IDE, terminal, browser, Slack, CLI, and other engineering surfaces. The emphasis is on letting teams stay in their existing workflow while giving agents access to the context and tools they need.

What stood out to me wasn't just the agents.

It was the workflow.

Factory doesn't feel like:

"Here's your AI engineer."

It feels more like:

"Here's an environment where AI participates throughout engineering."

That's a subtle difference.

But an important one.

The Real Difference Isn't Autonomy

Most comparisons measure autonomy.

Can it write code?

Can it debug?

Can it open pull requests?

Can it execute terminal commands?

Those are useful capabilities.

But I think they're measuring the wrong thing.

The more interesting question is:

Where does the autonomy actually live?

For Devin, autonomy largely revolves around owning and completing engineering tasks.

For Factory, autonomy extends into the engineering workflow itself—planning, reviews, issue management, code changes, and coordination across multiple interfaces.

That's not simply a feature difference.

It's a workflow difference.

Both Eventually Hit the Same Wall

This is where my perspective shifts away from comparing products.

Neither platform struggles because it can't write code.

They struggle whenever context becomes fragmented.

Questions like:

Why was this architecture chosen?

Which deployment failed last week?

Why does this service behave differently in production?

Which business rule exists only in a design document?

Why did the previous team intentionally avoid this implementation?

None of those answers live inside the repository.

They live across documentation.

Deployments.

Incidents.

Architecture decisions.

Runtime behavior.

Operational history.

That's the part AI still has to reconstruct.

And that's where things become difficult.

Context Is Becoming the Competitive Advantage

I don't think the next generation of engineering tools will compete primarily on code generation.

That capability is improving everywhere.

The bigger opportunity is preserving context.

Imagine an AI that doesn't just understand your repository.

It understands:

why the change was requested
how similar changes behaved in production
deployment history
observability signals
security policies
previous incidents
release patterns

That's a much richer picture than code alone.

And it leads to better engineering decisions.

Why This Matters Beyond Factory.ai and Devin

This is also why I think we're moving beyond the era of isolated AI coding assistants.

The industry is starting to explore AI-native software delivery, where planning, development, deployment, runtime, observability, and governance remain connected instead of living in separate tools.

That's one reason platforms like Revolte caught my attention.

Not because they're trying to replace Factory or Devin—they're solving a different problem.

The interesting idea is preserving delivery context across the entire software lifecycle so AI isn't forced to rediscover the same information every time it moves from coding to deployment or from production back to development.

Whether that architectural approach becomes the norm remains to be seen.

But I think it's pointing toward a bigger shift than simply building another autonomous coding agent.

So Which One Would I Choose?

It depends on what I'm trying to optimize.

If I wanted an AI teammate that could take ownership of a well-scoped engineering task and work toward completion, I'd lean toward Devin.

If I wanted AI woven throughout the engineering workflow—from IDE to terminal to collaboration tools—Factory's approach is compelling because it extends beyond a single interface and emphasizes shared engineering context.

I don't think one replaces the other.

I think they represent two different visions of AI-assisted engineering.

Final Thoughts

A year ago, we were debating whether AI could generate useful code.

Today, we're debating how much responsibility it should take.

That's meaningful progress.

But I don't think the long-term winner will be the tool with the most autonomous agent.

I think it'll be the one with the deepest understanding of how software is actually delivered.

Because AI can only make good engineering decisions when it understands more than the code.

It has to understand everything around the code.

And that, in my view, is where the next chapter of software engineering begins.

What “Read-Only Fridays” Quietly Reveal About Your Platform

joshua dyson — Mon, 09 Feb 2026 09:08:56 +0000

A while back, I came across the idea of “read-only Fridays.”
No production changes. No writes. Just observation.

At first, it sounds like a sensible process rule.
But in production systems, rules like this usually exist for a deeper reason.

Read-only Fridays aren’t really about Fridays.
They’re about trust in your platform.

They’re not about the calendar.
They’re about confidence.

When teams trust their platform:

deploys are small and reversible
rollbacks are boring
observability answers questions quickly
on-call doesn’t feel like a gamble

Friday isn’t special. It’s just another day.

When they don’t, risk gets pushed into process rules.
Freezes, sign-offs, exceptions, calendar-based safety nets.

Those rules aren’t failures , they’re signals.

They tell you the platform doesn’t yet give teams enough confidence to change safely, so humans compensate instead.

The interesting question isn’t “Should we allow Friday deploys?”
It’s:

*“What would need to be true for this rule to disappear?”
*
Almost always, the answer is platform work:

clearer pipelines
faster feedback
better observability
easier recovery

Calendars don’t create safety.
Platforms do.