Carly Stephens

Senior Marketing Manager, EMEA

Kodie Dower

Social Media & Content Marketing Manager

This year, Coder released its <a href="https://resources.coder.com/ai-maturity-model">AI Maturity Self-Assessment</a> alongside a five-stage framework for understanding how engineering organizations adopt agentic AI. The goal was to give engineering leaders a concrete way to benchmark where they stand and plan what comes next. Over several weeks, 100 engineering organizations completed the assessment.

The pattern in the responses was immediate and consistent. These are not organizations debating whether to use AI. The vast majority are already running agents. The gap is between that adoption and the infrastructure, governance, and measurement needed to support it.

Four numbers from the assessment define the core tension:

<img src="https://www.datocms-assets.com/19109/1776726138-frame-1.png" alt="">

Each of these gaps showed up independently across findings. Together, they tell a single story: adoption is real, and the operating model to match it is not. Here is what the data revealed and what the organizations pulling ahead are doing differently.

<h2>Finding 1: Most teams have moved past code completion</h2>

The most striking finding from the assessment is that individual AI productivity tools are no longer the whole story.

How teams currently use AI:

<img src="https://www.datocms-assets.com/19109/1776787521-frame-2.png" alt="">

Those running agents of any kind represent 61% of respondents. A <a href="https://github.blog/news-insights/research/survey-reveals-ais-impact-on-the-developer-experience/">2024 GitHub survey</a> found that 92% of developers were already using AI coding tools in some form and the move from passive suggestion to active agent execution has accelerated. The era of AI as a glorified autocomplete is over.

But the concentration tells a more specific story. Nearly 80% of respondents are still at the first two stages of the <a href="https://resources.coder.com/ai-maturity-model">maturity model</a>: Code completion tools and human-directed local agents. Only a small fraction have moved to cloud-based agents that respond to event triggers, and fewer still are experimenting with agents that identify their own work from product roadmaps or coordinate across the full development lifecycle. The field is early. Organizations that have not yet formalized their approach are not behind. They are exactly where structured adoption should begin.

The risk profile, however, shifts meaningfully between those stages. At Level 1, the primary concern is shadow IT proliferation as engineers adopt tools without security oversight. At Level 2, the stakes rise: agents handle entire features across dozens of files, integrate with version control and project management tools, and require consistent environments and permissioned data access to behave predictably. Most teams making that leap are not yet making the corresponding infrastructure investments.

Recent supply chain incidents have made this concrete. When <a href="https://coder.com/blog/your-developers-laptops-are-the-softest-target-in-your-security-stack">compromised npm packages harvested GitHub tokens and cloud credentials</a> from developer workstations during the Shai-Hulud 2.0 attack, the organizations that contained the damage fastest had already moved development off local laptops and into governed environments.

<h2>Finding 2: Agent usage is outpacing environment readiness</h2>

If most teams have moved past code completion, the next question is whether the infrastructure underneath them has kept pace. For the majority of respondents, it has not. 

The assessment asked how standardized developer environments are today, and the gap between adoption and the numbers diverge sharply from AI adoption rates.

Here&#39;s the current state of developer environment standardization:

<img src="https://www.datocms-assets.com/19109/1776726336-frame-3.png" alt="">

70% of respondents are running AI agents in infrastructure that was never designed to support them.

This gap is not abstract. Standardized environments are the execution layer that makes agent behavior predictable, auditable, and safe. Without them:

<ul>
<li>The same agent instruction produces different results on different machines </li>
<li>Security controls cannot be enforced uniformly across teams </li>
<li>The traceability required by enterprise compliance frameworks does not exist </li>
<li>Incidents are difficult to investigate or attribute after the fact</li>
</ul>

McKinsey&#39;s <a href="https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-ai-transformation-manifesto">AI transformation manifesto</a> makes this point directly: tech platforms are strategic assets that &quot;determine a company&#39;s execution speed&quot; and &quot;enable AI to scale responsibly,&quot; and without digital trust, there is &quot;no right to deploy AI.&quot; The assessment data confirms both principles as lived realities for the majority of respondents. Organizations that skip the foundational infrastructure work cannot build the trust or repeatability that scaling demands.

The fix is conceptually simple but organizationally hard: agents and humans need to work in the same governed environments, under the same constraints. When that parity exists, output is reproducible, auditable, and easy to hand off in either direction. When it doesn&#39;t, every team is running a slightly different version of reality, and incidents become impossible to attribute after the fact.

The <a href="https://coder.com/blog/what-the-claude-code-leak-tells-us-about-supply-chain-security">Claude Code source map leak</a> in March 2026 illustrated the upside of centralized environment management. Organizations that controlled tool versions through workspace templates were insulated from the downstream exploitation, while those relying on developers to pull from public registries were exposed within hours. 

<h2>Finding 3: Governance exists on paper but not in practice</h2>

Environment standardization is one half of the readiness equation. The other is governance: who is allowed to do what, under what constraints, and with what level of oversight. 

The assessment data suggests that most organizations have started thinking about this, but few have built anything enforceable.

This is how organizations approach AI governance:

<img src="https://www.datocms-assets.com/19109/1776726507-frame-4.png" alt="">

Only 31% have reached organization-wide governance or better. The security picture underneath those numbers is sharper still:

<img src="https://www.datocms-assets.com/19109/1776727179-frame-5.png" alt="">

The takeaway is that policy frameworks developed for human developers are not automatically extending to cover the agents those developers are now directing. 

Most organizations in the 44% pilot category are running binary governance: a tool is either approved or blocked. That works for human-scale adoption. It breaks down when agents operate at machine speed across dozens of repositories, each with different sensitivity levels, different compliance requirements, and different risk profiles.

The organizations closing this gap are moving toward tiered governance, where access and oversight scale with risk. Low-risk operations are enabled by default. Medium-risk work requires review. High-risk changes trigger multi-approval workflows. A centralized decision point applies those policies consistently across tools and teams, logging every AI-assisted operation with enough detail to reconstruct what happened and why. Automated checks for secrets, static analysis, and policy violations block unsafe patterns before code ever reaches review.

<a href="https://coder.com/blog/financial-services-has-an-ai-governance-problem">Financial institutions</a> have been early adopters of this layered approach, driven by regulatory pressure that makes the cost of getting it wrong existential. The pattern they are building, <a href="https://coder.com/blog/secure-agentic-ai-now-production-ready">centralized LLM gateways</a> for observability, process-level network isolation for agents, governed workspaces for auditability, is the same pattern the assessment data suggests every organization scaling agents will eventually need.

<h2>Finding 4: Adoption strategy reflects the governance gap</h2>

The adoption patterns respondents described mirror the governance data closely.

72% of teams are scaling AI from informal experimentation and carrying every unresolved security question with them into production.

<img src="https://www.datocms-assets.com/19109/1776727489-frame-6.png" alt="">

According to a <a href="https://www.gartner.com/en/newsroom/press-releases/2022-08-22-gartner-survey-reveals-80-percent-of-executives-think-automation-can-be-applied-to-any-business-decision">Gartner analysis of AI deployment failures</a>, the majority of failed enterprise AI initiatives collapsed not because the AI technology was inadequate, but because the organizational operating model was not built to support it.

The disconnect is clearest when you look at what the transition from local agents to cloud-based automation actually requires: standardized environments, permissioned data access, comprehensive logging, and cost monitoring. The majority of teams in this transition zone have completed none of those steps. They are running agents that need governed infrastructure on infrastructure that was built before agents existed.

This is what structured adoption looks like in practice: 

<ol>
<li>Start with one to two teams. </li>
<li>Select high-value and low-risk use cases like test generation, documentation updates, and code refactoring. </li>
<li>Establish daily learning loops to gather quantitative metrics and qualitative feedback. </li>
<li>Define explicit criteria for expansion like zero AI-related security incidents, measurable productivity improvements, and positive developer feedback. </li>
<li>Only expand when those criteria are met. </li>
</ol>

The <a href="https://resources.coder.com/ai-maturity-model">maturity model&#39;s adoption roadmap</a> phases this over 12 months, starting with inventory and policy, moving through focused pilots, and expanding to workflow automation only after environment parity and security controls are validated.

The organizations that move through this process deliberately are the ones that reach the genuine ROI inflection point: multiple agents operating in parallel on routine work, while engineers focus on architecture, problem framing, and review.

<h2>Finding 5: How teams measure success reveals what they value</h2>

Perhaps the starkest data point in the assessment involves measurement.

<img src="https://www.datocms-assets.com/19109/1776727591-frame-7.png" alt="">

Only 10% of respondents have linked AI adoption to business outcomes. The other 90% cannot yet answer the question that matters most to executive stakeholders: &quot;Is AI actually working?&quot;

Measurement shapes investment. The metrics that actually signal value fall into four categories: 

<ol>
<li>Productivity and flow (lead time for changes, throughput per engineer, PR cycle time from creation to merge) </li>
<li>Quality and risk (post-merge defects, security exceptions avoided, mean time to restore service) </li>
<li>Developer experience (satisfaction with AI-enabled environments, signal-to-noise in code reviews) </li>
<li>Cost (AI spend per unit of value delivered, environment utilization efficiency).</li>
</ol>

Without a framework that tracks these outcomes alongside adoption, the case for continued investment cannot be made. An <a href="https://coder.com/blog/ai-development-infrastructure-how-enterprises-get-control-without-compromise">LLM gateway</a> that logs every model interaction with attribution to teams, projects, and workflows makes this measurement practical by turning agent activity into queryable data rather than a black box. 

The teams at the top of the maturity curve treat measurement as infrastructure, not an afterthought. An executive dashboard tracking delivery, quality, security, developer experience, and cost is the mechanism that enables evidence-based expansion and stops bad investments before they compound.

<h2>What engineering leaders should do now</h2>

Agentic AI is no longer experimental for most engineering organizations. It is operational. <a href="https://coder.com/blog/ai-agents-are-already-in-your-codebase-is-your-infrastructure-ready">Agents are already running in your codebase</a>, directing workflows, proposing code changes, and in some cases taking on entire deliverables. The organizations pulling ahead are the ones building the operating model to match.

The real risk sits with the 44% running limited pilots under initial policies, moving toward broader agent usage without the infrastructure to support it. The gap between &quot;we have some policies&quot; and &quot;we have organizational-level governance and environment standardization&quot; is where most incidents occur and where governance debt compounds fastest.

Based on both the assessment data and the patterns of organizations that have successfully scaled agentic AI, four priorities stand out:

<ol>
<li>Standardize environments before expanding agent scope. Consistent, AI-ready infrastructure is the prerequisite for safe scale. Environments must maintain parity between human and agent workflows. Until they do, governance is theoretical.</li>
<li>Establish a centralized decision point with logging. Every AI-assisted operation, whether initiated by a human or an agent, should be recorded with enough detail to reconstruct what happened, when, and why. An LLM proxy that applies policy, routes requests to appropriate models, and maintains a complete audit trail is the mechanism that makes this practical at scale.</li>
<li>Move from ad-hoc to structured pilots with defined success criteria. Define what &quot;working&quot; means before expanding. Every informal pilot that scales carries its unresolved questions into production. The expansion criteria should be explicit: zero AI-related security incidents, measurable productivity gains, stable environment performance, and positive developer feedback.</li>
<li>Instrument outcomes, not just adoption. Usage metrics cannot tell you whether AI is working. Business outcomes like cycle time, defect rates, security exceptions avoided, and cost-to-serve can. Deploy a dashboard that tracks these before scaling, not after.</li>
</ol>

The data shows that most organizations have already made the decision to adopt agentic AI. The question now is whether the infrastructure and governance to support that decision will catch up before the risks do.

The organizations that get this right will ship faster with fewer defects, demonstrate compliance by design, and create space for engineers to do higher-leverage work. The ones that scale chaotically will spend the next 18 months retrofitting controls and watching delivery slow under the weight of governance debt that accumulated in the meantime.

Take the <a href="https://resources.coder.com/ai-maturity-model/AI_Maturity_Self_Assessment">AI Maturity Self-Assessment</a> to benchmark where your organization stands today. Read the <a href="https://resources.coder.com/hub/col/resource-center/the-5-stage-maturity-whitepaper">full AI Maturity Model whitepaper</a> for the complete five-stage framework, risk mitigation controls, and a 12-month adoption roadmap.

This year, Coder released its AI Maturity Self-Assessment alongside a five-stage framework for understanding how engineering organizations adopt agentic AI. Over several weeks, 100 engineering organizations completed the assessment. These are the findings.

What 100 Engineering Teams Revealed About AI Maturity and What to Do About It

We recently co-hosted a <a href="https://coder.com/events-webinars/aws-coder-workshop-build-faster-safer-dev-environments/register">hands-on workshop with AWS</a>, where attendees got a look at how Coder can be deployed on AWS sandbox, including AI-driven development workflows using Amazon Q Developer and Claude Code through Bedrock. 

What became clear across the session is that the conversation around cloud development environments has shifted. Teams are still adopting them to standardize where developers write code, but they&#39;re also increasingly building the infrastructure that makes agentic AI development possible without compromising security or governance.

Here&#39;s what that looks like in practice.

<h2>The local development problem hasn&#39;t gone away</h2>

<a href="https://about.gitlab.com/the-source/platform/how-to-accelerate-developer-onboarding-and-why-it-matters/">44% of organizations</a> say onboarding new developers takes more than two months. And across six multinational enterprises, <a href="https://getdx.com/blog/ai-cuts-developer-onboarding-time-in-half/">new hires without AI tools took a median of 91 days</a> to reach their 10th pull request. 

The root cause is almost always the same: local environments that accumulate dependencies, version-specific configurations, and setup steps that live on individual machines and break constantly.

Cloud development environments solve this by moving development off the laptop and into governed cloud infrastructure. For example, with Coder on AWS, workspaces are defined through templates and provisioned on demand. Developers pick a template and get a working environment in minutes. No local setup, no version conflicts, and no weeks spent getting code to compile.

As Greg Hoelzer, Senior Partner Sales Engineer at Coder, put it during the workshop: &quot;We don&#39;t necessarily change how you code. We change where you code — and then we can provide new capabilities in terms of how you code by enabling you to safely introduce agentic development into your workspace.&quot;

That second part (safely introducing agentic development) is where the real urgency is right now.

<h2>Why agents can&#39;t live on laptops</h2>

As organizations move from traditional development to coding assistants and eventually to autonomous multi-agent workflows, three things shift simultaneously: Security risks increase, compute costs rise as agents consume more resources, and productivity spikes dramatically.

The security risk deserves the most attention. Running an AI agent on a local machine creates what we call the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. When all three exist in one place, you risk data exfiltration through prompt injection or agent errors. An agent with broad credentials and internet access could leak sensitive information if it processes untrusted input — and on a developer&#39;s laptop, there&#39;s no clean way to prevent that.

This is especially pressing for regulated enterprises and government agencies. As Hoelzer described it: &quot;A lot of folks, especially in regulated and larger enterprises, are saying that they want the value and productivity they may get from an AI agent, but they need something like Coder so that they can safely introduce these capabilities into their organization.&quot;

Cloud development environments address this by placing each agent in an isolated workspace with scoped credentials, controlled network access, and clear boundaries around what the agent can reach.

<h2>Template-defined workspaces as infrastructure</h2>

The foundation of this approach is template engineering: defining development environments as infrastructure-as-code that your platform team controls centrally.

For example, a single Coder deployment on AWS can support multiple workspace types, each tailored to a specific persona or project:

<ul>
<li>Cloud-native development with relevant CLIs and toolkits pre-installed </li>
<li>Serverless development targeting architectures that might not match a developer&#39;s local hardware </li>
<li>Agentic development with AI coding agents configured and ready to run tasks autonomously </li>
<li>Gen AI prototyping with supporting services like vector databases deployed alongside the workspace</li>
</ul>

Each template can be version-controlled in Git and deployed through a standard GitOps flow, giving platform teams full version history and audit trails. The result is that spinning up a new developer environment (or an agent environment) takes minutes instead of weeks. And every environment is consistent, reproducible, and governed by the same policies.

<h2>Scaling agentic development securely</h2>

Where this gets really interesting is when you combine template-defined workspaces with AI agents that can operate autonomously.

Consider a practical workflow where you use one AI agent to scaffold an application from a set of requirements. Then, you hand that codebase to a different agent in a separate workspace and ask it to review the architecture with a focus on security. That agent identifies issues, and instead of handing them back to a human, it spins up additional workspaces (each with its own agent) to address the findings and submit pull requests back to the original project.

This kind of parallel, self-spawning agent workflow is only practical when each agent runs in its own isolated cloud environment. On a local machine, multiple agents working on different approaches to the same codebase would conflict with each other, corrupt branches, and create more problems than they solve. In cloud development environments on AWS, each agent gets its own workspace, its own resources, and its own scoped permissions.

You can also mix and match agents and models. This way, the same environment can run a task against one model, switch to a different one for a lighter-weight evaluation, and test a third for speed. The cloud development environment becomes a place to evaluate which tools and models work best for specific tasks, without any impact on other developers or production systems.

<h2>From developer productivity to AI infrastructure</h2>

Organizations that have already made this shift are seeing the payoff:

<ul>
<li>Palantir cut their time to first commit from 15 days to one hour. </li>
<li>Skydio replaced a homegrown solution and slashed dev VM spend by 90%. </li>
<li>A government agency moved all source code off 1,500 laptops into Coder, tightening security while improving the developer experience.</li>
</ul>

In each case, the initial investment was about developer productivity: faster onboarding, consistent environments, better security posture. But that same infrastructure is now what lets them scale agentic development: template-defined, isolated, cloud-hosted workspaces turn out to be exactly what you need to run AI agents securely and in parallel. The investment in developer productivity becomes AI infrastructure… without rebuilding anything.

As models get smarter and agents take on longer-horizon tasks, the teams that already have cloud development environments in place — with templates that define what agents can access, workspaces that isolate agent activity, and governance that scales alongside adoption — will be ready to move immediately.

To see the full webinar, check out the recording <a href="https://coder.com/events-webinars/aws-coder-workshop-build-faster-safer-dev-environments/register">here</a>.

We recently co-hosted a hands-on workshop with AWS, where attendees got a look at how Coder can be deployed on AWS sandbox, including AI-driven development workflows using Amazon Q Developer and Claude Code through Bedrock. 

How to Build Faster, Safer Cloud Development Environments on AWS with Coder

Danny Kopping

Staff Software Engineer, Coder

Most companies talk about dogfooding. At Coder, we clear the calendar and hand everyone the keys.

In February 2026, we held our second company-wide hackathon. Twenty-seven people formed nine teams. They had one week to build something new on top of Coder&#39;s own products. The only rule: ship it and demo it.

The hackathon was open to everyone, not just engineering. Marketers, designers, community managers, and demand gen leads all signed up alongside backend engineers and PMs. At a company that builds developer infrastructure, using your own tools is how you find out what works, what&#39;s missing, and what becomes possible when you give people the space to build.

<h2>How it worked</h2>

Teams formed around pitched ideas. Anyone could propose a project, recruit collaborators, and start building. The mix was intentional: engineers paired with designers, marketers teamed up with PMs, and teams brought fresh perspective to technical problems.

Each team had one week to go from idea to working demo. At the end, every team submitted a video walkthrough of what they built. Finalists presented live demos at the company All Hands, where the winners were announced.

<h2>What people built</h2>

Eight teams submitted projects that ranged from Kubernetes operators to branded graphics generators, and the creativity of what surfaced surprised everyone.

<h3>Infrastructure and platform engineering</h3>

Team R (Winner): This team tackled one of the most common pain points Coder customers face: initial setup. They built a Kubernetes operator that exposes Coder resources as native K8s objects, giving platform teams a familiar interface for managing Coder deployments. Then they went further, building an AI agent named &quot;Blake&quot; that lets teams deploy Coder clusters directly from Slack. The combination of declarative infrastructure management and conversational deployment turned a multi-step setup process into something teams could kick off in a single message.

<img src="https://www.datocms-assets.com/19109/1774038946-team-r.png" alt="">

Basement Musicians: This team modernized Coder&#39;s own local development setup. The existing tooling relied on an aging shell script that had grown unwieldy over time. The group replaced it with a Docker Compose configuration that ships with observability baked in, giving every developer on the team a faster, more reliable way to spin up a local environment.

SystemD &amp; CharlieV: This team built a workspace agent supervisor that automatically detects and restarts <a href="https://coder.com/blog/launch-dec-2025-agent-boundaries">agents after crashes</a>. When an agent goes down mid-task, the supervisor catches it and brings it back without manual intervention. The result is a resilience layer that becomes essential as teams run more autonomous workloads.

<h3>Observability and developer experience</h3>

NETGRU 2: Electric Boogaloo (Runner-up): This five-person team built a dashboard for tracking workspace connections with clean/dirty disconnect analysis and aggregate networking data. For operators debugging complex enterprise environments, visibility into connection health is critical. The tool gives platform teams the data they need to diagnose network issues before they escalate into support tickets.

<img src="https://www.datocms-assets.com/19109/1774039018-netgru2.png" alt="">

Side Eye (Third place): This team integrated <a href="https://coder.com/blog/coder-launches-blink-the-fastest-way-to-build-and-deploy-ai-agents">Blink</a> with <a href="https://coder.com/blog/inside-the-stack-secure-and-scale-ai-coding-agents-with-coder">Coder Tasks</a> so that AI agents can launch full dev environments directly from conversational context. The workflow eliminates context-switching entirely. An agent working through a problem in Blink can spin up an isolated workspace, run code, validate changes, and return results without the developer ever leaving the conversation.

<img src="https://www.datocms-assets.com/19109/1774038980-team-side-eye.png" alt="">

<h3>Internal tools and culture</h3>

Team Blink-182: This team built a <a href="https://blink.so/">Blink</a>-powered onboarding assistant that customizes the new-hire experience by role. The assistant walks new employees through their first 90 days with tailored guidance, surfacing the right documentation, introductions, and milestones based on whether someone is joining engineering, marketing, or another team.

Project Puppy Pals: The marketing team&#39;s three-person squad built a web-based branded graphics generator for self-service blog thumbnails, social images, and other templated assets. The team started by writing a product requirements document before building, which gave the AI agent clear structure from the start. The agent planned each feature before implementing it and almost one-shot every update. For a team of non-engineers, the experience was a proof point: agents are remarkably powerful when you set them up with the right context and communicate a clear vision.

Magenta: This cross-functional team spanned design, demand gen, community, and engineering. Their project explored what happens when you bring Coder&#39;s brand personality into the product itself. The group updated color treatments, created delightful error states, and hid Easter eggs throughout the interface. The project was a reminder that developer tools don&#39;t have to feel sterile.

<h2>What the hackathon revealed</h2>

Two things stood out.

From an engineering perspective, the hackathon showed how quickly teams can move from idea to working prototype when the development infrastructure is already in place. Teams spun up environments, built functional tools, and demoed them live in a single week. That speed reflects what Coder is building for its customers: less time configuring, <a href="https://coder.com/blog/inside-anthropics-ai-first-development">more time creating</a>. When the platform gets out of the way, people build faster than you&#39;d expect.

From a non-engineering perspective, the hackathon proved that AI agents have reached the point where they can <a href="https://coder.com/blog/vibe-coding-my-first-app-with-blink-no-cs-degree-needed">turn non-technical teams into builders</a>. Project Puppy Pals was a clear example. The team had no professional engineering experience, but by starting with a PRD and giving the agent structured context before each feature, they shipped a working tool in a week. Clear planning, frequent collaboration, and a shared vision turned out to matter more than technical expertise. 

&quot;One of my biggest takeaways was how much AI agents allow almost anyone with an idea to jump on a project and help with prototyping,&quot; said Chris Boone, Product Engineer &amp; Registry Guru at Coder. &quot;Coder makes that possible on a single platform, with people sharing workspaces and collaborating in real time. I also really valued the different perspectives that teammates from other parts of the company brought. There&#39;s a lot we gained from working so closely with people outside our normal teams.&quot;

The range of projects told its own story. Kubernetes operators. Connection debuggers. Graphics generators. Product Easter eggs. When you give an entire company the space to build, the ideas that surface span far beyond what any single team would come up with on their own.

<h2>What comes next</h2>

Coder builds tools for developers and AI agents. The best way to keep those tools sharp is to use them yourself and let the <a href="https://coder.com/blog/building-together-coder-s-community-vision-for-2026">entire company take a swing</a>. The second hackathon made one thing clear: when you lower the barrier to building, the results go places no roadmap would predict.

We&#39;re already thinking about the next one.

Want to build at a company where the tools you make are the tools you use? <a href="https://coder.com/careers">Check out our open roles</a>.

Most companies talk about dogfooding. At Coder, we clear the calendar and hand everyone the keys.

What Happens When You Let the Whole Company Loose on Your Own Product

In our recent <a href="https://resources.coder.com/anthropic-webinar?_gl=1*5c4qza*_gcl_au*MjA2Njc5NDY4NS4xNzY4MjQyMDU4*_ga*MTA0MDk2MDY5MC4xNzYwNDU0MzIx*_ga_FTQQJCDWDM*czE3Njk3MzYxMTQkbzE5OSRnMCR0MTc2OTczNjExNCRqNjAkbDAkaDA">webinar with the team at Anthropic</a>, the minds behind Claude Code told us that it will soon handle 30 minutes to an hour of autonomous work without supervision.

Not even six months later, today Claude Sonnet 4.5 has been shown to code for <a href="https://www.tomsguide.com/ai/claude-sonnet-4-5-can-code-for-30-hours-straight-and-it-could-change-the-future-of-work-forever">30 hours straight</a>.

This means that most development teams are building for the wrong future.

Right now, models need guidance, which is why the local interactive terminal interface works so well. You run Claude Code, watch what it does, course-correct when needed, and approve changes before they happen.

But the impending shift from interactive sessions to background agent work will change everything about your infrastructure requirements, which means most teams are optimizing for today&#39;s models, not tomorrow&#39;s. 

<h2>The local development bottleneck</h2>

Most teams start with one Claude Code instance running locally. It works great; you get faster at writing boilerplate, debugging issues, and building small features. Then you want more… and why wouldn’t you? Why not run one agent fixing tests while another works on a feature? 

But that&#39;s when the local setup falls apart. Agents conflict, your local branch becomes a mess, and managing the chaos takes more time than the automation saves.

The problem isn&#39;t the agents. It&#39;s trying to run multiple agents on infrastructure designed for one developer doing one thing at a time. And as models get smarter and increasingly work those long-horizon tasks for 30 minutes to an hour, locally managing worktrees and Docker containers becomes even more of a nightmare.

Suppose you want to run multiple Claude Code instances on different tasks — one refactoring a module, another fixing a CI issue, and a third building a prototype feature — and let them all run simultaneously while you focus on something else.

But on a local machine, this only creates chaos:

<ul>
<li>Multi-repo access gets messy when you&#39;re constantly using --add-dir or managing folder structures </li>
<li>Race conditions between multiple agents create conflicts and corrupted branches </li>
<li>Files get overwritten as one agent&#39;s changes confuse another agent&#39;s trajectory </li>
<li>Each agent needs isolation that your laptop wasn&#39;t meant to provide</li>
</ul>

These problems get worse as models improve: More autonomy means more risk without proper isolation.

For better or worse, your laptop wasn&#39;t designed to be a multi-agent orchestration platform.

<h2>The three scaling problems that remote environments solve</h2>

Running multiple Claude Code instances exposes three fundamental problems that local development can&#39;t solve cleanly.

<h3>Race conditions</h3>

When multiple agents run in the same local repository, they step on each other constantly. One agent edits a file while another agent reads it. Changes conflict. Git states become inconsistent. You end up with nothing more than corrupted branches and wasted work.

Remote environments eliminate this by giving each agent its own isolated workspace. Three agents can work on three different tasks in three separate environments.

No conflicts, no race conditions, and no agents confusing each other&#39;s trajectories.

<h3>Multi-repo context</h3>

Claude Code only knows what it can read in your codebase, what it fetches via MCP servers, and what you tell it. And when your work spans five different repositories, giving Claude that context locally means constant manual configuration. You either instantiate Claude in a folder above all five repos, or you repeatedly use --add-dir to expand access as you go. Both approaches are clunky and error-prone.

A remote environment, on the other hand, handles multi-repo configuration at the environment level. You specify which repositories belong together, and Claude walks into a workspace that&#39;s already set up correctly.

The context is there from the start.

<h3>Security isolation</h3>

Anthropic follows what they call the &quot;lethal traffic&quot; model for agent security. The rule is simple: never have all three of these in one place:

<ul>
<li>Access to proprietary data </li>
<li>Internet access </li>
<li>Access to untrusted data</li>
</ul>

When all three exist together, you risk data exfiltration through prompt injection or agent errors. An agent with full credentials and internet access could accidentally leak sensitive information if it processes untrusted input.

Remote environments solve this through sandboxing and restricted credentials, to where each agent runs with limited permissions in an isolated space. So, for example, you can give an agent read-only access to Kubernetes logs without giving it the ability to modify production infrastructure.

This approach lets agents remain capable while staying safely constrained. The environment does the security work instead of relying on the agent to police itself.

<h2>How Anthropic engineers are already leveraging remote environments</h2>

Anthropic engineers are already using Coder to run Claude Code remotely for multi-agent workflows. Not sequentially, not with constant babysitting — just agents working in parallel in isolated environments.

Multi-repo setups require specific configuration, and Coder handles this at the environment level. Instead of manually configuring access or repeatedly using --add-dir, you specify which repositories belong in an environment, and Claude walks into a workspace that&#39;s already set up correctly.

The result? No local bottlenecks. Engineers just kick off multiple runs on different tasks and let remote infrastructure handle the complexity.

<h2>Why you should build this infrastructure now</h2>

Anthropic sees remote environments like Coder as the future for longer-horizon agentic tasks.

With it, your engineers will immediately kick off multiple agent runs across different tasks. No scrambling, rebuilding your tooling, or discovering that your local development setup can&#39;t handle the load.

Teams that are prepared for this evolution will scale instantly as models improve. Teams that wait will be stuck managing Docker containers on laptops.

So set up your remote infrastructure now, configure your multi-repo environments, build your security model, and get your engineers comfortable with remote workflows. As models increasingly achieve these long-horizon tasks, you’ll be ready for it.

To hear more from Anthropic about how they’re building the future of Claude Code with <a href="https://coder.com/">Coder</a>, check out the <a href="https://resources.coder.com/anthropic-webinar?_gl=1*5c4qza*_gcl_au*MjA2Njc5NDY4NS4xNzY4MjQyMDU4*_ga*MTA0MDk2MDY5MC4xNzYwNDU0MzIx*_ga_FTQQJCDWDM*czE3Njk3MzYxMTQkbzE5OSRnMCR0MTc2OTczNjExNCRqNjAkbDAkaDA">full webinar</a>.

The impending shift from interactive sessions to background agent work will change everything about your infrastructure requirements.

Why Anthropic Engineers Are Running Claude Code Remotely with Coder

Building for 2026: Why Anthropic Engineers Are Running Claude Code Remotely with Coder

Financial services stands at an inflection point. For decades, the industry has operated under a simple assumption: developers write code on their laptops, push it to repositories, and let pipelines handle the rest. Security teams built controls around this model. Compliance teams audited it. The entire regulatory apparatus assumed humans were the ones writing software.

That assumption is breaking down.

AI coding assistants like GitHub Copilot and Cursor have already changed how developers work. The next wave, autonomous AI agents that can execute multi-step workflows without human intervention, will change everything else. Gartner predicts that <a href="https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027">15% of day-to-day work decisions will be made autonomously</a> through agentic AI by 2028, up from effectively zero in 2024. For financial services, where a single compliance failure can trigger nine-figure fines, this transition demands more than new tools. It demands new infrastructure.

<h2>The governance gap</h2>

The challenge facing FinServ institutions today extends beyond adopting AI. The real problem is adopting AI in a way that satisfies regulators, protects sensitive data, and scales across thousands of developers and agents.

Traditional approaches are failing. When developers and AI agents run on local laptops, audit trails become fragmented. API keys proliferate across teams. Shadow AI experiments pop up faster than security teams can track them. <a href="https://hai.stanford.edu/ai-index/2025-ai-index-report">Stanford HAI&#39;s 2025 AI Index</a> documented a persistent gap between organizations recognizing responsible AI risks and actually mitigating them. In regulated industries, that gap becomes liability.

Gartner&#39;s prediction that <a href="https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027">over 40% of agentic AI projects will be canceled by 2027</a> reflects this reality. The failures won&#39;t come from bad models or insufficient compute. They&#39;ll come from inadequate risk controls, escalating costs without clear ROI, and governance structures that were never designed for autonomous agents.

At one global financial technology company with over 15,000 engineers, platform engineering leadership identified these pain points early. The goal was clear: allow new developers to commit code on day one instead of day 15 or 30. That kind of onboarding friction compounds when you add AI agents to the mix. If human developers struggle with environment setup, secret management, and access controls, autonomous agents operating at machine speed will expose every weakness in the system.

<h2>The evolution toward agent-ready infrastructure</h2>

The institutions solving this problem have recognized a fundamental shift in how software gets built. The inner loop of development, that rapid cycle of writing, testing, and iterating on code, can no longer live on local machines. It needs to move to governed cloud environments where both humans and agents operate under the same controls.

This evolution has three phases.

The first phase centered on cloud development environments for humans. Organizations moved developers off laptops and into standardized, pre-configured workspaces. This solved environment drift, accelerated onboarding, and gave platform teams visibility into how development resources were being used. Coder has led this category for years, trusted by enterprises that need secure, self-hosted infrastructure they fully control.

The second phase, happening now, extends those environments to support AI assistants. Developers using Copilot, Cursor, or Claude need access to the same governed infrastructure. Models need authentication. Prompts need logging. Costs need tracking. Put simply: <a href="https://coder.com/blog/every-cursor-needs-a-coder">every Cursor needs a Coder</a>.

At a major investment bank, this challenge drove their adoption of Coder. Engineering teams needed a path of least resistance for centralizing model configuration as they rolled out AI coding tools across their organization. The specific pain points were familiar: slow feedback loops between analysts and traders, unreliable pipelines, environment inconsistencies. Coder gave them standardized environments where data scientists and analysts could use familiar tools like Jupyter Notebook while maintaining enterprise governance.

The third phase, emerging now, brings fully autonomous agents into production. These agents don&#39;t just assist developers. They execute tasks independently: fixing bugs, writing documentation, running test suites, responding to incidents. This phase demands capabilities that traditional development infrastructure was never designed to provide.

<h2>Building the governance layer</h2>

Autonomous agents require deterministic controls. An agent that can access your codebase, call external APIs, and execute commands needs boundaries that are enforced at the infrastructure level, not hoped for through careful prompting.

Coder&#39;s approach addresses this through three capabilities built specifically for the agentic era.

<a href="https://coder.com/docs/ai-coder/ai-bridge">AI Bridge</a> provides centralized governance for all model and agent access. Authentication flows through existing identity providers. Every prompt, every tool call, every model interaction gets logged and attributed. Cost visibility happens automatically. For compliance teams accustomed to auditing human actions, Bridge extends that auditability to AI.

<a href="https://coder.com/docs/ai-coder/boundary/agent-boundary">Agent Boundaries</a> enforces network isolation and access controls at the process level. Administrators define exactly which domains agents can reach, which tools they can invoke, which resources they can access. Everything else is blocked by default. When an agent encounters prompt injection or attempts to exfiltrate data, Boundaries stops it before damage occurs.

<a href="https://coder.com/docs/ai-coder/tasks">Coder Tasks</a> enables long-running autonomous execution with full observability. Agents can work for hours on complex tasks, filing PRs, running test suites, iterating on solutions, while maintaining the governance controls that regulated industries require. Humans can inspect progress, intervene when needed, and review results before anything reaches production.

Read more about how Coder enables foundational infrastructure for AI development in our recent blog <a href="https://coder.com/blog/launch-dec-recap">here</a>.

<h2>What this looks like in practice</h2>

One global fintech&#39;s trajectory illustrates what committed AI infrastructure investment looks like at enterprise scale. Over the past twelve months, their Coder deployment doubled in active users. The organization made a multi-year strategic commitment that signals confidence in governed cloud development environments as foundational to their engineering future.

The partnership extends beyond expanded licensing. This institution joined Coder&#39;s design partnership program to co-develop four capabilities critical to their AI adoption strategy:

<ul>
<li>AI Bridge will provide the compliance and governance observability their security teams require. </li>
<li>Agent Boundaries will enforce network isolation for autonomous agents accessing sensitive financial data. </li>
<li>Coder Tasks will enable background automation for build, test, and deployment workflows. </li>
<li>A custom integration will bring their internal AI tools directly into governed workspaces.</li>
</ul>

Perhaps most striking is where this organization sees the next frontier: deploying Coder directly on mainframe infrastructure. By running workspaces on existing mainframe systems, they can leverage ultra-low compute costs to power build and test processes across both developers and agents. It&#39;s a reminder that AI development infrastructure isn&#39;t about forcing organizations onto new platforms. It&#39;s about meeting them where their critical systems already live.

A major investment bank&#39;s use case shows the second-phase evolution. Analysts ship new models directly to traders via shared ports in Coder. Removing fragile pipelines accelerates iteration and collaboration. The outcome: faster response to changing market conditions, with governance maintained throughout.

As these organizations move toward the third phase, the infrastructure they&#39;ve built becomes the foundation for autonomous agent deployment. The same controls that govern human developers will govern AI agents. The same audit trails that satisfy regulators today will satisfy them tomorrow.

<h2>The path forward</h2>

The financial services industry has navigated technological transitions before. The move from trading floors to electronic markets. The shift from on-premises data centers to cloud infrastructure. Each transition required new governance frameworks, new compliance approaches, new ways of thinking about risk.

The transition to agentic AI development follows the same pattern. Organizations that build the right infrastructure now will capture the productivity gains while managing the risks. Those that bolt AI onto legacy governance structures will join the 40% of projects that Gartner predicts will fail.

Coder provides the foundation for this transition. Self-hosted to meet data sovereignty requirements. Open source for the auditability that regulated industries demand. Built for both humans and agents from the ground up.

The inner loop of software development has already started moving to the cloud. The question for financial services institutions is whether they&#39;ll lead that transition or react to it.

<hr>

Coder is the leading platform for AI Development Infrastructure, enabling enterprises to securely run human and AI-driven development workflows in consistent, governed environments. Learn more at coder.com.

Financial services stands at an inflection point. For decades, the industry has operated under a simple assumption: developers write code on their laptops, push it to repositories, and let pipelines handle the rest. Security teams built controls around this model. Compliance teams audited it. The entire regulatory apparatus assumed humans were the ones writing software. That assumption is breaking down.

Coder for Financial Services

Financial Services Has an AI Governance Problem. Here’s How Leading Institutions Are Solving It.

Quantum computing promises to revolutionize fields from drug discovery to materials science, but here&#39;s what most people don&#39;t realize: quantum computers need software to be useful. And writing software for quantum computers is fundamentally different from anything developers have done before.

In our recent webinar, <a href="https://resources.coder.com/webinar-psiquantum/psiquantum-webinar">How PsiQuantum Accelerates Algorithm Research With Coder</a>, Coder Product Manager Steven Kirby spoke with PsiQuantum’s Even Glemmestad and Ian Nanez about how they’re using <a href="http://www.coder.com">Coder</a> to build a development platform that enables the first useful, building-scale quantum computer. PsiQuantum, a leading quantum computing company, faced unique challenges when building their platform and in this webinar we explore how Coder provided a perfect solution.

<h2>What is quantum development?</h2>

Quantum development is the process of writing algorithms and software for quantum computers. Unlike classical computers that process information as binary bits (0s and 1s), quantum computers use quantum bits or &quot;qubits&quot; that can exist in multiple states simultaneously through a property called superposition.

This fundamental difference means quantum computers excel at specific types of problems where you have high connectivity between all elements, for example:

<ul>
<li>Chemistry and molecular simulation: Modeling how atoms and molecules interact </li>
<li>Drug discovery: Testing thousands of pharmaceutical candidates simultaneously </li>
<li>Material sciences: Designing new materials like room-temperature superconductors </li>
<li>Energy applications: More efficient solar panels and batteries</li>
</ul>

&quot;Quantum computers are very good at solving nature&#39;s equations,&quot; explained Even Glemmestad, Head of Product at PsiQuantum. &quot;Things like better drugs for diseases, corrosion-resistant materials, more effective solar panels. These are the applications we&#39;ll see first.&quot;

<a href="https://www.psiquantum.com/">PsiQuantum</a> has raised over $2 billion and recently broke ground on their quantum compute site in Chicago, with work on their Australian site soon to follow, to build million-qubit scale, fault-tolerant quantum computers. Not just five for proof-of-concept, but machines capable of solving real-world problems within the decade.

<blockquote>
“Better drugs for diseases, corrosion-resistant materials, more effective solar panels. These are the applications we&#39;ll see first.&quot;
</blockquote>

Fault-tolerant quantum computing impacts energy, finance, pharmaceutical, wide areas of fundamental scientific research, and many critical industries.

<h1>Why don&#39;t traditional development environments work for quantum computing?</h1>

You can&#39;t just spin up a quantum computer on your laptop to test code. Early-stage quantum computers are massive machines that operate at temperatures near absolute zero. And even the world&#39;s largest supercomputers can only simulate quantum systems up to about 30 qubits before running out of memory.

According to research published in <a href="https://journals.aps.org/prx/abstract/10.1103/PhysRevX.10.041038">Physical Review X</a>, the memory required to simulate quantum computers grows exponentially with the number of qubits. At 30 qubits, you&#39;ve maxed out a typical supercomputer. At 31 qubits, you&#39;d need two. By 50 qubits, there isn&#39;t enough classical computing power in the world to fully simulate it.

&quot;Any little disturbance, someone clapping their hands across the room, could in theory be enough to cause the data to flip,&quot; explained Ian Nanez, Senior Product Manager at PsiQuantum, describing quantum errors. Early quantum computers can only perform a few hundred operations before these errors make calculations meaningless.

This creates a fundamental challenge: How do you develop and test quantum algorithms when you can&#39;t run them on real hardware yet, and simulation has strict limits?

The answer requires specialized development infrastructure that can:

<ul>
<li>Provide massive compute resources instantly when needed </li>
<li>Run securely on private infrastructure (quantum IP is under constant attack from nation-states) </li>
<li>Deliver pre-configured environments with complex, rapidly-evolving quantum libraries </li>
<li>Support multiple development modalities (VS Code, Jupyter notebooks, terminal access) </li>
<li>Scale from small simulations to metal GPU instances</li>
</ul>

<h1>How did PsiQuantum solve this challenge?</h1>

After trying web-based tools that couldn&#39;t scale and managed cloud services that didn&#39;t provide sufficient security control, PsiQuantum built Construct, their quantum development platform powered by Coder.

Coder solved PsiQuantum&#39;s critical challenges:

<ul>
<li>Security and Control: Self-hosted deployment on PsiQuantum&#39;s AWS infrastructure protects quantum IP from constant attacks by nation-states and competitors. </li>
<li>Instant Massive Compute: Researchers provision any size machine in 1-2 minutes, from standard instances to metal P3 GPU machines. </li>
<li>Pre-Configured Environments: Complex quantum libraries come already installed. Researchers click a button and start writing code immediately instead of spending hours on setup. </li>
<li>Flexible Access: VS Code, Jupyter notebooks, or terminal access, all through the browser with the same powerful infrastructure underneath. </li>
<li>Custom Integration: PsiQuantum uses Coder&#39;s API to build their own Construct interface while maintaining complete control over workflows and security policies.</li>
</ul>

The result? Both internal researchers and external partners get fully-configured Quantum Development Environments (QDEs) in under two minutes, with access to PsiQuantum&#39;s specialized tools like Workbench, a Python library for creating advanced fault tolerant algorithms that handles complex operations like automatic qubit allocation and quantum error management.

&quot;We tried a few different approaches,&quot; Glemmestad said. &quot;But we really needed to step this up. We needed it integrated, secure, and self-hosted. We can&#39;t just outsource this. It&#39;s too central to what we do.&quot;

<blockquote>
&quot;We had to come up with a secure solution that keeps IP safe. I&#39;m happy Coder was the solution for that.&quot;
</blockquote>

PsiQuantum’s Construct leverages Coder to deploy fully-configured Quantum Development Environments (QDEs) fast

Want to see quantum development in action? <a href="https://resources.coder.com/webinar-psiquantum/psiquantum-webinar">Watch the full webinar</a> where the PsiQuantum team demonstrates Construct, walks through quantum algorithm development with Workbench, and answers questions about getting started in quantum computing.

<h1>Going deeper: Key challenges in quantum development</h1>

<h2>Why is quantum development so complex?</h2>

Early quantum researchers could draw algorithms gate-by-gate on whiteboards. That works for tens or hundreds of operations. It doesn&#39;t work for the billions of operations fault-tolerant quantum computers will perform.

In classical computers, bit flip errors are extremely rare. Quantum computers have two types of errors (bit flips and phase flips) that happen frequently. This is why early NISQ (Noisy Intermediate-Scale Quantum) systems could only do hundreds of operations before errors corrupted results.

Fault-tolerant quantum computing solves this through real-time error correction, enabling billions of operations. But now you need high-level programming abstractions, just as modern developers write in Python instead of manually managing memory addresses.

PsiQuantum&#39;s Workbench demonstrates this evolution. Quantum addition that would require manually managing dozens of qubits and gates becomes:

&quot;In classical computing, automatic memory management is normal,&quot; Glemmestad noted. &quot;But in quantum computing, this is not normal. You&#39;d have to painstakingly manage qubits yourself. When you get to huge scales, it&#39;s critical.&quot;

<h2>How do you ensure security in quantum development?</h2>

Nation-states actively target quantum computing IP because of its potential to reshape cryptography, national security, and entire industries. The threat is already real: according to research reported in <a href="https://www.techradar.com/pro/security/forget-ransomware-most-firms-think-quantum-computing-is-the-biggest-security-risk-to-come">TechRadar</a>, two-thirds of organizations are concerned about &quot;harvest-now-decrypt-later&quot; attacks, where adversaries collect encrypted data today with the intent to decrypt it once quantum computers become powerful enough. 

Critical industries like defense, telecommunications, and infrastructure face particular risk from nation-state actors with the resources to exploit quantum breakthroughs for espionage or data theft.

For PsiQuantum, this security landscape made self-hosting non-negotiable. Managed cloud IDEs simply couldn&#39;t provide the control needed when developing technology with such profound implications. By self-hosting and using Coder, PsiQuantum gained complete data sovereignty on their own infrastructure, the ability to implement custom security policies, full audit trails for environment access, and seamless integration with their existing security systems.

<h2>What role does open source play in quantum development?</h2>

Despite intense security requirements, PsiQuantum contributes heavily to open source quantum development. They&#39;ve released libraries including Bartik (for quantum resource analysis) and QREF (a common data interchange format for quantum systems), and offer a 90-day free trial of Construct with permanent free access for academics.

&quot;Open source plays a critical role in quantum software development,&quot; Nanez emphasized. &quot;All the different tools out there are exceptional, and we want to contribute to that ecosystem.&quot;

This balance between security and openness reflects a broader truth in quantum computing. A recent article in <a href="https://thequantuminsider.com/2025/07/19/researchers-push-for-open-source-quantum-tools-to-break-critical-industry-bottlenecks/">Nature Reviews Physics</a> argues that open-source development could accelerate the field by reducing costs, improving benchmarks, and expanding the talent pool. The researchers found that while competitive open-source initiatives exist for high-level software like algorithm compilers, lower layers of the quantum stack remain largely proprietary but could improve interoperability and foster collaboration.

Coder shares this commitment to open source. Our core platform is open source, enabling organizations like PsiQuantum to build on a foundation they can inspect, modify, and control while contributing back to the developer community. Whether you&#39;re building quantum algorithms or traditional applications, open platforms provide the flexibility and transparency that cutting-edge development requires. You can secure your IP while still advancing the broader ecosystem.

<blockquote>
&quot;Open source plays a critical role in quantum software development.&quot;
</blockquote>

<h1>Watch the full webinar</h1>

This article only scratches the surface of quantum development. In the full webinar, the PsiQuantum team demonstrates Construct in action, walks through quantum algorithm development with Workbench, explains resource profiling tools, and answers questions about getting started in quantum computing.

<a href="https://resources.coder.com/webinar-psiquantum/psiquantum-webinar">Watch the complete PsiQuantum webinar on the Coder YouTube channel</a> to see quantum development in practice and learn how infrastructure choices enable breakthrough technology.

For another look at how Coder powers cutting-edge development, check out our conversation with Anthropic about their AI-first development approach. <a href="https://coder.com/blog/inside-anthropics-ai-first-development">Read the Anthropic case study</a> or <a href="https://resources.coder.com/anthropic-webinar/anthropic-ai-coding-agents-webinar">watch that webinar</a>.

Building development infrastructure for cutting-edge technology? Learn how <a href="https://coder.com/">Coder powers secure, self-hosted development environments</a> that scale from quantum computing to AI development and beyond.

Quantum computing promises to revolutionize fields from drug discovery to materials science, but here's what most people don't realize: quantum computers need software to be useful. And writing software for quantum computers is fundamentally different from anything developers have done before.

Coder & PsiQuantum

Quantum Development 101: Building Software for the Next Computing Revolution

Kodie is a content and comms professional focused on enterprise and developer tools. A passionate open source advocate, he's all-in on content engineering, usin

AI-native Development

Secure Environments for 2,500+ Developers

Kodie Dower

Explore the latest from Kodie

What 100 Engineering Teams Revealed About AI Maturity and What to Do About It

How to Build Faster, Safer Cloud Development Environments on AWS with Coder

What Happens When You Let the Whole Company Loose on Your Own Product

Building for 2026: Why Anthropic Engineers Are Running Claude Code Remotely with Coder

Financial Services Has an AI Governance Problem. Here’s How Leading Institutions Are Solving It.

Quantum Development 101: Building Software for the Next Computing Revolution

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies