This post is a bit of thinking out loud. I come from an infrastructure as code background, but the more I think about where development is heading – and there’s a lot being said and debated in the industry right now – the more it spills into all sorts of areas, technologies, and concepts. So don’t pin me down on any of this; consider it a snapshot of what’s currently on my mind.

I’ve spent the last few years writing a lot of Bicep, Terraform, YAML pipelines and the like – fighting my way through docs, API definitions, community posts, and a lot of red deployment errors. The introduction of GitHub Copilot with its GPT models already marked a huge leap in developing and efficiency, by displaying inline suggestions and creating smaller snippets. Then agents came in, models got more capable seemingly week by week. With the recent jumps, especially Claude Opus, I genuinely believe the way we humans write code is going to shift away entirely.

Agents are not just LLMs spitting out some tokens anymore. An agent like the one in GitHub Copilot is a worker on steroids. It knows the code base, the decisions, the history of the project, the Git graph – equipped with a rich skillset through MCP servers, skills, and even sub-agents. Just give your agent the Terraform MCP server and it’ll fetch the provider documentation or query the Terraform registry itself. This entire ecosystem makes developing more powerful than it has ever been, which leads me to a few questions I keep circling back to:

• What’s the future of writing code?
• How do we ensure the code that gets generated stays along our requirements and guardrails?
• And do programming languages still need to look the way they do today, when the majority of their users are no longer humans, but agents?

From writing code to directing agents

A year ago, “agentic” mostly meant a loop wrapped around a model. Today, the agent has the codebase indexed, knows your architectural decisions, can call tools through MCP, and can spin up sub-agents for narrow sub-tasks. That’s a different beast.

The practical effect: the unit of work I hand off has gotten much larger. Where I used to ask GitHub Copilot to autocomplete a resource block, I now describe an outcome (“add a private endpoint for this storage account, follow our existing naming convention, add some evaluations for this deployment”) and review the result. The agent does the boring legwork – reading docs, matching the existing module style, wiring up the variables – and I do the part that needs judgement.

And this isn’t something that will come, it is already happening. Last year, Microsoft’s CEO Satya Nadella said that 20-30% of their code was already being written by AI. In April 2026, Google’s Sundar Pichai announced that 75% of all new code at Google is now AI-generated – up from 25% just eighteen months ago. Engineers still review and approve everything, but AI is doing the first draft.

If that trajectory continues, the human role moves further away from typing code and closer to specifying outcomes, designing platform constraints, and reviewing what comes out. Which is exactly where the next questions become interesting.

Where does the source of truth live?

When we hand off coding tasks to agents, we still need something to make sure the result lines up with what we actually wanted. It’s the same as briefing a developer: vague requirements give you vague output. We need a source of truth.

This is where I think the industry will move into spec-driven development (SDD). Instead of treating the code as the source of truth, you write a specification first – outlining requirements, methodologies, guidelines, constraints – and the code is generated from that spec. The spec, not the code, becomes the artifact you maintain over time. Future changes go into the spec; the code is regenerated.

Think about what that could actually mean in practice. If your spec defines what your application or infrastructure needs to do – the intent, the constraints, the guardrails – then swapping out the underlying implementation becomes a different kind of problem. Need to move from Terraform to Bicep, or from Bicep to Pulumi? In a spec-driven world, that’s not a migration project. You regenerate from the spec. The spec didn’t change; only the code that was derived from it did. That’s an extreme example, and we’re probably not there yet. But given the trajectory of the last few months, it’s not as far-fetched as it sounds.

GitHub released Spec Kit in August 2025 as an open-source toolkit for exactly this. A few concepts in it stand out to me:

• A constitution.md file that defines the non-negotiable principles for your project – testing approaches, conventions, technology choices. This is interesting because it’s effectively the place where platform teams can encode the rules they expect every project to follow.
• A structured workflow (/specify, /plan, /tasks, /implement) that takes you from intent to implementation step by step, with the spec staying authoritative throughout.
• It’s agent-agnostic – it works with GitHub Copilot, Claude Code, Gemini CLI, and others.

For our IaC world specifically, IBM has published IaC Spec Kit, a fork that adapts the SDD methodology to infrastructure provisioning especially. It separates what you need (cloud-agnostic resource specs) from how you do it (specific provider, module choices), and generates Terraform from there. I haven’t run it through anything serious yet, but the direction is the right one for IaC: the spec captures the architectural intent, the code is regenerated when things change.

The mental shift is the part that matters more than the tooling. As GitHub put it: the what before the how. Whether Spec Kit specifically is the framework that wins is almost beside the point – the methodology is what’s being figured out right now, and IaC is a particularly good fit because most of what we write is already a declaration of intent.

Will programming languages still look human in the future?

Programming languages and frameworks are essentially the interface between humans and the software or infrastructure we build. They’re designed for us: readable syntax, intuitive abstractions, ergonomic APIs.

If the human part fades away, do these languages still need to look this way? Will we get more agent-native languages? Or will agents skip the abstraction entirely and start writing closer to machine code, with the agent itself becoming the interface that we – the humans – interact with?

It feels a bit absurd to have machines generating human-oriented code that gets compiled and consumed by machines anyway. There’s a layer in there that exists purely for our benefit, and that benefit is shrinking.

I don’t have a clean answer here. But I do think the next generation of languages, frameworks or DSLs might look very different if we design them around how agents read, navigate and modify code rather than how humans do – denser, more uniform, fewer abstractions, more machine-friendly type systems. And the more this shift happens, the harder it becomes for the humans still in the loop to spot-check what’s being generated. Which loops directly into the next two sections.

Platform governance becomes the safety net

Here’s the flip side of the productivity gain: enormous amounts of code are being generated at speed, often assembled from shallow pattern-matching rather than genuine understanding. That introduces real risks: security vulnerabilities from misapplied patterns, performance problems from code that works but doesn’t scale, and maturity gaps where nobody fully owns what was built. All of that pressure lands on the platform underneath.

Mature governance has always been important. It’s becoming critical. If you can’t trust that every line of code generated against your platform was written with full understanding of your constraints, you have to enforce those constraints technically. In an Azure context, that means doubling down on the things that have been good practice for a while:

• Azure Policy at management group and subscription level to deny non-compliant resources before they’re deployed: allowed regions, no public network access, service configurations, security settings, mandatory diagnostic settings, etc.
• Solid RBAC with custom roles where the built-ins are too broad. Least privilege has to be the default, not the goal.
• Deny assignments and resource locks for the things that should never change.
• Landing zones with policy-as-code baked in from day one, so the guardrails travel with every new subscription instead of having to be re-applied by hand.

The point is: when generated code might break your rules, you want the platform itself to push back. An Azure policy denying public network access on a storage account doesn’t care whether a human or an agent wrote the Bicep template that just got submitted – both are denied the same way.

The widening expertise gap

There’s a related concern that’s been on my mind. As code generation becomes accessible to almost anyone, the gap between people who actually understand what they’re shipping and people who are gluing together suggestions is getting wider. And it’s hard to see, because the output looks plausible.

Engineers end up justifying decisions an agent made, sometimes without fully understanding why those decisions were made. “The agent suggested this provider configuration” is not a design rationale. In a careful code review, that gets caught. In a fast-moving sprint with a busy reviewer and a polished-looking PR, it might not.

This is one of the places where the spec-first approach could actually help. If the spec captures the why, the constraints, the rationale, the trade-offs, then a reviewer can check whether the generated code matches the intent, not just whether it compiles or deploys. The spec becomes the artifact that carries expertise across the team and across time, even when the code underneath gets regenerated three times.

I don’t think this gap is going to close on its own. It might be that the role of senior engineers shifts more toward writing and reviewing specs, designing platform guardrails, and curating the agent’s tooling – and less toward writing code line by line. Which, honestly, is probably where the most value was anyway.

Where this leaves me

Coming back to where I started: the question I keep landing on is whether the languages and IaC frameworks we use today will keep evolving the way they have, given that they’ll mostly be consumed by agents in the near future. If agents are the primary writers, the optimization target shifts. Maybe HCL and Bicep keep going. Maybe something agent-native emerges and takes over the next ten years.

Either way, the parts I’m most sure about:

1. Specifications, not code, will increasingly be where intent lives.
2. Platform governance – Azure Policy, RBAC, deny assignments, landing zones – stops being a nice-to-have and becomes the safety net under everything else.
3. The expertise gap is real: the people who can write good specs and design good guardrails are the ones with a durable advantage – but that only holds if they understand the underlying technology well enough.

These are early thoughts and I’m sure I’ll change my mind on parts of this. If you’ve been thinking through similar questions, or you disagree with any of this, hit me up – I’d love to hear it. Cheers!