AI coding assistants speed development, raising questions about human judgment and core engineering skills

“Meat proxy” is the worst insult you can hurl at me right now. The term, popularized in August 2026 by the software engineer Niklas Gruhn, refers to a person who takes what artificial intelligence generates and passes it on to another person without reading or even thinking about the output first. As someone who takes pride in my independent thinking, that is the biggest insult I could imagine receiving, if people thought I was operating under AI’s instructions. It’s easy to look down on people who copy and paste AI-generated text, code, or images. We have a name for this stuff: AI slop. As a society, we snicker at the people putting out AI slop—“They’re so lazy, but they’re not fooling anyone.” For a long time, I thought I’d never rely on AI to think, especially when it came to making editorial decisions about my own writing. But as the models got better, I couldn’t help but be tempted to feed them something—a draft LinkedIn post, an email I needed to send to a coworker, or even a text to a friend about a sensitive matter—to see what AI had to say. What I found was that AI can be genuinely helpful. It was nice to have another pair of eyes read through what I had drafted before sending it out, comforting even. And that was how I found myself two weeks ago copying and pasting my draft texts to friends and family into ChatGPT to get its read before I sent them out. That was my “Oh crap, am I a meat proxy now?” moment. After which I frantically texted my friend, “I don’t want to be a meat proxy, Stefan.” Why people become meat proxies Meat proxies aren’t necessarily lazy. They may value speed for tasks they genuinely do not care about but have to complete. They might be someone who has to write a paper for school, gives AI the prompt and the readings, then copies and pastes the output and submits it on Canvas. They could be someone who asks AI a question and assumes that everything returned to them is true, no fact-checking necessary. That cavalier attitude explains how we end up with the AI faux pas of prompt instructions or ChatGPT responses accidentally included in submitted essays and emails. Or, they may be afraid of getting something wrong and find it easier to trust AI than go through the painstaking process of learning, producing, and trusting their own work. Fear can numb our thinking, and AI is trained on more data than any one human could ever learn. It presents everything with such confidence that it’s easy to doubt ourselves in the face of such authority. Sometimes, the fear of being wrong outweighs the terror of offloading our thinking to someone or something else.  There’s another reason we may be so willing to trust AI. It feels human. We’ve given it names, voices, and personalities, and designed it to have conversations with us. There’s evidence that anthropomorphizing AI can make us more likely to trust it. And I can see why. At work, I don’t feel like I’m consulting a piece of software anymore. Instead, AI feels like a ramping-up buddy, so of course I’ll sometimes accidentally defer to its judgment. How to use AI with agency  Many companies around the world are adopting AI to generate more revenue, and their employees are expected to use these solutions to be more productive. AI has allowed social media managers to keep tabs on the latest trends around the clock, enabled analysts to do their jobs faster, and, in a way, given all of us personal assistants. This is why the discussion is not as black and white as, did you use AI, or even, did you delegate work to AI? Of course you did, and more than ever, you’re expected to, or you’ll never get through your mountain of work. Whether we like it or not, AI is embedded in our workflows. The question isn’t whether or not to use AI; it’s how to use it without becoming a meat proxy. The deciding factor of whether we have crossed into meat proxy territory is whether we are still exercising human judgment. Even when AI has summarized information or done analysis for you, are you the one making the decision about what to do with that, or have you delegated that most important step to AI, too? To use AI with human agency, approach each session by doing your own preparation first. That could be having a hypothesis about the answer you are hoping to get from AI about a problem, or it could be developing a point of view outside of AI tools so you are ready to push back at AI’s initial output, which should almost never be taken as final.  Once you arrive at an output resulting from a bit of back and forth with AI, learn to sit with it. Take the time to read the output in its entirety. Ask yourself whether what you just read makes sense, whether it’s clear, and increasingly important, whether it sounds like you.  Use human judgment with AI but reserve judgment of other humans It’s tempting to judge people who have delegated judgment to AI, but when companies invest in AI expecting higher productivity, that expectation can easily push employees to trust AI rather than themselves. The expectation to work much faster while retaining human judgment is almost contradictory by its nature, which explains why some people become meat proxies, not by choice, but due to pressure. This becomes a new question we as professionals must grapple with: what we are delegating to AI and whether we are retaining ultimate judgment. I’d argue that anyone actively thinking about this is unlikely to be or become a meat proxy. As for those of us quick to judge and label a person a meat proxy, we should probably exercise some restraint and human judgment of our own. Just because someone used AI does not mean they delegated their thinking to it, and just because the final output is bad does not mean AI was responsible for it. Sometimes, we as humans are responsible for the very bad output. Calling someone a meat proxy doesn’t address the problem, and it doesn’t provide any feedback on how to do better besides not relying on AI, which is unrealistic. After reading this, if you think it was bad, just know I wrote it myself and take full responsibility for it. When it comes to writing opinion pieces, my philosophy is to always write them myself without any use of AI because I want the opinions to be truly mine. So you can dislike this piece, but please don’t call me a meat proxy.

Originally published on tamiz.pro. Every month, another AI agent framework crosses the 50K GitHub stars threshold. AutoGen, CrewAI, LangChain, MetaGPT—these projects accumulate stars faster than most developers can read their README files. Meanwhile, git merge remains the single most searched error on Stack Overflow, and the number of engineering blogs written about resolving merge conflicts in a large monorepo has remained flat for a decade. This isn't a coincidence. It's a symptom of a culture that rewards novelty over competence, and I think it's actively making our industry worse. The Star Economy Is a Distraction GitHub stars are a vanity metric that has metastasized into a full-blown attention economy. A framework that lets you orchestrate five LLM agents to write poetry gets more stars in a week than a carefully designed concurrent lock manager gets in a year. This isn't because the lock manager is unimportant—it's because "agents" is a buzzword and "concurrency" is a chore. The problem isn't that AI agent frameworks are useless. They're genuinely interesting engineering artifacts. The problem is that they've created a false signal about what good engineering looks like. When a junior developer opens GitHub and sees that the most popular repository is a Python wrapper around ChatGPT, they don't learn that they need to understand HTTP, or that their database queries are slow, or that their CI pipeline has been broken for three days. They learn that the future is about calling APIs. Merge Conflicts Are the Real Test Let me make a concrete argument: if you can handle merge conflicts at scale, you understand more about software engineering than someone who can prompt-engineer a multi-agent system. A merge conflict isn't just "git said two lines overlap." A real merge conflict in a codebase with 200+ active developers, 50+ feature branches, and a shared infrastructure layer is a systems problem. It asks: Do you understand the domain well enough to know which change is semantically correct? Can you reason about the interaction between two changes that were developed in isolation? Do you have the judgment to know when to refactor, when to accept, and when to escalate? Can you communicate with the person who made the conflicting change without it becoming a political fight? These are the skills that separate senior engineers from junior ones. They're not glamorous. They don't get you a keynote slot. But they're what actually keep a codebase alive when it hits the thousand-developer mark. The Fundamentals Nobody Wants to Talk About Here's what I mean by "going back to basics." The skills that are being de-emphasized while everyone chases agent frameworks: Version control mastery. Not just git add and git commit. Rebase vs. merge strategies. Understanding the difference between a fast-forward merge and an octopus merge. Writing merge drivers. Understanding the git rerere mechanism. These are the skills that let a team of 50 people work on the same codebase without descending into chaos. Code ownership and boundaries. Before you can orchestrate agents, you need to understand module boundaries. What does it mean when two agents (or two developers) modify the same abstraction? The DDD concepts that AI agent frameworks pretend to solve are the same concepts that have been taught in distributed systems since the 1990s. Testing at the integration level. AI agent frameworks ship with demo scripts that work. Real integration testing—where you verify that your agent framework actually composes correctly with your existing services—is still an unsolved problem. And the people who can solve it are the same people who understand how to write a good integration test for a monolithic application. Performance and resource management. An AI agent framework that spawns five subprocesses and makes ten sequential HTTP calls to an LLM API is a performance disaster. The people who can fix this are people who understand process scheduling, connection pooling, and memory management. Not people who can write a prompt. The Danger Isn't the Trend, It's the Narrative I'm not arguing that AI agent frameworks are bad. I'm not arguing that we should stop building them. I'm arguing about what we teach, what we reward, and what we consider "engineering." The narrative is clear: the future of software engineering is about orchestrating AI agents. The reality is that the future of software engineering is about building systems that contain AI agents alongside everything else—databases, message queues, legacy services, third-party APIs, and human developers who still need to resolve merge conflicts. When we celebrate the 60K-star agent framework and ignore the merge conflict resolution problem, we're telling developers that the hard part of engineering is the interface—the prompt, the orchestration layer, the framework API—rather than the substance—the correctness, the performance, the maintainability, the actual integration with the real world. What Actually Matters Here's my thesis: the developers who will succeed in the next decade are not the ones who can use the latest agent framework. They're the ones who can: Resolve a merge conflict between two changes that touch the same business logic module, understand the domain implications of each change, and produce a correct resolution. Design a system where AI agents operate within well-defined boundaries—boundaries that require understanding of module interfaces, dependency injection, and error handling. Debug an integration failure between an AI agent and a legacy REST API—failure that requires understanding of HTTP semantics, timeout behavior, and retry logic. Write a test that verifies an AI agent's behavior under adversarial input—behavior that requires understanding of property-based testing, fuzzing, and formal verification concepts. These are not glamorous skills. They don't get you a conference talk. But they're the skills that actually build reliable software. The Path Forward I'm not being nostalgic. I'm being practical. The AI agent framework wave is real, and it's creating enormous value. But value is created by engineers who understand systems, not just interfaces. The next generation of developers needs to learn that the merge conflict is not a bug—it's a feature of the system that demands deeper understanding. If you're a tech lead, invest in your team's fundamentals. Teach them how to resolve complex merge conflicts. Have them read the git source code. Make them design module boundaries before they write a single line of orchestration logic. Yes, this is unsexy. But it's the difference between a team that can build something that works and a team that can build something that lasts. If you're an individual developer, here's my advice: pick up an open-source project with 200+ contributors. Volunteer to resolve merge conflicts. Learn how the maintainers handle competing changes. Understand the tension between feature velocity and code coherence. This is the training that no AI agent framework course can give you. The 60K-star agent framework is exciting. But the zero-star merge conflict is where the real engineering happens. Go resolve some conflicts. For more technical insights on engineering fundamentals and AI development, visit Tamiz's Insights. Frequently Asked Questions Q: Are AI agent frameworks really overhyped? A: Not inherently. They're interesting engineering tools. The problem is the attention they receive relative to fundamental skills like version control, module design, and integration testing. The hype cycle creates a false signal about what matters. Q: Should I stop learning AI agent frameworks? A: No. Learn them, but don't stop learning the fundamentals. The developers who will succeed are the ones who can orchestrate agents and resolve merge conflicts, write integration tests, and understand system boundaries. Both skill sets matter. Q: How do I practice merge conflict resolution? A: Contribute to a large open-source project (e.g., Kubernetes, Rust, React). Volunteer to review PRs with conflicts. Use tools like git rerere to understand how Git handles recurring conflicts. Read the git documentation on merge strategies. The goal is to understand the domain implications of conflicts, not just the mechanics.

I first heard about NUMMI years ago on an episode of This American Life. Toyota took over one of General Motors’ worst factories in Fremont, California, rehired many of the same workers, and turned it into one of its best plants. As software engineering enters the era of AI-generated code, NUMMI offers a crucial lesson: increasing speed without built-in mechanisms for quality only helps you produce defects faster. One of GM’s Worst Factories In the early 1980s, GM closed its Fremont plant due to chronic absenteeism, grievances, strikes, and deliberate sabotage. The prevailing view was simple: the workers were the problem. When Toyota created the NUMMI joint venture in 1984, they rehired those exact same workers and sent union leaders to Japan to study the Toyota Production System. They learned that quality was not enforced by end-of-line inspectors—it was built into every step by the people doing the work. The workers returned and transformed GM’s worst plant into a model of efficiency. The Cord and the Flow At the heart of NUMMI’s success was the andon cord. If a worker found a defect, they pulled a cord to call for help, stopping the line if necessary. At GM, workers were forced to let defects move downstream, where they became exponentially more expensive to fix. Toyota viewed a defect moving downstream as a failure, treating problem discovery not as an error, but as an opportunity to fix the system. Modern software engineering digitized this concept: commit → build → test → deploy → production CI/CD, automated testing, feature flags, and instant rollbacks are simply digital andon cords designed around flow—producing in small batches to get immediate feedback and contain damage early. Kaizen and Culture Toyota also practiced kaizen (continuous improvement) by listening to the factory floor. They built simple fixtures and tools to eliminate awkward movements, recognizing that the person doing the job daily understands friction better than management. In software, we call this developer experience: internal platforms, faster CI builds, and local setup scripts. NUMMI demonstrated that ordinary people inside a good system produce extraordinary results, while talented people trapped in a bad system eventually look incompetent. But culture cannot be a motivational poster. Culture is not what leadership writes on the wall. Culture is what the system rewards when something goes wrong. Now We Have AI AI has made generating software fast and cheap. However, using AI purely to maximize volume leads directly to AI slop: unmaintainable code, superficial test coverage, hallucinated documentation, and over-engineered abstractions. AI makes bad engineering practices scale just as quickly as good ones. If AI generates code ten times faster, our feedback loops must adapt. Automated tests, strict observability, clean architecture, and human comprehension become more critical, not less. The goal should not be "How much more code can we generate?" but rather "How can AI remove friction so humans can think better?" The AI Andon Cord Because AI agents can generate fifty "stations" of work before a human steps in, we need explicit circuit breakers to stop runaway generation: Tests fail? Stop. Scope creeps beyond the task? Stop. The diff exceeds readable limits? Stop. Architecture grows unnecessarily complex? Stop. The faster we generate, the more valuable the ability to stop becomes. Don’t Ask AI to Move the Line Faster Engineering leaders must resist measuring AI solely through output metrics like lines of code or closed tickets. Go to where the work happens: sit with engineers, identify where AI adds friction, and build guardrails around it. Without the right system, AI simply speeds up the production of bad software. With the right system—and an andon cord built for AI—it becomes the ultimate tool in an engineer's hands.

AI coding agents have changed the speed of software development dramatically. A task that once took a team weeks can sometimes be implemented in hours. An AI agent can explore a repository, understand existing patterns, write code, run tests, and open a pull request—all while a human is still trying to understand the first few files. This creates a new engineering problem: The bottleneck is no longer writing code. It is understanding what is being built. The AI Speed Gap Many engineering teams are adopting AI coding tools with an obvious goal: move faster. But there is an uncomfortable side effect. The amount of code an engineer is expected to review can grow much faster than their ability to understand it. This becomes particularly difficult during migrations or when adopting unfamiliar frameworks. You may be learning a new architecture, reviewing AI-generated code, understanding other people's changes, and still being expected to deliver faster than before. Trying to solve this by simply reading more code doesn't scale. We need a different workflow. Don't Go From Ticket → Code A traditional workflow looks something like: Ticket → Developer understands problem → Developer designs solution → Developer writes code → Review With AI agents, it can easily become: Ticket → Agent explores repository → Agent designs solution → Agent writes code → Pull request The human has effectively been removed from some of the most important reasoning steps. A better workflow is: Ticket → AI investigation → Architecture proposal → Human understanding → AI implementation → Human review Before asking an agent to write code, ask it to explain: Where does this functionality currently live? How does the existing system work? What components, services, APIs, or data flows are involved? What exactly needs to change? What is the smallest reasonable change? What existing patterns should be followed? What could this change break? How should we test it? The goal isn't to make the AI slower. The goal is to make sure the engineer understands the change before the code starts multiplying. Your Job Is Changing You don't need to understand every line of AI-generated code. You need to understand the system well enough to answer five questions: Where does this feature live? What is the architecture around it? What is changing? Why is this implementation correct? What could break? If you can answer those questions, you can review a large change without manually reconstructing every line of code. Your value isn't necessarily in typing every line anymore. It is increasingly in understanding the problem, making good technical decisions, and validating what the AI produces. Use AI as a Teacher, Not Just a Coder AI coding agents are also powerful learning tools. When you encounter unfamiliar code, don't just ask: "What does this code do?" Ask: "Teach me this implementation. Assume I understand the old architecture, but I'm new to this framework. Map the concepts to things I already know." You can also ask: "Why was this approach chosen?" "What are the alternatives?" "What assumptions does this code make?" "What are three ways this implementation could be wrong?" This turns the AI from a code generator into a senior engineer sitting next to you. If AI only writes your code, your dependency on it increases. If AI writes code and helps you understand the system, your engineering capability increases alongside it. Learn the 20%, Not Everything When adopting a new framework, it is tempting to start from the beginning and learn everything. That is rarely practical during a fast-moving project. Instead, identify the small set of concepts that explain most of the code you actually encounter. For a new UI framework, that might mean focusing first on: Components State Properties Events Rendering Lifecycle Composition Data flow Testing Then learn how your organization's architecture uses those concepts. You don't need to become an expert in the framework before contributing. You need enough understanding to build the right mental model. Build an External Brain When everything is changing at once, don't rely on memory. Maintain a simple system map of your application: Application │ ├── Platform │ ├── UI │ ├── Components │ ├── State │ └── Routing │ ├── Backend │ ├── APIs │ └── Services │ ├── Data │ └── Testing For each major area, capture four things: What is it? Why do we use it? How does data flow through it? Where does the code live? Let AI help maintain this documentation as the system evolves. Over time, this becomes your mental map of the application—and makes every subsequent AI-generated change easier to understand. The Goal Isn't to Understand Everything The goal is predictive understanding. You should eventually be able to look at a ticket and think: "I know roughly where this belongs." Then look at the proposed implementation and think: "I understand why the agent chose this approach." And finally look at the pull request and think: "I can identify what could go wrong." You may not understand every line. But you understand enough to predict the behavior of the system. That is a much more scalable skill in an AI-assisted engineering environment. AI Makes Engineering Judgment More Important, Not Less The biggest mistake would be to respond to faster AI development by simply trying to work faster yourself. You can't compete with an AI agent at generating code. You don't need to. Instead, move yourself further upstream: Understand the problem → shape the architecture → let AI implement → validate the result → learn from the implementation. The engineers who thrive in this environment won't necessarily be the ones who write the most code. They'll be the ones who can understand systems, make good decisions, and keep humans in control while AI operates at machine speed.

Originally published on tamiz.pro. Two years ago, I could not make a Copilot suggestion pass code review without rewrites. Today, half my PRs ship with AI-generated code that I barely edited. The tooling genuinely got better. The question nobody asks honestly is whether I got worse at the underlying engineering — and whether my colleagues, juniors especially, are being quietly hollowed out by an assistant that answers every question before they struggle through it. This is not an anti-AI rant. It is a developer's technical audit of what has changed, what has been genuinely replaced, and what has been quietly eroded. The distinction between those two categories is the entire argument. What AI Actually Replaced (And We Should Accept That) There are real, measurable categories of work that AI coding assistants have genuinely automated. These are not losses. They are wins. Boilerplate and scaffolding. Generating a React component from a spec, writing a CRUD endpoint, creating a Dockerfile, setting up a test fixture — these were never intellectually interesting. They consumed time and attention that could have gone to architecture decisions or debugging. AI handles these well now. A junior developer who spends twenty minutes on a boilerplate template can instead spend that time understanding the system's data flow. Documentation and API lookups. Before AI, I spent more time reading TypeScript type definitions than writing code. I would open a library's docs, search for the right overload, and discover that the function signature I remembered was from two versions ago. AI assistants now answer these questions in context, with accuracy that has improved dramatically. This is pure time savings with zero cognitive cost. Regex, date parsing, and string manipulation. These were the tax developers paid for working with text. AI writes regex patterns, date formatting utilities, and string transformations that work on the first try. This is a genuine replacement — not because the task was hard, but because the cognitive overhead of getting it right was disproportionate to its value. Test generation for straightforward cases. Unit tests for pure functions, snapshot tests, and integration test scaffolding are now reliably generated. The generated tests are not always meaningful, but the structural work of writing them is done. If your daily work is dominated by these categories, AI has made you more productive. That is unambiguous. I am not arguing against that. What AI Made Lazy (And This Is the Real Problem) The concerning trend is not replacement. It is the substitution of understanding with suggestion. Let me be specific about what I have observed in my own work and in the work of junior developers on my teams. Debugging has become search-and-paste. When an error occurs, the reflex is no longer "let me trace through the call stack and understand why this happened." It is "let me ask the AI what this error means and what to change." This works — until the AI gives you a plausible but wrong explanation, and you apply it without verifying. I have seen this happen repeatedly on my team. A developer pastes an AI-suggested fix for a race condition, it appears to work in testing, and then it manifests in production under load because the AI suggested adding a setTimeout instead of properly understanding the async flow. The fix was syntactically correct and semantically wrong. Type safety is being bypassed. TypeScript exists to make invalid states unrepresentable. When you are typing code from scratch, you engage with the type system — you ask "what does this function actually accept?" When you paste AI-generated code, you skip that engagement. The code compiles. The types are wrong. The error appears three layers down in production. I have reviewed PRs where the AI generated a any cast to make a type error go away, and the developer merged it without questioning why the cast was needed. Architecture decisions are being outsourced to autocomplete. This is the one that worries me most. When a junior developer asks "how should I structure this module?" and the AI returns a pattern, they adopt it without evaluating whether it fits the system. The AI has no context of your team's conventions, your deployment constraints, your performance requirements. It gives you a textbook answer, and textbook answers fail in production because production is not a textbook. I have seen this with state management choices, database schema designs, and API contract decisions. The AI's suggestion was reasonable in isolation. It was wrong for the system. The struggle is being skipped, and the struggle was the learning. This is the philosophical core of my argument, but I will ground it in engineering. When you write a function from scratch and it fails, you learn why it failed. You learn the language's semantics, the library's behavior, the system's constraints. When you generate code from a prompt and it works, you learn nothing. You have a working feature. You do not have understanding. Six months later, when that feature needs modification under different constraints, you cannot modify it because you never built the mental model. You can only regenerate it and hope the new prompt produces something compatible. This is not hypothetical. I have a team member who has been on AI-assisted development for eighteen months. Their code output is high volume and generally functional. But when I ask them to explain the reasoning behind a non-obvious design decision in their own code, they cannot. They ask the AI to explain it to them. The AI gives a plausible explanation. They nod. They do not understand. The Pattern I Am Watching I am not arguing that AI should not be used. I use it daily. I am arguing that there is a spectrum, and we are sliding toward the wrong end of it without noticing. The productive pattern: You understand the task. You write the code. You ask the AI to review it, suggest improvements, or catch edge cases. The AI is a second pair of eyes. You remain the primary author. This pattern preserves skill development while accelerating output. The lazy pattern: You describe what you want. The AI generates code. You paste it. You test it. If it works, you ship. The AI is the primary author. You are the delivery mechanism. This pattern produces output while degrading capability. The difference is not visible in the code that ships. It is visible six months later when the system needs to change, or when a bug appears that requires understanding rather than pattern matching. In the first case, you have the mental model. In the second case, you do not. What I Have Changed in My Workflow I have made deliberate adjustments based on this audit. These are not rules. They are practices. I write first, then ask. For anything non-trivial — any function with business logic, any architectural decision, any code that touches shared state — I write the initial version myself. Then I ask the AI to review it. I ask it what I might have missed, what edge cases exist, whether my approach has a better alternative. This keeps me in the author seat while using the AI as a collaborator. I ask "why" before "what." When the AI suggests a fix, my first question is not "should I apply this?" It is "why does this error happen, and why does this fix address the root cause?" If the AI's explanation does not match my own understanding of the system, I investigate further. If the explanation reveals something I did not know, I learn. If it reveals that the AI does not understand the system, I ignore the suggestion. I audit generated code for type safety and assumptions. Every AI-generated code block gets a review pass specifically looking for any casts, implicit type coercion, unvalidated inputs, and hidden assumptions about the environment. The AI does not know your deployment target, your data constraints, or your team's conventions. It optimizes for code that looks correct, not code that is correct in context. I protect junior developers' learning curve. On my team, we have a practice of "write it yourself first" for the first three months of a new hire's tenure. After that, AI-assisted development is encouraged, but code review explicitly asks the developer to explain their understanding of the code they pasted. If they cannot explain it, the code does not ship. This is non-negotiable for us. The Honest Assessment AI has not made developers dumber. AI has made it possible for developers to be dumber while still producing functional output. The tooling is genuinely better. The productivity gains are real. The replacement of boilerplate work is a net positive. But the erosion of foundational understanding is also real, and it is not visible in metrics. It is visible when the system needs to evolve, when a novel problem appears, and when a developer encounters a bug that does not match any pattern in the AI's training data. At that point, the developer who has been generating code for two years without writing it themselves has no fallback. They have no mental model. They have only the tool. The developers who will thrive are not the ones who use AI the most. They are the ones who use it correctly — who write first and ask second, who understand before they paste, who treat the AI as a collaborator rather than a replacement for their own reasoning. The AI got better while I was away. I do not think we got dumber. But I think some of us are getting lazier, and laziness in engineering is a slow, invisible failure mode that compounds until the system breaks. The question for every developer is not "should I use AI?" It is "am I using AI to augment my understanding, or to replace it?" The answer to that question is not visible in your PRs. It is visible in your ability to debug, to architect, and to explain why the code works the way it does. If you cannot answer that last question for your own code, the AI has not helped you. It has delayed the reckoning. For more analysis on AI's impact on developer workflows and engineering practices, see Tamiz's Insights for ongoing coverage of the tools and trends shaping modern software engineering. Frequently Asked Questions Should I stop using AI coding assistants entirely? No. That would be a poor trade. AI assistants genuinely improve productivity for boilerplate, documentation, and routine tasks. The risk is not using AI — it is using AI in a way that prevents you from building understanding. The productive pattern is to write first, ask second, and always audit what you generate. How do I tell if I am in the "lazy pattern" vs. the "productive pattern"? The simplest test: can you explain the code you wrote to another developer without referencing the AI? Can you debug a modification to that code from first principles? Can you explain why you chose a particular approach over alternatives? If the answer to any of these is "I would need to ask the AI," you are in the lazy pattern for that task. Does this apply to AI tools beyond coding assistants? Yes. The same dynamic applies to AI-generated documentation, AI-assisted architecture design, and AI-generated test suites. The pattern is universal: when the tool produces the answer before you have built the understanding, you skip the learning. The fix is the same: engage first, ask second, audit always.

"Will AI replace developers?" is the wrong question. The better one is: how should we change the way we work? AI's biggest gift isn't faster typing. It gives teams more room to understand the problem, test their decisions, and build products people actually want to use. TL;DR AI should extend what your team can do, not let anyone skip the thinking. Start with repetitive work where the result is easy to check. Put guardrails in place before you speed up: testing, security, and review apply to AI output too. Measure product outcomes, not lines of code. The work hasn't shrunk. It has moved. An engineer can now ask AI to sketch a feature, explain an unfamiliar codebase, write test cases, draft API docs, or summarise a production incident. Tasks that used to break a whole afternoon of focus now take minutes. That doesn't make the engineer's job smaller. It moves the most important work to the front: choosing the right problem setting the right constraints weighing the trade-offs owning the experience users end up with AI can generate options. People still have to choose the one worth building. The trap: speed that turns out to be debt AI-generated code can look completely convincing while resting on a bad assumption, missing an edge case, or calling an API that no longer fits. A team that only tracks how much faster it ships is easy to fool. What feels like productivity can be technical debt that shows up later. ✅ Use AI as a lever Ask it to state its assumptions and risks before it proposes a solution Review the diff, the tests, and the user-facing behaviour like any other change Save the prompts, decisions, and results that worked so the whole team learns from them ❌ Don't use AI as a shortcut Shipping generated code you don't understand Pasting customer data or secrets into tools that haven't been approved Letting fast code generation replace discovery and product thinking How we adopt AI at Nexa Tech 1. Start small Pick repetitive work that's easy to verify: unit tests for pure functions, pull-request summaries, fixtures, or turning an issue into a checklist. The value is real and the risk is low. 2. Set guardrails first Decide which data never leaves your systems, who reviews AI output, what the minimum test coverage is, and when you roll back. Clear rules are what let a team use AI with confidence. 3. Give AI context, not just prompts AI does better work when it knows your conventions, your architecture, and your definition of done. Keep the README, decision records, good examples, and test suite up to date. They help new teammates and AI alike. 4. Measure outcomes Track lead time, post-release defects, review time, and user satisfaction. If a tool adds lines of code but none of these numbers improve, it hasn't given you a real advantage. The skills that are worth more now Skill Why it matters 01 Asking better questions Breaking a vague problem into constraints, success criteria, and steps you can verify. 02 Technical judgement Spotting the answer that is almost right but doesn't fit your system, your data, or your users. 03 Systems thinking Weighing product, operations, security, and experience together so the decision holds up over time. Make AI a team advantage, not a personal trick The strongest team isn't the one with the most AI tools. It's the one that turns what each person knows into something the whole team can use: prompt patterns for familiar tasks, review checklists, component libraries, reliable tests, and regular, honest talks about what worked and what didn't. 💡 Pair before you automate For the first few weeks, let AI suggest and let people decide. Note where it saves time, where it adds noise, and why. Once you have that evidence, you'll know what is safe to automate. One question to ask every time Before accepting any AI output, ask: "If AI weren't here, how would I check this?" If you can still read the code, run the tests, inspect the data, and explain the choice to a teammate, AI is making you stronger. If you can't, it is hiding a gap. AI isn't the enemy of good engineering. It raises the bar. Good engineers will be judged less by how fast they type and more by how well they turn complex problems into products people can trust. How is your team using AI in its workflow? What has worked, and what hasn't? Let me know in the comments 👇 Originally published on the Nexa Tech blog.

Earlier this year, I had my first practical experience integrating Artificial Intelligence into my daily workflow. The initial challenge was using AI to extract business rules from a legacy AS/400 system. This work was done directly on the COBOL codebase without making any changes to the code itself. Once the rules were extracted, the output was reviewed alongside a COBOL specialist. Shortly after, I took the next step: using AI to develop new solutions in Java, Spring Boot, and Google Cloud Platform (GCP). I must admit, it is quite intimidating at first to watch an AI generate code and run tests so rapidly. During this initial phase, I relied heavily on manual prompting. Over time, I transitioned to SDD (Spec Driven Development), which drastically optimized the quality and precision of the generated code. Since I had already been reading articles about AI in development, my biggest concern was always code review. Reviewing a few lines is easy, but doing so when the AI produces hundreds or thousands of lines of code is a completely different story. Relying solely on manual reviews would be unfeasible and would defeat the purpose of using AI to boost team productivity. This stage made me feel quite insecure at first; after all, since you didn't write that code from scratch, you feel a lack of control over the situation. To mitigate this risk, I adopted a clear strategy: before deploying the application, the golden rule is to ensure that all unit tests run successfully across the entire application. This became the main safety net to verify that the AI hadn't broken existing functionalities. Next, the application is deployed for functional testing. In the implementations where I used AI, the tests passed 95% of the time. A few minor bugs were caught during the QA (Quality Assurance) phase, but most of them were related to the specification rather than the code itself. For instance, there was a scenario where a specific query was supposed to use a LIKE clause, but the AI didn't include it simply because it wasn't specified. Another bug found in QA involved a request that returned a 200 OK status, but one of the underlying tables failed to update under certain conditions due to an unhandled exception. Once you get past that initial adaptation phase, the process becomes much less stressful. The generated code keeps getting better, and the code review process itself now includes AI analysis. Of course, this requires a continuous refinement of instructions—without improving the specifications, the quality of the generated code suffers. Today, I view AI as my pair programmer, a partner that assists throughout the entire software development lifecycle, from technical refinement to final implementation. I am deeply grateful to the company for giving me the opportunity to move past theory and start using AI in a responsible and professional manner. Artificial Intelligence is here to stay and change the game. Will it replace programmers? I don't have the answer to that. But I do know that change is happening right now, and I choose not to be left behind.

One of the popular memes in literature, movies and tech journalism is that man's creation will rise and destroy it. Lately, this has taken the form of a fear of AI becoming omnipotent, rising up and annihilating mankind.The economy has jumped on the AI bandwagon; for a certain period, if you did not have "AI" in your investor pitch, you could forget about funding. (Tip: If you are just using a Google service to tag some images, you are not doing AI.)However, is there actually anything deserving of the term AI? I would like to make the point that there isn't, and that our current thinking is too focused on working on systems without thinking much about the humans using them, robbing us of the true benefits.What companies currently employ in the wild are nearly exclusively statistical pattern recognition and replication engines. Basically, all those systems follow the "monkey see, monkey do" pattern: They get fed a certain amount of data and try to mimic some known (or fabricated) output as closely as possible.When used to provide value, you give them some real-life input and read the predicted output. What if they encounter things never seen before? Well, you better hope that those "new" things are sufficiently similar to previous things, or your "intelligent" system will give quite stupid responses.But there is not the slightest shred of understanding, reasoning and context in there, just simple re-creation of things seen before. An image recognition system trained to detect sheep in a picture does not have the slightest idea what "sheep" actually means. However, those systems have become so good at recreating the output, that they sometimes look like they know what they are doing.Isn't that good enough, you may ask? Well, for some limited cases, it is. But it is not "intelligent", as it lacks any ability to reason and needs informed users to identify less obvious outliers with possibly harmful downstream effects.The ladder of thinking has three rungs, pictured in the graph below: Image: Notger Heinz Imitation: You imitate what you have been shown. For this, you do not need any understanding, just correlations. You are able to remember and replicate the past. Lab mice or current AI systems are on this rung.Intervention: You understand causal connections and are able to figure out what would happen if you now would do this, based on what you learned about the world in the past. This requires a mental model of the part of the world you want to influence and the most relevant of its downstream dependencies. You are able to imagine a different future. You meet dogs and small children on that rung, so it is not a bad place to be.Counterfactual reasoning: The highest rung, where you wonder what would have happened, had you done this or that in the past. This requires a full world model and a way to simulate the world in your head. You are able to imagine multiple pasts and futures. You meet crows, dolphins and adult humans here.In order to ascend from one rung to the next, you need to develop a completely new set of skills. You can't just make an imitation system larger and expect it to suddenly be able to reason. Yet this is what we are currently doing with our ever-increasing deep learning models: We think that by giving them more power to imitate, they will at some point magically develop the ability to think. Apart from self-delusional hope and selling nice stories to investors and newspapers, there is little reason to believe that.And we haven't even touched the topic of computational complexity and economical and ecological impact of ever-growing models. We might simply not be able to grow our models to the size needed, even if the method worked (which it doesn't, so far).Whatever those systems create is the mere semblance of intelligence and in pursuing the goal of generating artificial intelligence by imitation, we are following a cargo cult.Instead, we should get comfortable with the fact that the current ways will not achieve real AI, and we should stop calling it that. Machine learning (ML) is a perfectly fitting term for a tool with awesome capabilities in the narrow fields where it can be applied. And with any tool, you should not try to make the entire world your nail, but instead find out where to use it and where not.Machines are strong when it comes to quickly and repeatedly performing a task with minimal uncertainty. They are the ruling class of the first rung.Humans are strong when it comes to context, understanding and making sense with very little data at hand and high uncertainties. They are the ruling class of the second and third rung.So what if we focus our efforts away from the current obsession with removing the human element from everything and thought about combining both strengths? There is an enormous potential in giving machine learning systems the optimal, human-centric shape, in finding the right human-machine interface, so that both can shine. The ML system prepares the data, does some automatable tasks and then hands the results to the human, who further handles them according to context.ML can become something like good staff to a CEO, a workhorse to a farmer or a good user interface to an app user: empowering, saving time, reducing mistakes.Building a ML system for a given task is rather easy and will become ever easier. But finding a robust, working integration of the data and the pre-processed results of the data with the decision-maker (i.e. human) is a hard task. There is a reason why most ML projects fail at the stage of adoption/integration with the organization seeking to use them.Solving this is a creative task: It is about domain understanding, product design and communication. Instead of going ever bigger to serve, say, more targetted ads, the true prize is in connecting data and humans in clever ways to make better decisions and be able to solve tougher and more important problems.Republished with permission of the World Economic Forum. Read the original article.