DEV Community: joshua dyson

How to Build a Platform Engineering Team & Internal Developer Portal: Lessons from Modern Engineering Organizations

joshua dyson — Sun, 26 Jul 2026 18:03:08 +0000

Platform engineering has become one of the fastest-growing disciplines in software engineering. As organizations scale, the number of services, pipelines, cloud resources, and operational tools grows just as quickly. Without a common platform, every product team ends up solving the same infrastructure problems independently.

I've found that successful platform engineering initiatives don't begin with technology—they begin with understanding where developers are losing time. An internal developer portal isn't just another dashboard; it's a way to standardize workflows, reduce cognitive load, and let engineering teams focus on building products instead of managing infrastructure.

This article walks through how I'd approach building a platform engineering team and an internal developer portal from the ground up.

TL;DR

Build a platform team to enable developers, not control them.
Start by solving your biggest developer pain points.
Treat the platform as an internal product with real users.
Provide self-service workflows instead of manual requests.
Build an Internal Developer Portal (IDP) that becomes the single place for documentation, services, deployments, and ownership.
Measure success using developer adoption and delivery metrics—not the number of platform features shipped.

Why Platform Engineering Exists

As organizations grow, engineering teams often experience the same challenges:

Developers wait days for cloud resources.
CI/CD pipelines are inconsistent across teams.
Documentation is scattered across multiple tools.
Nobody knows who owns a particular service.
Security and compliance checks vary between projects.

Eventually, engineering teams spend more time navigating systems than building software.

That's where platform engineering delivers value—by creating reusable capabilities that every team can consume.

Step 1: Identify Developer Pain Points

Before writing a single line of code, spend time understanding where developers lose time.

Typical questions include:

How long does it take to create a new service?
How long does onboarding take?
How many deployment steps are manual?
How often do developers ask for infrastructure support?
Which requests repeatedly go to the platform or DevOps team?

The answers help prioritize what the platform should solve first.

Step 2: Define the Platform Team

A platform engineering team isn't simply a renamed DevOps team.

Its mission is to build reusable products for internal engineering teams.

A typical team might include:

Platform Engineers
Site Reliability Engineers (SREs)
DevOps Engineers
Cloud Engineers
Security Engineers
Developer Experience (DevEx) Engineers

Their customers are developers—not external users.

Step 3: Build an Internal Developer Portal

The portal becomes the central place where developers interact with the platform.

Instead of searching multiple systems, developers should be able to:

Discover services
View ownership
Create new projects
Deploy applications
Request infrastructure
Read documentation
View dashboards
Check service health

One portal replaces dozens of disconnected tools.

Step 4: Standardize Service Templates

Every new microservice shouldn't start from scratch.

Create reusable templates that include:

Repository structure
CI/CD pipeline
Testing framework
Logging
Monitoring
Security scanning
Documentation

Example template:

service:
name: payments-api
language: nodejs
runtime: node20

ci:
tests: true
lint: true
security_scan: true

deployment:
environment: staging
strategy: rolling

monitoring:
metrics: enabled
logs: enabled
tracing: enabled

A developer can bootstrap a production-ready service in minutes rather than hours.

Step 5: Automate Infrastructure

Developers shouldn't create cloud resources manually.

Infrastructure should be provisioned through reusable templates.

Example:

apiVersion: platform.company.io/v1

kind: Service

metadata:
name: payments-api

spec:
runtime: node20
database: postgres
cache: redis
monitoring: enabled

Behind the scenes, automation provisions everything consistently.

Step 6: Build Self-Service Workflows

Every manual ticket is an opportunity for automation.

Examples include:

Create a repository
Provision Kubernetes namespaces
Generate CI/CD pipelines
Request databases
Issue TLS certificates
Configure DNS
Rotate secrets

Instead of waiting for another team, developers complete these tasks through the portal.

Step 7: Make Ownership Visible

One of the most valuable features of an internal portal is service ownership.

Every service should answer questions like:

Who owns it?
Which team supports it?
Where is the documentation?
Which environments exist?
When was it last deployed?

Example configuration:

service:
name: payments-api

owner:
team: payments

repository:
github: company/payments-api

slack:
channel: payments-alerts

runbook:
docs/runbook.md

Finding the right information should take seconds—not a series of Slack messages.

Step 8: Integrate CI/CD and Observability

Developers shouldn't switch between multiple tools to understand what's happening.

A portal should surface:

Latest deployments
Build status
Test results
Security findings
DORA metrics
Logs
Metrics
Traces
Incident history

The goal is to give developers a complete view of their services from a single interface.

Step 9: Measure Success

Platform engineering isn't successful because it launches a portal.

It's successful when developers actually use it.

Useful metrics include:

Developer onboarding time
Service creation time
Deployment frequency
Lead time for changes
Self-service adoption
Number of manual support requests
Internal platform satisfaction
Portal usage

If the platform reduces friction, these metrics should improve over time.

Common Mistakes

Some platform initiatives struggle because they:

Build too many features before validating user needs.
Focus on technology instead of developer experience.
Force teams onto rigid workflows.
Ignore documentation.
Treat the platform as an infrastructure project rather than an internal product.

The best platforms evolve through continuous feedback from engineering teams.

A Typical Platform Architecture
Developer
│
▼
Internal Developer Portal
│
├── Service Catalog
├── Documentation
├── Templates
├── Self-Service Actions
├── CI/CD
├── Infrastructure Automation
├── Security
└── Observability
│
▼
Cloud Infrastructure

The portal becomes the entry point, while automation handles the operational complexity behind the scenes.

Final Thoughts

Platform engineering isn't about centralizing control—it's about decentralizing capability.

When developers can create services, provision infrastructure, deploy applications, and access documentation through self-service workflows, they spend less time waiting and more time delivering value.

The most effective platform teams don't measure success by the number of tools they've built. They measure it by how much engineering friction they've removed.

If you're starting a platform engineering initiative, resist the urge to build everything at once. Solve one high-impact problem, gather feedback, and iterate. Over time, your internal developer portal will become more than just a collection of tools—it will become the foundation of how your engineering organization builds, ships, and operates software.

Devin isn't a replacement for engineers,it's an AI teammate. It can explore codebases, implement features, debug issues, run tests, and open PRs. But it still needs clear requirements and human review. The real value is accelerating delivery, not replacing

joshua dyson — Sun, 26 Jul 2026 17:59:48 +0000

README.md explains the project to humans. AGENTS.md explains it to AI coding agents. I think it'll become a standard file for teams using AI-assisted development. Are you using one yet?

joshua dyson — Sun, 26 Jul 2026 17:43:11 +0000

Preventing Hallucinated Package Dependencies in AI-Generated Code: A Practical Guide

joshua dyson — Fri, 24 Jul 2026 14:26:23 +0000

AI coding assistants are remarkably good at generating boilerplate, tests, and even complete features. But every now and then, they'll confidently import a package, function, or API that simply doesn't exist.

These "hallucinated dependencies" can waste debugging time, introduce supply chain risks, and even make it into pull requests if nobody notices.

This tutorial walks through a practical workflow to catch these issues automatically before they reach production.

We'll build a simple CI workflow that:

Detects missing or invalid dependencies
Verifies package installation
Scans for typosquatting risks
Runs dependency and security checks
Fails the pull request automatically when something looks suspicious

Everything uses standard tooling that you can add to an existing GitHub repository.

What Is a Hallucinated Dependency?

Suppose you ask an AI assistant to build a feature.

It returns something like this:

import { SmartCache } from "fast-cache-ai";

const cache = new SmartCache();

Looks reasonable.

Except...

fast-cache-ai doesn't exist.

Sometimes AI invents:

Package names
Functions
SDKs
API endpoints
Configuration options

The generated code looks convincing enough that developers often don't notice until CI fails—or worse, until someone tries to publish or deploy it.

Why This Matters

Beyond broken builds, hallucinated dependencies can create security problems.

Imagine an attacker publishing a package with the same hallucinated name.

If your build installs it automatically, you've just created a potential software supply chain risk.

That's why validating dependencies should be part of every AI-assisted development workflow.

Step 1: Install Dependencies from the Lock File

Always prefer deterministic installs.

For Node.js:

name: Install packages run: npm ci

Avoid:

run: npm install

Using the lock file ensures everyone—and your CI system—is installing exactly the same dependency versions.

Step 2: Verify Package Availability

A simple validation step can prevent many mistakes.

npm view express version
npm view react version

If the package doesn't exist, the command exits with an error.

For Python:

pip index versions requests

For Go:

go list -m all

These checks are lightweight and easy to automate.

Step 3: Enable Dependency Review

GitHub's Dependency Review Action helps identify risky dependency changes in pull requests.

on:
pull_request:

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

steps:
  - uses: actions/checkout@v4

  - uses: actions/dependency-review-action@v4

This highlights newly introduced dependencies before they're merged.

Step 4: Scan for Vulnerabilities

After validating dependencies, scan them.

Example using npm:

npm audit

Or:

npm audit --audit-level=high

For Python:

pip-audit

Security scanning won't catch hallucinations directly, but it helps identify risky packages before deployment.

Step 5: Detect Typosquatting

Hallucinations sometimes resemble legitimate packages.

For example:

expressx
react-core
lodashjs
fast-cache-ai

A simple review process should flag packages that:

Are newly introduced
Have very few downloads
Have recently been published
Closely resemble well-known packages

Even a manual review of new dependencies adds an extra layer of protection.

Step 6: Add an Automated CI Check

Here's a minimal GitHub Actions workflow:

on:
pull_request:

jobs:
validate:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: 20

  - run: npm ci

  - run: npm audit --audit-level=high

  - run: npm test

If dependency installation fails, the pull request never reaches production.

Example Repository Structure

example-app/
│
├── .github/
│ └── workflows/
│ └── dependency-check.yml
│
├── package.json
├── package-lock.json
├── src/
├── tests/
└── README.md

This keeps validation close to the code and makes it easy for contributors to understand the workflow.

Try It Yourself

To see the workflow in action:

Create a simple Node.js application.
Add the GitHub Actions workflow above.
Introduce a fake package into package.json (for example, "fast-cache-ai": "^1.0.0").
Open a pull request.
Watch the workflow fail during dependency installation.

It's a simple exercise, but it demonstrates how automated validation can catch AI-generated mistakes before they become production issues.

Additional Best Practices

A few habits can significantly reduce dependency-related issues:

Review every new dependency in a pull request.
Prefer well-maintained, widely adopted packages.
Commit lock files.
Enable automated dependency updates.
Run security scans in every CI pipeline.
Treat AI-generated imports the same way you treat manually written code—verify them before trusting them.

AI should accelerate development, not replace engineering judgment.

Final Thoughts

Hallucinated dependencies aren't a flaw unique to any one AI coding assistant—they're a natural consequence of language models generating plausible-looking code.

The good news is that they're also one of the easiest AI-related risks to mitigate.

A few automated checks in your CI pipeline can catch missing packages, identify suspicious dependency changes, and stop broken pull requests long before they reach production.

As AI becomes a routine part of software development, building lightweight validation into your workflow is no longer just a nice-to-have. It's part of writing secure, reliable software.

Avoiding CI/CD Vendor Lock-In with Portable YAML: Lessons Learned Building Flexible Pipelines

joshua dyson — Fri, 24 Jul 2026 13:26:32 +0000

Over the last few years, I've worked with teams using GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, and newer AI-native delivery platforms. One lesson keeps coming up:

The more vendor-specific your pipeline YAML becomes, the harder it is to migrate later.

By keeping pipeline definitions modular, separating business logic from platform-specific configuration, and relying on portable scripts where possible, teams can significantly reduce migration effort while preserving flexibility.

The Problem

Most CI/CD platforms use YAML.

At first glance, they look remarkably similar.

steps:

checkout
install
test
build
deploy

But beneath that familiar syntax are platform-specific features:

Custom actions
Proprietary expressions
Vendor-specific runners
Secret management APIs
Environment variables
Deployment strategies

Over time, those dependencies become difficult to untangle.

I’ve seen teams realize this only when they wanted to migrate to a different platform—or simply evaluate another option.

YAML Isn't Portable by Default

Many developers assume YAML equals portability.

It doesn't.

This GitHub Actions example:

on:
push:
branches: [main]

jobs:
test:
runs-on: ubuntu-latest

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: 20

  - run: npm ci
  - run: npm test

works perfectly...

...inside GitHub Actions.

Moving it to GitLab CI or another platform usually means rewriting jobs, triggers, environment variables, authentication, and deployment steps.

The YAML file survives.

The workflow doesn't.

What Actually Travels Well?

I've had much better results treating the pipeline as an orchestrator—not the place where all the logic lives.

Instead of embedding everything inside YAML, move reusable logic into scripts.

For example:

steps:

run: ./scripts/install.sh
run: ./scripts/test.sh
run: ./scripts/build.sh
run: ./scripts/deploy.sh

Now those scripts can be reused almost anywhere:

GitHub Actions
GitLab CI/CD
Jenkins
CircleCI
Azure DevOps
Self-hosted runners

The pipeline simply decides when to execute them.

Keep Vendor-Specific Features at the Edge

Some platform-specific features are worth using.

Examples include:

GitHub Actions Marketplace
GitLab Review Apps
Azure DevOps Environments
CircleCI Orbs

The mistake is building the entire delivery process around them.

Instead, I try to isolate vendor-specific functionality to small sections of the pipeline.

That makes future migrations far less painful.

Standardize the Workflow

Across projects, I like keeping the same delivery stages regardless of platform:

Checkout
↓
Dependencies
↓
Lint
↓
Tests
↓
Build
↓
Security Scan
↓
Package
↓
Deploy

The orchestration tool can change.

The workflow remains familiar.

Infrastructure Should Be Portable Too

The same philosophy applies outside CI/CD.

Instead of relying on deployment features tied to one platform, use portable infrastructure tooling where practical.

Examples include:

Docker
Kubernetes
Terraform
OpenTofu
OpenTelemetry

These standards make changing CI/CD platforms much less disruptive because the surrounding ecosystem remains consistent.

Where AI Can Help

As AI becomes more integrated into software delivery, I think portability becomes even more important.

An AI system that understands your delivery workflow shouldn't depend entirely on one CI/CD vendor.

Instead, it should reason about concepts like:

Build failures
Test results
Security findings
Infrastructure changes
Deployment health

Those concepts exist regardless of whether the pipeline runs in GitHub Actions, GitLab CI/CD, Jenkins, or another platform.

That's one reason I'm interested in AI-native delivery platforms like Revolte. Rather than replacing existing CI/CD tools, the idea is to add intelligence around the delivery workflow—analyzing pipelines, deployments, infrastructure, and runtime behavior—while allowing teams to continue using the tools that fit their environment.

What I'd Do Today

If I were designing a CI/CD platform from scratch, I'd follow a few simple rules:

Keep YAML as thin as possible.
Move business logic into reusable scripts.
Prefer open standards over proprietary integrations.
Standardize pipeline stages across repositories.
Isolate vendor-specific functionality.
Treat CI/CD as interchangeable infrastructure, not a permanent dependency.

Those decisions don't eliminate migration work, but they make future changes dramatically easier.

Final Thoughts

Vendor lock-in rarely haxppens overnight.

It happens one convenient feature at a time.

Most of those features are useful, and many are worth adopting. The key is knowing where convenience ends and long-term flexibility begins.

For me, portable pipelines aren't about preparing to switch CI/CD vendors tomorrow. They're about preserving the freedom to evolve your engineering stack as your team's needs change.

A little discipline in how you structure your YAML today can save weeks—or even months—of migration effort down the road.

CI/CD Pipeline Security: What's the one security check you consider non-negotiable before every deployment? #cicd #pipeline #security #deployment

joshua dyson — Thu, 23 Jul 2026 12:02:49 +0000

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:

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.