I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. Slowly your brain just gets trained to mid thinking like an LLM. At least that’s my theory and I think there was some study that showed that interacting with an LLM at the start of a problem significantly narrowed the solution space to something sub optimal
> 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 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.
Predictable yeah. We're far better to find the right overarching narrative of the architecture and the necessary intermediate layers of abstractions. LLMs will invent verbal structs that sound okay but not have the elegance of a senior OOP. Although once the good foundation is there, agents can be great at extending and maintaining features on it.
This sounds very much like a problem of the context, that should be solvable by having a file with instructions on how to do generic utilities somewhere in the code (e.g. AGENTS.md)
We have; but it's also not easily practical because there is some judgement involved and it's not really feasible to point out all of the edge cases (bloating the context).
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.
> If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written.
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.
Have you tried drilling into the reasoning when this happens? This is why I usually leave it in "Plan Mode" and when it proposes a solution that seems unusual or unexpected, I point out why I think it is and ask it to justify it's position.
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).
> 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.
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
Fast food might be the right approach if it's a business that prefers speed to maintainability, and they might move towards that with LLMs. I wish more developers would go with it instead of fight it. It's not like it's a personal failure you can't convince the business to slow down and prefer quality.
The quality of the craft can live on in open source and personal projects.
More like developers who give quality away for free then are left wondering why businesses who make millions still end up squeezing the life out of them.
I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.
That’s a good point but I think this article above would push back on this point slightly. I certainly am able to do a lot more with LLMs because it can produce a passable solution in a lot of places but I’m not sure it expands my solution space really. I tend to separate what I’m able to build and what I’m able to solve. I can build a frontend with an LLM but I don’t think I’m able to solve frontend engineering problems.
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.
If you have a very specific decision in mind, there's no need to ask the LLM at all and hope it guesses it. Depending on how sure I am, I will either explain what I want vaguely, or even phrasing things as questions, or be direct and inflexible. It ends up writing the code I would.
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 was mainly just speaking to the point of the article with regards to ability to think about code/solve technical problems. I think most EMs I speak to would say their technical skill set is degraded from years not writing code. I think if you just review code without writing it, your technical skills degrade regardless of whether you are reviewing junior or LLM code. In both cases you maybe gain architecture design and soft skills but you are definitely not improving your technical skill set
> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one.
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.
some models do ok with instruction, some don't. You still have to review pretty thoroughly and make corrections or re-prompt.
For the most part I use claude code w/ opus plan mode + sonnet implementation mode, and it does pretty well. I go through the planning process for anything other than the most basic changes.
I'm not sure about this. I think it's much the same as when you work in an organization comprising humans, and many of them are not so right about everything. Perhaps this will be familiar :)
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.
But the specs can’t be fully detailed or else they would just be code which is the point the article above makes. You can certainly limit where the LLMs have freedom by writing more detail but obviously that defeats the purpose of LLMs. What I mean more broadly though is more along the lines of baked in solutions. The LLM will generally prefer certain architectures/libraries/patterns. If you develop a spec alongside an LLM (which I think most people do) you will get pushed towards those. You kind of close yourself off to other ways of solving a problem.
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.
That presumes that software has a wide solution space. In my experience writing software from the kernel all of the way to distributed systems is that the space is narrow. There are certainly a few long tail areas that require unique approaches, but you'll hit those a couple of times a decade.
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.
What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along
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.
I don't want to be a manager, but I also don't want to be a technician (for the most part). I want to be an engineer, which means my job is to solve problems. LLMs help me solve problems faster, so I use them.
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.
Three quarters of my university class couldn’t code properly, like seriously struggled with basic coding tasks but still made their way through the course.
You then get into the work environment where despite hiring efforts you still find those numbers hold.
You seem to think you can only be an engineer if you are holding the shovel yourself.
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.
Maybe engineer was the wrong word. Developer/programmer, where I'd say that yes, you need to wield the tools yourself rather than telling someone/thing else to
I'm happy for you that you enjoy being a manager. I'm just saying that a lot of people seem to have found they prefer managing another system writing the code for them asking it nicely to do things, rather than writing code myself. I'm in the camp of enjoying typing code, and I do not want to become a manager, either of LLMs or people
People bragging that they "dont touch code" and only "argue" with agents are reinventing the slowest possible IDE.
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.
In the latest commit, refreshTokenExpiry should be snake case. Fix and make a note to do that in $LANG.
Or otherwise scope the rule. The point is you don't need to be super verbose about it and you get to fix forward too, preventing the same issue reoccurring. You build knowledge and context that let you move faster.
Codex and CC are actually getting better at reviewing code and flagging issues. False positive rate dropped fairly significantly. Also obviously might be very personal preferency but creating clear specs and iterating on specs really helps to crystalize the approach I want to take to solving a given problem.
But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code?
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?
I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?
The difference is that LLMs are not compilers. You can't trust the output to be correct. They routinely make bad design choices. If you're prototyping some kind of throwaway MVP, you're just sketching something, it's probably fine not to review it. If you're trying to build a piece of software that's going to survive for years, why are you doing this? The tech is clearly not yet fully mature.
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.
It did atrophy, but more importantly understanding what's going on below the code you are writing, even if your project isn't assembly, also atrophied. When you're coding an Electron app with Javascript you're so far removed from any concept of the efficiency a modern CPU can achieve you stop caring about optimization. Speed and memory management don't matter and then you get... well, the modern web.
There's clearly a range of outcomes, from the people pushing the envelope in system performance (look at the state of networking ASICs and the code to drive them) to people adopting hyper-complex frameworks for cloud orchestration and job coordination that turn a few screens of code into system so slow and complex it needs a team to maintain it. It's all happening at once, and it's probably ok. Keep in mind, knowing how to write assembly and knowing how to get good performance out of a CPU are two different things, modern chips are insanely complicated and the mental model is a long way from the days of the 386 or 68030 (let alone pre-MMU computing).
The compiler has been written by a lot of very smart people, it is very well tested and sometimes has even been formally proven to output exactly what the language specifies, and I have a mental model of what the code it outputs does in relation to what I write.
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).
The move to HLLs created new classes of problems that assembly programmers didn't face; so while the # of problems that necessitated understanding hw didn't shrink, it did relative to the list of things that could now go wrong.
And they did atrophy! I only know assembly because I deliberately studied it and practiced it for reverse engineering. But in my view, no longer being able to understand high level code is a much, much bigger problem than not understanding assembly.
Yeah. Actually, that's a cool thing to think about. Will it be possible in the future for an LLM to be deterministic enough to the point of becoming essentially a text to code compiler? Like, an entire class of LLMs that are meant to be deterministic to the point that even upgrades to the model wouldn't completely change the outputs (it could have some breaking changes).
reality is more nuanced. some people still need to inspect machine code by hand. people who primarily write SaaS django boilerplate don’t. the arguments were made back then, im sure.
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.
This analogy is always weird to me, the change your talking about was still deterministic. Switching from programming to describing programming and having a machine make a best guess is not a deterministic shift as previously happened.
Already happening. For many people, coding isn't the only thing they've abandoned. They've also traded science and engineering for LLM punditry. Rather than "focusing on solving problems," as they often claim, they spend their time chasing unscientific debates about which model or magic prompt "performs better." By unscientific, I mean there's nothing measurable, no reproducible methodology, and no way to validate their hypotheses. Or rather, their wild speculations that change every week.
Accountability is the key. You are accountable for the work product. You need to do what is necessary to make sure that the product meets standards. How you do it is of secondary importance. If reading code is what is needed to guarantee quality and you stop, that is on you.
There is a saying that many countries have offshored building hardware, aka manufacturing. Now they are offshoring software building to AI. Perhaps the silicon valley will grow a rust belt.
I don't think it's necessarily a question of laziness. It's more about velocity.
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.
I wish the tech field wasn't so full of clueless grifters. The most frustrating thing is that this kind of people, the kind who loudly and confidently assert bullshit claim based on insufficient knowledge, have a knack for positioning themselves in positions of power.
It’s aggressively AI written. I’d rather just read the prompt.
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.
Following the calculator analogy made by another person here and not disrespectful but joking intentended but this sounds kinda:
"I'm done. I'm not going to do a calculation, remember a single formula or theorem anymore. Now I'm just choose the problem that I want to solve and the math branch that I wanna use. I think all these educations stages (decades) was the toll we had to pay and I'm not going to pay anymore. "
Also who can say that is able to consider all weights that each decision involves and be able to surpass AI's broad view!?. I mean ... mythos finding a full chain of processes to make an exploit from a single bug? We can beat that ?! For how long ?
I don't know where it is going to end up but as a newcomer to the field I 'll try to keep learning programming and build a solid base. Focusing less on knowing all little syntax of each language or library and outsourcing all boring and repetitive tasks to AI.
I don't take sides here: I welcome such a wonderful tool but everything has its tradeoffs.
I'm a Software Engineer and I think the author is probably right that many Software Engineers are misguidedly placing too much weight on their ability to read and write code.
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)
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.
The people who I work with who have gone full LLM prompt engineer are the people who produced low quality, sloppy work. Generally they never liked to be challenged and never appeared to put much effort in.
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.
> After many years into coding I found out that writing the code was the toll I paid to get those decisions into reality.
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.
This text is regurgitated on a daily basis. I skimmed through the text and could tell not only that but also that the author has given up on writing altogether.
> I think harder about the real problems
Are you /really/? If an LLM gives you an immediate, coherent answer, there's a risk you accept the framing too quickly instead of doing the harder work of questioning premises, testing alternatives and noticing what might be missing.
> If an LLM gives you an immediate, coherent answer, there's a risk you accept the framing too quickly instead of doing the harder work of questioning premises, testing alternatives and noticing what might be missing.
Arguably having a conversation with something so confident but random makes me more inclined to "verify before trust" instead of the usual "trust but verify." Im already very question premisy but interacting with ai 10x's that instinct. My skepticism level is higher because of temperature and seeing when I ask something multiple times I get dice roll answers.
Opposite, I trust less and less the more I use these things. Must write certain things myself, especially types. Sometimes I'll even touch a new file myself (I know, creating files yourself?!) and write some pseudocode in a new file alongside some voice vomit
With all the people saying that you're going to have problems because the LLM is not good at refactoring or large code bases or OOP, etc. the point may be that if you're working to develop skills, an LLM herder might be a good one. Even if the models are almost, but not quite, good enough yet - they will be.
When looking for a career move you might want to focus on the trajectory more than the current state.
You know any AI war heroes? You went full AI engineer, man. Never go full AI engineer. You don't buy that? Ask Roy Lee, 2025, "Cheat On Everything." Remember? Went full AI engineer, went home empty-handed.
The problem I have is that I find generic code reviews really, really boring. With agents I write less code but read more code that I didn't write myself, which makes the job more boring than it was.
I would rather let AI do the code reviews and focus on test coverage.
This would be fine if LLMs had a dedicated language or a well-tuned abstraction that suited their abilities well. Right now we are trying to fit our square languages into the LLM's round hole.
I’ve been on and off and on the bandwagon on this.
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.
I just can't get behind this perspective, perhaps because I am a 'bad prompter', simply due to the lack of capability from current models. I end up rejecting them, asking them to implement again, they spew out tons of crap code instead of a 10 line fix, and on, and on.
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.
There seems to be a split. There are a substantial group of people like yourself who don't get what they want from LLMs. There are folks like me who get excellent idiomatic code almost every time. Both experiences are real and should be respected. I'm hoping that future investigations will find out why that is the case.
Most of the AI submissions are from people who are here to self-promote their own content and have little to no other participation. It's like this stuff appeals to a different audience than made up this site 5 years ago. Everything and everyone feels so nonsubstantive now.
These blogs are AI-written. Claude/ChatGPT love a follow-up. I guarantee they’re suggesting something along the lines of “Great catch on that typo. This is looking good. Ready for plenty of upvotes on Hacker News and Reddit!”
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.
Is anyone doing this who is not making CRUD web-apps or other very common types of programs for which there is masses of training data to copy from the net?
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)
"low level highly performance sensitive" doesnt mean uncommon. What you're doing may be common with loads of examples to copy. (I dont know cus u didnt say what you're actually doing)
Feels like what one of those morbidly obese people riding electric scooters would write about not missing walking one bit. God forbid they end up in an area where accessible alternatives to stairs are not a thing.
I haven’t touched LLM coding beyond using TabNine originally and that has since been disabled. My LSP is good enough and I haven’t fallen behind on delivering code before deadlines. Not sure what the constant hype is about.
And look I wrote all that in 1 paragraph without bullet points detailing anything over and over.
People using google translate to speak a language. Except the language contains more complexity, meaning, and compression that the writer can't describe without using more words/tokens than it would be to actually write with the same precision. They could instead use better tools to achieve equal results with higher confidence.
"The fun part was never lifting weight. The fun was in being buffed with a 6-pack and picking up women. The fun is in bullying those who are weaker than me. I never liked going to the gym and lifting weights. What I actually love is the result of the lifting, but I never wanted to do the hard work".
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".
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.
We're basically doing the same thing where I'm at.
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.
I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. Slowly your brain just gets trained to mid thinking like an LLM. At least that’s my theory and I think there was some study that showed that interacting with an LLM at the start of a problem significantly narrowed the solution space to something sub optimal
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.
can you say which llms you're using? have you tried different ones and how were they?
Team is a mix; I'm personally using Codex, gpt-5.5 high fast + Claude Opus 4.6 (occasionally Sonnet 4.6).
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.
Predictable yeah. We're far better to find the right overarching narrative of the architecture and the necessary intermediate layers of abstractions. LLMs will invent verbal structs that sound okay but not have the elegance of a senior OOP. Although once the good foundation is there, agents can be great at extending and maintaining features on it.
This sounds very much like a problem of the context, that should be solvable by having a file with instructions on how to do generic utilities somewhere in the code (e.g. AGENTS.md)
We have; but it's also not easily practical because there is some judgement involved and it's not really feasible to point out all of the edge cases (bloating the context).
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.
> If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written.
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.
Have you tried drilling into the reasoning when this happens? This is why I usually leave it in "Plan Mode" and when it proposes a solution that seems unusual or unexpected, I point out why I think it is and ask it to justify it's position.
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).
> 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.
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
How much time do I want to spend on this vs. just writing the old-fashioned way?
Fast food might be the right approach if it's a business that prefers speed to maintainability, and they might move towards that with LLMs. I wish more developers would go with it instead of fight it. It's not like it's a personal failure you can't convince the business to slow down and prefer quality.
The quality of the craft can live on in open source and personal projects.
I agree, just like some people decide that they're OK with eating junk food every day, knowing the long term risk. They are free to take it.
Lol sure thing Sam!
More like developers who give quality away for free then are left wondering why businesses who make millions still end up squeezing the life out of them.
I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.
That’s a good point but I think this article above would push back on this point slightly. I certainly am able to do a lot more with LLMs because it can produce a passable solution in a lot of places but I’m not sure it expands my solution space really. I tend to separate what I’m able to build and what I’m able to solve. I can build a frontend with an LLM but I don’t think I’m able to solve frontend engineering problems.
It's a mixed bag.
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.
If you have a very specific decision in mind, there's no need to ask the LLM at all and hope it guesses it. Depending on how sure I am, I will either explain what I want vaguely, or even phrasing things as questions, or be direct and inflexible. It ends up writing the code I would.
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 was mainly just speaking to the point of the article with regards to ability to think about code/solve technical problems. I think most EMs I speak to would say their technical skill set is degraded from years not writing code. I think if you just review code without writing it, your technical skills degrade regardless of whether you are reviewing junior or LLM code. In both cases you maybe gain architecture design and soft skills but you are definitely not improving your technical skill set
> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one.
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.
How do you make it follow your instructions though? I often an agent like Codex how to build something, and then it just ignores me.
some models do ok with instruction, some don't. You still have to review pretty thoroughly and make corrections or re-prompt.
For the most part I use claude code w/ opus plan mode + sonnet implementation mode, and it does pretty well. I go through the planning process for anything other than the most basic changes.
Yes, and LLMs are also very supportive, you get less critical feedback.
I'm not sure about this. I think it's much the same as when you work in an organization comprising humans, and many of them are not so right about everything. Perhaps this will be familiar :)
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.
> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative
Not really. You write the specs, you write the architecture. You ask the model to implement your solution.
But the specs can’t be fully detailed or else they would just be code which is the point the article above makes. You can certainly limit where the LLMs have freedom by writing more detail but obviously that defeats the purpose of LLMs. What I mean more broadly though is more along the lines of baked in solutions. The LLM will generally prefer certain architectures/libraries/patterns. If you develop a spec alongside an LLM (which I think most people do) you will get pushed towards those. You kind of close yourself off to other ways of solving a problem.
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.
That presumes that software has a wide solution space. In my experience writing software from the kernel all of the way to distributed systems is that the space is narrow. There are certainly a few long tail areas that require unique approaches, but you'll hit those a couple of times a decade.
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.
What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along
I’ve found it interesting too.
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.
I don't want to be a manager, but I also don't want to be a technician (for the most part). I want to be an engineer, which means my job is to solve problems. LLMs help me solve problems faster, so I use them.
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.
Three quarters of my university class couldn’t code properly, like seriously struggled with basic coding tasks but still made their way through the course.
You then get into the work environment where despite hiring efforts you still find those numbers hold.
I’m not surprised LLM usage has taken off.
You seem to think you can only be an engineer if you are holding the shovel yourself.
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.
> LLM doesn't feel like a person. It feels way better
Somebody trademark this! :D
Maybe engineer was the wrong word. Developer/programmer, where I'd say that yes, you need to wield the tools yourself rather than telling someone/thing else to
I do not manage LLMs, I manage people.
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.
I'm happy for you that you enjoy being a manager. I'm just saying that a lot of people seem to have found they prefer managing another system writing the code for them asking it nicely to do things, rather than writing code myself. I'm in the camp of enjoying typing code, and I do not want to become a manager, either of LLMs or people
People bragging that they "dont touch code" and only "argue" with agents are reinventing the slowest possible IDE.
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?
See, I'd say something like:
In the latest commit, refreshTokenExpiry should be snake case. Fix and make a note to do that in $LANG.
Or otherwise scope the rule. The point is you don't need to be super verbose about it and you get to fix forward too, preventing the same issue reoccurring. You build knowledge and context that let you move faster.
Codex and CC are actually getting better at reviewing code and flagging issues. False positive rate dropped fairly significantly. Also obviously might be very personal preferency but creating clear specs and iterating on specs really helps to crystalize the approach I want to take to solving a given problem.
But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code?
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?
I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?
The difference is that LLMs are not compilers. You can't trust the output to be correct. They routinely make bad design choices. If you're prototyping some kind of throwaway MVP, you're just sketching something, it's probably fine not to review it. If you're trying to build a piece of software that's going to survive for years, why are you doing this? The tech is clearly not yet fully mature.
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.
The comparison with compilers is absurd on its face, yet some keep pushing it as if repeating it enough times will make it true.
It did atrophy, but more importantly understanding what's going on below the code you are writing, even if your project isn't assembly, also atrophied. When you're coding an Electron app with Javascript you're so far removed from any concept of the efficiency a modern CPU can achieve you stop caring about optimization. Speed and memory management don't matter and then you get... well, the modern web.
And the modern web being usable is basically thanks to the people who understand lower level optimization.
There's clearly a range of outcomes, from the people pushing the envelope in system performance (look at the state of networking ASICs and the code to drive them) to people adopting hyper-complex frameworks for cloud orchestration and job coordination that turn a few screens of code into system so slow and complex it needs a team to maintain it. It's all happening at once, and it's probably ok. Keep in mind, knowing how to write assembly and knowing how to get good performance out of a CPU are two different things, modern chips are insanely complicated and the mental model is a long way from the days of the 386 or 68030 (let alone pre-MMU computing).
The compiler has been written by a lot of very smart people, it is very well tested and sometimes has even been formally proven to output exactly what the language specifies, and I have a mental model of what the code it outputs does in relation to what I write.
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).
They absolutely did: https://vivekhaldar.com/articles/when-compilers-were-the--ai...
The move to HLLs created new classes of problems that assembly programmers didn't face; so while the # of problems that necessitated understanding hw didn't shrink, it did relative to the list of things that could now go wrong.
And they did atrophy! I only know assembly because I deliberately studied it and practiced it for reverse engineering. But in my view, no longer being able to understand high level code is a much, much bigger problem than not understanding assembly.
Especially because Markdown --> code is _non-deterministic_
Yeah. Actually, that's a cool thing to think about. Will it be possible in the future for an LLM to be deterministic enough to the point of becoming essentially a text to code compiler? Like, an entire class of LLMs that are meant to be deterministic to the point that even upgrades to the model wouldn't completely change the outputs (it could have some breaking changes).
reality is more nuanced. some people still need to inspect machine code by hand. people who primarily write SaaS django boilerplate don’t. the arguments were made back then, im sure.
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.
This analogy is always weird to me, the change your talking about was still deterministic. Switching from programming to describing programming and having a machine make a best guess is not a deterministic shift as previously happened.
Already happening. For many people, coding isn't the only thing they've abandoned. They've also traded science and engineering for LLM punditry. Rather than "focusing on solving problems," as they often claim, they spend their time chasing unscientific debates about which model or magic prompt "performs better." By unscientific, I mean there's nothing measurable, no reproducible methodology, and no way to validate their hypotheses. Or rather, their wild speculations that change every week.
I think I read so much code over the last 15 years, that its not a thing i will lose.
But at least for me, I really read a lot of code, a lot of PRs from others and evaluated them.
Accountability is the key. You are accountable for the work product. You need to do what is necessary to make sure that the product meets standards. How you do it is of secondary importance. If reading code is what is needed to guarantee quality and you stop, that is on you.
There is a saying that many countries have offshored building hardware, aka manufacturing. Now they are offshoring software building to AI. Perhaps the silicon valley will grow a rust belt.
Trust creep is the part I worry about too. Today I read every diff.
I don't think it's necessarily a question of laziness. It's more about velocity.
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.
Feels AI-written as well and a recycling of 1000 versions of this point.
Yes, it reads like every goddamn LinkedIn post these days.
I wish the tech field wasn't so full of clueless grifters. The most frustrating thing is that this kind of people, the kind who loudly and confidently assert bullshit claim based on insufficient knowledge, have a knack for positioning themselves in positions of power.
It's not just the tech field. It's everywhere these days.
It’s aggressively AI written. I’d rather just read the prompt.
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.
Following the calculator analogy made by another person here and not disrespectful but joking intentended but this sounds kinda:
"I'm done. I'm not going to do a calculation, remember a single formula or theorem anymore. Now I'm just choose the problem that I want to solve and the math branch that I wanna use. I think all these educations stages (decades) was the toll we had to pay and I'm not going to pay anymore. "
Also who can say that is able to consider all weights that each decision involves and be able to surpass AI's broad view!?. I mean ... mythos finding a full chain of processes to make an exploit from a single bug? We can beat that ?! For how long ?
I don't know where it is going to end up but as a newcomer to the field I 'll try to keep learning programming and build a solid base. Focusing less on knowing all little syntax of each language or library and outsourcing all boring and repetitive tasks to AI.
I don't take sides here: I welcome such a wonderful tool but everything has its tradeoffs.
I'm a Software Engineer and I think the author is probably right that many Software Engineers are misguidedly placing too much weight on their ability to read and write code.
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)
I’m forcing myself to write code.
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
The people who I work with who have gone full LLM prompt engineer are the people who produced low quality, sloppy work. Generally they never liked to be challenged and never appeared to put much effort in.
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.
can an architect review a system he didn't design or build?
If you never coded that architecture yourself, you are not able to tell if it fits the problem, pros and cons, if the implementation is in accordance.
Imagine reviewing CQRS without having built one
You are choosing to be enraged. If a tool works it works.
> After many years into coding I found out that writing the code was the toll I paid to get those decisions into reality.
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.
This text is regurgitated on a daily basis. I skimmed through the text and could tell not only that but also that the author has given up on writing altogether.
> I think harder about the real problems
Are you /really/? If an LLM gives you an immediate, coherent answer, there's a risk you accept the framing too quickly instead of doing the harder work of questioning premises, testing alternatives and noticing what might be missing.
> If an LLM gives you an immediate, coherent answer, there's a risk you accept the framing too quickly instead of doing the harder work of questioning premises, testing alternatives and noticing what might be missing.
Arguably having a conversation with something so confident but random makes me more inclined to "verify before trust" instead of the usual "trust but verify." Im already very question premisy but interacting with ai 10x's that instinct. My skepticism level is higher because of temperature and seeing when I ask something multiple times I get dice roll answers.
Opposite, I trust less and less the more I use these things. Must write certain things myself, especially types. Sometimes I'll even touch a new file myself (I know, creating files yourself?!) and write some pseudocode in a new file alongside some voice vomit
Also, /only/ verifying is exhausting...
With all the people saying that you're going to have problems because the LLM is not good at refactoring or large code bases or OOP, etc. the point may be that if you're working to develop skills, an LLM herder might be a good one. Even if the models are almost, but not quite, good enough yet - they will be.
When looking for a career move you might want to focus on the trajectory more than the current state.
Everybody knows you don't go full AI engineer.
You know any AI war heroes? You went full AI engineer, man. Never go full AI engineer. You don't buy that? Ask Roy Lee, 2025, "Cheat On Everything." Remember? Went full AI engineer, went home empty-handed.
Same here. It’s working well, though only using it for personal projects.
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
The problem I have is that I find generic code reviews really, really boring. With agents I write less code but read more code that I didn't write myself, which makes the job more boring than it was.
I would rather let AI do the code reviews and focus on test coverage.
Very well written article.
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.
This would be fine if LLMs had a dedicated language or a well-tuned abstraction that suited their abilities well. Right now we are trying to fit our square languages into the LLM's round hole.
Where does my trapezoid-shaped highly compressed and ambiguous natural language go? Well, of course, it goes in the square hole!
I’ve been on and off and on the bandwagon on this.
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.
How many people actually have this discipline?
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.
I just can't get behind this perspective, perhaps because I am a 'bad prompter', simply due to the lack of capability from current models. I end up rejecting them, asking them to implement again, they spew out tons of crap code instead of a 10 line fix, and on, and on.
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.
There seems to be a split. There are a substantial group of people like yourself who don't get what they want from LLMs. There are folks like me who get excellent idiomatic code almost every time. Both experiences are real and should be respected. I'm hoping that future investigations will find out why that is the case.
Sounds like they're not touching writing either.
The author appears to have gone full AI blog writer as well.
After a time the codebase feel foreign…
Most of the AI submissions are from people who are here to self-promote their own content and have little to no other participation. It's like this stuff appeals to a different audience than made up this site 5 years ago. Everything and everyone feels so nonsubstantive now.
These blogs are AI-written. Claude/ChatGPT love a follow-up. I guarantee they’re suggesting something along the lines of “Great catch on that typo. This is looking good. Ready for plenty of upvotes on Hacker News and Reddit!”
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.
Is anyone doing this who is not making CRUD web-apps or other very common types of programs for which there is masses of training data to copy from the net?
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 write low level highly performance sensitive code and I get excellent results using LLMs. It isn't a narrow area of applicability.
"low level highly performance sensitive" doesnt mean uncommon. What you're doing may be common with loads of examples to copy. (I dont know cus u didnt say what you're actually doing)
It is a minefield for structural bio/chem.
Feels like what one of those morbidly obese people riding electric scooters would write about not missing walking one bit. God forbid they end up in an area where accessible alternatives to stairs are not a thing.
I haven’t touched LLM coding beyond using TabNine originally and that has since been disabled. My LSP is good enough and I haven’t fallen behind on delivering code before deadlines. Not sure what the constant hype is about.
And look I wrote all that in 1 paragraph without bullet points detailing anything over and over.
People using google translate to speak a language. Except the language contains more complexity, meaning, and compression that the writer can't describe without using more words/tokens than it would be to actually write with the same precision. They could instead use better tools to achieve equal results with higher confidence.
"The fun part was never lifting weight. The fun was in being buffed with a 6-pack and picking up women. The fun is in bullying those who are weaker than me. I never liked going to the gym and lifting weights. What I actually love is the result of the lifting, but I never wanted to do the hard work".
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".
My professional career:
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.
We're basically doing the same thing where I'm at.
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.
Isn't that just being a manager?
[dead]
[dead]