The Return of the Software Engineer

We've been spending a lot of time on our mountain bikes lately, and somewhere between the climbs and the descents, we keep coming back to the same question: Have we finally found the silver bullet for software engineering?

In 1986, Fred Brooks argued in No Silver Bullet that no single technology would yield a tenfold productivity increase in software development within a decade. His core insight was the distinction between essential complexity (the hard problems inherent to the domain) and accidental complexity (the mess we create with our own tooling and process). Eliminate accidental complexity, and you move faster. But essential complexity remains, and it demands skilled engineers to navigate it.

We've been building a lot of software lately, both by hand and with agents. Building with agents has driven us to rethink the role of the software engineer in an agentic world. And we can't help but think we've been here before.

Code without humans

We recently implemented a development approach inspired by StrongDM's AI Factory, which argues that "code must not be written by humans and code must not be reviewed by humans".

We found that the workflow reminded us of being back at Lucent Technologies, writing a design document for a project we wouldn't build until months later. This time was different. The "months later" collapsed into days. The pace of software development was faster than anything we'd experienced, and the quality was on par with any production system we've shipped.

And it wasn't just the build phase that moved faster. Requirements sharpened more quickly. We explored edge cases and refined acceptance criteria with an agent in minutes instead of days. Software design decisions that used to take rounds of whiteboarding came together in a single session. Acceptance testing and quality assurance accelerated too: generating test scenarios, validating behavior across boundaries, catching regressions early. Every phase of the lifecycle sped up, not just the coding.

That experience crystallized something we've believed for a long time. The bottleneck in software has never been typing speed. It's always understanding.

What matters at Initial Capacity

At Initial Capacity, we've never defined ourselves by a language or a framework. What sets us apart is how we build software — the mindset, the discipline, and the breadth we bring to every engagement.

Our industry has spent years fragmenting the engineering role into ever-narrower specialties. That's been a mistake. The best software engineers we've worked with operate across the full breadth of the craft, from requirements to user experience, to application architecture, to infrastructure - in greenfield and brownfield systems. They work directly with stakeholders and ask hard questions. They design interfaces that people can actually use. They decompose systems that can evolve independently. They understand how their code runs, scales, and fails in production. The era of narrowly-focused development (front-end only, back-end only) is fading.

When a small team of engineers can independently or collectively conceptualize the full picture, from user need to production deployment, the result is more coherent software built with far fewer miscommunications.

That breadth is also where agents (and most software teams) stumble. We've seen agents produce impressive code that solves the wrong problem, or scaffold infrastructure that doesn't match how the team actually operates. An agent doesn't know that the compliance team will reject that data flow, or that the user will never find that button. The engineering judgment to catch those things comes from people who've worked across the full lifecycle, not just the build phase.

This is why we're doubling down on our investment in software engineering. Not on writing tests first, pairing, or following a specific design pattern; those practices help, but they aren't the core. And not on figuring out how to pair with agents like Claude, though we do that well. We're investing in engineers who understand problems deeply before solving them, who ensure the "-ilities" (reliability, scalability, observability, security) are baked into the design from the start, and who find edge cases across teams before they become incidents. Who could switch from a conversation on Kubernetes to concurrency in Java without missing a beat.

The silver bullet we've been waiting for

We're starting to think Brooks' article might need an update. We may have found the tenfold productivity increase he said was impossible. Agents are that powerful.

But Brooks also wrote about the importance of great software engineers. He argued that the best way to improve software wasn't better tools, it was investing in the people who design it. Grow great software engineers, he said, because the difference between a good software engineer and a great one is enormous.

That's exactly the bet we're making at Initial Capacity. The silver bullet isn't the agent. It's the engineer who knows how to wield it.

Part-1 of a 2 part article series on AI