AI coding tools increase developer output but keep software engineering reliant on human oversight

I can write code faster today than I could a few years ago. AI can explain an unfamiliar library. It can generate a function. It can suggest a fix. It can write SQL. It can help debug an error. It can even explain the code it just generated. From a productivity perspective, this is incredible. But I've started thinking about a different question: What happens to the learning process when the difficult part of coding becomes optional? I don't think AI is making developers less capable. But I do think it has created a new risk: We can now become productive before we become good. And those are not the same thing. The Struggle Was Part of the Learning Think about how we traditionally learned programming. You wrote something. It didn't work. You read the error. You searched for an explanation. You tried something else. It failed again. You read documentation. You changed the code. Eventually, it worked. That process was frustrating. But something important was happening during those frustrating hours. You were building a mental model. You were learning why the system behaved the way it did. You weren't simply learning the answer. You were learning how to arrive at the answer. AI changes that equation. Today, you can paste the error into an AI assistant and get a possible explanation almost immediately. That's useful. But it also means you can skip several steps of the learning process. And sometimes those skipped steps were the most valuable ones. The Dangerous Part Isn't AI I don't think the problem is AI itself. The problem is how we use it. There is a big difference between: "Explain why this error is happening." and: "Fix this." The first can teach you something. The second can simply remove the obstacle. Both can get you moving again. But they don't necessarily produce the same learning. This distinction becomes even more important when you're learning something new. If I already understand Python and ask AI to help me optimize a piece of Python code, that's one thing. If I'm learning Python and ask AI to write every function I don't understand, that's very different. In the second case, I may finish the project without actually learning how I built it. Productivity Can Hide the Learning Gap This is where things get interesting. Imagine two developers learning the same technology. Developer A spends three hours struggling with a problem. Developer B asks AI and solves it in ten minutes. On the surface, Developer B has been more productive. But what happens when the same problem appears next month? Developer A may recognize the pattern. Developer B may need to ask AI again. Neither person necessarily did anything wrong. They optimized for different things. One optimized for completion. The other accidentally optimized for understanding. The problem is that modern development increasingly rewards completion. And AI is exceptionally good at helping us complete things. I Don't Want to Go Back to Coding Without AI This is important. I'm not arguing that developers should stop using AI. That would be like saying developers should stop using debuggers because debugging used to be harder. Tools are supposed to make us more capable. I use AI because it genuinely makes many parts of development faster. The goal isn't to preserve unnecessary struggle. The goal is to preserve useful struggle. That's a very different idea. If I'm spending thirty minutes trying to remember a syntax detail that I could verify in ten seconds, I don't think that struggle is valuable. But if I'm trying to understand why an architecture behaves the way it does, immediately asking AI for the answer may deprive me of an important learning opportunity. The "Try First" Rule I've started thinking about a simple rule: Try first. Ask AI second. Not always. But often. If I encounter a problem I believe I can solve, I give myself some time to reason about it before asking AI. I might: read the error inspect the code form a hypothesis test the hypothesis search the documentation try a solution Then I ask AI. And something interesting happens. The AI's answer becomes much more useful because I have a mental model of the problem. I'm no longer asking: "What should I do?" I'm asking: "Here's what I think is happening. Am I missing something?" That is a much more powerful interaction. AI Should Challenge Your Thinking This is also changing how I think about prompts. Instead of always asking AI to produce something, we can ask it to challenge us. For example: "Here is my approach. Find the weaknesses." Or: "Don't solve this yet. Give me three questions I should investigate." Or: "I think this is the cause of the bug. Try to disprove my hypothesis." Or: "Review my solution, but don't rewrite it. Tell me what I misunderstood." These interactions keep the developer inside the reasoning loop. AI becomes less like an answer machine and more like a thinking partner. That's a much healthier relationship. There Is a Difference Between Knowing and Accessing This may become one of the biggest distinctions in AI-assisted development. I don't need to memorize every Python method. I don't need to remember every SQL syntax variation. I don't need to know every framework API by heart. AI and documentation can handle a lot of retrieval. But I still need to understand: What am I trying to do? Why does this approach make sense? What assumptions am I making? What could go wrong? How would I know if the result is wrong?** Those are not simply information-retrieval problems. They are reasoning problems. And I don't think AI makes those skills less important. I think it makes them more important. The New Developer Skill Might Be Knowing When Not to Ask There is an interesting irony here. As AI becomes better at answering questions, the skill of asking good questions becomes more valuable. But perhaps there is another skill: Knowing when to answer the question yourself first. If I ask AI everything immediately, I may become extremely efficient at retrieving answers. But I may become less practiced at generating them. That distinction matters. A calculator didn't make mathematicians less intelligent. But someone who never learns basic arithmetic because a calculator exists has a different problem. The tool isn't the issue. Dependency is. AI Can Make You a Better Developer The same technology that creates this risk can also solve it. AI can explain unfamiliar code. It can give you alternative approaches. It can challenge your assumptions. It can create exercises. It can act as a tutor. It can review your implementation. It can ask you questions instead of giving you answers. It can help you understand why something works. Used this way, AI doesn't replace the learning process. It can actually accelerate it. The difference is whether we're using AI to avoid thinking or to improve our thinking. Maybe We Need a New Development Loop The old loop looked something like: Problem ↓ Think ↓ Code ↓ Test ↓ Debug ↓ Learn AI can turn it into: Problem ↓ Think ↓ AI assists ↓ Code ↓ Test ↓ AI challenges ↓ Human evaluates ↓ Learn I prefer the second model. Not because AI does more. Because the human still does the important thinking. The Real Risk Isn't Becoming Lazy People often ask: "Has AI made developers lazy?" I'm not sure that's the most useful question. Developers have always looked for ways to avoid unnecessary work. That's part of engineering. The better question is: "Are we automating away work that was actually teaching us something?" That's much harder. Because some effort is waste. And some effort is education. The challenge is learning the difference. I Don't Want to Become Faster at Being Wrong This is probably the simplest way I can describe my concern. AI can dramatically increase development speed. But speed is not the same as progress. If I misunderstand the problem and AI helps me implement the wrong solution in ten minutes instead of ten hours, I haven't necessarily become a better developer. I've simply become faster at being wrong. That's why I still want to understand the fundamentals. I still want to read documentation. I still want to debug. I still want to write code without assistance sometimes. Not because I dislike AI. Because I want to remain capable without it. The Goal Isn't to Code Without AI I don't think the future belongs to developers who refuse to use AI. And I don't think it belongs to developers who let AI do everything. The interesting middle ground is this: Use AI for leverage, but keep ownership of your understanding. Let AI handle repetitive work. Let it explain unfamiliar concepts. Let it review your code. Let it challenge your assumptions. Let it help you move faster. But occasionally close the AI window and ask yourself: "Do I actually understand what I just built?" If the answer is yes, you're probably using the tool well. If the answer is no, perhaps the tool moved faster than your understanding. And that's something worth paying attention to. Because in the AI era, I don't think our biggest challenge will be learning how to make machines do more. It may be learning how to make sure we continue to think while they do it. Want More: Head over to ReThynk AI to access our latest research, magazine articles, and developer resources. Click Here

I've come to a realization. I have to use AI as part of my workforce. Not because I can't code. Not because I don't understand what I'm building. And certainly not because I want to surrender my projects to a machine. I need to make progress. I have a lot of things I want to build, and unfortunately, I still only have 24 hours in a day. KiwiEngine. Blackwater Sound. Music software. Artist platforms. Stores. Guitar pedals. Amplifiers. Electronics. Games. Writing. Teaching. And that's before we get into actually making music. I can either spend the next several years trying to do every little thing myself, or I can use the tools available to me to start bringing these ideas to life. I've made my decision. I Don't Have The Luxury Of Being A Purist There's a perspective in software development that I understand and respect. Learn your tools. Understand your language. Write your own code. Master your specialty. Become exceptionally good at what you do. There's nothing wrong with that. But I think we sometimes make the mistake of treating one approach to professional development as though it's prescribed to everyone. Not everyone is trying to accomplish the same thing. Some developers want to specialize deeply in a particular area of engineering. Some want to work for established companies. Some want to become experts in a particular language, framework, or discipline. Those are legitimate goals. But they're not necessarily mine. I'm a builder. I have a vision for things that extend well beyond software development. Software is one of the tools I use to bring those things into existence. And if I'm spending all my time proving that I can personally implement every line of code, I'm not necessarily getting closer to those goals. I'm just getting better at doing everything myself. Those aren't the same thing. I Can Put My Code Where My Thoughts Are One thing I've learned about myself is that I'm a big thinker. I see systems. I see how things connect. I see how one piece of infrastructure can support five different projects. I can look at a music business, a software platform, a storefront, and an electronics workshop and start imagining how they could operate together. And for the most part, I can put my code where my thoughts are. I've been doing that with KiwiEngine. The problem isn't that I don't know how to build things. The problem is that I can't personally implement every idea at the speed I can envision it. There are only so many hours available. And I don't have an entire engineering department sitting behind me. So why wouldn't I use technology that helps me extend my capacity? AI Doesn't Design My Vision This is where I think an important distinction needs to be made. I don't hand AI a vague idea and tell it to go build my company. I design the systems. I establish the architecture. I determine the responsibilities of the libraries. I make decisions about how the pieces interact. I write and develop the foundations. Then I use AI to help with implementation, repetitive work, documentation, tests, and other tasks that would otherwise consume significant amounts of time. That's delegation. And delegation doesn't eliminate responsibility. If anything, it makes responsibility more important. Because now I have to understand not only what I'm building, but what I'm approving. No Ghost Code I have a very deliberate boundary when it comes to AI working on KiwiEngine. AI does not have independent authority to commit code, change architectural direction, or make decisions on my behalf. It doesn't get to decide that a library should be rewritten. It doesn't get to introduce dependencies because it thinks they're convenient. It doesn't get to change the design philosophy because another approach is more conventional. And it doesn't get to silently commit code I haven't approved. There is no ghost code. If AI is going to take an action that changes the project, it needs my explicit authorization. I review the work. I approve the direction. I remain responsible for the result. AI can be part of my workforce without becoming the owner of my work. The Grunt Work Is Still Work Here's something I think gets lost in conversations about AI-assisted development. Not every programming task requires the same level of creative investment. Some tasks are genuinely interesting architectural problems. Others are repetitive implementation work. Writing another adapter. Creating another set of tests. Updating documentation. Implementing a pattern that's already established elsewhere in the project. Working through boilerplate. Those things matter. They still need to be done correctly. But they don't all require me to spend hours personally typing every character. If I've already established how a system should work, why wouldn't I use a tool to help implement that established pattern? My time is better spent reviewing the result, improving the architecture, and moving on to the next problem. That's not avoiding engineering. That's managing engineering work. AI Doesn't Eliminate The Need To Understand Your Code There's a difference between using AI to extend your abilities and using it to avoid developing them. I don't believe AI should become an excuse to stop learning. If I don't understand a change, I shouldn't approve it. If I can't explain why something belongs in the architecture, it probably doesn't belong there yet. If AI generates code that violates the design principles of KiwiEngine, that code doesn't get a pass simply because it works. Working code isn't automatically good architecture. And generated code isn't automatically correct. AI can make mistakes. It can misunderstand requirements. It can introduce unnecessary complexity. It can confidently implement something that doesn't fit the rest of the system. That's why oversight matters. I want AI helping me move faster, not helping me accumulate problems faster. I'm Not Trying To Win A Coding Endurance Competition This is the part I've been thinking about the most. What exactly am I proving by doing everything manually? That I can work longer? That I can memorize more syntax? That I can rebuild the same implementation for the fifteenth time? I already know I can build software. I want to use that ability to accomplish something. I want to create tools for musicians. I want to produce music. I want to develop physical products. I want to experiment with electronics. I want to build businesses around things I genuinely enjoy. I want to spend more time creating cool things and less time getting bogged down in technical work simply for the sake of purity. If AI can help me accomplish that while I retain ownership and oversight, I'm going to use it. KiwiEngine Is Supposed To Create Leverage This is actually very consistent with why I'm building KiwiEngine in the first place. The whole point of a reusable framework is to avoid solving the same problems repeatedly. Juice helps me avoid recreating common styling behavior. Nectarine helps establish reusable configuration patterns. Other libraries and engines provide foundations I can build upon. AI fits into that philosophy as another form of leverage. KiwiEngine reduces the amount of infrastructure I need to rebuild. AI reduces the amount of implementation work I need to personally perform. Together, they allow me to spend more time on the problems that are unique to what I'm creating. And that's the entire point. I Want To Build Things, Not Just Talk About Building Them I have enough ideas to keep myself busy for several lifetimes. What I don't have is several lifetimes. I have this one. And I would rather spend it bringing as many meaningful ideas into reality as I reasonably can. I'm not interested in pretending that using AI somehow makes those ideas less mine. The architecture is mine. The decisions are mine. The responsibility is mine. The vision is mine. The tools help me execute it. That's how I see AI. Not as a replacement for my abilities. Not as an excuse to abandon craftsmanship. And not as an autonomous authority over my projects. It's part of my workforce. I intend to use it that way. The future isn't something I'm waiting around for. It's already here. And I have things to build.

I have a problem. AI has made me a more productive developer, but it's also made programming less fun. I use AI. These days, I can give a local AI agent a task and watch it work directly on my project: writing code, changing files, fixing errors, while I barely touch the code. It's incredibly useful, but I find it boring. And I've felt this way pretty much from the beginning. I'm not bored with technology or building things. I'm bored with what the actual process of programming is becoming. I'm not the only one. When the hard part was the fun part Before AI, building something usually meant getting stuck. You had an idea, you knew roughly what you wanted, and then came the annoying part: how do I actually build this? You searched documentation, opened Stack Overflow, tried something, it broke six other things, you questioned your career choices, you made coffee, and then, eventually, it worked. That tiny moment was ridiculously satisfying. The feature itself might have been nothing special: a modal finally behaved correctly, an animation stopped jumping, a state bug that made sense after two hours of staring at it. But you figured it out. That feeling mattered more than I realized until it started disappearing. I thought I wanted this Developers have spent decades making programming easier: higher-level languages, frameworks, package managers, autocomplete. Every generation of tools has removed some tedious work, and mostly that's a good thing. I don't miss writing the same boilerplate for the hundredth time. AI takes it further. We went from autocomplete to Copilot suggesting code as we typed, to agents that can do programming without me. That's where it stops feeling like just another productivity improvement. Maybe programming was a craft for me I recently read a Reddit discussion called "AI has made programming so boring." What interested me wasn't the usual debate over whether AI code is good. It was the disagreement over what programming is even for. Some developers said the code was never the important part. They just want to build things, and if AI helps them do that faster, even better. I get that. But for me, figuring out the code was part of the fun. If AI reduces programming to describing what I want, waiting, and saying "yes, change that," I'm more productive, but am I still doing the thing I originally loved? I'm not sure. I feel this even more with my personal projects. Before AI, I could spend days figuring things out, changing my mind, breaking something, fixing it again. When the project finally worked, it really felt like mine. Now an agent can do a huge part of that work for me in a fraction of the time. So why doesn't that feel better? Because being faster doesn't necessarily make it more satisfying. It's a bit like painting. Someone who loves painting doesn't pick up a brush only because they need a picture. They want to paint it. Maybe that's what I miss in programming: I want to do it. Frontend may feel this first Nolan Lawson recently described AI as "the asteroid currently hitting frontend web development" One example stuck with me. Browser and CSS performance are among Lawson's areas of expertise, but he says that today he'd probably give a Chrome performance trace to Claude Code and ask it for suggestions. Even experts are starting to hand parts of their own specialty to AI. And that says a lot about how quickly the job is changing. Lawson also mentions something I hadn't thought about: "agent experience" may start to matter more than developer experience. We still need to know what we're doing because AI gets things wrong, but more and more, knowing something can mean knowing enough to check the work AI already did. And I'm not sure I enjoy that version of the job. "You're not a coder. You're a problem solver." I keep seeing versions of this: developers aren't paid to write code; they're paid to solve problems. Fair, but it misses that people don't choose careers purely for economic output. We also choose them because we enjoy the work itself. What if I actually like writing code? For some of us, programming isn't just something we have to get through to build the final product. It's part of why we became developers in the first place. So when I'm told, "Great, now AI can do most of that, and you can supervise it instead," I'm not sure that's an upgrade. I didn't become a developer to write better Jira tickets. But I'm not giving up AI Here's the annoying part: I'm not going back. AI is too useful, and pretending I don't need it just to keep programming the old way doesn't make much sense either. The question isn't whether I'll use AI. I will. It's: how do I use AI without letting it do the parts I actually want to do myself? I don't know what that balance looks like yet. Maybe sometimes I'll choose to build something without AI simply because I want to. It's like solving a puzzle when the answer is already online. You can look it up and finish in a minute, but then what's the point? I want to solve it myself. Maybe boredom is telling me something Maybe being bored with AI-assisted programming isn't something I need to fix. Maybe it's telling me something about what I actually enjoyed about programming in the first place. For now, I only know this: AI made me faster. I'm just not sure it made programming more fun, and I'm starting to think those are two very different things. That's part of why I started learning application security and ethical hacking, something I've always been curious about. I want to understand what happens behind the applications we build, how they can be broken, and how to make them more secure. Being a beginner again feels good. I get stuck. I have questions again. Sometimes I understand nothing for a while. That's exactly what I've been missing. I just need harder questions. P.S. I'll be writing more about what I learn in AppSec in my next posts. And I'm curious: has AI made programming more fun for you, or taken some of the fun away?

The question "will AI replace developers?" is the wrong question. The right one: which parts of development are already automated, which are becoming automated, and which require human judgment for the foreseeable future? The honest answer is more nuanced than either the doom camp or the optimism camp admits. What AI Has Already Replaced Boilerplate and scaffolding. CRUD endpoints, form validation, database migrations, component scaffolding — all faster and often better when generated. A developer who spends three hours hand-writing a REST API in 2026 is not being thorough. They're not using their time well. Implementing known patterns. Authentication flows, payment integrations, file uploads, rate limiting — these are solved problems. AI has read all the docs and can produce working code faster than any developer can look them up and type. Writing tests for existing code. Describing a function's behavior and asking Claude to generate a test suite is one of the highest-ROI uses of AI tools. The tests are often better than what a pressed developer writes in a hurry. Explaining unfamiliar code. Dropping an unfamiliar codebase into Claude and asking it to explain what a function does — this works. Not perfect, but dramatically faster than reading code cold. What AI Has Not Replaced Knowing what to build This is the most underrated skill in software development, and AI doesn't touch it. A business says they need a "dashboard." AI can build a dashboard. But whether a dashboard is actually what the business needs — that requires understanding context that exists only in human conversation and business knowledge. The developer who can hear "we need to track user engagement better" and translate it into three concrete, buildable features with an ROI estimate is doing something AI cannot do. The business context doesn't exist in the codebase. Architecture with long-term consequences AI will help you design a system. It will reason through trade-offs and explain implications. What it doesn't have is skin in the game. An experienced developer knows the "clever" solution is usually wrong three months later. They've been in the meeting where a technical decision from two years ago is now costing the company six figures to unwind. That scar tissue informs judgment in a way no training data replicates. Ask Claude to design a multi-tenant architecture — it gives you valid options. Ask a senior developer who has run multi-tenant SaaS in production — they pick one and tell you exactly what will go wrong in 18 months and why it's still the right choice. Different thing. Debugging novel failures This is the clearest dividing line. AI is excellent at debugging known patterns — N+1 queries, race conditions in Promise.all, stack overflows in recursion. These have signatures in training data. AI struggles with failures it hasn't seen before. The production bug that only manifests under a specific combination of load, timezone, and third-party API behavior. The memory leak that takes six hours to appear and disappears when you add logging. These require forming and testing hypotheses in an environment you can observe but AI cannot. Holding five competing explanations, designing a minimal test case for each, systematically eliminating them. That remains fundamentally human. Evaluating AI output Here's the recursive skill: using AI tools effectively requires the ability to evaluate what they produce. A developer who can't tell whether Claude's output is correct, secure, and idiomatic is in a worse position than someone who doesn't use AI at all — they're shipping bugs faster. The developers who get the most out of AI coding tools are the ones with enough experience to catch the 10% that's subtly wrong. Junior developers who rely on AI without the ability to evaluate the output are building on a foundation they don't understand. Security threat modeling AI knows the OWASP top 10. It will tell you to sanitize inputs and use parameterized queries. What it doesn't know is your threat model. Who are your adversaries? What's the actual value of the data you're protecting? Which attack vectors are realistic given your deployment context? Those are judgment calls that depend on business context AI doesn't have. The Shift in What Matters Skills becoming less valuable: Raw typing speed Memorizing API signatures Writing boilerplate from scratch Basic algorithmic problem-solving Skills becoming more valuable: Problem decomposition — breaking ambiguous requirements into buildable specs System thinking — how components interact at scale Evaluation — reading code and knowing if it's right Communication — translating between business requirements and technical constraints Taste — knowing what good software feels like, not just what works today That last one is hard to define but easy to recognize. A developer with taste looks at a system and sees the decisions that will cause pain in 18 months. They choose the boring technology that will still be maintainable when they're gone. They push back on features that solve the wrong problem. That judgment isn't in the training data. What This Means The developers struggling in 2026 are the ones who defined their value by output speed. AI has compressed that advantage. The developers doing well defined their value by outcomes — whether the right thing got built, in a way that lasts, solving a real problem. AI makes them faster at execution without touching their core value. Using AI tools effectively isn't about replacing your judgment. It's about spending less time on parts that don't require it, so you have more capacity for parts that do. AI has replaced the parts of development that were always commodities — the typing, the boilerplate, the lookups. It hasn't replaced the judgment that made good developers valuable in the first place. What's changed is that the commodity work is now visibly commodity. There's no longer anywhere to hide behind volume. The freed-up time either becomes room for higher-leverage work, or it becomes visible slack that's hard to justify. The developers using that time to get better at architecture, system design, and product thinking are compounding their advantage. Full article: stacknotice.com/blog/developer-skills-ai-cant-replace-2026

Originally published on tamiz.pro. The primary anxiety among software engineers in 2024 is not that AI will write code, but that it will write it better and faster than we do. For decades, the currency of the profession was the ability to translate logical requirements into syntactically correct, efficient machine instructions. That currency is rapidly depreciating. The emergence of agentic AI systems and 'System 1' large language models (LLMs) that operate with near-instantaneous, pattern-matching precision is forcing a fundamental redefinition of what it means to be a software engineer. We are moving from an era where engineers were implementers to one where they are architects, validators, and orchestrators. The role is not disappearing; it is leaping to a higher level of abstraction. To remain relevant, we must consciously reclaim our engineering identity by shifting our focus from the mechanical act of coding to the systemic act of design, risk mitigation, and specification. This shift is not merely a career adjustment; it is a structural necessity for the software industry. The Illusion of the 'Code Producer' Historically, software engineering was conflated with code production. Junior engineers were hired for their ability to debug and implement; senior engineers were recognized for their architectural foresight and code quality. The value proposition was clear: you write the code that makes the system work. However, this model was always slightly incorrect. Code is a byproduct of engineering, not the engineering itself. Engineering is the process of solving complex problems within constraints. As AI models become capable of generating boilerplate, handling trivial logic, and even writing entire microservices, the 'code producer' aspect of the role becomes commoditized. If an AI agent can generate a REST API endpoint from a natural language description in seconds, the individual engineer who spent two hours writing that same code has lost their competitive edge on that specific task. The market will naturally adjust to pay for the outcome (a working feature) rather than the process (writing the lines of code). This commoditization is not a sign of the engineer's obsolescence, but a sign of their evolution. The engineer who views their job as 'writing code' is in a precarious position. The engineer who views their job as 'building reliable systems that solve business problems' is in a strong position. The latter role requires skills that current AI models struggle to provide: deep contextual understanding, nuanced trade-off analysis, and long-term maintainability thinking. System 1 vs. System 2 Thinking in Engineering In cognitive science, 'System 1' thinking is fast, automatic, and intuitive, while 'System 2' is slow, deliberate, and logical. Current state-of-the-art LLMs operate predominantly as System 1 engines. They are exceptionally good at pattern completion and probabilistic next-token prediction. They can 'intuit' the correct syntax for a specific framework or the common structure of a unit test. However, they lack the capacity for sustained, goal-directed reasoning required for complex, multi-step architectural decisions. Software engineering, at its highest level, is a System 2 activity. It requires breaking down ambiguous problems into well-defined sub-problems, considering edge cases that may not have historical data, and making decisions based on non-functional requirements like security, scalability, and team velocity. The new engineer's role is to act as the System 2 overlay to the AI's System 1 capabilities. We must use our deliberate reasoning to guide the fast, probabilistic output of the AI. This means: Specification over Implementation: We must write better prompts, which are effectively high-level specifications. The quality of the AI's output is directly correlated to the precision of the constraints we provide. Verification over Creation: We must shift from being the one who writes the code to the one who verifies it. This requires a deep understanding of what 'correct' looks like, not just syntactically, but semantically and contextually. Architecture as Code: The architectural decisions (data flow, service boundaries, API contracts) must be explicit and formal. The AI can implement the components, but it cannot choose the optimal topology for a complex domain without human guidance. The Shift to Orchestration and Agentic Workflows The next evolution in AI assistance is not just autocomplete; it is agentic. Agentic AI systems can plan, execute, and iteratively refine tasks. They can write a test, run it, read the failure, and update the code until it passes. This loop is incredibly powerful, but it is also a black box to many engineers. To reclaim our identity, we must become orchestrators. We are no longer individual contributors pushing commits; we are system owners delegating tasks to a fleet of AI agents. This requires a new set of skills: Context Management: How do we provide an AI agent with just enough context to do the job correctly without overwhelming it or introducing hallucinations? This involves managing vector stores, retrieval-augmented generation (RAG) pipelines, and explicit knowledge graphs. Safety Boundaries: How do we define the 'blast radius' of an agent's actions? If an agent is given access to a production database, what are the guardrails? We must design 'least privilege' architectures for AI agents, much like we do for human users. Quality Assurance of AI Output: We need new tooling and processes to review AI-generated code. This is not just code review; it is intent verification. Did the AI solve the problem we stated, or did it solve a related but different problem? The engineer who masters this orchestration layer will be the one who leverages AI to achieve 10x productivity, not by working 10x harder, but by managing 10x more autonomous agents. Reclaiming Value: The New Core Competencies If code generation is automated, what skills become more valuable? The answer lies in the domains where AI is currently weakest: ambiguity, ethics, and long-term strategy. 1. Deep Domain Modeling AI can write code that fits a pattern, but it struggles with domain-specific nuances that are not well-represented in its training data. An engineer who deeply understands the domain (e.g., financial regulations, medical data privacy, supply chain logistics) can provide the critical context that the AI lacks. This expertise becomes the bottleneck, and thus the value. We must move away from being 'generalists in syntax' to 'specialists in domain logic'. 2. Security and Trust Engineering As AI agents are given more autonomy, the surface area for attack grows. An AI agent that is susceptible to prompt injection or that hallucinates dangerous permissions becomes a security liability. Engineers must take ownership of the 'trust chain' in their systems. This involves secure prompt engineering, rigorous sandboxing of agent actions, and continuous auditing of AI behavior. The role of the security engineer and the platform engineer will merge with the application engineer. 3. Human-AI Interaction Design Software is no longer just a set of static functions; it is a dynamic collaboration between human intent and AI execution. We need to design interfaces and feedback loops that make this collaboration transparent and trustworthy. This includes 'explainability' features that show why an AI made a certain decision, and 'steering' mechanisms that allow humans to correct the course in real-time. This is a new discipline of UX design, specifically for agentic systems. Practical Strategies for Engineers How do we implement this shift in our daily work? Here are actionable strategies: Retro-engineer Your Prompts: Start treating your prompts as production code. Version them, test them, and refine them. Build a library of 'prompt patterns' for your specific stack. Automate the Review, Not the Decision: Use AI to generate initial test cases, but keep the decision on test coverage and edge case identification with a human. Use AI to spot obvious bugs, but keep the architectural review with a human. Focus on 'Glue' Code: AI is best at isolated, well-defined functions. It is worst at the 'glue' that connects complex systems: data transformation between disparate APIs, legacy integration, and complex state management. Invest your energy in these areas where AI still requires significant human supervision. Document Your Reasoning: In an AI-assisted workflow, the code is often ephemeral (generated and regenerated). The reasoning for why a certain architecture was chosen becomes the permanent asset. Document your decisions using Architecture Decision Records (ADRs). This ensures that even if the code is regenerated by a new version of the AI, the intent and constraints remain preserved. Conclusion: The Engineer as the Prime Mover The era of the 'lone coder' is ending. The era of the 'system orchestrator' is beginning. This is not a demotion; it is a promotion. We are moving from the factory floor to the design studio. We must reject the narrative that AI is replacing engineers. AI is replacing task execution. Engineers will replace task execution with strategic oversight. The engineers who thrive will be those who embrace this shift, who view AI not as a competitor but as a powerful tool that amplifies their own cognitive abilities. To reclaim our identity, we must stop defining ourselves by what we type on our keyboards. We must define ourselves by the problems we solve, the systems we design, and the value we create. The code will be written; the question is whether it will be written correctly, securely, and sustainably. That question remains, and will continue to remain, in the hands of the engineer.

AI is writing more code. That part is obvious now. Developers can ask an agent to: create a feature write tests fix a bug refactor a module update documentation generate SQL review a pull request even run commands and modify files And in many cases, it works surprisingly well. But something else is happening at the same time. Developers are writing less of the code, while becoming responsible for more of it. That is the part I think we are underestimating. Because when production breaks at 2 AM, nobody is going to ask: “Which model generated this function?” They are going to ask: “Who owns this system?” And the answer is still us. The Old Workflow Was Easier to Reason About A traditional development workflow looked something like this: Understand requirement ↓ Design solution ↓ Write code ↓ Test it ↓ Review it ↓ Deploy it ↓ Maintain it The developer touched almost every stage. That had problems. It was slower. It required more manual work. But there was one big advantage: The person responsible for the code usually understood how it was created. Now the workflow is changing. The New Workflow Looks More Like This Understand requirement ↓ Ask AI to plan ↓ AI writes implementation ↓ AI writes tests ↓ AI fixes errors ↓ AI reviews code ↓ Developer approves ↓ Production Look carefully at where the human appears. Sometimes the developer is only deeply involved at the beginning and the end. That creates a strange new situation. The developer may be responsible for: architecture they did not design code they did not write tests they did not write dependencies they did not choose edge cases they never considered behavior they only partially understand Yet the developer still owns the result. Responsibility Did Not Disappear This is the mistake I think teams need to avoid. AI-generated code can make something feel less like your responsibility. It is easy to think: “The agent generated it.” But production systems do not care who typed the code. If you merge it, approve it, or deploy it, it becomes part of the system you own. That means you are still responsible for questions like: Is this secure? Does it actually meet the requirement? What happens if the API fails? Can this corrupt data? Does it create a race condition? Is the dependency trustworthy? Can another developer maintain it? What happens under load? What happens six months from now? AI can help answer these questions. But it cannot remove your responsibility for them. “The Tests Pass” Is Not Enough This becomes especially dangerous when AI writes both the code and the tests. Imagine this: Requirement ↓ AI misunderstands requirement ↓ AI writes implementation ↓ AI writes tests for its interpretation ↓ All tests pass Technically: Green CI. Practically: Wrong feature. This is one of the most important things developers need to remember in AI-assisted development. Tests can prove that code behaves according to a certain expectation. They cannot automatically prove that the expectation itself was correct. If the same model creates both the implementation and the test, they can share the same misunderstanding. That is why human review still matters at the requirement level. Developers Are Becoming Supervisors of Software Creation The developer role is slowly changing from: Write Test Debug to something closer to: Define Constrain Delegate Inspect Verify Approve Own That is not necessarily bad. In fact, it can be incredibly productive. But it requires a different skill set. The best developer may no longer be the person who can type code fastest. It may be the person who can: define the problem clearly design good boundaries recognize bad architecture inspect a large diff quickly detect missing edge cases understand system behavior verify assumptions know when AI is confidently wrong Those are engineering skills, not typing skills. The Dangerous Part Is Losing System Understanding This is where I think the real risk begins. Suppose an AI agent adds a feature across 15 files. It modifies: database schema service logic API handlers validation background jobs caching tests frontend state Everything passes. You review the diff quickly. You merge. Then two months later, something breaks. Now you need to answer: Why was this implemented this way? But maybe nobody knows. The AI session is gone. The reasoning was never documented. The developer who approved it only reviewed the output. This is how teams can slowly build systems that work but are no longer deeply understood. Code Generation Can Create Understanding Debt We already talk about technical debt. But AI introduces something slightly different. I think of it as: Understanding Debt Technical debt is often: “We know this code is messy, but we shipped it anyway.” Understanding debt is: “We own this code, but nobody fully understands why it works this way.” That can be even more dangerous. Because messy code is visible. Missing understanding is harder to detect. Everything may look fine until something unusual happens. Small AI Tasks Are Safer Than Huge AI Tasks One simple way to reduce this problem is to stop giving agents enormous tasks. Compare these two prompts. Bad: Build the full subscription system. Better: Analyze the current billing architecture. Explain which files need to change. Do not modify code yet. Then: Implement only the subscription data model. Do not change unrelated files. Then: Add the billing service using the existing service pattern. Then: Add tests for the new behavior. Smaller tasks create smaller diffs. Smaller diffs are easier to understand. And code that is easier to understand is easier to own. Ask for the Plan Before the Code One of the most useful changes you can make is simple: Ask the AI to explain what it plans to do before it changes anything. For example: Before writing code: 1. Explain the current architecture. 2. List the files you plan to change. 3. Explain why each change is needed. 4. Identify possible risks. 5. Wait for approval before implementation. This gives you a chance to catch bad direction early. Fixing a bad plan is cheap. Fixing 800 lines generated from a bad plan is not. Review Decisions, Not Just Syntax Traditional code review often focuses on lines. + const result = await processPayment() But with AI-generated code, the more important review may be: Why is payment processing happening here? That is a different level of review. Instead of only asking: Is this line correct? Ask: Should this responsibility live in this module? Instead of: Does this function compile? Ask: Does this architecture make sense? Instead of: Does the test pass? Ask: Is this testing the right behavior? AI is making syntax cheaper. That means developers need to spend more attention on decisions. Never Merge Code You Cannot Explain This rule becomes much more important in the AI era. You do not need to memorize every line. But you should be able to explain: what changed why it changed what data moves through the system what can fail which assumptions exist which external services are involved how the feature can be rolled back If someone asks: “Why does this work this way?” and your answer is: “The AI generated it.” That is not enough. Once it is merged, it is your system. Let AI Generate Less Context Switching, Not More Complexity AI is extremely good at saving developers from repetitive work. That is where it can create huge value. Let it help with: boilerplate repetitive tests simple migrations documentation refactoring suggestions test data type generation small bug fixes But be careful when the AI starts generating: new architectural layers new dependencies large cross-cutting changes security-sensitive logic complicated concurrency data migrations payment logic The higher the blast radius, the more human understanding should increase. Not decrease. Documentation Matters More Now If AI made an important design choice, capture the reason. Not this: // Process the payment processPayment(); But something like: // We process payment before creating the final order because // failed payments must not create confirmed inventory reservations. That tells the next developer why the code exists. Architecture Decision Records can also help for larger choices. The AI session will disappear. The reasoning should not disappear with it. The Developer Still Needs to Know How to Debug There is another interesting effect here. The more code AI writes, the more valuable debugging becomes. Because when generated code fails, someone still needs to understand: logs state timing network behavior databases dependencies concurrency deployment infrastructure AI may help investigate. But a developer who does not understand the system will struggle to know whether the AI's explanation is correct. That is why I think debugging may become an even more important skill in the AI era. Writing code is becoming easier. Understanding why a system is broken is not. A Better AI Development Workflow Instead of: Prompt ↓ Generate ↓ Tests pass ↓ Merge Try this: Define requirement ↓ AI analyzes existing system ↓ AI proposes plan ↓ Developer reviews plan ↓ AI makes small change ↓ Developer understands diff ↓ Tests run ↓ Failure cases reviewed ↓ Architecture reviewed ↓ Merge The AI is still doing a lot of work. But the developer remains connected to the reasoning. That is the important part. Five Questions I Ask Before Approving AI-Generated Code Before merging, ask: 1. Can I explain what changed? If not, keep reviewing. 2. Does this actually solve the requirement? Not just the test. The real requirement. 3. What assumptions did the AI make? Look for hidden assumptions around data, APIs, users, permissions, and infrastructure. 4. What happens when something fails? Network timeout? Database error? Duplicate request? Partial write? Unexpected input? 5. Will another developer understand this later? Because somebody will eventually maintain it. Maybe you. AI Does Not Reduce Ownership This is probably the most important idea. AI can reduce: typing boilerplate implementation time repetitive work But it does not automatically reduce: responsibility risk ownership maintenance production consequences In fact, AI may increase the amount of software a developer is responsible for. One engineer may soon oversee the amount of code that previously required several people to produce. That makes engineering judgment more important, not less. The Real Developer Skill Is Changing For years, software development was strongly associated with writing code. Now code itself is becoming easier to produce. So the valuable skills move upward. Understanding the problem. Choosing the architecture. Defining constraints. Recognizing risk. Reviewing decisions. Debugging failures. Protecting maintainability. Taking ownership. Those things are much harder to automate completely. Final Thought AI may write more and more of our code. That is probably going to continue. But there is a dangerous assumption hiding behind that productivity: If AI writes the code, AI owns the consequences. It doesn't. You do. The future developer may write less code personally. But they may be responsible for more code, more systems, and more decisions than ever before. So maybe the most important question in AI-assisted development is no longer: “Can the AI build this?” It is: “If I approve this, do I understand it well enough to own it?” Because generating code is becoming cheap. Owning software is not.