Software Engineering Is Becoming Metaprogramming

Clay Head of Technology Mark Hahnenberg talks with Stephen Poletto about why software engineering is becoming metaprogramming, the observability layer Clay is building for its coding agents, and a closed-loop QA agent his team built that finds bugs every day. An audio version of this interview is available on Spotify.

Three Takeaways

• Software engineering is becoming metaprogramming. In Hahnenberg's view, engineers will increasingly focus on building the guardrails and containers within which agents write code.

• The meta-level work starts with observability. A new dedicated team at Clay is building visibility into where agents succeed, where they struggle, and which parts of the codebase need attention first.

• Intuition comes before efficiency. Clay supports any AI tool an engineer wants to try, with no mandates or leaderboards. The skill of directing agents, Hahnenberg believes, only comes with practice.

Introduction

Ask engineering leaders what they most want to know about AI, and it's no longer which coding tools to invest in. It's what the job becomes when agents do more of the building.

As Head of Technology at Clay, Mark Hahnenberg focuses on improving agentic software development lifecycles within the company as it continues to pioneer the go-to-market engineering category it invented. His answer to the bigger question runs through everything Clay is doing right now: engineers are experimenting with building the system that builds the system, so to speak. What he revealed on Stack Trace is one of the more concrete previews available of where engineering is headed.

Building the Container

At Clay, Hahnenberg launched a provisional “agentic DevEx” team, as he calls it, to lay the foundation for constructing and improving the entire agentic engineering lifecycle.

At the core of what they're building: an observability layer for agents. Engineers are vocal, but agents won't surface challenges unless prompted. The observability layer uncovers what agents won't volunteer: which teams are using which agents, how often agents ship code that doesn't need immediate rewriting, and where in the codebase they struggle.

The team's output isn't product code; it's the instrumentation that makes every agent writing product code more effective.

Hahnenberg finds it telling that when he compares notes with other companies, few are focused on this specific area. His view is simple: you can't really know how your agents are performing, or improve how they perform, without visibility.

Closing the Loop

The next question is how much agents can accomplish on their own, and Clay's first answer is already running in production.

One of Hahnenberg's current projects is a new workflow builder inside Clay with an MCP server. On top of it, the team has deployed a Devin workflow that operates much like a fuzzer: it builds a random workflow through the MCP server, runs tests against it, reads the logs, figures out what's broken, makes and verifies fixes, and opens a pull request. The agent handles the whole cycle, from building to fixing, with no human in the middle. It's Clay's first foray into what Hahnenberg calls "closing the loop." 

What’s key is that no one at Clay wrote those bug fixes; their engineers built the system that produces them. That, in Hahnenberg's view, is what the role is becoming.

The same project taught him his most practical lesson about guiding agents. When the Devin agent got stuck on a string of problems, Hahnenberg didn't change anything about its environment. He just asked it questions, Socratic-method style, about what it needed, and the agent realized it could do things it had claimed it couldn't. "Don't assume that what the agent is telling you it can't do, it actually can't do," he says. Agents, he finds, give up too easily. Once the agent works through a problem, the playbook gets saved so it doesn't have to learn the same lesson twice.

Learning to Operate at the Meta Level

A world of closed loops and background agents raises the question: what does senior IC engineering look like from here?

According to Hahnenberg, there's ordinary abstraction, where you still operate inside the system (just at a higher level with less detail) and there's metaprogramming (Lisp macros, C++ templates, Ruby DSLs), where the components of the system become objects you manipulate directly.

The future of engineering, he believes, is the second kind: metaprogramming for software engineering. "You're not building the system directly anymore; you're building the system that builds the system," he says. The engineer builds the guardrails and the container within which an agent builds the intended product, then offers guidance while the agent works out how to meet the specification. The skill to develop now is precision: being able to articulate exactly how you want something built and what specific goal you want to achieve.

That kind of precision only comes with practice, which is why Clay's approach to adoption is deliberately permissive. Engineers at Clay are free to try any agentic coding tool. Most have gravitated toward Claude Code and Cursor, but there are no mandates, leaderboards, or gamified metrics. "We're really optimizing for adoption right now, more than efficiency," Hahnenberg says.

And once building refocuses on specification, the circle of builders widens. The designer on Hahnenberg's project uses Claude Code to build interactive versions of their design ideas, at far higher fidelity than Figma allows. Someone on the go-to-market side, not an engineer, recently demoed a Chrome extension they'd built for themselves. Knowing precisely what you want and directing a system to build it was never exclusive to engineering.

What This Means for Leaders

Hahnenberg's framing gives engineering leaders a better question than "how do we adopt AI tools?" It's: what does your organization look like when engineers are building the system that builds the system?

Clay's answers so far: give agents their own developer experience function, starting with observability. Read agent failures as a refactoring roadmap. Let people build intuition before you measure them on efficiency. And start thinking now about how juniors develop judgment when the tasks they used to learn on are the first ones agents absorb.

Hahnenberg is candid that everyone, Clay included, is still experimenting with solutions. But his bottom line is optimistic: engineers will become more efficient, and they'll build more ambitious software than they could before. The job isn't disappearing. It's moving up a level.

For more episodes of Stack Trace, subscribe to Span's YouTube channel or to the Stack Trace podcast on Spotify.