The Pendulum Swings Back

I've been working in software development for nearly three decades. When I started, the way we built systems was very different from how most teams operate today.

We didn't have product managers, project managers, scrum masters, or dedicated frontend and backend developers, or DevOps engineers. When a client came to us with a problem, I would sit with them, understand their business, and translate that into a working system.

I would sketch out the main screens, identify the core business logic and entities, choose the right third-party components (and factor their cost into the proposal), draw a Gantt chart, estimate the timeline and budget, and put together a proposal. Once approved, we built it. We also handled database optimization and application server configuration because we believed — correctly — that a great system requires the whole stack to work well together.

The systems we delivered tended to be solid. They solved real problems, performed well, and we supported many of them for years. Quality wasn't something we bolted on later; it was baked into how we worked — and that single discipline is what prevented the slow, expensive unravelling that "ship fast, fix later" so often produces.

Then the industry changed.

Specialization became the norm. Roles multiplied. Processes became more layered. I watched talented people become excellent at one slice of the work while losing visibility of the whole. I took on some of the new titles myself and saw the same pattern from the inside: many smart colleagues were only ever seeing part of the picture.

As a leader, I made a deliberate choice. I started actively looking for — and trying to develop — engineers who were curious beyond their job title. People who wanted to understand the business problem, not just implement a ticket. People who were willing to step into adjacent areas and learn. People who cared about the whole system.

Time has consistently shown me that these "all-rounded" engineers punch above their weight. They make better architectural decisions, spot problems earlier, and deliver solutions that actually hold up in production.

Now, with the arrival of capable AI tools and agents, something interesting is happening.

The way I used to work — understanding the user problem, the product context, the business logic, the data layer, the frontend experience, and the deployment concerns — suddenly feels less like an outdated habit and more like a genuine advantage.

One person (or one human + AI agent) can now operate meaningfully across layers that used to require an entire team. I can explore product ideas, understand user pain points, reason about frontend and backend trade-offs, consider data implications, and think about how something will actually run in production — all in the same head.

It doesn't mean one person should do everything alone. It means the ability to see and connect across the entire system has become dramatically more powerful.

Interestingly, this idea seems to be resonating more widely. AWS CTO Werner Vogels has been talking about the rise of the "Renaissance Developer" — someone who combines technical depth with broad systems thinking and architectural vision. Many experienced engineers on forums and in conversations are describing a similar feeling: the skills that made us feel like dinosaurs during the heavy specialization era are suddenly relevant again.

I don't think this is nostalgia. I think the pendulum is swinging back toward something healthier.

The best teams I've been part of weren't collections of narrow specialists executing tickets. They were groups of curious builders who understood the problem deeply and cared about the end result. AI doesn't replace that — it amplifies it.

For those of us who have been around a while, this moment feels oddly validating. The fundamentals we learned the hard way — talking to users, thinking in systems, owning outcomes end-to-end, and staying curious across boundaries — are becoming more valuable, not less.

And for the next generation of engineers, I hope we can pass on both the new tools and the old mindset: that great software comes from people who can see the whole picture.