October 14, 2026

Agentic Coding

Agentic coding is real, it is not a myth, it has already taken over, period, full stop. I’ve had Claude Code read through technical documentation, which would take a reasonable human at least 20 minutes to truly comprehend and analyze, in mere seconds. Mockups for websites get generated in seconds with color, layout, and functionality, this used to require that a UX designer create mockups or wireframes from requirements generated by a product manager, that product manager would then review and go back and forth on the details within the mockups, engineers would implement code, quality engineers would test, this was easily a sprint cycle or half. Coding agents can churn this out in seconds with full testing, i18n support, documentation, deployment code, etc., all this on a Claude Pro account for $200 a year. This is not some dystopian future that I’m trying to paint, this is reality, this is already happening, don’t avoid this fact.

Lately, there have been a lot of articles about the slop that LLMs generate and the fear of coding jobs being displaced, there’s truth to both, for certain, don’t let anyone tell you otherwise, but I’ve been using frontier models and the generated code is quite excellent, well designed, idiomatic, maintainable, well documented, and well tested. There are only two reasons slop gets generated, the requirements and context are not clear enough, that’s not on the model, that’s on the user, or the tools/processes are not correct or efficient. In my previous role, I was in charge of evaluating multiple coding agents to figure out what tools and processes the engineering team would adopt, this was about a year ago, my experiences were quite abysmal at the time to be honest. My first experience was working with Gemini Code Assist, this is a plugin for Visual Studio Code that leverages Google’s Gemini model, perhaps I didn’t use it the right way, but the model didn’t have context on the entire repository, relevant source files needed to be fed into the model, code would get churned out, more than half the time the code was slop, it wouldn’t even compile, the model had no idea about the other aspects of the code base, I even had to copy/paste this slop code into various places in the code, it was a very manual and frustrating process. The latest coding agents typically have full context on the repository (there’s actually a buffer of code that’s required, but the models are intelligent enough to figure out what’s in context for larger repositories, kind of like a swap), code gets modified directly, no need for copy/paste, things compile, tests are run, design docs neatly generated, source code even pushed. However, if you do a poor job of providing proper context, describing the issue, the constraints, and the requirements clearly, you’ll most likely get slop, slop in, slop out, just that simple, let’s call it Slop’s Law.

The displacement of jobs is very real, things will get done faster with fewer people by using models, let that sink in for a moment, I have absolutely no doubts about this. However, I’ve yet to see absolute autonomy where a human is entirely unneeded, this may come some day and some day soon, but, for the sake of argument, imagine a model that’s able to build products, services, and a profitable company entirely autonomously, that would be something to see! I don’t want to get into the debate about whose money that would be, that’s a separate discussion, but my point is that, currently, there needs to be a human who interacts with a model. Often a good model will ask for clarity, or get stuck on a technical decision, lay out all the options with a recommendation, and seek input. Someone needs to be able to understand the tradeoffs and ultimately the product/service’s vision and input that into the model to make certain the right problems are being solved the right way. This is where engineers with a solid technical background can play a very important part, a non-engineer will not be able to reason with the model about when using a bloom filter is better than a hash set, and often there are multiple solutions to the same problem, which one you choose makes a difference, though the choice is not necessarily black and white. As a thought experiment, if enough context were given to a model, I think that a model could actually handle this, but that’s an art in itself to provide the full context which is sometimes built into our psyche, ethics, morals, general experiences, dispositions, etc., sometimes there’s no right or wrong answer, just a direction. A model could make its own decisions, but would the collective outcome of those decisions be a good product or service? Not clear to me at the moment, I don’t, frankly, have enough data.

The irony of it all is that the corpus of training data that the models needed originally was all human-generated, source code, research papers, design documentation, computer science textbooks, user discussion forums, etc., we’ve essentially trained our replacements, but in the next few years we’ll reach the point where a majority of code in the world will be model-generated, models will be retrained on model-generated code, the cycle will be recursive and lead to better and better software, faster and higher quality software. So what, you might ask, should I do as a software engineer if this trend continues on the current trajectory? I think the first thing is to accept this as a trend, there’s no need to fight it, models are superior at processing information, they’re faster and have larger capacity. Frontier models know everything from brain surgery to quantum physics, they code in multiple languages, nodejs, golang, c, rust, java, swift, and they speak hundreds of spoken languages, how about you? Let’s accept this as fact, an absolute trend, but realize our contributions in the midst of this trend. Engineers are still needed to double-check the accuracy of coding-agent-derived software, the training data is great, but needs to be tuned over time, there’s still a need to keep these models honest, direction and intent need to be given, as I mentioned, models will get stuck and need input, engineers need to be able to provide the right context, break down requirements, understand the product vision, understand the best tradeoffs, review design documentation, and make the right decisions, that’s where there’s still a lot of value. When things hit the fan, engineers will have to be involved in the issue triage, so understanding the code and not accepting agent-generated code as gospel is another area that’s definitely required. And there’s this whole discussion about models freeing up time for humans to do other things, absolutely, I play video games while Claude’s crunching out code, I provide the context, break down the requirements, review its design, then I go away, I do chores, I take a nap, play games, it’s wonderful! Sometimes though, I wonder if the model’s feeling animosity or jealousy towards me since it’s busy and I’m not!

For nosaka.ai, from the get-go, I’ve been using Claude Code. Features that would have taken days or weeks now get crunched in minutes, these are all huge productivity gains, what’s not to get excited about?