DEV Community: joshua dyson

AI Platform Engineering: Building Smarter Internal Developer Platforms

joshua dyson — Thu, 29 Oct 2026 17:10:46 +0000

As engineering organizations grow, developers often spend more time navigating infrastructure, configuring environments, understanding deployment processes, and requesting access than focusing on application development.
Platform engineering addresses this challenge by providing reusable capabilities and self-service workflows that help developers build, test, and deploy software without needing to understand every underlying infrastructure detail.
AI introduces another opportunity. Instead of relying exclusively on predefined templates, documentation, and manual requests, engineering teams can use AI to help developers express their intent, understand platform capabilities, troubleshoot issues, and coordinate development tasks.
The result is an emerging approach known as AI platform engineering: combining the foundations of platform engineering with AI-assisted and agent-driven workflows.
The objective is not simply to add a chatbot to an internal developer portal. It is to make engineering workflows easier to use while preserving the reliability, security, and governance that platform teams are responsible for.
What Is Platform Engineering?
Platform engineering is the practice of building and maintaining internal platforms that provide developers with standardized, reusable capabilities for software delivery.
These capabilities may include:
Application templates and service scaffolding.
Development and testing environments.
Infrastructure provisioning.
CI/CD pipelines.
Secrets and identity management.
Logging, metrics, and observability.
Security controls and compliance checks.
Deployment workflows and operational tooling.
An internal developer platform (IDP) brings relevant capabilities together behind a consistent developer experience.
Rather than requiring every development team to solve the same infrastructure problems independently, platform teams provide supported paths that developers can use to deliver software.
A good platform reduces unnecessary cognitive load while allowing teams to retain flexibility where it matters.
What Is AI Platform Engineering?
AI platform engineering applies AI capabilities to the design, operation, and use of internal developer platforms.
AI can help developers interact with platform capabilities using natural language, generate configurations, explain errors, and coordinate tasks across the software development lifecycle.
For example, a developer might request:
"Create a service with an API endpoint, configure a test environment, add the required validation checks, and prepare the changes for review."
An AI-enabled workflow could interpret the request, identify the relevant templates and policies, generate a plan, and prepare the necessary changes.
Depending on the platform, the workflow may execute some steps automatically and require approval for others.
The platform remains responsible for defining the supported capabilities, permissions, policies, and operational boundaries within which AI can work.
Why Internal Developer Platforms Need an AI Layer

Developer self-service still requires technical knowledge A conventional self-service portal may provide templates and deployment buttons, but developers still need to understand which template to select, which configuration values to provide, and how to resolve errors. AI can help explain available options and translate a development requirement into an appropriate workflow.
Platform documentation can be difficult to navigate Large engineering organizations maintain documentation across infrastructure repositories, internal portals, runbooks, and team-owned systems. An AI assistant with access to approved, current documentation can help developers locate relevant instructions and understand platform conventions. Its answers should remain grounded in the actual documentation and supported capabilities.
Repeated configuration work creates unnecessary overhead Teams frequently repeat tasks such as creating service scaffolding, updating configuration files, preparing test environments, and adding standard checks. AI can help generate these artifacts, while templates and deterministic validation enforce consistency.
Platform teams become a bottleneck When developers must request help for routine infrastructure and deployment tasks, platform engineers may spend a large portion of their time handling repetitive requests. AI-assisted self-service can help developers resolve routine issues independently, leaving platform engineers more time for architecture, reliability, security, and platform improvements.
Governance becomes harder as autonomy increases Giving developers and AI agents more execution capabilities creates additional questions around permissions, approval, auditability, and policy enforcement. An effective AI platform should make the approved path easier to follow without allowing agents to bypass the organization's controls. Five Ways AI Can Improve an Internal Developer Platform
Natural-language developer self-service Developers can describe what they want to build rather than navigating a large set of disconnected tools and configuration forms. An AI-enabled platform can interpret the request, ask for missing information, and recommend the appropriate template or workflow. The generated plan should identify the changes it intends to make before execution begins.
Automated project scaffolding AI can help generate service structures, configuration files, initial tests, documentation, and other development artifacts. Standard templates and validation rules can ensure the generated output follows the organization's conventions. This can reduce repetitive setup work, especially when teams create many similar services.
Environment provisioning assistance Developers often need temporary environments for feature development, testing, or reviewing a change. AI can help prepare environment configuration and initiate approved provisioning workflows. The platform should enforce resource limits, access permissions, cost controls, and cleanup policies to prevent unnecessary infrastructure usage.
Context-aware troubleshooting When a build or deployment fails, developers need to understand the relevant logs, configuration, dependencies, and recent changes. An AI assistant can help gather this information, explain likely causes, and suggest next steps. Any proposed changes should still pass the platform's normal validation and security checks.
Policy-aware software delivery Platform engineering often standardizes requirements such as security scans, approved dependencies, required tests, and deployment approvals. AI can help developers understand these requirements and prepare compliant changes. However, the enforcement of critical policies should remain in reliable, independently validated controls rather than depending solely on an AI-generated explanation. AI Platform Engineering Architecture A practical architecture can be organized into five layers. Layer 1: Developer experience This is where developers express their intent and interact with the platform through a portal, command-line interface, code editor, or other supported interface. Layer 2: AI orchestration The AI layer interprets requests, gathers relevant context, creates execution plans, and coordinates the available tools. It should distinguish between actions it can perform and actions requiring approval or additional information. Layer 3: Platform services This layer exposes reusable capabilities such as project scaffolding, infrastructure provisioning, repository management, testing, and deployment workflows. Layer 4: Policy and security controls Identity, permissions, secrets management, environment isolation, audit logging, and approval requirements define the boundaries within which AI and developers can operate. Layer 5: Observability and feedback Logs, metrics, traces, deployment outcomes, and developer feedback help teams monitor platform performance and identify areas for improvement. These layers work together. An AI interface without reliable platform services will have limited execution capabilities, while powerful automation without appropriate governance can create operational risk. How to Introduce AI Into Your Internal Developer Platform Step 1: Identify developer friction Interview engineering teams and review workflow data to identify repetitive requests, common configuration mistakes, long waiting periods, and frequent support tickets. Select one problem with a measurable impact. Step 2: Establish supported platform capabilities Document the templates, APIs, workflows, environments, and integrations the platform supports. AI should operate through defined interfaces wherever possible rather than inventing new procedures for every request. Step 3: Start with read-only assistance A useful first step is an AI assistant that can explain documentation, locate relevant configuration, summarize build failures, or answer platform questions. Measure answer quality and ensure that the assistant distinguishes verified information from uncertainty. Step 4: Add bounded execution Once the read-only workflow performs reliably, allow the AI layer to prepare selected changes or execute low-risk tasks in a controlled environment. Define explicit permissions and approval requirements for each type of action. Step 5: Integrate validation and governance Ensure that generated code and configurations pass the normal testing, security, and policy checks. The AI layer should not be able to bypass mandatory controls simply because a task was expressed in natural language. Step 6: Measure developer outcomes Track time to create a new service, environment provisioning time, deployment lead time, platform support requests, failed changes, and developer satisfaction. Use these measures to determine whether the AI layer genuinely improves the developer experience. Common Challenges in AI Platform Engineering Poor documentation and inconsistent standards: AI cannot reliably guide developers if platform documentation is outdated or conflicting. Excessive autonomy: Agents with unrestricted access to infrastructure can create security, reliability, and cost risks. Unclear ownership: Platform teams need to define who owns AI workflows, reusable templates, policies, and incident handling. Tool fragmentation: Adding an AI interface across disconnected systems may create another layer of complexity instead of simplifying the developer experience. Unmeasured productivity claims: Faster code generation does not necessarily translate into faster, safer software delivery. Insufficient feedback loops: Teams must continuously evaluate whether AI-generated plans, configurations, and recommendations are useful and correct. How Revolte Fits Into AI-Native Platform Engineering Revolte is an AI-native software delivery platform designed to help engineering teams move from developer intent toward production-ready software through connected development and delivery workflows. For teams exploring AI platform engineering, an important consideration is how developers can express their intent, review proposed plans, generate or modify code, run quality and security checks, and progress through delivery with appropriate controls. The broader goal is to reduce unnecessary coordination between development and delivery activities without removing engineering oversight. When evaluating Revolte for an internal developer platform use case, teams should verify the available interfaces, integrations, infrastructure support, governance capabilities, and deployment workflows against their requirements. Final Thoughts AI platform engineering extends the idea of developer self-service by making platform capabilities easier to discover, understand, and use. The most effective approach combines AI-assisted interaction with standardized platform services, reliable automation, and enforceable governance. Start with a specific developer pain point, build on a clear platform foundation, and measure the impact on developer experience and delivery performance. Explore Revolte to learn more about AI-native software delivery and how developer intent can be connected to engineering workflows with visibility and control.

7 Best Devin Alternatives in 2026: AI Software Engineers Compared

joshua dyson — Wed, 28 Oct 2026 08:18:41 +0000

Devin, from Cognition, made the "AI software engineer" mainstream. You tag it in Slack or a ticket, and it spins up its own virtual machine, writes the code, tests it and keeps going until a pull request is ready to merge. For well-scoped tasks, that kind of handoff is powerful.
Full autonomy isn't what every team needs, though. Some engineering leaders want agents that are just as capable but easier to steer, with clear approval points and an audit trail. Some need help beyond the pull request: deployments, incidents and legacy migrations. Others just want an agent that lives in the editor their developers already use. This guide compares seven Devin alternatives on the trade-off that matters most here: how much autonomy you get, and how much control you keep.
Disclosure: this guide is published by Revolte, one of the platforms listed. Each tool is described from its current public product pages, which are linked at the end.
Why teams look for a Devin alternative
Teams usually start looking for one of three reasons. Control: an agent that works on its own for hours is efficient, but regulated teams need to decide exactly which actions need human sign-off. Scope: Devin's job ends at a merge-ready pull request, while delivery continues through environments, releases, monitoring and incident response. Workflow fit: some developers prefer to pair with an agent in their IDE or terminal rather than hand tasks to a remote one.
Devin alternatives at a glance

Revolte: best for autonomy with governance, from code to production Revolte is AI for the entire software delivery lifecycle. Where Devin focuses on getting a task to a merge-ready pull request, Revolte's agents carry on through testing, deployment and production operations. They also handle data migration and application modernization. Its promise is simple: you direct, Revolte delivers. The difference is in the controls. Agents run inside the Revolte Harness, a sandboxed, permissioned execution environment. Context Management grounds them in your codebase, architecture decisions and prior work. The Revolte IDP and Platform layer connects their output to the environments, pipelines and infrastructure you already run. Human-in-the-loop controls set approval thresholds per workflow, team or risk level, so routine changes flow while high-risk ones wait for the right engineer. Delivery Intelligence turns every agent action into an audit trail. On top of that, Revolte adds runtime, delivery and FinOps observability, and a developer CLI. Choose Revolte if: you want Devin-level autonomy, but with risk-based approvals, full traceability and coverage all the way to production. That's why teams in banking, legal and fintech use it. Consider: automated quality engineering and security and performance use cases are listed as coming soon.
Factory: best for delegating across many tools Factory is an agent-native development platform whose "Droids" plan, build, review, test and ship. Like Devin, it's built for handing off complete tasks. It reaches further into your existing tools, with Droids on the command line, desktop, web, mobile, Slack, Microsoft Teams, Jira, Linear and CI. Missions handle long-running, multi-phase work, and Automations run event-driven or scheduled workflows. It supports multiple model providers, persistent "Droid Computers", human approval checkpoints and enterprise deployment controls. Choose Factory if: you like Devin's handoff model but want it built into more of your team's tools. Consider: like Devin, its core output is engineering work up to review. Check how far it reaches into deployment and operations for your stack.
Augment Code: best for building your own agent loops Augment Code's Cosmos platform is for building an "always-on software delivery system". You configure agent loops for first-pass code review, ticket-to-PR, vulnerability remediation and incident investigation. They are triggered by GitHub, GitLab, Slack, Linear, Jira, schedules or webhooks. Agents share context and memory across the lifecycle and run in managed cloud sandboxes or on your own machines, with permissions, audit trails and human review points. Choose Augment if: your platform team wants to design its own automations rather than delegate one task at a time. Consider: it takes more setup than a ready-made agent.
Cursor: best for developers who want the agent in their editor Cursor takes the opposite approach to Devin. Developers stay in an AI-native IDE and work alongside an agent that can use models from several providers. When they want to delegate, Cursor's cloud agents run in parallel on their own machines and test their changes. There is also a CLI, an @cursor Slack integration and Bugbot for pull request review. Cursor lists SOC 2, ISO 27001 and ISO 42001 certifications. Choose Cursor if: you want to make developers faster rather than replace task handoffs. Consider: it's focused on code, so deployment and operations sit outside it.
Claude Code: best for a scriptable, customizable agent Claude Code is Anthropic's agentic coding tool. It reads your codebase, edits files, runs commands and opens pull requests. It runs in the terminal, VS Code, JetBrains, a desktop app and the browser. You can mention @claude in Slack with a bug report and get a pull request back, or run it in GitHub Actions and GitLab CI/CD for review and triage. Teams shape its behavior with CLAUDE.md instructions, skills, hooks and MCP connections. It can also run parallel agents and cloud scheduled tasks, and the Agent SDK lets you build custom agents. Choose Claude Code if: your engineers want an agent they can script and adapt, from quick pairing to fully headless runs. Consider: it's a developer tool, so delivery-wide governance and environments are things you build around it.
OpenAI Codex: best for teams already on ChatGPT OpenAI Codex runs in the ChatGPT desktop, mobile and web apps, the Codex CLI, an IDE extension and Codex Cloud. Codex Cloud is where long-running tasks run on isolated machines. Scheduled tasks are among its listed workflows, and it signs in with a ChatGPT account. Choose Codex if: your organization already runs on ChatGPT and wants autonomous coding in the same place. Consider: it's code-focused, not a delivery platform.
GitHub Copilot cloud agent: best for GitHub-native teams GitHub Copilot's cloud agent is the closest built-in equivalent to Devin for GitHub users. You assign it an issue or start a task from the agents panel. It researches the repository, implements the change, and runs tests and linters in an ephemeral cloud environment. Then it opens a pull request with session logs for review. Choose Copilot cloud agent if: your code lives on GitHub and you want the lowest-friction option. Consider: it works only with GitHub-hosted repositories, on one repository and branch per task, and each session is capped at 59 minutes. How to choose the right Devin alternative Decide first how much you want to hand off. If you want developers to stay hands-on, pick an editor or terminal agent such as Cursor, Claude Code or Codex. If you want to hand off well-scoped tickets, Factory and Copilot's cloud agent work much like Devin, and Augment lets you design that handoff yourself. If the slow part of your delivery comes after the pull request, or you need provable control over what agents do, choose a platform that covers the whole lifecycle with governance built in. Revolte is built for exactly that. Whichever you shortlist, ask the same four questions. Where do agents execute? What can they access? Who approves which actions? Can you show an auditor a complete record of what an agent did?

7 Best Factory AI Alternatives in 2026 (Compared for Enterprise Teams)

joshua dyson — Mon, 26 Oct 2026 11:02:07 +0000

Factory is one of the better-known names in agentic software development. It describes itself as an agent-native platform where "Droids" plan, build, review, test and ship code. You can run them from the command line, desktop, web, Slack, Microsoft Teams, Jira, Linear and CI. For many teams, that is exactly what they need.

But no single agent platform fits every team. Some teams want agents that go past the pull request into deployment and production operations. Some need stricter governance because they work in a regulated industry. Others would rather keep agents inside the IDE or the GitHub workflow they already use. If you're in one of those groups, this guide compares seven Factory AI alternatives on what matters most: how much of the software delivery lifecycle each one covers, where its agents run, and how much control your engineers keep.

Disclosure: this guide is published by Revolte, one of the platforms listed. We've tried to describe every tool, including our own, from its current public product pages, which are linked at the end.

How we compared them

We looked at four things. SDLC coverage: does the tool stop at code, or does it also handle review, testing, deployment and operations? Execution: where do agents run, and how isolated are they? Governance: are there approval checkpoints, permissions and audit trails? Fit: which team is each tool really built for?

Revolte: best for governed, end-to-end software delivery

Revolte is built as AI for the entire software delivery lifecycle, not just the coding step. Its agents handle application development, testing, deployment and production reliability, along with data migration and application modernization. The idea is that engineers direct the work and agents deliver it, from intent to production.

What sets Revolte apart from Factory is how far it goes past the pull request and how much weight it puts on governance. Agents run inside the Revolte Harness, a sandboxed, permissioned environment. Context Management grounds them in your codebase, architecture decisions and prior work. The Revolte IDP and Platform layer connects their output to your existing environments, pipelines and infrastructure. Human-in-the-loop controls let you set approval thresholds per workflow, team or risk level. Delivery Intelligence records every agent action as an audit trail. Revolte also includes runtime, delivery and FinOps observability, and a developer CLI.

Choose Revolte if: you need agents that ship to production and operate what they ship, and your security or compliance team needs traceability. Revolte's customers include banking, legal and fintech teams. Consider: automated quality engineering and security and performance use cases are listed as coming soon, so check the roadmap
if those are your priority.

Devin: best for fully autonomous task handoff

Devin, from Cognition, is an autonomous software engineer that spins up its own Windows, Mac and Linux virtual machines. It builds and tests its work there and keeps going until a pull request is ready to merge. Teams tag @devin in Slack or Microsoft Teams, or connect it to Linear, Jira and GitHub. It can split large tasks across parallel cloud agents, review code with Devin Review, and run scheduled or trigger-based workflows, including a "Security Swarm" that hunts for vulnerabilities and coverage gaps. On the enterprise side, it offers per-session VM isolation, SSO, SCIM, RBAC, audit logs and private networking.

Choose Devin if: you want to delegate whole tasks and review finished pull requests. Consider: it's centered on producing code and pull requests. Deployment and production operations depend on what you connect it to.

Augment Code: best for always-on agent loops

Augment Code now sells Cosmos, a platform for building an "always-on software delivery system". Agent loops cover first-pass code review, ticket-to-PR, vulnerability remediation and incident investigation.

They are triggered from GitHub, GitLab, Slack, Linear, Jira,
schedules or webhooks. Agents share context and memory across planning, coding, review, testing and incidents. They can run in managed cloud sandboxes or on machines you manage, with permissions, audit trails and human review points.

Choose Augment if: you want to build your own event-driven agent loops. Consider: you design the loops yourself, so getting value takes some platform-engineering effort.

Cursor: best for developers who live in the editor

Cursor is an AI-native IDE. Its in-editor agent lets you pick models from several providers. It also offers cloud agents that run in parallel on their own machines and test their changes, a CLI, an @cursor Slack integration, and Bugbot for pull request review. Cursor lists SOC 2, ISO 27001 and ISO 42001 certifications.

Choose Cursor if: your goal is to make individual developers faster. Consider: it centers on writing and reviewing code. Deployment, operations and delivery governance sit outside it.

Claude Code: best for flexible agentic coding across surfaces

Claude Code is Anthropic's agentic coding tool. It reads your codebase, edits files, runs commands and opens pull requests. It runs in the terminal, VS Code, JetBrains, a desktop app and the browser. It also connects to Slack, GitHub Actions and GitLab CI/CD for automated review and issue triage. Teams can customize it with project instructions (CLAUDE.md), skills, hooks and MCP connections to tools such as Jira and Google Drive. It can also run parallel agents and cloud scheduled tasks, and the Agent SDK lets you build your own agents.

Choose Claude Code if: you want a powerful, scriptable agent that engineers can shape around their own workflows. Consider: it's a developer tool rather than a delivery platform, so environments, deployment governance and audit across the pipeline are things you build around it.

OpenAI Codex: best for teams already on ChatGPT

OpenAI Codex is available in the ChatGPT desktop, mobile and web apps, the Codex CLI, an IDE extension and Codex Cloud. Codex Cloud is for long-running work on isolated machines. Scheduled tasks and long-running work are listed among its workflows, and it signs in with your ChatGPT account.

Choose Codex if: your organization has standardized on ChatGPT and wants coding agents in the same place. Consider: like Cursor and Claude Code, it's focused on building code, not running the full delivery pipeline.

GitHub Copilot cloud agent: best for GitHub-native teams

GitHub Copilot's cloud agent takes work from an issue, a pull request or the agents panel. It researches the repository, plans and implements changes, and runs tests and linters in an ephemeral cloud environment. It then opens a pull request for review, with session logs that show what it did.

Choose Copilot cloud agent if: your code and workflow already live on GitHub and you want the lowest-friction option. Consider: it works only with GitHub-hosted repositories and one repository and branch per task, and each session is capped at 59 minutes.

How to choose the right Factory alternative

Start with where your delivery actually slows down. If the bottleneck is writing code, an IDE- or CLI-based agent such as Cursor, Claude Code or Codex will help fastest. If it's the backlog of well-defined tickets, an autonomous agent such as Devin or Copilot's cloud agent can take tasks off your plate. If the slowdown sits after the pull request, in reviews, environments, releases, incidents or compliance sign-off, you need a platform that covers the whole lifecycle with governance built in. That's where Revolte, Augment Cosmos and Factory itself compete.

For regulated teams, put governance first. Ask every vendor four questions. Where do agents execute? What can they touch? Who approves what? Can you produce a full audit trail of agent actions for your auditors?

AI SDLC Explained: Why Faster Coding Didn't Make Us Ship Faster

joshua dyson — Mon, 26 Oct 2026 08:02:23 +0000

We rolled out AI coding assistants and our pull request count went up. Our lead time to production barely moved. The reason turned out to be simple: writing code was never our bottleneck. Pull requests waited in review, flaky tests blocked merges, deploys waited for someone with the right access, and incidents kept pulling the same engineers off feature work.

AI made one stage of the pipeline faster, and the queue just moved downstream. That is the problem the AI SDLC idea is trying to solve.

What is AI SDLC?

AI SDLC, short for AI software development lifecycle, means applying

AI across every stage of delivery rather than at a single step. Planning, coding, review, testing, deployment and production operations all get AI support, and they share context. An agent reviewing a pull request knows why the change was planned. An agent responding to an incident knows what was deployed an hour ago.

Without that shared context, you don't have an AI SDLC. You have a collection of disconnected AI tools.

An agentic SDLC goes a step further. Instead of suggesting code for a human to paste, agents carry out multi-step work themselves. They build a change, write and run the tests, prepare the deployment and propose a fix when something breaks in production. Engineers set the intent, approve risky actions and stay accountable for what ships.

Why coding assistants alone don't move the needle

Delivery speed is set by the slowest stage, not the fastest. If code generation gets twice as fast but review, testing and release stay the same, lead time hardly changes. Many teams see the opposite effect: more pull requests, longer review queues and test suites that can't keep up. There is also a context gap. A coding assistant sees a file or a repository, but not your deployment history, runbooks, compliance rules or the reasons a service was built the way it was.

So its output needs heavy human checking, which eats up the time it saved.

What makes an SDLC genuinely agentic

In practice, an agentic SDLC needs five things working together. Agents need deep context, grounded in your codebase, architecture decisions and production history rather than just the open file. They need safe execution in sandboxed, permissioned environments, where they can build and deploy without touching what they shouldn't. They need human-in-the-loop governance, with approval thresholds set by workflow and risk level. That way a dependency bump can ship on its own, while a schema change in a payments service waits for a senior engineer. Every action needs to be traceable, with a record of what changed, why and who approved it. Finally, agents have to work through the Git, CI/CD, cloud and observability tools you already run, instead of forcing you to rebuild your platform.

Where to start

Don't start where the demos look best. Start where your queue is longest. Measure lead time, review wait time, test flakiness and time to restore service. Then pick one bounded workflow, such as automated pull request review or incident triage for a single on-call rotation.

Define the guardrails before you scale, connect the context agents need, and expand stage by stage once the first workflow has earned trust. The principle that holds it all together is simple: agents do the work, engineers own the outcome.

Disclosure: I work at Revolte AI, where we're building an agentic platform for the full software delivery lifecycle.

Which stage of your pipeline is the real bottleneck right now: review, tests, deploys or incidents?

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?