There's a widespread discomfort in the development field. A feeling that the ground has shifted, but no one handed out the new map. Generative AI entered the daily routine, and suddenly what used to take hours, writing functions, building queries, creating components, solving trivial bugs, now takes minutes. Sometimes seconds.
The most common reactions are either "AI will replace everyone" or "nothing changes, it's just another tool." Both are wrong. The first is alarmism. The second is denial.
What happened was a role shift. The developer didn't become unnecessary. The type of contribution expected from a developer changed. And understanding this change early, especially for those at the beginning of their career, is the difference between becoming a low-impact professional and an indispensable one.
The model we knew
For a long time, the industry operated with a reasonably clear division of responsibilities:
The traditional cycle of a demand:
Someone identifies a problem → someone from product investigates and defines scope → an architect or senior developer designs the solution → a developer implements.
Each stage had its people, its ceremonies, its rituals. Refinement, sprint planning, design review, code review. Not that it was bad, it was just a structure that made sense when each stage was costly.
Within this model, career progression looked roughly like this:
- Junior received small, well-defined tasks. Coded, tested, fixed. Most of the time was spent on execution: the manual labor.
- Mid Level took on more complex demands, started thinking about how the code fits into the system. Refactored, participated in technical decisions.
- Senior defined architecture, evaluated trade-offs, mentored. Coded less, thought more.
AI compressed this. Much of the manual labor that served as training for juniors is now automated. And this raised the question hanging in the air: "If AI does what I used to do, what do I do now?"
What actually changed
To understand the new role, we need to decompose what AI actually affected. It wasn't just the code. It was the entire cycle.
Execution became trivial
Writing code was never the end goal, but the means. AI turned the means into something almost trivial. CRUD functions, UI components, basic unit tests, automation scripts, all of this can be generated in seconds with reasonable quality.
This didn't eliminate the need to know how to program. It eliminated the need to spend most of your time programming trivial things.
Research and understanding became accessible
Before, to understand a problem domain, you needed to: read extensive documentation, talk to stakeholders, attend meetings, study the market. Everything took days.
Today, with AI tools we can:
- Quickly explore a technical domain you're unfamiliar with
- Generate architecture sketches to validate ideas
- Prototype solutions in minutes to test concepts
- Simulate scenarios and anticipate problems
The boundary between Product and Development blurred
And here is one of the most profound and least discussed changes.
The Developer as Product Thinker
There's an uncomfortable truth in the industry: much of the ceremony surrounding the product cycle exists because execution was expensive.
Think of the classic process: understand the problem, refine the problem, do research, model the solution, execute. Each stage required different people, different meetings, different time. Everything needed to be well-defined before moving to execution, because execution was the bottleneck. Getting the definition wrong meant wasting weeks of development work.
AI didn't eliminate these stages, but made each of them cheaper and faster. What used to take a week of discovery can now be explored in an afternoon with the right tools. What required a 20-page requirements document before touching code can now be validated with a functional prototype in hours.
This means developers can and should participate more actively in product stages:
- Question the problem itself. Don't just receive a ticket and execute, but ask: "Is this really the problem that needs to be solved? What's the impact? Is there a simpler way to tackle this?"
- Do micro-research autonomously. Explore the domain, understand the user context, compare with existing solutions. All without needing to wait for an alignment meeting.
- Prototype to validate, not just to deliver. Create quick, imperfect versions that serve to test hypotheses before investing in robust implementation.
- Model solutions with a product vision. Think not only about "how does this work technically" but also "how does this solve the user's problem" and "how does this sustain itself over time."
It's not that the Product Manager role ceased to exist. It's that the overlap between what a PM does and what a dev does has grown significantly. The developer who can operate in that overlap with the differentiator of understanding both technology and product has become the most valuable professional in the market.
The ceremony hasn't disappeared. But the need to rigidly separate who thinks and who executes has decreased. The same person can now cover a much larger slice of the cycle.
The New Role: Orchestrator, Architect, Product Thinker
If before the question was "how do I make this work?", now the questions that define a good developer are:
About architecture:
- "What's the best way to structure this?"
- "How does this communicate with the rest of the system?"
- "What trade-offs are we assuming with this decision?"
About product:
- "Are we solving the right problem?"
- "Is there a simpler version that already validates the hypothesis?"
- "How does this impact the experience of whoever uses it?"
About execution:
- "Does what AI generated here make sense?"
- "Which edge cases were ignored?"
- "Does this scale? Is this secure? Is this maintainable?"
The developer of the new model is someone who navigates the entire spectrum, from the problem to the code. They don't need to be a specialist in everything, but they need the discernment to know when they're in product territory, when they're in architecture territory, and when they're in execution territory. Having critical thinking, and this part is important, because we can't delegate this fundamental part to AI: the thinking, the reflection, the discernment.
Do fundamentals still matter? More than ever!
There's a real risk here. With AI tools generating functional code in seconds, a dangerous temptation emerges: accepting anything that "works."
And "working" is not the same as "being good."
Code generated by AI often:
- Has generic, ambiguous variable names
- Mixes responsibilities in a single function
- Ignores proper error handling
- Uses approaches that don't scale
- Creates unnecessary coupling
- Passes the happy path test but fails on the first real edge case
Without fundamentals, the developer becomes a tool operator who accepts any output without questioning. It's like an architect who doesn't understand structures: they can design the most beautiful floor plan, but if they don't know that the vault needs a beam, the building collapses.
The orchestra analogy still holds: the conductor doesn't need to play violin with the same technique as the first violinist, but they need to know how to hear when the violin is out of tune. And for that, they need a trained ear.
Fundamentals are the developer's trained ear.
What to study: a practical path
In short:
The foundation
- Programming logic and data structures: understand code structure like: arrays, if/else, switch, and so on. Not to memorize algorithms, but to evaluate whether AI delivered an efficient solution or a time bomb.
- Debugging: reading stack traces, using breakpoints, understanding execution flow, isolating problems. When code is broken, whether AI-generated or not, you have to know how to debug to fix it. Those who don't know end up re-prompting until it works by chance.
- Git: branches, merge, rebase, code collaboration. Seems basic, but it's the foundation.
- HTTP and how the web works: requests, responses, status codes, headers, authentication. Without this, the system becomes a black box.
Patterns and critical code thinking
- Design patterns: Strategy, Observer, Factory, Repository, Dependency Injection, and so on.
- SOLID: the Single Responsibility Principle alone changes how code is read. When AI generates an 80-line function doing five things, it becomes obvious it needs to be decomposed.
- Tests: unit, integration, end-to-end. AI can generate tests, but knowing what to test and why is exclusively human.
- Clean Code: meaningful names, small functions, avoiding side effects.
It's important to emphasize that these code patterns are not "silver bullets", each has a context where it works. It's also worth considering the application of each one.
Architecture and systems
- Software architecture: monolith vs. microservices, Clean Architecture, event-driven. Understand trade-offs, not dogmas.
- Data modeling: normalization, indexes, SQL vs. NoSQL, domain-driven design. If the data model is wrong, no query saves it.
- Basic infrastructure: Docker, CI/CD, deployment concepts. You don't need to be DevOps, but you need to understand how code gets to production.
Product thinking
- Questioning requirements: it's important to understand the limits and expectations of the demand.
- MVP mindset: deliver the smallest functional piece that validates a hypothesis, instead of building the perfect system from the start. Agile philosophy.
- Business context reading: Understand the impact of the demand, who the users are, what the success metric is. You don't need to become a PM, but you need to think like one.
- Communication: writing good PR descriptions, documenting technical decisions, explaining problems clearly, clear git commits. With AI in the mix, the ability to articulate what's needed has become even more central.
AI orchestration
- Applied prompt engineering: being precise in context, constraints, and expected results. This is an extension of technical thinking, not a magical skill.
- Code review of AI-generated code: Develop a critical eye for what the tool produces. Hidden edge cases, disguised inefficiencies, solutions that seem right but aren't.
- Discernment on when to use AI: Not every task benefits from it. Sometimes, for simple problems, writing directly is faster. Sometimes, for learning, trying before asking for help is more valuable.
The shift in the learning cycle
Before, juniors learned by doing repetitive work. Made mistakes, fixed them, repeated. It was slow, but it built intuition.
The cycle now is different:
- Define what needs to be done
- AI generates a starting point
- Evaluate, refine, correct
- Understand why each decision was made
Step 4 is where real learning happens. Every time AI generates something, the right questions are:
- "Why this approach and not another?"
- "What happens if I change this parameter?"
- "What are the limits of this solution?"
These questions transform a tool operator into a software engineer.
On the ceremony that's being left behind
To close this point about Product: I'm not saying that refinement, discovery, and planning stopped being important. They remain fundamental. What changed was the granularity and formality.
It's no longer necessary to wait a week of meetings to understand if an idea makes sense. A developer with product thinking and AI tools can:
- Explore the problem in an afternoon
- Prototype a solution in hours
- Validate with quick data
- Arrive at refinement already with a concrete proposal
Heavy ceremony existed because each stage was expensive. Now that stages are cheap, the structure needs to keep up. And the developer who knows how to operate in this lean cycle, from problem to solution, will stand out.
The programmer didn't die. The role changed. From executor to architect. From typist to orchestrator. From ticket receiver to technical product thinker.
There's no risk of AI replacing those who program, but rather those who only program.
The fundamentals that support this transition are the same as always: logic, patterns, architecture, debugging, critical thinking. But now, added to a new dimension: product vision, the ability to navigate from problem to code, and discernment to know what to accept, what to refine, and what to reject from what the machine delivers.
The future belongs to those who understand the entire system, not just one piece of it.
Top comments (0)