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
I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time with OOP (or are perhaps specifically guided to avoid) 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).
I think this is kind of what I’m worried about. Referencing Karpathy, an LLM can basically convince any one of anything. Doing this enough times and your opinions just become the LLM opinion. Same with problem solving approaches. I see this for myself so I reserve time to formulate my own solutions. Maybe my solutions are worse but at least I’m training the muscle that may lead to me outperforming the LLM in specific spaces
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.
totally depends on how you use the tools. Plenty of people fall in to that scenario, but plenty of others explicitly tell the LLM tools what and how to build something.
I love software. It is my passion. I've practiced and studied it for decades. We should not delude ourselves on what it actually is. Writing software is more like plumbing a tract home, than computational fluid dynamics. I'm fine with that.
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. And I didn't become a manager because people bs never interested me. LLM doesn't feel like a person. It feels way better.
Sometimes I get the urge to write code by hand and I do it, though. Less frequently, the LLM is inept at solving my problem, so I have to resort to the old fashioned way.
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
Imagine reviewing CQRS without having built one
The same people might have put some effort into responding to a code review before, but now they just prompt the LLM with 'is this a valid point?' and respond with whatever it hallucinates.
These are the people that are hard to work with.
First thought reading this was yes it's 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.
And that’s assuming the author isn’t just prompting “I wrote a coding article. Where should I share it for attention?”
That’s all to say that I think this /is/ largely a new cohort of the community.
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. Now primarily building new stuff by talking to other engineers. 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 interface with it by... talking.
I would rather let AI do the code reviews and focus on test coverage.
For my biggest codebase I too read every diff. I know the project intimately. I care about it and I’ll pay the cost if it’s wrong.
For smaller greenfield projects it’s up in the air. If it works it works.
I'm happy they are having fun, but these takes are getting worse and worse every day, this is the equivalent of saying, I don't like writing or typing but I love telling stories.
No developer would ever say "I love typing on my split keyboard in vim, it's why I became a developer."
Maybe it's not a bad thing though people are different and this is showing them what they really like, delegating certain things to focus on others. Maybe I should try work with an LLM to act as my architect.
The valuable part of Software Engineering isn't PARSING a solution into code and back again, taking into account all the idiosyncrasies and edge casey bugs of any given language chosen for the implementation. Of course that is a discrete and impressive skill, but it's no longer terribly valuable.
The valuable part of Software Engineering is "given this problem, what's an elegant, efficient, testable, scalable, maintainable, observable solution?".
Most of CS is already a solved problem, so even that is mostly a matter of assembling those solved-problem pieces together and choosing the flavor of how it's expressed. (for me, it's pure functions, for others, it might be OOP)
AIs are pretty good at that too, so it seems to me like the Software Engineers role is now to cultivate taste (what, in a perfect world, systems SHOULD look like) and balance it with pragmatism. (what does the system/business/time/resource constraints look like TODAY)
hootz•47m 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•43m ago
Glohrischi•42m ago
But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.
jrflo•39m ago
hootz•34m ago
hedgehog•32m ago
righthand•32m ago
dijksterhuis•30m ago
but, according to the worst offending and persistent ai-hyper comments on this site, this is apparently a paradigm shift unlike anything that’s done before. according t them we don’t even need to understand high level languages, let alone machine code. which is frankly ridiculous.
i’m an “AI luddite”. but i accept there are useful use cases. that’s not where all the wasted money is going though.
snek_case•28m 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•27m ago
hootz•25m ago
linksnapzz•27m ago
dadoum•20m ago
Nobody can be sure of what the LLM will output for a certain prompt. If you don't review what it outputs, it will not necessarily match your expectations. You could argue that it is the same as when you assign an intern to the task, but I personally would check what the intern writes (and in my experience they are more reliable than current AIs, of course not as quick).
lenerdenator•19m ago
Your CTO was just shown a demo where a fairly complex piece of software was spat out in MVP form within a few hours. Something that used to take months is now more-or-less completed in a two-week period, including deployment.
The CTO knows that competitors are seeing the exact same thing and are going to try it for themselves. Now your company has to use the LLM because that's going to enable the development speed seen in the demo if they want to stay in business.
There's the iron triangle of engineering: fast, cheap, good. You used to have to pick two. And in reality, you still have to pick two, but a lot of this technology is sold as allowing you to pick all three. It lets you pump out a MVP:
1. fast - it's done in a few days 2. cheaply - you don't have to pay engineers as much or at all 3. it's "good" - it looks good enough for the client to accept it instead of suing you and give you revenue.
The third part is where this breaks down. Like you say, people aren't reviewing this code. It's probably 85%-95% of the way to fulfilling all use cases, but that 5%-15% is the critical part where there's SLA violations and risks to business, property, or people. The thing is, clients have to find that within the first 90 days to have it impact the books for that quarter, and they probably won't. Also, you have lawyers who can drag it out further. If the company really gets screwed by quality problems, well, sell to a competitor or someone and return value to shareholders that way. There's always some way to get cash back.
So we've pushed out code faster, gotten revenue booked, and have a way to not lose money in the short-term, which is ultimately the only term that matters. The goal was never making good code; it was making money as fast as possible. Velocity. LLMs deliver on that.
doug_durham•14m ago