posts: add new post

2026-01-13 16:21:33 -06:00
parent ec4a3a8d6a
commit ca0e48dbea
2 changed files with 57 additions and 0 deletions
@@ -0,0 +1,57 @@
 ```json meta
 {
  "title": "Why Agentic AI Won't Replace Engineers",
  "lead": "My thoughts on the rise of agentic AI and why I believe it won't be replacing engineers due to fundamental issues with the math, economics, and liability of such systems.",
  "isPublished": true,
  "publishedAt": "2026-01-13",
  "openGraphImage": "posts/why-ai-wont-replace-engineers/og-image.png"
 }
 ```
 In the last year, the software industry has been largely preoccupied by the rise of agentic AI - AI systems that can run in a loop, receive feedback from their actions, and adjust their behavior accordingly. We saw demos of "Devin" or "AutoGPT" resolving GitHub issues, writing code, and even deploying applications with minimal human intervention. This has led to a lot of speculation about the future of software engineering and whether these AI systems will eventually replace human engineers. Increasingly, folks are saying that software engineering is cooked and that writing your own code is a dead-end career. In other words, the skill of programming is just a commodity that AI will be able to do better, faster, and cheaper than humans.
 I, on the other hand, have become increasingly convinced that the right move as a developer is not to become a shepherd of AI agents and leave my skills as a programmer to rot on the vine, but rather to double down on my craft and become an even better engineer whose skills are as sharp as ever and whose abilities are not obscured by the reliance on AI systems. I believe that many of the predictions about agentic AI as a replacement for human engineers are fundamentally flawed due to issues with the math, economics, and liability of such systems.
 In other words, this is the "Steel Man" argument against the dominance of Agentic AI. And it is entirely possible I read this in 5 or 10 years time and laugh at how wrong I was. But for now, this is where my thinking is at.
 ## P(Reliability) < 1.0
 The core conflict in trying to replace human engineers with agentic AI is the issue of reliability. No matter how good an AI system is, it will never be 100% reliable. There will always be edge cases, unexpected inputs, or situations that the AI has not been trained on that can lead to failures. In software engineering, even a small mistake can lead to significant issues, including security vulnerabilities, data loss, or system outages. Human engineers are able to use their judgment and experience to catch these issues before they become problems. AI systems, on the other hand, may not have the same level of understanding or context to make these judgments.
 Sure, I will concede that there are domains where the demand for reliability is lower and the tolerance for failure is higher. In these cases, agentic AI may be able to handle certain tasks effectively. But in high-stakes environments where reliability is critical, such as healthcare, finance, or infrastructure, the risk of relying solely on AI systems is, I think, too great. And the best you will ever be able to do is to continue applying ever-increasing levels of effort to push the probability of reliability closer and closer to 1.0, but never actually reaching it.
 ## Review and Oversight Tax
 I'm not going to sit here and write that AI systems are not getting better nor that they do in fact generate code at an alarming rate. They do. It is pretty incredible and it often feels like magic when the code it generates is remarkably similar to the code I would have written myself. In fact, this was one of the reasons I signed up for a GitHub Copilot subscription. Having AI-powered code completions has been a huge productivity boost for me. However, the problem with scaling this type of code generation to agentic AI systems that can write and deploy code autonomously is the review and oversight tax that comes with it.
 What I mean by this is that when I am evaluating the code generated by Copilot for a single method or even just several lines of code, I can quickly review it for correctness, style, and security. However, when an agentic AI system is generating entire applications or systems, the amount of code that needs to be reviewed increases dramatically. This means that human engineers will still need to spend a significant amount of time reviewing and testing the code generated by these systems to ensure that it meets the necessary standards. This review and oversight tax can quickly erode any productivity gains that come from using agentic AI systems. Imagine the reaction you get today from coworkers when you open a PR that is 500+ lines of code across 60 files. Everyone is jumping at the chance to review that PR, aren't they?
 Now imagine that PR was generated by an AI system and no engineer really feels full ownership for the changes. The amount of time and effort required to review and test that code would be significant. This means that even if agentic AI systems can generate code quickly, the overall productivity gains likely have some serious diminishing returns due to the need for human oversight which again - see above - can never be fully eliminated due to the reliability issue.
 ## Speed vs Coherence
 LLMs are really good at generating text quickly. This is one of their core strengths. However, when it comes to generating code, speed is not the only factor that matters. Coherence and maintainability are also important considerations. LLMs have a fundamental limitation in that they generate text based on patterns in the data they have been trained on and the context provided to them. This means that while they can generate code quickly, the code may not always be coherent or maintainable over time because projects will reach a level of size and complexity that is difficult for an LLM to fully grasp in a single prompt or even a series of prompts.
 I think this issue is probably minimal at this point given that so many agentic systems are still in their infancy and humans are still heavily involved in the process, carefully crafting prompts and guiding the AI systems. However, as these systems become more autonomous, the risk of generating incoherent or unmaintainable code increases. This means that human engineers will still need to be involved in the process to ensure that the code generated by these systems is coherent and maintainable over time.
 ## Who Do You Sue?
 One of the biggest issues with relying on agentic AI systems to replace human engineers is the issue of liability. If an AI system generates code that leads to a security vulnerability or data breach, who is responsible? Is it the company that developed the AI system, the company that deployed it, or the individual engineer who oversaw its use? This is a complex legal and ethical issue that has yet to be fully resolved.
 Imagine if, as an engineer who wields agentic AI systems to generate code, you now need to carry the equivalent of malpractice insurance in case the code generated by the AI system leads to a security vulnerability or data breach. This could lead to increased costs for companies and engineers alike, making it less attractive to rely on these systems. I can only imagine that engineers would be a lot more cautious about approving PRs generated with agentic AI if they knew that they could be held personally liable for any issues that arise from the code.
 And regardless of where the liability is placed, the reality is that companies will likely be hesitant to fully rely on AI systems for critical tasks due to the potential legal and financial risks involved. This means that human engineers will still be needed to oversee and manage these systems to ensure that they are being used responsibly and ethically.
 ## What About De-Skilling?
 This is probably the biggest concern I personally have about the unknown impact on the engineer when relying heavily on agentic AI systems. Sure, the companies and businesses that deploy these systems and mandate their use will likely reap most of the economic benefits, but where will the engineers be left? I'm concerned that there is a real human cost to pushing software development towards an agentic AI model. Engineering largely relies on a feedback loop of learning, coding, and debugging. Engineers gain expertise - aka intuition - through time spent in this loop.
 This expertise is what allows them to make good decisions about architecture, design patterns, and trade-offs. If engineers are relying heavily on agentic AI systems to generate code, they may not be getting the same level of feedback and learning opportunities that they would if they were writing code themselves. Over time this could lead to a de-skilling of the engineering workforce, where engineers become less skilled and less capable of making good decisions about software development.
 I feel this risk is being largely ignored by some of the biggest proponents of agentic AI systems who themselves are more often than not senior engineers who've already obtained a high level of expertise. They may not fully appreciate the impact that relying on these systems could have on the development of junior engineers who are still learning the craft. If we want to ensure that the engineering workforce remains skilled and capable, we need to be careful about how we integrate agentic AI systems into the software development process. We need to find room for human engineers to continue learning and growing their skills.
 ## Conclusion
 I hope you'll come away from reading my thoughts not with the idea that I am anti-AI or anti-agentic systems. I am not. In fact, I believe that AI has the potential to be a powerful tool for software engineers, helping them to be more productive and efficient. However, I also believe that there are fundamental issues with relying solely on agentic AI systems to replace human engineers. Issues with reliability, review and oversight tax, coherence, liability, and de-skilling all point to the need for human engineers to remain involved in the software development process. Rather than seeing agentic AI as a replacement for human engineers, I believe we should see it as a tool that can augment and enhance their skills, allowing them to be even better engineers than they were before.
 It would also be awesome if we could stop with all the doom and gloom predictions about the death of software engineering as a career. There is still so much to be built and so many problems to be solved that skilled engineers will be needed for the foreseeable future. So let's double down on our craft, continue learning, and embrace the tools that can help us be even better at what we do. The future of software engineering is bright, and I for one am excited to be a part of it.