The takes are everywhere. On one side: 'AI will replace junior developers within 18 months. Senior developers are next. Learn prompt engineering or find a new career.' On the other side: 'AI is a fancy autocomplete. It can't understand requirements, can't architect systems, can't debug production incidents. Developers are safe.'
I've spent the past year building with AI as a first-class tool — integrating Claude into Creator AI, using Cursor and Claude for my personal projects, watching AI-assisted code land in production. My take is more nuanced than either camp, and I think the framing of 'doomed vs safe' is the wrong question entirely.
What AI Is Genuinely Excellent At
Let me be honest about what AI coding tools actually do well, because dismissing them is intellectually dishonest.
Boilerplate Elimination
AI is transformatively good at boilerplate. CRUD endpoints, form validation, database schema migrations, test fixtures, configuration files, TypeScript interface generation from JSON — work that's necessary but not mentally engaging. A task that would take a developer 45 minutes now takes 3 minutes of prompting and 5 minutes of reviewing the output. This is not small. Boilerplate represents a significant portion of real software engineering work.
Cross-Language Translation
Porting code between languages — Python to TypeScript, Java to Kotlin, old JavaScript to modern ES2024 — is mechanical work that AI does extremely well. I used Claude to port a Node.js SMS parser to Kotlin for Gunti. The translation was 90% correct on the first pass, with the remaining 10% being platform-specific idioms that needed adjustment. What would have taken a day took two hours.
Documentation and Test Generation
Generating meaningful documentation from code and writing unit tests for clearly-defined functions are AI's strongest suits. The tests it generates for pure functions with well-defined inputs and outputs are often better than what a time-pressured developer would write manually.
What AI Is Still Genuinely Bad At
Here's where honest assessment matters more, because this is where the overconfidence claims get dangerous.
Understanding Unstated Requirements
Most software requirements are incomplete. A product manager asks for a 'search feature.' What they actually mean involves: understanding the data model, knowing which fields should be weighted, handling pagination, considering performance at scale, accommodating future filter additions, and deciding whether fuzzy matching is needed. A developer asks those questions and thinks through the implications. An AI builds exactly what was asked — and then you spend three weeks refactoring it because the requirements were underspecified.
Debugging Complex Distributed Systems
When something breaks in production — a race condition, a memory leak under specific load patterns, an intermittent timeout in a distributed transaction — the debugging process requires forming and testing hypotheses across multiple system layers simultaneously. It requires intuition built from seeing similar failures before. AI tools can suggest causes and point to code, but the actual diagnosis of subtle production issues still requires a human who understands the full system.
Architectural Judgment
Should this system use a message queue or direct API calls? Should this data live in PostgreSQL or Redis? When does a microservice boundary make sense, and when does it create accidental complexity? These decisions depend on the specific constraints of a business — expected load, team size, budget, organizational structure — that can't be fully expressed in a prompt. AI gives you options. Choosing between them requires judgment that comes from experience.
The most dangerous failure mode I've seen: a developer uses AI to quickly generate a solution, it works in development, it ships to production, and two months later it collapses under load because the AI generated code that was technically correct but architecturally wrong for the actual usage pattern.
The Historical Pattern Everyone Forgets
Every generation of software tooling has been described as 'replacing programmers.' Compilers were going to make assembly programmers obsolete (they did, and massively increased the number of programmers by lowering the barrier). COBOL was going to let business people write their own software (it didn't, and business analysts became their own discipline). Visual Basic, drag-and-drop tools, website builders — all were going to eliminate the need for 'real' developers.
What actually happened each time: the tools raised the productivity floor, the demand for software increased faster than the productivity gains, and more developers were needed than before. When building a website went from requiring a web developer to being doable with Squarespace, the number of web developers didn't decrease. It increased — because suddenly every small business wanted a custom website that Squarespace couldn't build.
AI is the same pattern, at a larger scale and faster pace. But the pattern is recognizable.
The Floor Rises. The Ceiling Rises Higher.
Here's the dynamic that I think people miss: AI tools raise the floor of developer productivity significantly. A developer who struggled with SQL can now write competent queries. A developer who was weak on testing can now generate test suites. This closes gaps. It makes average developers more capable.
But it also raises the ceiling. A genuinely strong developer who knows how to use AI as an amplifier — who can review AI output critically, who uses it for leverage on the mechanical work and brings deep judgment to the architectural work — becomes dramatically more productive. The 10x developer, a controversial concept in normal times, is something closer to real when AI handles the repetitive work and an experienced engineer focuses entirely on the hard problems.
This doesn't make the market better for everyone uniformly. For someone who was adding value primarily through grinding out boilerplate, the value proposition shrinks. For someone who was adding value through system thinking, architecture, and judgment — the market for their skills grows, because now they can execute faster.
The New Developer Role
What does being a 'good developer' mean in this environment? I think it looks like this:
- System thinker: Understanding how pieces fit together at a level that AI cannot replicate without deep context you provide
- Critical reviewer: AI output is confident, readable, and plausible — but not always correct. The ability to spot subtle bugs, performance problems, and architectural mismatches in generated code is increasingly valuable
- Requirement excavator: Getting from what a stakeholder says they want to what a system actually needs to do. This is a human skill that AI assists but doesn't replace
- AI orchestrator: Knowing when to delegate to AI, what to delegate, and how to verify the result — this is its own skill set that experienced developers are still figuring out
- Deep domain expert: The more context you can provide to an AI about your specific domain, constraints, and tradeoffs, the better its outputs. Deep domain knowledge becomes more, not less, valuable
The Uncomfortable Part
I'll be direct about something the optimistic takes skip: some jobs will change significantly. Entry-level work that was primarily about building CRUD features to well-defined specs — that work is going to look different. It will either be done faster (by fewer people), or it will be done at a more sophisticated level by the same number of people (as AI handles the mechanical implementation).
The path for early-career developers isn't to be afraid of this — it's to not spend years becoming excellent at the things AI does well. Instead: invest in understanding systems deeply, build real projects with real users, develop opinions about architecture, learn to work with AI as a multiplier rather than a replacement for thinking.
My Actual Prediction
Not doom, and not status quo. The amount of software in the world is going to increase dramatically, because the cost of building it is falling. New categories of software will become economically viable that weren't before. The demand for people who can envision, architect, and ship software systems will grow.
The developers who will struggle are those who treat programming as a mechanical trade — who learn to write code but not to think about systems. The developers who will thrive are those who understand that writing code was always the easy part. The hard part was always understanding what to build, why to build it that way, and how to make it reliable at scale. AI is very good at writing code. It is not good at those other things.
We're not at the end of software engineering. We're at the beginning of a period where software engineering becomes something closer to a genuine system design discipline — where the conversation between human and machine produces things neither could build alone. That's not doom. That might be the most interesting time in the field's history to be working in it.