Who Builds the Mission Now? How the IC Is Expanding the Definition of a Developer

From IC Insider Coder

By Austen Bruhn, Staff Solutions Engineer — US Public Sector at Coder

The hardest problems in IC software development in 2026 are not technical. They are organizational – it’s the challenge of overcoming mission knowledge gaps between the people who understand the problem and the people who can actually solve it.

The person who best understands a mission gap — the all-source analyst who has spent five years tracking a specific threat actor, the SIGINT specialist who recognizes patterns invisible to anyone outside their collection account — is rarely the person positioned to act on it. That knowledge gets translated into a requirement. That knowledge gets written down as a requirement, then turned into a statement of work and, ultimately, that becomes a contract. Somewhere in that chain, irreplaceable operational insight loses most of its fidelity.

This bottleneck rarely makes it into conversations about IC modernization. Infrastructure debt does. Talent retention does. Procurement timelines do. But the gap between the people who understand the mission and the people authorized to build tools for it is at least as consequential as any of those. And it’s been widening while the rest of the conversation moved on.

A new kind of builder is emerging

The conversation is starting to shift. CDAOs at major defense primes are investing in citizen developer programs — training analysts, logisticians, and specialists to build workflows, notebooks, and data transformations without traditional coding backgrounds. The Marine Corps Chief AI Officer has pushed for models where operators contribute directly to the tools they use in the field, rather than filing requirements and waiting. Gartner estimates that citizen developers now significantly outnumber professional developers in large enterprises, and the ratio is still moving even in the Defense Industrial Base (DIB).

What’s making this realistic rather than aspirational is the state of AI-assisted development. The DoD’s own Chief Digital and AI Office acknowledged in a February 2026 solicitation that its software development workforce “currently lacks standardized, enterprise-wide access to AI-enabled coding tools that are commonplace in the commercial sector,” and that the gap “limits developer productivity [and] slows the delivery of mission-critical software.” That gap is exactly the opportunity. An analyst who can describe a problem clearly, evaluate whether a proposed solution makes sense, and iterate is someone who can build useful things today in a way they couldn’t before. The underlying technical knowledge required has dropped significantly. The domain expertise those analysts already carry has not.

What this looks like on the mission

Take an OSINT analyst who has identified a gap in how the community is processing a new collection source.

Under the model most programs still operate on, that insight gets written down as a requirement. It gets reviewed, prioritized, and eventually turned into a statement of work or added to an existing program. Months later—sometimes longer—there’s a tool. Whether it still fits the original need is a separate question.

The alternative looks different.

That same analyst opens a compliant development environment, selects a template aligned to their data stack, and starts prototyping. An AI coding assistant helps fill in the gaps where they don’t have deep engineering experience. Within a few days, something is testable. Within a week, it’s shareable.
The key difference isn’t just speed. It’s fidelity. The person who understood the problem is still the one shaping the solution.

DoD’s Advana platform—a centralized, CAC-enabled data and analytics environment—has already shown what happens when that barrier is removed. Analysts can access data, build workflows, and share useful outputs without standing up a program first.

The opportunity for the IC is extending that model beyond analytics into broader development, so domain experts can do more than analyze data. They can build the tools they need, when they need them.

The infrastructure problem underneath all of this

None of it happens if standing up a compliant workspace takes two weeks or longer.

That’s the constraint that kills citizen developer initiatives before they start. When provisioning access to a development workspace still means navigating approvals, provisioning steps, and configuration work that only a handful of people understand, the friction is high enough that only few engineers bother. Domain experts who might prototype something valuable just don’t. The opportunity cost is invisible, so it doesn’t show up in any program’s risk register.

There are also constraints that don’t go away: accreditation boundaries, ATOs, and networks that weren’t designed for rapid iteration. Those are real, and they shape what’s possible.

Platform engineering addresses this at the source. Small, focused platform teams define what compliant development looks like, build it into self-service templates, and let anyone with access spin up a workspace in minutes — pre-configured, policy-compliant, ready to go. Workspace infrastructure is defined as code. Security controls are built in rather than added after the fact. The same template that works on an unclassified network works identically on a classified one, in an air-gapped facility, without asking the builder to re-platform when they change networks.

That last point matters more than it might sound. A senior analyst willing to try building something shouldn’t have to become a system administrator first. The infrastructure either gets out of the way or it doesn’t.

Security as the floor, not the door

The compliance model most programs inherited treats security as a gate: something you pass through at the beginning or prove at the end. That made sense when developers were a small, specialized population that could be managed through access controls and vetting processes.

It breaks down when the goal is to expand who builds. You can’t selectively enforce compliance based on whether someone has a traditional development background. What you can do is move the enforcement into the platform itself. Toolchain access is defined before anyone writes a line of code, audit logs are generated automatically, and policy is traveling with the workspace rather than depending on individuals to follow procedures correctly every time.

In a platform model, the controls are defined once and enforced everywhere. NIST’s Secure Software Development Framework (SSDF) has been making this argument at the policy level for years: security should be continuous and integrated, not a final checkpoint. Platform engineering is how that principle becomes operational reality. When compliance is built into the platform, it stops being the mechanism that determines who gets to start building.

What the IC actually stands to gain

The agencies that figure out how to turn domain expertise into repeatable, shareable capability will have something that can’t be easily replicated by competitors or contractors. The analyst who developed a novel approach to a collection problem retires, and under the current model, that approach retires with them — maybe preserved in a report, maybe not. A Science study published in early 2026 found that productivity gains from AI-assisted coding were sharpest among experienced practitioners — not junior developers. The IC’s senior analysts, operators, and specialists are exactly that population.

When those people can build tools that encode what they know, expertise becomes institutional rather than individual. An analyst’s data transformation becomes a template. A targeting workflow becomes a starting point for the next team. The distance between having an idea and building something useful around it starts to compress.

The competitive pressure here is real. Near-peer adversaries are moving aggressively to apply AI to their own software development and autonomous operations. The IC’s response can’t just be better infrastructure for the engineers it already has. It needs infrastructure that expands who gets to build, and that starts with ensuring the people who understand the mission are the ones shaping the tools.

The IC’s advantage will belong to the organizations that stop separating those two groups at all.

Austen Bruhn is a Staff Solutions Engineer for the US Public Sector at Coder, where he works with government and defense programs on secure, compliant development infrastructure across classification levels.

Coder is the AI software development company leading the future of autonomous coding. Coder helps teams build fast, stay secure, and scale with control by combining AI coding agents and human developers in one trusted workspace. Learn more at coder.com.

About IC Insiders

IC Insiders is a special sponsored feature that provides deep-dive analysis, interviews with IC leaders, perspective from industry experts, and more. Learn how your company can become an IC Insider.