Where Does the Foundation Come From?

I've been a software engineer for more than 20 years, and I can say without hesitation that I'm more productive with agentic AI in the loop. In areas where I'm already an expert, I move at least two to three times faster. Additionally, AI has let me contribute in areas I'd normally never touch.

But there's a catch, and it took a summer of interns at Digits to make me see it clearly. I wrote about it at length in a recently published ACM Queue article, "Where Does the Foundation Come From? — here's the short version, and what it taught us about how engineers actually learn.

The reason I get that multiplier is that I can lean on two decades of experience. I know what questions to ask. I can spot when generated code is subtly wrong. I can look at an architecture document and know which paragraph is doing too much.

New graduates are now expected to be more productive too — because of the same tools. The question no one has answered: where do they get the foundation those tools assume they already have?

The deep end

This summer, I led the internship program at Digits. When the interns arrived, our first instinct was to bring them straight to where our full-time engineers already are. We had recently reshaped our development environment around agentic AI — virtualized sandboxes where models operate, skill-based workflows for well-defined tasks, the whole stack of patterns that lets a Digits engineer hold ten threads at once.

So on day one, we handed them everything. Container environments, code-exploration agents, a skill that walks you through producing an architecture document — the one- to three-page doc every Digits engineer writes before making a nontrivial change to a service. For experienced engineers, that skill removes about half the boilerplate and frees them to focus on the load-bearing design decisions.

The interns used it, and they produced architecture documents that were technically complete. Every section filled. Every code reference correct. And they were unreadable.

Summary sections that should have been three sentences ran three paragraphs. Dependency sections cataloged every import statement of every adjacent file. Test plans rehearsed the entire conceptual testing landscape instead of naming the two or three things that actually needed testing.

The interns hadn't failed the skill. The skill had assumed judgment they hadn't had a chance to build yet — what level of detail fits the audience, what's load-bearing versus scaffolding, what can be left out because the reader can be trusted to know it. Without that direction, the tools produced everything they could, and more powerful tools only made it worse.

The symptom looked like a tool problem. It was a grounding problem.

The fix: a phased on-ramp

So we adjusted. We rebuilt the program around three phases, each deliberately brief — measured in days, not weeks, because these were bright graduates and learning speed was never the issue. The issue was sequence.

Phase one: manual coding. Closed environment, no agentic assistance, write the code by hand against the real codebase. Not to prove they could — most already could — but to build vocabulary. When an agent later referenced those components and conventions, they'd recognize them instead of parsing them from scratch.

Phase two: AI as assistant. We do a lot of paired programming at Digits, and this phase treated AI the same way — a pairing partner, not a co-author. Explain this function. Walk through this control flow. Suggest a single-method implementation. By the end, the interns could navigate the system and form their own positions before the agent suggested one.

Phase three: agentic. Only then did we hand back the full stack. And this time, when an agent produced an architecture document, they could read it and say: this paragraph is doing too much, this section is the actual contested decision, this dependency is wrong. They had what the tools assumed they had to begin with — direction.

We reinvented something old

Walking the program back, we realized we'd accidentally compressed a career arc. An engineer in the 2000s started by writing code by hand because there was no other way, picked up assistance gradually as they were ready to direct it, and eventually orchestrated sophisticated tooling because the foundation underneath was already built. That arc used to take years, mostly by accident. We compressed it into weeks — but we didn't skip a single phase.

AI is the accelerant within each phase, not a substitute for the phases themselves. For an engineer with grounding, AI is a multiplier. For an engineer without it, AI creates a productivity illusion: output gets larger, faster, and more polished, while the understanding underneath doesn't grow with it.

Why this matters for how we build

This philosophy isn't confined to our internship program. It's the same principle at the core of how we build Digits for accountants.

Digits does the repetitive work — booking, reconciling, verifying — and brings professionals in exactly where judgment is required. The accountant isn't bypassed; they're elevated to the work only they can do: reviewing exceptions, applying expertise, standing behind the outcome. The system amplifies judgment. It doesn't pretend to replace it.

AI can compress the path to expertise. It cannot replace the path.

The full paper goes deeper — including what this means for how universities should teach and assess software engineering in an AI-forward world. Read it here.