The End of the Shallow Developer

I used to own and operate a 12-week coding bootcamp. It worked. We taught people the core fundamentals of OOP in Java and C#, how to design and connect to relational databases, and how to build dynamic web applications.

For many years, this was a viable pathway for people. Businesses were short on implementers, and frameworks provided enough abstraction that the learners could join teams and start producing value reasonably quickly.

The model worked because the industry had valuable work for people who were just getting started.

I always encouraged my students heading out into real jobs that this was just the start, and they would need to continue developing their skills in both depth and breadth. Some embraced this and went on to build very successful careers. Others didn't and washed out of the field when their salary expectations exceeded their value.

And now, we have AI. I've spent the last few years learning to use it, and the whole time I've been thinking about what it means for educating the next generation of IT professionals. I work with learners, schools, and enterprise companies. I'm a software architect, educator, and four-time entrepreneur.

And I have some things to say.

The Commoditization of Code

I don't believe anyone can seriously argue that AI tools haven't made producing volumes of code cheaper. And this really isn't anything new. After all, back in the mid 2000s, I used a T4 template that would pull a database schema and generate a repository pattern plus CRUD stored procedures. Because writing that code was tedious. The value was never in the grunt work; it was in deciding what to build and why.

The problem today is that beginners and non-technical leaders don't understand the difference between implementing a spec and understanding things like data integrity, authentication, authorization, system boundaries, operational requirements, and long-term maintainability.

This is the difference between a software developer and a software architect.

Why Shallow Is Problematic

Historically, we have had a place for shallow developers. As an architect, I could design a front-end interface, but I still needed a team to implement it. And I see this in the prompting:

• A shallow developer writes: "Build me an authentication system."
• I write a several-page specification on how I want an authentication system that supports OIDC, short-lived access tokens, refresh-token rotation, audit logging, and tenant isolation. As part of the process, I've also thought about the threat model and understand the trade-offs of using stateless JWTs.

I've never met a junior developer who knows what those terms mean, let alone understands their repercussions.

Now, I know some AI boosters will say, "Well, AI can write a detailed specification too." Yes, it can, but the human in that loop can't recognize what's missing, challenge assumptions, or determine whether the solution is appropriate.

Back when I was consulting on small-business database solutions, owners would always claim they wanted zero downtime and zero data loss... until I showed them how much that costs. Then, suddenly, 30 minutes was acceptable.

The Rise of the Systems Thinker

Only a small subset of professional software developers understand architecture. Architecture is not a collection of diagrams or design patterns. Architecture is about understanding what is happening behind the abstraction layers (e.g., HTTP vs React), understanding the consequences of choices (in particular second- and third-order effects), and crafting solutions that are appropriate to the business need.

For example, adding a caching layer is one of the easiest ways to make an application appear faster. Understanding all the consequences is another matter.

• A junior developer grabs a caching framework and tosses it in.
• A more experienced developer considers cache invalidation and inconsistency.
• An architect considers what happens when the cache fails, how the system behaves under a sudden spike of traffic, what operational burden the cache introduces, and whether caching is the right solution in the first place.

And caching is a relatively easy problem to solve compared to what you find in sophisticated distributed systems.

Architecture is less of a job title and more of a way of thinking about software.

You Can't Skip the Fundamentals

The question keeping me up at night is, "If everyone needs to up their architecture game, what does that mean for education?" Well, I'm honestly not 100% sure yet, but I'm pretty confident that these capabilities are the ones that will be in demand:

• An understanding of programming deep enough to work across multiple paradigms and languages.
• How data is modeled, stored, queried, and kept consistent.
• How computers and networks operate.
• How applications are deployed, monitored, secured, and recovered.
• How systems behave under load and failure.
• How to communicate requirements, decisions, and tradeoffs clearly.

And this is the tension: You cannot become a competent software architect by asking AI to build software for you. Architectural judgment comes from getting dirty. You must build things, break things, fix things, and live with the consequences of your decisions.

I have learned far more from reworking my own mistakes than any book I've ever read.

Here's Where I Get Sad

Not everyone can become an architect. Architectural thinking is difficult. I've worked with many capable developers who can implement features to spec but struggle to reason about the broader consequences of technical decisions.

Only part of this is gained from experience and education. A big part comes from curiosity, the ability to cope with higher-order abstraction, and the ability to reason through interacting systems. And, unfortunately, telling every developer to skill up on architecture isn't any more helpful than telling every accountant to become a CFO.

I'm not saying these developers can't make meaningful contributions, but I am concerned about whether the labor market will keep compensating them for the work they can do at the high rates they command today.

Well... It's more than a concern. I'm skeptical. If all you do is take tickets out of Jira, toss them into AI, glance at the PR, then hit "merge", I don't see a future where I need you.

But if you're the type of person who can reason about what is being done and why, anticipate issues in advance, and deliver high-quality, reliable outputs, then I think you're going to make bank.

The Junior Pipeline Issue

Here's what companies and higher education are going to need to solve:

1. AI reduces the demand for routine programming.
2. However, routine programming provides the experience necessary to develop architectural judgment.
3. Architectural judgment is already valuable, but that value will go up.
4. Companies may reduce opportunities to acquire that judgment.

In short, we're automating the apprenticeship that creates the experts we still need.

What This Changes For Me

Skill Foundry was already on the way towards broadening its curriculum. I added a self-hosting course this summer. I believe modern technical education needs to move beyond producing applications to understanding systems.

The programming content I have? Still good. But the future state of Skill Foundry is teaching how to deploy applications, administer Linux servers, design databases, diagnose network, container, and permissions issues, secure services, and investigate failures.

And yes, AI and AI tools will be a part of this, but only as an amplifier of those fundamental skills, using the AI tools to help deliver what you know needs to be created, not outsourcing your thinking.

This shows up when I evaluate the learners I mentor. I expect the application to work, because they submitted it. But I want learners who can explain why their application works, diagnose why it doesn't, understand the consequences of their implementation decisions, and operate what they've built. A working demo without that understanding is not a passing grade.

Framework proficiency is not likely to be a sufficient qualification for professional development. And the skills I've outlined here will take a lot longer than 12 weeks.

Software development isn't dead. Not even close. But the entry point is changing.

Happy Coding