It’s unfortunate because many of us are going “full AI” when it comes to coding. And there are some true gives and takes that are interesting to explore.
Sadly, this piece reads like pure hype.
And look I wrote all that in 1 paragraph without bullet points detailing anything over and over.
I've been working with Apache AGE (openCypher in Postgres) recently and found that left to its own device, the agent wrote terribly inefficient queries, even when given a test harness and instructions to examine the result of the query plan.
It just didn't seem to understand the graph traversal, even when given the graph schema and small snippets.
I ended up hand-writing the structural "skeleton" of the main query that I performance tuned to a certain extent and then handed it over to Codex to finish off. Once it had this skeleton to start from, it was able to do a much, much better job of writing this query.
> Slowly your brain just gets trained to mid thinking like an LLM
Regression to the mean.I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time (or are perhaps specifically guided) with OOP and writes a lot of `private static` utility functions. A lot of duplicated small utilities that can end up becoming a maintenance nightmare should the behavior need to be normalized/fixed. String key formatting, for example. JSON serialization behavior, another very common one. At a higher level, it needs very active guidance to search for existing code and re-use interface contracts via DI consistently (we have instructions and skills for this, but hit or miss on usage and adherence)
It generates very repetitive code and doesn't have the wits to refactor is in a way that is reusable, even in simple cases (basic JSON serialization).
It really dislikes to create object and type hierarchies on its own (e.g. move the repetitive serialization to a base class) and prefers to write one-offs. Works, but not very elegant; lots of duplication and touch points for regressions.
It also has a tendency to write more "verbose" solutions where sometimes simpler ones will work.
Mix of CLI (Codex) and GH Copilot (if I want active line selection).
We have a set of custom skills and knowledge base as well.
What is not clear to me is whether this is inherent desirable behavior on the part of the agent or not. Why? Because for the agent, the code is more isolated and its immediate changes have a lower blast radius by internalizing some behavior (`private static`) versus touching a shared method or hierarchy.
I can see why the underlying models may be steered this way, but it creates a different kind of problem when things really should be shared.
This is my experience as well, and I've been using Claude Code a lot.
Extremely impressive tools, but they're like fast food. They will solve your immediate problems quickly and cheaply, but you're going to have issues on the long term if that's all you use.
Sometimes I get the "you're right!" response, but often it will also explain why it made the decision it did, and it's rational enough that I accept the new approach.
It's still very much like a junior dev in this way - pretty good at 'just make it work', pretty good at monkey-see-monkey-do, and occasionally surprises you with something novel (to you).
The quality of the craft can live on in open source and personal projects.
Not really. You write the specs, you write the architecture. You ask the model to implement your solution.
You can stop this by detailing exactly what solution you want but I think continuous leaning on the LLM will lead you into a confined space.
It's not all that different from what happens if I am delegating a larger task to another human being. The only actual difference there is that wit a person, I'd rather underspecify as to give them ore of a sense of freedom and opportunity for growth, while the LLM isn't learning anything, so, if anything, it's easier.
I've noticed that Claude with the current model can act most of the time like a trusted senior engineer sounding board for me. However on occasions we disagree. Recently we had a stand up argument about a proposed solution to a potential security risk in a system. I realized Claude had taken on a kind of "corporate culture" thinking on the problem (which was to do with use of a vault/broker to hold user credential data) that would be appropriate in some contexts, but wasn't in ours. The experience was totally like arguing with someone on the corporate Slack, but in the end I control what gets deployed so I won. But I'd say 90% of the time I get as much value out of Claude on these discussions as I would if I knew one competent person for each of the subjects we discuss, and had called that person for advice. Of course even though my network is...vast...I just don't know a competent person in every single field.
Obviously the agents are great at producing large chunks of code, but they often make minor and sometimes trivial mistakes which need amending.
Typing something like "in src/auth/session/token_manager.ts the refreshTokenExpiry variable should be refresh_token_expiry. update every reference and make sure nothing else changes" and waiting for the LLM to do its thing takes longer than opening the file and doing the rename yourself.
If you are describing microscopic edits in natural language you are not avoiding coding. You are coding through an extremely verbose, lossy interface with higher latency and lower precision.
EDIT: flagged?
My current verdict. When used properly, and if you actually read the code, pushback when needed and don’t get approval fatigue, and also practice hand coding here and there, you can definitely get immense productivity boosts while not compromising on quality. The issue is blindly accepting AI code, architecture, “are you sure this is prod ready?” “Ok ship it” is not going to end well. Too many times I caught the top SOTA models, 1M context, effort on max, suggest or do terrible things and say it with confidence.
TLDR if you read the code (and understand the architecture), and know when to push back. This can work amazingly well.
Otherwise you will gradually build a Rube Goldberg machine.
I think most people dont want that discipline either. engineers in the west live in a world of convenience. The loss of discipline is almost expected. Apart from those who really love it and take pride.
And we’ve seen that outsourcing to low cost regions = no discipline.
Note that I'm not saying the agents are useless. They certainly write a lot of code and sometimes it is good. But I don't think you can get away without touching code yourself simply because at some level it is often the most concise way to get your idea across. I find it best to implement a core set of changes by-hand, and then ask the system to e.g. replicate them to other dependencies. I genuinely don't understand how anyone can work on a system with any complexity, and get the results they actually want, without touching code.
I always considered myself a builder, a creator. The end result is interesting and it's important for me the end result to be just as I envisioned it.
Typing code isn't exciting. Thinking, planning, finding solutions and driving the LLM to implement the finished product is.
It’s like I spent 20 years mastering painting in watercolour… nerding out on other painters, canvas options, even the backstory on some guy that makes a specific paint etc.
And I don’t regret any of that. but now I’m just loving creating my art 100x faster.
I thought I loved the craft (and I did) but more, I loved the product.
Building software consists of many parts. I love each individually. I was always a bit dissatisfied about how they interact and how they block each other. I love puzzle solving, I love debugging, but I kinda hated building software because it depended on those elements and I'm not fond of context switching.
I can love building software now.
This idea of reviewing an architecture that you never coded is just a fantasy.
At some point in time, me and a lot of people, thought that using Redux was a great idea until we had to manage verbosity and middlewares. Now we had to deal with the consequences of our decisions and we learned.
I also think this article is just a rage bait
When looking for a career move you might want to focus on the trajectory more than the current state.
I tend to do oddball stuff (eg. software for custom arcade machines, AR games) and any forays I've made into AI code have made it seem like a total waste of time for me. (ie. I will spend much longer trying to get AI do to a shitty job, compared to just doing it myself)
I do see the long-term goal as being the elimination of most engineering positions. If you can have an architect - or, even better, some solution manager talking directly to the customer - just prompt a solution into existing and monitor most of it, you can really reduce the headcount.
Not saying this is a 1:1 parallel, or that writing is what makes you a good coder, but I do wonder - if you remove the entire process of making something, what is left there? Sure, people keep arguing that architecting or "managing" AI agents is the actual moat, but is this really? If you do not participate in the craft itself, how would you get better?
I mean, I have amazing ideas for wooded furniture I'd like to build. I doubt that if you give me an LLM connected to a router that I would be able to build something by "architecture, review, push back, and argue". I simply lack the knowledge to make something out of wood. And the only way to get this knowledge is to go and make something and not "architect, review, push back, and argue".
The one project that did give me pause was an S3 Server. Not entirely sure I trust that…
Toying with the idea of sticking a proxy in between that runs the vibe coded S3 in parallel to a classic server and see if the results track
Year 0-12: Coding lots, learning lots.
Year 12-22: A product I built really took off. Building via other enginers. Lots of product management/politics. Atrophying coding skills.
Year 22-28: I'm tired of building by talking. Re-learning coding.
Year 28-: "Here's this thing called Claude Code".
I wonder if there'll be another cycle that involves someone like me.
I would rather let AI do the code reviews and focus on test coverage.
hootz•26m ago
Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?
maxheyer•22m ago
Glohrischi•21m ago
But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.
jrflo•18m ago
hootz•13m ago
hedgehog•11m ago
righthand•11m ago
dijksterhuis•9m ago
snek_case•7m ago
Just yesterday, I was trying to use Claude Opus 4.7 to debug an issue in a program that I wrote, and its solution was to remove a feature, change the design to eliminate the problem without consulting me. I only found out that it had removed this feature through testing. Imagine not reviewing things like that. How can people argue for this with a straight face? We'll probably get there eventually, but there's no need to rush before the tech is ready. Doing that is just being clueless.
cguess•7m ago
hootz•4m ago
linksnapzz•6m ago