It's been a few years since I actively blogged. Over six years in fact, and in the ever changing world of tech that is a different era entirely. Back then, the engineering landscape was relatively stable: you knew your stack, you optimized within known constraints, and you shipped features. The industry moved, but incrementally.
Today, everything feels more urgent, more can we solve this now and if so when can we get to market, more take this data point and charge full steam ahead. That's not because things move faster in chronological time—we didn't suddenly step into Star Trek and command Ensign Crusher to "warp ahead". Instead, the fundamentals of what we do as engineers have shifted. And I think it's worth writing about.
The Divide Has Collapsed
Years ago, there was a meaningful separation: engineers building production infrastructure (databases, microservices, infrastructure) and people building tools for specific problems (data analysis, automation, small applications).
The cost of entry to build production-grade software was high. You needed deep knowledge: SQL, system design, deployment strategies, performance optimization. That created natural specialization.
Then AI happened. And suddenly, the cost of bringing software to smaller, everyday problems dropped dramatically.
Want to build a tool that automatically renames files in a folder based on their content? A chatbot for your friend's niche side project? A script to extract and organize data from PDFs? Five years ago, these were "not worth building." Today? Prompt an AI, refine the output, deploy it. Done before lunch.
A junior engineer—or someone who isn't an engineer at all—can now prompt an AI model to write code, refine the output, deploy it, and have something useful running in hours. Not every time, but often enough that the old gatekeeping has evaporated.
The result? We're all expected to be more. Broader. Fuller-stack. The nature of specialization is shifting—what once meant going deep in one domain now means developing breadth across systems and understanding how pieces connect. That's not loss; it's evolution.
Less Syntax, More Strategy
Here's what I've noticed: writing code is no longer the constraint.
You can sit down with an AI model and scaffold an API, write database migrations, build a React component, or debug Kubernetes manifests in minutes. The syntax—the mechanical part—is solved.
What isn't solved: deciding what to build, why, and how it fits into a larger system. Architecting so that the next person (or next version of you) can reason about it. Aligning software decisions with user needs and business constraints. Knowing when to say "we don't need this."
The engineers who will thrive aren't the ones who memorized design patterns. They're the ones who can ask the right questions, make principled tradeoffs, and see three moves ahead.
Managing AI Like a Junior Developer
(Or: How to Mentor an AI Without Losing Your Mind)
If you're writing code with AI assistance, you're spending your time on:
| Task | What You're Doing |
|---|---|
| Prompting | Figuring out how to ask the question so you get useful output |
| Reviewing | Reading what the model produced, checking for subtle bugs, logical errors, missing edge cases |
| Refactoring | Shaping the code to fit your codebase's conventions and structure |
| Debugging | Hunting down where and why things went wrong |
Sound familiar? That's exactly what code review and mentorship look like. You're not writing all the code yourself—you're curating, directing, and polishing what an assistant produces.
The skills are the same. But now the "assistant" is a language model, not a person.
Full-Stack, Higher Expectations
With AI handling the scaffolding, developers can now build across the full stack—frontend, backend, mobile, infrastructure—faster than ever. That's powerful. It means smaller teams can build broader products.
But it also means hiring expectations have shifted. Job postings that once said "senior backend engineer" now expect you to own your API and ship a dashboard and optimize your database queries.
It's an open question whether this represents genuine evolution or if we're asking too much too fast. Like most transformations, there are meaningful gains and real costs.
Hiring Has Changed
Interview questions about coding puzzles (sorting algorithms, binary search trees) have become almost quaint. If the test is "implement quicksort," you can prompt it out in seconds. That's not a useful signal anymore.
Instead, I see interviews focusing on:
| Focus Area | The Question |
|---|---|
| System Thinking | Can you design an architecture that scales? Can you reason about tradeoffs? |
| Spotting AI Errors | Given code generated by an AI, can you catch the subtle bugs, the off-by-one errors, the missing null checks? |
| Managing Agentic Tools | Can you direct an AI assistant to build something useful? Can you critique its output intelligently? |
These are harder to test. But they're closer to what actual engineering looks like now.
Why Write About This
I'm blogging again because the engineering landscape deserves reflection. We're in a transition moment—not the first, certainly not the last, but significant enough to think through carefully.
I'm interested in:
Building better with AI assistance without losing rigor — Quality and maintainability still matter, even when code is generated fast.
Skills that remain non-negotiable as automation rises — Understanding what won't be automated helps you stay valuable.
Career strategy when the field is shifting — You need a plan for navigating this transition, whether you're early or mid-career.
The ethics and practicalities of building with these tools — We need thoughtful approaches to responsible AI integration.
Backend patterns, systems thinking, fullstack engineering, and lessons from open source — Technical depth, architectural knowledge, and community wisdom remain foundational.
Some of this will be technical. Some will be career strategy. Some will be philosophy. Some will be about how we as humans navigate an increasingly automated world of AI—where we draw the line of what's permissible and what isn't. I'm interested in ethics, critical thinking, and impact as it relates to governance, responsibility, and the long-term health of our communities.
The decisions we make now about how we build, what we build, and why we build it will shape the industry for years to come.
But it'll all be worth thinking through together.
Welcome back to the blog.
Until next time: live long, Python & prosper. 🖖