Interestingly I’ve learned more about languages and systems and tools I use in the last few years working with agentic coding than I did in 35 years of artisanal programming. I am still vastly superior at making decisions about systems and techniques and approaches than the agentic tools, but they are like a really really well read intern who knows a great deal of detail about errata but have very little experience. They enthusiastically make mistakes but take feedback - at least up front - even if they often forget because they don’t totally understand and haven’t internalized it.
The claim you should know everything about everything you work on is an intensely naive one. If you’ve worked on a team of more than one there’s a lot of stuff you don’t totally grok. If you work in an old code base there’s almost every bit of it that’s unfamiliar. If you work in a massive monorepo built over decades, you’re lucky if you even understand the parts everyone considers you an expert in it.
I often get the impression folks making these claims are either very junior themselves or work basically alone or on some project for 20 years. No one who works in a team or larger org can claim they know everything in their code base. No one doing agentic programming can either. But I can at least ask the agent a question and it will be able to answer it. And after reading other people’s code for most of my adult life, I absolutely can read the LLMs. The fact a machine wrote crappy code vs a human bothers me not in the least, and at least the machine will take my feedback and act on it.
you have 35 years of experience and have already built up the learning capability and general framework to acquire new knowledge. you know how to use agentic coding as a tool to supplement your work. the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know
Juniors will figure out how to make things work just as well as we did. They may end up with a different set of skills, but competitive advantage is still a thing, and so competition will mean they end up with the best skills suited for the environment.
Exactly this. We need to be more precise than blanket statements like "agentic coding is a trap" and start figuring out what a "tasteful" application of agentic coding looks like. ChatGPT is destroying liberal arts curriculums because students can choose to not do anything of the thinking themselves and produce mediocre work that passes the bar. I think the same problem is showing itself with agentic coding, just with more directly measurable consequences (because the pile of software ends up failing in a more spectacular way than the pile of bad writing).
On liberal arts is simply a matter of what the students want to get out of the class, vs what the teacher wants the students to do: There's a huge disconnect in goals and expectations, so there's no way for the teacher to actually win. The fact that there's such disconnect should give the departments pause.
This doesn't happen at all for using agentic coding: What the programmer wants and what the boss wants are pretty well aligned. There are corner cases where someone isn't allowed to use LLMs, but does it anyway, but in most cases, the organization agrees.
> what the students want to get out of the class, vs what the teacher wants the students to do: There's a huge disconnect in goals and expectations, so there's no way for the teacher to actually win. The fact that there's such disconnect should give the departments pause.
Unless the teacher's role is to scaffold and support the students in acquiring what the students want, gain trust and lower the disconnect.
Honestly I'm not really thinking about the boss-programmer relationship, but rather the programmer-agent relationship. At best, you get what fnordpiglet is talking about, where it's a symbiotic relationship. On the other side of the coin, you get a parasitic relationship like the OP is talking about: the agent delivers results, you take credit, you fail to develop (or maintain) long-term skills, you become a non-value-adding middleman, you get replaced.
IMO, by the time todays juniors would have 5-10 years of expected experience, the entire field will be something different altogether. Language choice distribution will collapse (if not change altogether), whole new modalities of monitoring and progressive delivery guardrails will come into play, essentially creating a 24/7 incremental rollout of pure agentic code, correctness will be determined by a mix of language features and self-monitoring by models in production and automated testing against production snapshots in pre-production, and deep debugging will the be province of a select group of engineers and there will be a pathway to those roles for juniors, but those roles will be coveted and difficult to break into (and probably will require education and maybe even informal accreditation).
Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".
You also wrongly assume that requirements can always easily expressed as natural language.
Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.
> Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".
What I think will happen is AI will write code and it will do the best it can to mitigate mistakes prior to rollout, but once rollout time occurs, rollout will be incremental and it will self monitor by defining success conditions at rollout time. The nature of the code will mitigate "catastrophe" to a small group at worst, but most likely initial rollout will just run new versions of the code in a simulated context (language design could benefit from this) and analyze potential outcomes without affecting current functionality.
But when the code goes live... it will be slowly scope changes progressively (think feature/experiment flags) and if it fails in the initial cohort, it will redirect. If success is positive, it will increase the rollout cohort.
This is a normal software engineering practice today, but it's labor and process intensive when driven by humans. But in a world where humans are less involved, this process is scalable.
This assumes failures can be detected and fixed more easily than generating the corresponding change. I am not convinced that's the case.
Counter points to my own arguments:
1. We don't know yet in detail what AI is good at.
2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.
> 2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.
This I think is the unexplored aspect of what's happening right now. Guardrails around "good enough" systems is where the future value lies. In the future code will never be as good as when the artisans were writing it, but if you have an automated process to validate/verify mediocre code (and kick it back to AI for refinement when it fails) before it's fully productionized, then you have a pathway to scaling agentic coding.
> rollout will be incremental and it will self monitor by defining success conditions at rollout time.
This sounds a lot like allowing an LLM to define tests as well as implementation, and allowing the LLM to update the tests to make the code pass. Recently people have come to understand (again?) that testing and evaluation works better outside of the sandbox.
> Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.
I'd note here that the long arc of software engineering has been commodifying the discipline into tooling. Ask any unix greybeard how shitty modern abstractions are and they'll give you all you can stomach and yet the wheel turns despite their treasured insights.
Up until about four months ago, the sentiment by so many programmers online (here, reddit, etc) was that LLMs were absolutely useless at coding. And yet, many of us were puzzled, because we were having success with them, at coding.
People were burying their heads.
Today, there are not many of those people left. Some, but not a lot. Because you can only deny reality for so long.
I don't know what the coding world is going to look like in 5-10 years, but everything has changed radically in the space of a year from maybe 10% of people using agents to code to probably 95% of people now. In about a YEAR.
I don't know, but my assumption is these things will get better to a point where they will be automating close to 100% of coding, and deploying, and verifying, etc. The old job we had will be completely changed well before 10 years. I still think us "engineers" will have a role to play, but I genuinely don't know what it will look like.
someone probably made this same argument against certain frameworks over the years and juniors still figured it out. we need to stop trying to babysit learning for hypothetical situations.
the bar to "start" is lower and the bar to actually competency is higher now, juniors who want to actually learn instead of just pressing enter over and over again will do so regardless of whatever you do to "help" them.
It's not really a hypothetical. I work with one junior who's submitted an incorrect bugfix 3 times and counting; he seems genuinely incapable of processing the idea that there's a correctness issue he has to resolve, rather than a prompt engineering issue that will allow Claude to figure it out if only he asks in the right way.
that's not the tooling's fault i feel. i've used LLMs to help explore and debug issues, point me to the right documentation to investigate, etc. I WISH i had something like this 30 years ago.
Due to English-language limitation my most adult life, I struggled to code. Used visual coding etc. But of course, I can't make a living on drag-and-drop harness.
Comes in GPT-3.5, accelerated my learning. Now I'm running my incorporated company, just launched one software-hardware hybrid product. Second one is a micro-SaaS in closed beta.
The point is: when people use "juniors" as a fixed shaped blobs of matter, they focus on the juniors that were in any case going to make mistakes: AI or not. Misses the key point of agentic usage.
So now you can code? If I sat you in front of a computer with no internet and no GPU but your choice of IDE, you would actually be able to produce a product?
I didn’t speak English my early teenage years, and that haven’t stopped me from reading books about programming in my native language. I remember spending hours in bookshops, excited to pick up next book to devour and try out.
I don't believe in victimhood and so didn't want to go here, but since we are comparing notes:
English alphabets came into my education at the age of 10. I got my first computer at the age of 21. I began speaking broken English around the age of 23. Proper internet at the age of 25 or so.
Not to mention, my native language doesn't have programming books, even today.
Of course, an avid reader and Science nerd here. Curiosity and tinkering never stopped.
>> Comes in GPT-3.5, accelerated my learning. Now I'm running my incorporated company, just launched one software-hardware hybrid product. Second one is a micro-SaaS in closed beta.
> accelerated what learning? learning to code? learning to engineer? learning to manage? learning to market?
I'm pretty certain that you think you're talking to an owner of a business but you're actually talking to an AI-techbro whose "software-hardware hybrid product" and "incorporated company" has exactly zero revenue after it was prompted into existence in the hope that it will make some money before other people realise they could prompt the same thing for less.
No, look. You claimed things that I am skeptical about.
Vibing a product into existence without needing any development knowledge or experience just means you now have a "product" that can't really be sold for money.
If a junior builds something with agents that turns into a mess they can’t debug, that will teach them something. If they care about getting better, they will learn to understand why that happened and how to avoid it next time.
It’s not all that different than writing code directly and having it turn into a mess they can’t debug—something we all did when we were learning to program.
It is in many ways far easier to write robust, modular, and secure software with agents than by hand, because it’s now so easy to refactor and write extensive tests. There is nothing magical about coding by hand that makes it the only way to learn the principles of software design. You can learn through working with agents too.
> that will teach them something. If they care about getting better,
This pre-supposes the idea that the business is _willing_ to let that happen, which is increasingly unlikely. The current, widespread attitude amongst stakeholders is “who cares, get the model to fix it and move on”.
At least, when we wrote code by hand, needing to fix things by hand was a forcing function: one that now, from the business perspective, no longer exists.
This is what I have been thinking. Business will always try to do more with less because their only true goal is figuring out how to make more money. They will sacrifice giving those juniors time to learn from their mistakes for the sake of making more widgets (code). From the wider generational view, they will rob today's juniors from the chance to learn and thereby keep the talent pipeline full so they can profit today, the future (and the developers who will arrive there) be damned. The economic game is flawed because it only ever comes down to a single output that is optimized for: money. One solution? I think software people might consider forming unions. I know that's antithetical to the lone coder ethos, but if what this comment reflects is true, the industry needs a check and balance to prevent it from destroying its foundation from the inside.
Coding by hand is not mere typing symbols into editor that LLMs are now replacing, it’s thinking, abstracting, deciding how to apply your knowledge and experience, searching for information.
And of course in the current workplace where there’s often a push from managers to use LLMs as much as possible and to put as much work as possible on yourself, in this churn junior will not get to learn anything besides prompting and simple tooling.
> the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know
Y'all need to stop worrying about the kids.
They're smarter than us and will run circles around us.
They're going to look at us like dinosaurs and they're going to solve problems of scale and scope 10x or more than what we ever did.
Hate to "old man yells at cloud" this, but so many people are falling into the trap because of personal biases.
While the fear that "smartphones might make kids less computer literate" is true, that's because PCs are not as necessary as they once were. The kids that turn into engineers are fine and are every bit as capable.
For example preliterate people have absolutely insane memory. In comparison my memory sucks. Having to use notes, look things up etc sucks. Literacy is a tradeoff but at least it can be argued to be worth it.
Then there is smartphones. This is not the same. The tradeoffs compared to pre smartphones cannot be argued to be worth it imo and I was 20 years old when they were introduced. They make society and lives worse. It's not just about not being able to use PC but your attention and social skills sucking.
Then there is AI which is even worse than smartphones. The tradeoffs are so unthinkably bad I can't really even describe it.
> Also, no one gets smarter by outsourcing thinking.
Thinking is happening at a higher level. Humans are adepts at abstraction, and they are always capable of looking under the hood when needed.
We've never had so much societal capability as now. And that's only going to accelerate. Smart people will use these tools effectively. Don't be so bearish on human ingenuity.
Think of these tools as bullshit / busy work removers. You can focus on what matters and get more done than ever before. Deeper work, more connective work. It also opens fields of research up in an interdisciplinary fashion. People might explore outside of their limited domain now that they have help.
> The claim you should know everything about everything you work on is an intensely naive one
This is a slight tangent from that, but I place a lot of value on the ability to offload some/most of the mental model to AI. I need to know less about everything (involved in this one task) when working on it, because a lot of the peripheral information can be handled by the AI. I find that _incredibly_ useful.
This post does not make the claim that "you should know everything about everything you work on" - its making the claim that writing code and being able to read code effectively are intrinsically linked.
I wonder if it's not so much the coding that people don't want to write, but it's more about the weight of all the orchestration, data engineering and research that has to be done (or, understood in the first place) to get anything off the ground these days. It feels off the charts complicated, and of course is now shifting rapidly.
Agreed. I don't know anything about turning sand into transistors or assembly but do well. So I don't know my full stack either.
What is important is not being afraid to learn the rest of your system and keeping an index.
Most importantly it's about being able to spin up on anything quickly. That's how you have wide reach. Digging in when you have to, gliding high when you have to. Appropriate level for the problem at hand.
When I was in college eons ago they taught CS folks all of engineering. "When do I need to know chem-e or analog control systems?" We asked. "You won't. You just need to be able to spin up on it enough to code it and then forget it. We're providing you a strong base."
> The claim you should know everything about everything you work on is an intensely naive one.
I disagree with this take. Personally, I pride myself in learning the code bases I work on in detail, sometimes better than the leads for those code bases. I’m not saying that everyone should do so, but it’s achievable and not naive at all.
Knowing it better than the leads isn’t that hard - they spend most their life in meetings and teaching people how to think. Knowing the code base in detail is important - but I’m certain unless you wrote it all, there are parts you don’t know. I’m sure what you do is build enough scaffold understanding and depth in the core parts you can visit any part and understand it. But I’m also certain there are parts that based on pure recall you care unaware of the details. Someone else wrote it, you haven’t had to read it yet, and thus it’s a black box. Either that or your code base is quite small relative to the team size, or the team is very unproductive. The supposition one person is fully aware of any growing code base built by a team or organization - or a monorepo being built by 10,000 developers over 15 years - is prideful. A lot of it works because it works and you accept that unless you need to inspect a part because it’s not working. Whether a machine wrote it or an intern 10 years ago did, it’s a black box until it has to not be.
Even if you did write it all, unless you are regularly in all of it (which sounds like a horrible job to me), or it is rather small, in my experience you will be at some point trying to git blame some section of code you don’t understand only to find the finger pointed at your ghost.
> The claim you should know everything about everything you work on is an intensely naive one.
It is true that you normally do not need to know everything, or even most of it.
Despite this, it is necessary to be able to discover and understand quickly anything about the project or system on which you work.
I have seen plenty of software teams that became stuck at some point because they could not solve some trivial problem that required a zoom into the project where some extra skills were required for understanding what they saw, like understanding a lower-level language, or assembly language or some less usual algorithms or networking protocols and so on.
Or otherwise they were stuck not because they lacked the skills to interpret what they saw, but because they used something that was a black box, like a proprietary library or a proprietary operating system, and it was impossible to determine what it really did instead of what it was expected to do, without being able to dive into its internals.
So I believe that the environment should always enable you to know everything about everything you work on, even if this should be only very seldom necessary.
> But I can at least ask the agent a question and it will be able to answer it
A problem here is that, in some sense, the agent that wrote the code is not the same agent that is answering questions about it. if the original agent didn't leave their reasoning, you are probably out of luck.
There are tools like git-ai [0] that capture LLM sessions and associate each file edit to a specific agent action, and let agents query a given piece of code to read the conversation around it (what the user prompted, what was the reasoning of the LLM that created the code, etc). They could change the balance, but are not widely used
I have also seen the learning acceleration, there's a significantly increased set of techniques and technologies I have learned how to apply.
From a person perspective though, I'm apprehensive about the effect AI will have on the human "very well read intern." People who know a lot very deeply about specific areas are fascinating to talk to, but now almost everyone is able to at least emulate deep knowledge about an area through the use of AI. The productivity is there, but the human connection is missing.
I agree. I think this is personally very useful, but I think a great deal of what made computing an amazing industry to work in is going to or has already died. I suspect the general field as it existed will entirely cease to exist before the current set of well read interns have had much of a career chance. It is sad, but we have finally succeeded in programming ourselves out of jobs.
i agree with this. While refactoring the outdated code at my company, i realized that “you can’t know everything.” after the refactor, i can ask the LLM questions and get answers, but unfortunately, when integrating a new feature, it keeps treating it as a “new layer.”
I think it's important to at least have a mental model of code you directly commit to the codebase, and that doesn't happen if it was written by an agent.
"Hey! Just popping in to say that agentic coding is actually pretty great and is making me better in all the ways; but also want to say at same time that it's actually not all that different from anything else, so we can chalk up any critique to it to individual naivety and bias."
As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins". I really don't like these meetings where you're dragged in in the middle of them without any clue.
The questions came flying in fast, without any introduction, and this was about an external integration out of a dozen. They have their own lingo, different from ours, to make the situation worse.
I had a _very hard time_ making sense of the questions, as I indeed relied heavily on a model to produce these integrations (extremely boring job + external thick specs provided).
I'm still positive these would have simply not happened in a 10x the time if I did not use models, however, I'm now carefuly considering re-documenting the "ohhs" and "aahs" of these so that these kind of uncomfortable moments never happen again.
I haven't felt so clueless and embarassed in a meeting, ever. All I could say was "I'll get back to you on that one, and that one, and this one".
Cognitive debt is very real, and it hurts worse than technical debt on a personal level! Tech debt is shared across the team, cognitive debt is personal, and when you're the guy that built the thing, you should know better!
To be continued... But from now on, the work isn't done if I don't get a little 5 mins flash-card type markdown list of "what is this" and "what is that", type glossary.
> As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins".
This is a common thing doctors complain about. Patients come in, saying they just need a prescription for some drug or other. Good doctors often refuse to give any drugs or any advice until they understand the whole situation properly.
If you're a senior developer, you're the one who has to push back against behaviour you don't like. You have the authority. "Hm, interesting question. I'm going to need more context before I can give you my point of view. Can you give me a quick overview of the system architecture / explain what actual problems you're trying to solve with this approach?"
> This is a common thing doctors complain about. Patients come in, saying they just need a prescription for some drug or other.
Off topic, but this must be a USA-specific problem, where prescription drugs are actually marketed at Joe consumer. I think there is maybe one other country where this insane practice is allowed. Nowhere else are patients told to “Ask your doctor about Procrapin for your irritable bowl syndrome!!”
While I'm sure the US has its quirks, this is not a US-only "problem" (not a health expert so I'm not sure if it's even a problem to begin with).
I live in Norway and have heard from lots of people (coworkers, friends, acquaintances) that doctors are very reluctant to prescribing anything at all - the running joke is that they'll advise you to "get some fresh air and go for a walk" even if you just broke your leg in half
It's not exclusive to the USA. Happens every single day here in Brazil too. Prescriptions expire, but people still need their medications, so they come in for routine consults. Good opportunity to reevaluate the patient and make adjustments if necessary.
While prescription drug marketing to consumers is an issue in the US, I think the actual problem in this situation is people Googling their issue then coming to the doctor with the conclusion of their investigation instead of letting the doctor do the investigation themselves.
i think this is large part due to the horrific healthcare system we have here in the US. I have personally witnessed family struggle to get help from doctors because they don't interact with a patient's health outside of immediate action items like filling a prescription, writing a summary, charting, writing a referral, etc. They spend 0 time looking into what could actually be wrong with them outside of their immediate knowledge/guess. I would like to think this is due to the shortage of doctors we have here (self inflicted) and the high demands we place on them. It really just sucks to be told to take some med, wait 3 months, and then have to communicate for them between doctors while filling out the same form 3 times.
Sometimes patients will also have an expired prescription from a different doctor, and they want a top-up. Good doctors check. Just because some other doctor prescribed some drug 3 months ago doesn't mean its actually the right choice, or the right choice now.
Its not just a US thing. I have a few GP friends here in Australia. They complain about it too.
> If you're a senior developer, you're the one who has to push back against behaviour you don't like. You have the authority.
Not just that, but it seems like the grandparent had issues understanding what they were talking about. This is absolutely fine, and they should have just asked to continue explaining more until the problem was fully understood.
It’s obvious your opinion is important, but it’s not worth a lot if you don’t understand what the actual problem is.
Also, I personally don’t like to appeal to authority (not sure if that is what you meant), and instead just use the Socratic method to keep asking questions until they themselves understand the weaknesses. It’s a very friendly way of doing things.
> Can you give me a quick overview of the system architecture
I think what the OP is saying is that it's the OP's job to know that, and didn't, because they over leverage the LLM.
Like if a doctor was brought in on a cardio consult on their patient because they had a maybe unrelated heart condition, and the only thing they could answer to "why did you prescribe cemidine instead of decimine" is "lemme get back to you on that."
What kind of place do you work where you get dragged into a meeting halfway through and then are peppered with technical questions without context, that you're expected to answer on the spot? Please let us know because I'm sure a lot of us want to avoid such a place.
"I'll need to study the docs and code to answer these questions properly" is a perfectly fine (and very diplomatic) response to treatment like that.
Not OP, but similar context (~20yr exp.). You absolutely can get away with "I'll need to dig more into this to give you a good answer" but you are _for sure_ expected to have at least some answer ready-to-go. Especially if it's under your purview.
I don’t think it was made clear: the questions were about the code op “wrote” but they used a llm so couldn’t remember any of it. Probably got there from a git blame. This happens.
The implication is that, in the past, such a meeting would be fine, because they're an expert in what they've authored. It's "hey can you join for 5 minutes" because, in the past, they'd have had deep knowledge off the top of their head of the things they'd committed under their name.
But now they're not an expert in the code they've recently committed.
Maybe that's OK and expectations need to change, but I'd bet there are a lot of cases where the organization really wants to produce a (code, expert-in-the-code) pair, and should be willing to pay a little time to do that over producing just (code, guy-who-prompted-it).
> "I'll need to study the docs and code to answer these questions properly" is a perfectly fine (and very diplomatic) response to treatment like that.
By the time you said that, the AI could have given the 80% answer. So, no, this is no longer an adequate response. The right response would have been to take your tools and give an informed opinion on the AI answer, right there.
What are “your tools”? Many (most?) meaningful questions cannot be answered while you stall for time on a call. Or do you just mean ask an LLM the question and regurgitate its answer?
This can happen more or less anywhere if you spend enough time at a company. At some point you'll get pulled into a meeting like this because others think you're in expert in a codebase/area you're not.
I’d just say to this.. who cares, drop the ego. The tool was used and if you didn’t use it you’d be in worse trouble. I just say I dno I’ll ask the AI… easy :D
> To be continued... But from now on, the work isn't done if I don't get a little 5 mins flash-card type markdown list of "what is this" and "what is that", type glossary.
Easy, just have the agent write them for you at the end, then never read them...
I think that in an AI-native company, the people asking the question should be using their own set of the AI to query the codebase, before coming to ask you. The problem that you describe seems to be more relevant to an organization which has not fully embraced AI yet.
> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem.
An additional factor: to find issues in generated code, the developer has to care. Many developers (especially at big firms) are already profoundly checked out from their work and are just looking for a way to close their tickets and pass the buck with the minimum possible effort. Those developers - even the capable ones - aren't going to put in the effort to understand their generated code well enough to find issues that the agents missed. Especially during the current AI-driven speed mania.
Indeed. Generated code is also harder to read because it violates all semantic expectations that rely on the mental model of a human author. A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with.
Since LLMs have no internal evaluation, as a reviewer one has to account for it and evaluate line by line, rebuild from scratch any hidden rationale and tacit knowledge the LLM didn't have in the first place - only to be mislead into non concerns draining costly hours.
At this point, the investment is often deeper than writing from scratch.
I tried to capture some of my feelings on this on a recent personal blog post/rant. The easiest phrase is that LLMs are "legacy code as a service". They are trained on other people's legacy code. (No one is intentionally feeding LLMs their best proprietary code.) They produce output that is "Day 1 Legacy Code" in the sense that there's no human code owner to take responsibility and you might be able to ask the LLM that built it questions, but it is easier to accept is as the LLM that wrote it is no longer at the company (between context/memory limitations and regular model upgrades/retrainings, etc).
But also, yeah, it starts to get worse than classic legacy code because you could try to build a theory of mind about the legacy code author(s). There were skills in trying to "mind read" a past generation. To find clues in poetry words more than the poetry form. (The variable names and whatever comments may have survived including commit logs; things written for humans to help explain the whys/hows, not just the whats.)
I kind of think this article misses the mark a little.
There is skill loss from heavy AI use.
But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are building and making safe decisions with deep knowledge.
AI: Yes, its good and it can produce some good solutions, however it ultimately doesn't know what it's doing and at the best of cases needs strong orchestrators.
We're in a cesspit of business driven development and they're not getting the right harsh and repulational punishments for bad decisions.
I don’t disagree with any of that, but I think the brutal truth is that the priority of most businesses was always that approximate, slipshod, business-driven development. The human engineering process was only coincidentally a check back against the worst outcomes of that philosophy, not intentionally one.
I certainly think that is true of the current moment, but where I think this is going is towards a model where the cost of human labor collapses, feature delivery slows (relative to the churn that is happening now), but becomes more predictable and less error prone (in terms of final delivery). I think that is the model that we see in manufacturing, and I think it's probably going to replicate in software engineering. New code (that a human didn't even look at, tbh) will be stress tested for correctness, progressively introduced and final delivery will be easy to forecast and most of the time will be delivered on time.
Yeah but all these firms are going to get destroyed by firms led by people who are more disciplined and enforce rigour in thought etc that’ll be pushed through discouraging over-use of llm’s.
Apple didn’t go from near bankrupt to where it is today without that discipline.
I don't know if it really plays out like that, though I hope so. Many businesses are mega successful in spite of incredibly poor or inefficient technical execution. I don't know if it really matters so long as customers get the thing they want for the price they're willing to pay.
I think this matters even less in higher tech companies, because they're not playing in the margins where an inefficiency can hurt. Though perhaps ironically, I think AI providers really are in a realm where technical execution at the margins will make or break them.
We can hope. The markets are rarely rational to begin with and we live in a time where the biggest measuring stick for most companies is "what have you done in the last 3 months". There's not a lot of pressure on companies in today's marketplace to do the right thing over the "right now" thing or the fast broken thing or the dumb thing.
Skill loss is real. BUT, I have been complaining about skill loss to my bosses for literally a decade. So AI is just one problem for me. I was coding less and less every year for some reason.
I'm not sure skill loss is such a huge issue, in other words. It might just be a sign that the nature of our work if shifting. Being able to recite the C++ standard and using all the 100s of features correctly will just not be as highly regarded as knowing good architecture instead?
Another aspect is that it reorders some of our problems.
In typical development, we're more likely to go back and forth about "is this really what we want to make" or "what could possibly go wrong if we do that", and ideally we do it before PR's get approved or anything is merged/deployed. Some portion of that is getting moved to "we'll see if anyone complains later". As they say, an ounce of prevention is worth a pound of cure.
> We're in a cesspit of business driven development
It's not just businesses doing it either, I regularly see big PRs get merged on open source projects that seem fine on the surface but contain a 1000 paper cuts worth of bugs (not critical, but just enough to annoy you)
On top of that, the code wasn't idiomatic C++ (for this specific project) and the LLM completely ignored available APIs. Sure, it can be fixed, and maintainers should've caught it, but the amount of code being generated requires so much energy on everyone's behalf.
Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:
First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability.
Then, you take a day and write the code and make sure it passes tests.
Then, it's code review time, and this can involve a lot of back and forth with your team, resulting in multiple iterations and additional code reviews. Another "days or weeks" stretch. At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... even if done in parallel, let's add a conservative 2 weeks. Finally, you push to staging, and need to get some soak time internally among dogfooders, so you have some confidence that it's working. +1 week. Then you're ready to push from staging to prod, but since you work at a serious company, nothing goes to 100% prod right away--you need to slowly ramp up and check feedback/metrics in case you need to roll back. The ramp to fully launched could take another two weeks.
So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...
> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature.
This reminds me of one of my software engineering axioms:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
> So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...
Relevant: Programming as Theory Building (1985) by Peter Naur. The actual text is rather stuffy, but basically the code+docs cannot replace the richer in-human-heads ideas for what the real-world problem is and how computers should (or shouldn't) be used to face the problem.
>> a snapshot of your understanding of the problem
> Relevant: Programming as Theory Building (1985) by Peter Naur.
Great reference and I agree. From the abstract in the PDF I have of same:
Peter Naur’s classic 1985 essay “Programming as Theory
Building” argues that a program is not its source code. A
program is a shared mental construct (he uses the word
theory) that lives in the minds of the people who work on
it. If you lose the people, you lose the program. The code
is merely a written representation of the program, and it’s
lossy, so you can’t reconstruct a program from its code.
Programming is a fascinating combination of mathematical determinism and pure expression of consciousness. Both are entirely abstract, whose worth is only quantified indirectly.
Entire organizations are built upon these intangible work products. Careers are made, promotions given, "free valence problem solvers" allowed to soar, stock options issued to birth millionaires.
But Valhalla is only reached if a cadre of engineers can "see" the system, both for what it is now as well as what it must become.
1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
2. technically risky ideas that you never would have tried because it didn't make sense from risk+effort/reward standpoint are now within reach. it isn't "go faster" per se but the speed at which you can try something out still changes the nature of engineering process.
> 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
I think it’s because most PEs are in general conservative (the whole “mr no” meme) and also have limited experience writing software so they will be slow to adapt to this paradigm shift
Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.)
Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over
> and like i said current models are really really good at this
They're absolutely shit at this. You only say that because it's a thing you "don't want to be concerned with".
> in five minutes it will be better at debugging production issues
In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
> In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
> First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability.
All the process you described exists to maximise the amount of time your software engineers spend writing code[0]. You put this process in place because software engineers are among the most expensive employees in the business. Their time being wasted is meaningful to the bottom line.
Make the software engineers cheap enough and the need for a lot of this process evaporates. Companies that already _have_ these processes in place will be SOL because it's incredibly challenging to break a bureaucracy like that, but companies that either don't have these processes or manage to eliminate them will have a significant competitive advantage.
Which shouldn't be news. Startups have always competed with established businesses via speed of execution. What's new is the ability to maintain that speed for longer.
> At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA...
These are all in the firing line. If the company could outsource their legal liability to an external provider of these reviews, they would.
[0] We'll just ignore the irony that much of this process ends up being foisted on the employees whose time you're hoping to save.
It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.
Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike.
Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things".
Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure.
Repeat until spike is operational and you're happy with the abstractions used
Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders.
Integrate feedback into your spike, or even the original spec document and regenerate the whole thing.
So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work.
I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"
I have no idea what a “spike” is, but this seems like a good way to build software when there are no consequences to getting it wrong.
What happens if this “spike” violates someone’s patent or puts the company at legal/regulatory risk? What if it leaks users’ personal information? What if it introduces a vulnerability that my 13 year old can exploit? What if it crashes 2 million of your users’ devices because it didn’t anticipate some unusual configuration? What if the code totally conflicts with some other team’s future plans and you didn’t know because they never reviewed it?
This kind of yolo “just try it” development only works if you are very small and low-profile, don’t have hundreds of millions of users, or your software is inconsequential (nobody cares if it goes down or doesn’t work).
The point not to YOLO in vibe coded slop. It's that with agentic generation you can prove out concepts, features and technical approaches first because it's low cost. Once you have something working you can work on getting alignment.
And yes you should completely grok what you're finally committing, making sure it's fully tested. What it enables is lots of fast experimentation before settling on your final change.
I think it depends a lot on how automated the agent is and how long you let it run for. Full automation where you try to build an entire piece of software with agents... yeah, no, we are not there yet. At least not a few you care about maintainability.
Short-lived tightly-scoped agents can do alarmingly thorough and high-quality knowledge work, as long as the work itself is relatively mechanical and can either be carried out in independent chunks or sequentially. For example, a research agent like the Gemini "deep research" tool can save hours of digging around the web and compiling information. With careful prompting, sufficient background context, and good self-evaluation tools, an agentic loop can do very detailed data analysis, carry out serious statistics and machine learning projects, produce high-quality data visualization thereof, and put together a handy executive summary.
They occasionally hallucinate, go off track, get confused, and make mistakes. But they "know" everything that's been published in English for the last 200 years, they never get tired, and the code they write is good enough for throwaway scripting. The real power of agents being able to write code is that they can be extremely self-sufficient and flexible in carrying out these kinds of tree- and sequence-structured knowledge work tasks.
That's of course a different thing from "designing good software", which is neither tree-structured or sequential, and requires a level of intelligence (for lack of a better term) that LLMs do not seem to be capable of, at least not yet. But that's a more specific thing than just writing code in order to get stuff done that happens to require code.
>Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:
Ai writes the plans now. I just review and modify.
Respectfully, unless someone is really really bad at articulating what the quality standards are or works with a very niche stack that is definitely not the case anymore with SOTA models
Respectfully, the current models are all trained on everyone else's legacy code as of roughly six months ago and largely always will be. If I'm doing my job right an LLM cannot meet my personal quality bar on its own because I will always need innovation and excellence they will never see and thus cannot deliver. I also think that training these tools on my personal quality bar is more work than just writing it myself.
LLMs are plenty innovative and generate good quality code by default, and great quality code when directed well.
If you're not seeing this, at best you're probably unable to direct them or use them well.
FWIW, if you don't believe the above, I challenge you to put up a quick git repo, where you are unable to get the deserved quality out, and we can quickly show you how the same quality is available via SOTA agents, within a fraction of hand-coded time.
You're presuming too much about what OP's quality standards are. Can SOTA models outperform the average junior engineer? Yes, obviously. Can they match the best human engineers, if those humans were given all the time and interest in the world? Equally obviously not.
I use hundreds of millions of tokens a month, and LLMs have completely transformed the way I work. They're also, frankly, pretty mid programmers.
Yes, and? Something can be both scare and inadequate to a given task. FAANG L5s cost a pretty penny but I wouldn't trust a random one to prove a crypto library correct.
TL;DR — there’s a whole lot of craft in how you use agents
I think that’s mostly true, but also I think there is some skill to using agents well. Specifically, work with agents to get a really good product requirements document, then task it out into very narrow user stories / vertical slices (this takes some iterating—the AI really seems to want to think in horizontal layers today), then maybe walk through the code interfaces to be super sure you are aligned. At each step, I make the agent interrogate me thoroughly with every question it can think of, and even if we stop now we will have a system design and tickets that are much higher quality than me thinking alone. I could hand those off to anyone to implement, but I think having an agent TDD their way through the code is the sweet spot.
Whenever the agent is doing something I don’t like (e.g., some coding style thing), I pause and have another agent help me write a style guide that agents must read. This slows me down at first but I think it will pay off in time.
This is precisely why these types of articles don't make any sense to me, and strike me as case studies on human laziness. If you want good output, you'll review the output and iterate. If you want good foundations, you'll write them, and then later those foundations will prevent, to a very great degree, bad code from getting written by the LLM.
These articles frustrate me greatly. That said, the author's point about token cost is real, and a risk.
>Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write
Yeah, but in my experience, it takes the same amount of time or longer to cajole the AI to get it there. I'd rather write it myself and know how it works than insert an LLM as the middleman, especially when it isn't really proving to be any faster.
In my experience, it sure saves time. a lot of quality has significant mechanical components LLMs do great. Hey, this series of 300 functional tests are reusing the same few patterns without helper methods clarifying intent. Give me an overview of possible meaningful methods that would simplify the duplication. Ok, 2, 4 and 5 are good, but rename 2 to X, and change the order of parameters in 5. Implement across the tests, and make sure it all passes.
Still very significant savings over all that rather mechanical work. It's ultimately cheaper than doing a code review, and it's faster, because there's less need to manage the emotional state of the person whose code is being reviewed. Maybe I am a slow developer or something, but I am getting a lot of quality changes like that done that before I'd not have, solely because of time spent.
And not increasing the quality just causes problems anyway. Given the same quality, more changes mean more outages than before, just by probability. Increasing rate of change demands a similar increase in quality if you don't want your production support costs to go up. So spending at least a bit of time on quality, letting the LLM do the nagging little things that before you didn't do beause they they took too long and were not a core part of quarterly goals is basically mandatory.
IMO it still does save time generally but it’s not as much of a huge gain if you’re doing this.
I will admit there are occasional times after iterating so much I’m not sure if I’ve even saved time because going from “it works” to “it’s up to quality” takes so long
I've run a few experiments where I give it well-defined small side projects where I have a good idea of what I would do and how long it would take, and I time the process from start to finish.
So far, it's been pretty underwhelming--on par or slower, and it's definitely more frustrating lol.
Honestly, the only killer feature I found so far is overcoming ADHD activation energy lol. Getting annoyed with the idiot robot screwing up the Terraform migration is apparently a good way to get me to finish a Terraform migration.
It saves so much time! Think of the best find and replace and autocomplete and macro and every other possible super tool you use and roll everything into one. The design phase of any significant feature pales in comparison to all of the (now fully automated) tasks that you can just hand off to the agent to do nearly instantly and perfectly.
Actually ignore my comment I misunderstood the premise. I meant not vibe coding is the way to save time with production issues. Not the other way around!
If you are coding by hand like the old days you are probably not literally writing everything from scratch anyway, you are copy pasting a bunch of shit off google and stackoverflow or installing open source libraries.
I also reuse a lot of my own code. Either from libraries I built or just directly copy pasting (like boilerplate code for setting up the basics of something in my style).
I've been using AI tools to brainstorm approaches and sometimes generate code, but actually doing the typing myself. That way I'm less likely to forget the mechanics and programming language over time.
Same. Most of what I do is ask for an implementation plan, with minimal code, or no code, or pseudocode, and then write the actual code myself. This is for open source work, where the entire point of my enjoyment is that I write the code myself. I honestly wouldn't bother being an open source maintainer if the entire thing was just prompting an LLM to write code, and then reviewing it. That doesn't sound fulfilling at all.
If this was an actual paid job, I do wonder how that would change my LLM use. The reason I'm a software developer at all is because I love the craft. The act of building, of using my brain to transform ideas into code... that's what I enjoy. If it was just prompting an LLM, would I still do that job? I don't know. I'd probably start looking into the idea of switching careers, at least.
I have asked more than a few dozen people on this, and the answer after some probing is that no other knowledge based career exists that one can move to which is not exposed to AI. While many talk about moving to a labour oriented career, no one has actually done this in my immediate network and friend of friends network. It's day-dreaming in my opinion.
One approach you can use is to ask it to never write the code for you, which forces it to explain and then once you try the idea by coding yourself you get a better understanding of it. I use this approach with code I am required to maintain. It still bites me sometimes because the models still mixes a lot of incorrect information (usually just stuff that was correct in the past but is incorrect now). For throwaway and easy to verify scripts I ask it to generate, but I do ask to avoid over engineering and trying to catch all corner cases cause in scripts I prefer just letting things error as they are better understood as a step that failed. I also avoid languages I find hard to read (like powershell) and prefer to generate things that are short to fit in the monitor so I can read everything and understand (python, bash, batch are my goto scripting languages).
Same. I've also configured the system prompt to never give me a full solution or write a code for me. So whenever I ask it a question it produces a short 10 line example or even a pseudocode. This is far easier for me to reason about.
I still reject > 50% of AI suggestions, because they're too mediocre, like moving code for no reason or sometimes it is just plain wrong.
Remembering and understanding aren't the same thing. Merely reciting facts doesn't automatically give you the ability to apply those facts to solve problems.
Me too, ... more or less. I'm mostly still typing, sometimes copy-and-pasting with typed changes, and rarely copy-and-pasting verbatim. With the caveat that in some cases, like prototypes, proofs-of-concept, and porting code between languages; then maybe many lines are copy-and-pasted verbatim.
SotA models have cracked a handful of research-level math problems though.
The default Claude Code style harness is bad for complicated problems as well. Just taking the specific class or function you're working on, and putting it into a deep research style loop yields way better results. Limiting the initial context by hand is still the way to go in a lot of cases.
No, it's the same for math from what I've seen, aka it can do some of the easy things, usually with a lot of help. People usually mean the Erdos problems (aka "a list of things Paul Erdos thought were neat") and, well, here:
> While Erdős generated a huge number of problems, they are not all equally significant and important. I have, unfortunately, seen some mathematicians grow dismissive of Erdős problems recently, perhaps because they have seen reports of AI solving problems on this site that turned out to be quite simple, and wrongly generalised this to assume that all problems posed by Erdős are amusing novelties, of the level of olympiad problems.
The rest of the article isn't about AI at all, but I did think it was funny that it describes mathematicians as having more or the same opinion as SWEs.
Yeah this is the same conclusion I have. I primarily use AI for UI code, and guess what, it's all basically mechanical drudgery anyways. Put a div here, or put a Box here, apply some style rules, etc. This shit should have been automated decades ago yet for some reason we're still writing the same stuff with a different "twist" today.
Now if your career is built on writing out the same boilerplate code in its infinite slight variations every day, congrats, you've been automated. Thank god we can free up our intellects to focus on the actual hard problems, the ones that are somewhat cutting edge, the ones that actually push our field and humanity forward.
Literally every example of AI generated code (without significant human input) is just basic stuff that is wholly unimpressive. Oh wow, you had an AI generate a Next.js app? It's writing HTML for you? It made a generic SAAS? Guess I'll become a farmer now.
Or, wait, I'll continue to write my multithreaded real-time multiplayer network for a MMO, since the AI currently generates something that would get me fired 10 seconds ago if I tried to push it to production.
It's amazing how you introduce just the slightest difficulty or novelty to an AI and it just craps the bed. And then you go online and apparently we're gonna be replaced -6 months ago or something.
I had it throwing in free advice on my code working as intended, but not a normal pattern. It was something like:"Bonus! This bug exists!" And I had to tell it stop doing that. Or, for generated SQL renaming to keep deeply linked table columns human readable via comments it was - "You can't have a comment of this style here." It works perfectly so yes, yes I can.
I can certainly get it to do things that are reasonably common it seems like.
As for the article itself, I can agree with much of it.
I genuinely appreciated this comment—it made me chuckle. That said, I think there are better approaches to working with AI besides “here’s a big vague thing to work on, go write some code”. I think you have to iterate somewhat closely with the AI to write a doc describing exactly what you want the system to do and then scope out very narrow tickets and then have a separate agent do the TDD to actually produce the thing. The key insights here are (1) don’t let a code writing agent have too much scope—just a narrowly scoped ticket, (2) keep the coding agent’s context minimal, (3) don’t let the coding agent write much code without testing it. The agent should make very small changes at a time and then test that everything still works.
You will still need to QA stuff and review PRs, but I think AI done properly can genuinely make some tasks better.
> don’t let a code writing agent have too much scope—just a narrowly scoped ticket
it's interesting cuz my intuition is to give the language model writing the files as much context as possible, which means all of the previous planning thread. but I also thought you should plan with a small model and implement with a large one, and the meta seems to be plan with an expensive one and delegate code output to smaller ones. so what do I know.
> The agent should make very small changes at a time and then test that everything still works.
yeah I think if it's treated like a codegen machine it's basically just outputting code as if you're using a dsl, except the dsl is natural language and the output is meant to be edited, no `// this is generated code, do not edit` headers
> I think AI done properly can genuinely make some tasks better
thank god I dont need to write html by hand anymore, what a pita
I had AI fuck up writing a scraper[0]. A scraper. It hit a snag with cookies and spiraled into a tizzy. I liked the part where it assured me it could resume from the point of failure, while starting over for the 10th time because it had written no such code lol
[0] For those with AI scraping PTSD, it was a government site with public domain info and I know how to scrape politely
I mean that’s been my line every time someone makes impressed noises when I say I’m a programmer - it’s really not that hard, it’s really just a question of whether you like it enough to put the work in, like anything else. “Don’t you have to be a math wiz?” No dude 95% of the time whatever you’re trying to do already has a very well researched approach, a lot of times you’re just picking which pre-vetted solution to adapt to your needs.
Right. Like anywhere the conceptual problems haven't been all figured out yet, or where higher order effects happen with scale or particular shapes of data/substrate and you don't know them in advance.
Sometimes hard like interesting and you get to do really novel thinking. A load of p2p/decentralised things are hard like this.
Also sometimes hard like you get to a particular challenge and it turns out to be a notoriously unsolved mathematical thing, or you push against subtle boundaries of core libraries, runtimes, systems etc. Working with metagenome assemblies is this kind of hard.
Honestly the hard code I've done made such a difference to my brain. There's plenty of trivial stuff I'm happy to have automated, but of I can't work on the hard problems I may as well not be involved at all.
Would like to see a study of brain scans during flow, manual programming, compared to code review. If the conclusion is different parts of the brain are activated, then orchestration is a separate activity entirely. Reading code is not the same as writing code.
However, the code review study needs to compare between surface scanning and reviewing long enough to get over a theoretical slough of perspective: when you assume the coding chair and are in their frame, whether the brain shifts into a different cognitive mode.
Otherwise, just stamping "Looks good to me" is likely to lead to the same atrophy. There's no critical thought, even a self-summary of the change or active questioning.
Thoughtful, deliberate code review just plain takes longer. AI can help here a lot, although it still takes over the "get into review mode" process.
I absolutely feel like a "different" part of my mind is loaded when seriously engineering something myself vs vibecoding+reviewing. Even the reviewing is more annoying in the latter mental context.
Code review alone is kind of like being able to understand a foreign language enough to read it, but not really understand it in flowing conversation or being able to speak it, much less construct a complex piece of literature.
Retention also suffers, as you will quickly forget what you just reviewed. What is the last PR you remember?
> The developer is rarely the person pitching the feature, and is normally given the constraints and the PRD
This heavily depends on the industry and company culture.
I've pitched plenty of features and I've basically never had a spec land on my desk ready to go. Part of my job as a SWE is to help product folks decide what to build.
it's a fairly new way of doing things. I predict, in the future it will be more formalized and standardized like AGILE and SCRUM and all that boring stuff.
The result of that though would be establishment of development patterns that are good practices.
The rule of thumb is: An agent can write it, but a human has to understand it before it gets pushed to prod.
I'm still not convinced about the doom and gloom over developers being replaced. I'm not a dev as part of my main job function, but where I do use LLMs, it has been to do things I couldn't have done before because I just didn't have time, and had to de-prioritize. You can ship more and better features. I think LLMs being tools and all, there is too much focus on how the tool should be used without considering desired and actualized results.
If you just want an app shipped with little hassle and that's it, just let Claude do most of the work and get it over with. If you have other requirements, well that's where the best practices and standards would come in the future (I hope), but for now we're all just reading random blog posts and see how others are faring and experimenting.
while those things sucked, patterns imprinted on devs minds, passed on from generation of devs to the other until that's just the way things are done. CI is a good example, as are some of the documentation practices. Lots of teams that don't use agile or scrum formally, follow those concepts because that's just how they've seen others do things in the industry. I predict, LLM work will get some overdone and abstract thing like agile/scrum that lots of people hate, and few thing is useful, but then out of it the actually useful bits and pieces become self-organizing standards of sorts.
> The rule of thumb is: An agent can write it, but a human has to understand it before it gets pushed to prod.
The article essentially claims that no, that line of thinking is false. If the agent writes all of it (or too much of it, where "too much" is still not well defined), then your ability to understand it will atrophy with time, and you will either a) never push to prod, because you can't understand it well enough, or b) push to prod anyway, and cause bugs and outages.
I think the article is correct.
> I'm still not convinced about the doom and gloom over developers being replaced.
Agreed. The agents are just not good enough to write code unsupervised, or supervised by people without senior-level skills. And frankly it's hard to imagine them getting there. Each new release of the coding tools/models is a mixed bag. Some things are better, some things are worse, and the gains are diminishing with each iteration. I am afraid that we're going to hit a ceiling at some point, at least with the transformer architecture.
> but for now we're all just reading random blog posts and see how others are faring and experimenting.
Yes, exactly, and many people are not faring well. The article cites several examples of people feeling less capable after using LLMs to write code for a while.
What I said doesn't contradict the article. if what you said is true, then since a human can't understand it well enough, that approach is not good according to my rule of thumb, thus agreeing with article. I only established the litmus test.
That's exactly what I predict as well, I think it's inevitable. there will be middle managers and project managers needing a stick with which to beat the LLM mess into order, and keep themselves relevant, and it will suck all the same. But even such efforts result in establishment of good practices. In attempting to discredit the "slog" devs will establish "but instead, we should be doing $X".
i would hope so, as long as "good practices" really are good (for what thats worth anyway).
again, maybe overly cynical but ime "good practices" usually end up getting warped into "bad practices" caused by cargo-culting/up-selling by consultants as they try to mass-produce a new dev paradigm
The funny thing is that he mentions that Spec Driven Development is the future.
Technically we allready did this when we where doing Waterfall. I kind of miss it that we had good documentation. The last decade (maybe more?) I get jira tickets with a one liner. I often need to call people as they specify almost nothing.
I am still avoiding working with AI. I try to use some models locally for experiments. I refuse to pay for something that was build on ripping others off. And the local models are underwhelming thus so far.
Upvote. These remote models are going to get ever expensive. Their business future depends on the expected advancements in inference costs. One should never want to tie themselves to this prison.
the funny thing is once the llms got mostly good enough in november 2025 for me, it was mind boggling how much it helped me get stuff out of my head with ease.
its easier for me to code now, because its like i have a 24/7 insane intern that needs to be supervised via pair programming but also understands most topics enough to be useful/ dangerous.
ironically ive been spending much of my time iterating on ways to improve model reasoning and reliability and aside from the challenge of benchmark design, ive had some pretty good success!!
my fork of omp: https://github.com/cartazio/oh-punkin-pi has a bunch of my ideas layered on top. ultimately its just a bridge till i’ve finished the build of the proper 2nd gen harness with some other really cool stuff folded in. not sure if theres a bizop in a hosted version of what ive got planned, but the changes ive done in my forks have made enough difference that i can see the different in per model reasoning
I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term.
When you start coding as a way to scope out a problem, you're biasing yourself to think of everything in terms of abstractions which you invented for problems which you don't yet fully understand. My experience is that this distorts your own thinking; you are injecting your own biases into your learning process and locking down on decisions too early due to suck-cost bias.
Having a solution all coded-up and working after a couple of days creates the illusion that you've built something solid and maintainable and that any additional functionality needs to be added on top. Before you know it, the prototype has become the foundation.
It's like if I took you to some random country and told you to build a house and you started chopping wood and putting up the walls straight away. You might immediately have noticed that it's hot so you would put lots of windows... Good... But what you don't know yet is that this country gets hit by powerful cyclones once a year on average and your wooden house won't survive the first one. You started with the wrong material. It might work really well for the first few months until a point when it won't work at all and you'll have to rebuild the entire thing from scratch.
I think of it as driver's seat vs back seat vs passenger seat. You always take the back seat and eventually you will forget how to drive. You insist on always being in the front seat and you will miss out on the occasions where the LLM happens to know the area very well, like working with an unfamiliar library or problem domain. If it is a place that you are just passing through, it's a great to let it take the wheel and see where it will takes you. If it is a place that you need to become familiar with, it's great to have a dependable navigator beside you.
My sense is that a decade from now, the people who generally see their place as the driver seat but recognize when its not are going to be writing the code that matters.
I tend to think of it as like two pilots as on commercial airliners: you always have one pilot flying and one pilot monitoring.
You can debate with agentic coding who is monitoring and who is flying but, if we assume the user is monitoring what that means, in practice, for me is that I'm reading and making sure I understand all the changes the agent is proposing to make, as well as providing instruction, guidance, correction, etc. That includes reading and understanding all the code changes.
There’s too much in this article to comment on it all, but if we zoom into the first claim:
> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.
My question is why isn’t there an effort from the author to mitigate the insane things that LLMs do? For example, I set up a hexagonal design pattern for our backend. Claude Code printed out directionally ok but actually nonsensical code when I asked it to riff off the canonical example.
Then, I built linters specific to the conventions I want. For example, all hexagonal features share the same directory structure, and the port.py file has a Protocol class suffixed with “Port”.
That was better but there was a bunch of wheel spinning so then I built a scaffolder as part of the linter to print out templated code depending on what I want to do.
Then I was worried it was hallucinating the data, so I wrote a fixture generator that reads from our db and creates accurate fixtures for our adapters.
Since good code has never been “explained for itself 100%, without comments”, I employ BDD so the LLM can print out in a human readable way what the expected logical flow is. And for example, any disable of a custom rule I wrote requires and explanation of why as a comment.
Meanwhile, I’m collecting feedback from the agents along the way where they get tripped up, and what can improve in the architecture so we can promote more trust to the output. Like, I only have a fixture printer because it called out that real data (redacted yes) would be a better truth than any mocks I made.
Finally, code review is now less focused on the boilerplate and much more control flow in the use_case.
The stakes to have shitty code in these in-house tools is almost zero since new rules and rule version bumps are enforced w a ratchet pattern. Let the world fail on first pass.
Anyway, it seems to me like with investment you can slap rails on your code and stay sharp along the way. I have a strong vision for what works, am able to prove it deterministically with my homespun linters, and am being challenged by the LLMs daily with new ideas to bolt on.
So I don’t know, seems like the issue comes down to choosing to mistrust instead of slap on rails.
Edit: I wanted to ask if anyone is taking this approach or something similar, or have thought about things like writing linters for popular packages that would encourage a canonical implementation (I have seen some crazy crazy modeling with ORMs just from folks not reading the docs). HMU would love to chat youngii.jc@gmail
There's a subset of software engineers who understand most of the points from the article, but it looks more and more like this train can accelerate towards the cliff due to steam from burned money.
“The market can stay irrational longer than you can stay solvent” quote is usually applied to markets, but it can be applied to software engineering as well - all jobs can be gone even if world will be submerged into technological crisis, with single nine availability (and I'm talking about 9% :) ) and all accounts compromised.
I can’t say that I’ve felt my skills atrophy, but I’ve also never found backend web development to be that difficult. 90% of my job for my entire career could be described as digital plumber.
Interesting analogy. Through the lens of a data driven design, all we are doing is taking data in shape A, transforming it to shape B, and then sending it somewhere else.
An aspect i don't hear about enough is using agents to make better abstractions instead of treating the agent as the abstraction. We could work on making abstractions that allow expressing what we are building in most concise form without any boilerplate. The reviews are enjoyable, if llm providers fail we have a chance to use the great abstractions by hand. The alternative i see everywhere: We don’t care about the bad abstractions because agents write the code. We don't review because its too much and too noisy and we rather blow our brains out than manually dig through that react and spaghetti codebase and writing all the boilerplate and cross references by hand. We have to build for resilience and future us.
AI doesn't automatically make us better human beings, but they only expose our worst parts. Most people are not born great leaders and managers (need rigorous training and experience), and empowering them with AI kind of pushes them into a spot where they suddenly need to "lead". To fight brainrot from AI overuse, we must try harder to maintain that developer's priority list.
Lars we are on the same page. I use LLMs to help me scope and get a second set of eyes on the high levels of a task. Then I write the code. Often I automate boilerplate or boring objects but sometimes it's faster/better for me to just write them. Then I will ask an LLM to say write some tests. Then I will focus on the cases they missed and write those myself.
I have been described as a decel and a Luddite though so be weary of my opinions.
I don't use AI for everything, but I use AI to make repeatable, auditable workflows. For DevOps, I don't just ask AI to go on my production server and fix all issues. I ask it to write scripts, which I audit, then I dry run, then I test, and finally approve and run on production.
I was just looking through HN search for "show HN", and I saw many fitness and calorie tracking apps.
A lot of them disappeared just after a few months of launch; a few of them survived a year, then died out as their domain name expired.
People are making things, but they are not reaching their "audience".
I created https://macrocodex.app/, launched on 16 Mar 2026, and reached 10,000+ monthly active users.
Fitness/Calorie tracking is a competitive space where there are tons of apps and services.
I could never have built such an app because I do not know how to design pages; I can talk to a designer, but from past experience, it takes them a long time to understand what the market wants and projects. And companies with small budgets find it very difficult to find a good guy.
Many of my projects never got shipped because I dreaded making landing pages, icons, UI, etc.
I am not saying we did a very good job with AI on landing pages or UI at all; that's not an area of my expertise; the domain knowledge is, but the fact that many people find it useful, I think I’ve succeeded.
I've even put a ticket system in the app for support and received a few bug reports, which I resolved.
I wrote something that touches on a few of the same points not too long ago (namely vendor lock-in and inability to project cost with LLMs at the wheel). Tangential topics but I think there's a healthy enough amount of intersection to at least join in on the discussion.
I do agree that if we just rely on AI for all outputs and some reviews (at least to a threshold, because we simply can't keep up with the AI throughput as humans) we will eventually have skills atrophy. Here's where the tangents intersect: I've been working on a way to have the best of both worlds. We can still use AI to generate a large swathe of code, but use good old software engineering to do it. My project (https://salesforce-misc.github.io/switchplane/) inverts the control. Rather than having LLM-as-runtime and doing all the things, you define and write LangGraph control flows that only use the LLM when judgement is actually required. The basic principle is:
If it's deterministic, write it in code. If it requires judgement, use the LLM.
Switchplane itself is local-only but the principles can be applied to deployed agentic services as well. Because the approach is code-first, we can have that vendor independence: Use whatever model you want anywhere in the graph. One goes down? No problem. Swap the config without impacting the overarching control flow.
Cost becoming a factor? Limit LLM loops or constrain their access however you want. It's just code that needs to be updated. You control the runtime, not the LLM.
Concerned about non-deterministic behaviour when you need determinism? Don't be. It's in code.
Worried about skills atrophying because we're handing off everything to an LLM? That's mitigated somewhat here because you still need to think in systems in order to build execution graphs in the first place.
It might not demo as well as a number of markdown files being executed by an LLM. It's definitely a more reliable approach in the long run though.
Re vendor lock in point: this is a harness issue really. Sure, CC is restricted to Anthropic models, but it's not the only harness out there. So if one vendor has an outage or botches the quality of their models due to compute shortage, you can switch to another vendor. LLMs are the easiest to switch. Of course, if hardware costs go up, so will all AI vendors. The only way out for the employer would be to directly buy the hardware (or do a fixed price deal with a cloud provider).
Re the understanding code point: you can still use LLMs to understand code. If you write the spec without knowing anything about the code, of course the architecture might suck. Maybe there is already a subsystem that you can modify and extend instead of adding a completely new one for the new feature you are adding, etc.
I use LLMs for my daily workflows and they do understand code perfectly and much more quickly than if I read it.
CC isn’t even limited to Anthropic models, there’s a post on the front page right now to use it with Deepseek V4 since Deepseek provides an Anthropic compatible API and CC reads API URLs from env variables so you can override them.
I’ve build a configuration transpiler to Claude code and codex and found I can switch pretty quickly between both and run both at once. At the moment codex performs better. Prior CC did. There is no vendor lockin and this is an old canard in technology that LLMs in fact themselves make irrelevant. Once you’ve got an implementation that uses X converting it to Y is almost trivial with an LLM because the spec is canonical in the reference.
It’s buried in my dotfiles and not easily extracted. But the idea isn’t a hard one to implement, except the coding engineers are woefully unaware of themselves. Codex is easier because it’s open source. Claude you kind of have to futz with it for a while. Once you have the intermediate form working and outputting config for the two I’m sure you can coerce it to any other agent that comes along with similar constructs (marketplaces, etc). Theres some nuance for some MCPs particular those that download binaries like rust MCPs but its very complex I found and probably better to avoid unless you really need it.
>and then pulls the slot machine lever over and over
Does anyone really do this? You want verification and self-correction in a loop, not rerolling and cherrypicking. The non-determinism point is really tiresome to hear over and over.
I do this for debugging. Models are extremely vulnerable to framing effects and it's usually easier to spin up a fresh instance than it is to get an existing one to generate new hypotheses.
I've been having the same feeling too. At work, I try to do a hybrid prompt where I fill in things at method level with some placeholder pseudocode and let the prompt fill in the blanks. This helps with remembering and keeping a memory map. But its a lost cause keeping up with other's PRs that are often very verbose and high volume. For a lot of backend programming without a very complex domain, I think this works fine.
But I still want to be in touch with coding by hand and have ventured into systems programming, outside of work, which I feel AI is less useful for currently.
This is how I feel about things. Its like someone is demanding that I become a manager, when I was perfectly happy being a IC. And now I have to figure out how to be a manager of AI agents while at the same time not lose my ability to judge their work, or plan effectively, even though I'm not supposed to be doing things "by hand" anymore. But doing things "by hand" is how I reasoned through problems and figured out the plan to begin with.
The trap isn't agentic coding, it's using it as fancy autocomplete. When you delegate whole tasks with real acceptance criteria, not just single functions, the economics change completely.
Software engineers and their leadership have been pushing back on terrible product managers for decades. AI isn't the reason to stop our time honored tradition. If anything we can write the emails faster now
> Buried in a recent study[1] by Anthropic was a surprisingly honest moment when speaking about the risks of engaging with coding agents on a regular basis...
Nope. 1) Skills don't go away, you just get better at the things you do regularly, but your still have your old skills, 2) You only have vendor lock-in if you use lock-in devices (stop using Claude Code), 3) It's not an increase in complexity, it's a replacement, in order to gain efficiency (see: the cotton gin), 4) The increased cost is negligible considering average salary and resulting productivity
I sometimes wonder if I'm in a different universe to other devs. Anytime AI coding is brought up, comments are overwhelmingly negative and often point out correctness, quality, slop, etc.
There's also the 'more stuff is being delivered, but it's not right, full of holes and papercuts'.
I'm 22 years into development and couldn't think of going back to non AI programming now. Not only has it sped up velocity by an order of magnitude, it's also helped me unlock side projects that I would never even begin in the past as I knew I didn't have that time.
It's just like any tool though, and I've found enormous differences in outcome depending on how you drive it. Launching into 'build this' and expecting it to output code that you would manually write would not get you there; and I feel this is where most developers stall out.
Getting the right outcomes takes a lot of harness set up - the same as if you wanted to hire new devs and get them productive without peering with them. You would set up linting, good test coverage and approaches, thorough documentation about what your project is, the domain, the architecture etc. This at least gets good code consistency for the most part.
For how to build, https://github.com/bmad-code-org/BMAD-METHOD is really good and I've onboarded a few Saas projects into it now. Tech speccing and multiple cycles of elicitation are what deal with all the edge cases that you normally only encounter during coding. It does front-load all of the planning brainwork; but condensing that into a couple days of solid speccing is far more productive than spreading it out over months.
It's taken a while to get to this point, and most agents aren't good for substantial work out of the box. Most of the time what the agent does will be a product of its environment.
This is exactly the same problem of "mechanical engineers' job is to design parts, not machine them, so we'll take training on machines out of the mech eng curriculum." Result: fresh mech eng grads do not know how to properly design parts because they have no idea how they are machined.
I don't know if they've addressed it. But ~15 years ago, my father was mentoring some college students and noticed that while they had been taught to machine a block (i.e., the rudiments of machining), they had no idea how to design appropriate tolerances for e.g., a gear because they hadn't ever made anything that complicated. So it was an issue back then. Presumably these details are learned on the job through trial and error, or by oversight from a more senior engineer who understands the requirements better. But in the past it was understood you'd start learning them from actually building parts as part of the curriculum.
Doesn’t matter, if you ask for physically impossible features to cut this is something you could technically do. Or you ask for a feature that adds multiple setups to an otherwise simple part and makes it wildly expensive
The CNC doesn't know either. What usually happens is that an engineer at the CNC shop figures it out for you.
Knowing some machining still lets you design parts and assemblies that are some combination of cheaper, better, etc. This is noticeable with precision or high performance assemblies. And how many revisions are needed.
AI is just another tool and a new layer of abstraction. Do you really think the majority of people who write in high level languages truly understand what's going on under the hood? Do they really? Or is there at some point a divide between what needs to be done, how the application or logic should perform, and the actual translation of all that into machine code?
These blogposts (no doubt written with the help of AI) have been the topic of many a comment here and elsewhere across the internet for years now. The atrophying of skills is a serious concern and has been voiced again and again since 2022 by everyone skeptical of AI and I just think some people and some places just don't care.
At some point, if you're just pulling the lever on the slop machine with zero insights into your code, may be your boss is justified in asking why you should earn more than 50k a year.
Only way to cope with this I found is to grind leetcode or advent of code. It's kinda funny how fast this all changed. Less funny part is the fact that I'm now kinda feared for my job in some time.
How can we solve this at a more fundamental level?
I think many people already recognize the problem:
-“Our ability to write code is being damaged.”
-“If our ability to write code declines, our ability to recognize good code also declines.”
But the problem is that the market no longer works without LLMs.
Freelance rates and deadlines are now calibrated around LLM-assisted output. Even clients who write “do not vibe code” often set deadlines that are impossible to meet unless you use something like vibe coding. The client’s expectations themselves are becoming abnormal.
That is the irony of the market.
I honestly do not know what to do.
Recent Hacker News discussions are mostly a negative echo chamber about AI use. In other places, it is often the opposite: only positive echo. But almost nobody discusses the actual solution.
The main topics I keep seeing are roughly these:
1. Is the large repository PR system failing a fundamental stress test? Or should AI-generated(GEN AI) code simply not be merged? If PR review is moving from handmade production to mass production, how should the PR system change? Or should it remain the same?
2. As vendor lock-in continues, can we move toward local LLMs to escape it? Are cost and harness design manageable? What level of local model is required to reach a similar coding speed?
3. If we are forced to use agentic coding, how do we avoid damaging our own ability to code?
There is a passage from Christopher Alexander that I keep thinking about:
“A whole academic field has grown up around the idea of ‘design methods’—and I have been hailed as one of the leading exponents of these so-called design methods. I am very sorry that this has happened, and want to state, publicly, that I reject the whole idea of design methods as a subject of study, since I think it is absurd to separate the study of designing from the practice of design. In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things.”
— Christopher Alexander, 1971
This quote feels relevant to programming now.
If we separate the study and supervision fo programming from the actual practice of making, something important may be lost.
In architecture, there is this idea that without practice, the architect loses meaning. But now the market is forcing the separation.
People with enough symbolic capital and high status have the freedom not to use AI. But people lower in the market are under pressure to use it.
So I think the discussion now needs to move beyond whether AI coding is good or bad.
The real question is How do we keep using AI because the market demands it, while still preserving the human practice that makes programming meaningful and keeps our judgment alive?
I think these are the important question.
How do you maintain market value without using AI?
Or, if you do use AI, how do you avoid being treated as low-quality?
If you do not use AI, how can you remain more competitive than people who do use it?
If you do use AI, what advanatge do you have over people who do not use it, and how should you position yourself?
I know that agentic coding can cause skill degradation. I can feel it happening to me already. But for someone like me, who does not have strong status, credentials, or symbolic capital, social and market pressure makes AI almost unavoidable.
What frustrates me is that I do not see practical answers anywhere.
"How can we solve this at a more fundamental level?"
Stop using AI for coding. Period...there is no other solution. You can't make it work, nobody else can either. Without determinism, the entire process is useless. We need to stop trying to act like we all know that this isn't true. We have given it a chance, it failed, time to move on to something else no matter how much the VCs and execs don't want to. Those that do move on have a chance, the others have no future in software.
The issue is that you will end up without a job if the trend continues. It's similar to many cases of technical innovation - you can still have a few workers who do handcrafted works, but most of them have to use the machines, that may produce work of inferior quality but at much higher speed.
The market realigns, and unless you handwrite the highest possible quality at a quick pace, you won't be competitive with the vibe-coders who can fix a hundred issues a month.
It was the same with gps-assisted driving, now most people can't orient themselves autonomously. Worse, there are no roadsigns with directions installed, meaning that you are stuck with using the GPS.
"unless you handwrite the highest possible quality at a quick pace"
That's exactly what I do. I know I am lucky to be gifted in this skillset. But that's not a good reason to excuse people destroying the market for everyone.
I mean, why wouldn't they? Software developers are very often automating things, in order to reduce the amount of workforce, or the skill needed for economic activities.
Would you refuse to work on a navigation app such as Waze, since it allows everyone to work with platforms as Uber and pushes traditional taxis out of the market?
I agree with what you are saying, but if I cannot get work, I may literally have nothing to eat tomorrow.
So while I agree with your point, it does not feel like a practical answer for my situation. For someone who is already well known and has enough reputation, refusing to use AI may be a matter of principle. But I am dealing with survival.
I do not think your answer is bad. But because this is a survival problem, it is difficult for me to risk everything on principle.
In other words, I know that your answer may be the morally correct one. If everyone boycotted this, perhaps it would not be adopted so aggressively.
But I cannot do that.
What I need is a way to use AI while degrading my own ability as little as possible, and while still preserving my skills.
I am not saying you are wrong. I am saying that your answer is too idealistic for someone in my position.
I'm not being idealistic. I'm being very practical. You have the survival problem exactly backwards. Continuing to use it, that's the real danger in a practical sense. That only leads one direction and that direction isn't in your best interest.
I use AI mainly to improve the parts which I know I am pretty bad and need help and restrict it as I gain competency. Which means choosing to say no to copy pasting most things I wish to exercise my brain for and reading, understanding, processing and writing it more diligently. Treating brain like any other muscle that requires a gym, we do have cars and segways that can help us travel long distances quickly but we still require as a specie to walk and run. People with disability and underprivileged backgrounds also need these tools so it is a good option to have generally. Secondly we are human, we have made very good tools, we need to stop obsessing with being more productive in output and learn to be better, more considerate and respectful to each other and other species to make this planet generally for better world. It is the only one we got. At the same time, be more mindful about where and how we utilise our time and attention, they are very limited and the most valuable resources we can possibly possess.
Frankly I don't buy atrophy argument at all. I (and I believe many other people) switched multiple frameworks and languages over the years. I.e., I was an expert in Chef more than 10 years ago, and nowadays I hardly remember anything about it. Calling this a cognitive decline is a significant stretch.
If you're afraid of cognitive decline - try to get to proper orchestration using multiple agents. That's a fun exercise.
He's speaking facts. I have had the same concern about excessive cognitive offloading. As others have noted in the comments, AI tools when used correctly, can actually make us smarter and help us learn faster. But that requires a very particular usage pattern that is different from what I see with all the vibe coding going on these days.
I created a project called Ninchi to force myself to read my code and understand it. Recently I began also sharing it to see if there may be a larger need/opportunity. It's a small effort. We need to make a variety of efforts I think to encourage responsible AI usage before we end up drowning in slop.
agentic coding destroying the current tech industry would be bad for a few billionaires & their serfs but it would be very good for humanity, don’t fear the reaper
Writing code is not the hard part of software development. This is coming from someone who has programmed for 30 years, writing an average of 100k+ lines a year.
The sooner programmers start thinking about modeling the domain, user mental models, architecture and data structures and less focus on the mechanics of writing code, the better.
Writing code is the EASY part. LLMs have basically solved the easiest part of software development. They however are bad at all the stuff I mentioned. LLMs don't have a point of view, you do as a software developer.
Try this thought experiment. If, in 6 months, the agents were better coders than you are, would this argument still hold?
This is a personal thought experiment so think it through for yourself. What would the consequence be if the agents really were better than you and you acknowledged that?
The major premise of "It's a trap!" is that it matters if you lose your coding skill. (I'll gloss over general critical thinking and stick with coding for now) However in the world where on any given task it would be done to a higher level of quality and faster if you gave it to the agent, then what are you doing trying to do it yourself? There's plenty of room for that kind of thinking in hobbies, but in the professional world?
Maybe you can add some value in code reviews, but you may also be better off never reading the code at all. Maybe the how of coding stops mattering and the what of products needs to be your top concern.
I can tell you that the agents that I use today are much better coders than I am in the language we're using. I don't write it at all. I couldn't fizzbuzz in it. But with a small team we are building useful internal tools and features at a breakneck pace. I certainly feel the same feelings of getting dumber and losing my coding chops, but I have to step back and say, could what we've built have been built in 5x the time without agents? And the answer is probably no.
The thing I'm mastering now is conjuring software with agents. What lets them rip, what slows them down, where they are today and where they will likely be tomorrow.
I can tell you that you should re-invest in small, modular systems, because agents can build modules and greenfield projects instantly. I can tell you that there is a point at which agents fall over completely even on mid-sized projects, but that that point is receding with each new generation of model, and that Codex 5.4 XHigh Fast set to 500K context window is a beast. (5.5 has yet to win me over)
I can tell you that pushing direct to main is viable, that PRs slow down fully agentic teams, and if your agents have sufficient permissions they can fix things fast enough to be let loose even knowing they may delete your service. I wouldn't do it with your main product yet (unless you're starting your startup today) and I wouldn't try it with a large legacy project. But maybe that rewrite you've always wanted to do is here and just a prompt away.
Now, the sane among you will note that agents are not better today, that they might not ever be, and either way you should never trust a computer to make a decision because it can't suffer the consequences of its actions. Or more down to earth, there are some things that are too important to yolo.
But I will argue that a huge swath of us work in domains where if you're willing to challenge some of the basic assumptions of software development (you should understand the code, it should be maintainable by humans, it should be built to last) then you'll be able to provide very useful software much more quickly than you would otherwise be able to do. Save the skill for your hobbies, and build things people want.
I have been finding a good rhythm for greenfield projects.
When I first learned to code, I would do complete rewrites of a project several times. Each time I learned a lot, and the final result would be very stable and very well designed.
At the time, those seemed like large projects, but they were relatively small.
So I have learned to slow down, and spend considerable time thinking or overthinking before coding. Since for large projects, rewrites are not so efficient.
Except that all those rewrites were upfront thinking and overthinking of the highest quality.
I have recently attacked a couple new greenfield projects in "orchestrator" mode. The fact that I know I am exploring and creating throw away code lets me try things out ambitiously. I can obsess about the original and critical code, as I did before. But now I can quickly surround it with the mundane code it needs to be usable - which can happen very very fast - especially when its a throw away experiment.
My conclusion from these successes, and others, is agentic coding isn't something that can be judged without factoring in all kinds of context, and the ability of the "orchestrator" to come up with orchestration patterns well suited to the work.
If agentic coding is a trap, it is a trap created with the cooperation of the orchestrator.
EDIT: An agent is what you make it. I insist mine keep all memories in an in-project folder. And that documentation is for "both of us", whereas their folder is for actively developing their own understanding and ideas. They are not be agreeable or contrarian, but collaborate and contribute by considering anything and everything all the time, at their highest level of operation. At the beginning of every session, they review everything and from their "fresh" perspective, update their own materials for anything that strikes them or they believe is important. And that they do the same thing at the end of every session before last submit. Project appropriate "harnesses" like this make a massive difference. Never operate an agent in plain helpful-servant mode, it is a serious waste of talent. Push them to operate at a high level, all the time, and develop their own material purely for their own project related self-enhancement, and they contribute far more than speed coding.
Another interesting thing that seems to be helpful. I have the agent write a kind of zen document about what it values. Its first task, before any project related review, is to consider its own words, and update them if they con't feel right, or they want to add something important. To remind themselves of who they are, before engaging with the project. This moment of intentional self-reflection before diving straight into project details seems to help them maintain a birds eye view, and a stronger self-aware/self-motivated commitment to quality (defined completely in their own terms!). Their own words do appear to ring true to them. They reliably respond to this session-start ritual as an intriguing surprise.
20+ years in. For me, agentic coding has been nothing short of a godsend -- not because it writes code for me, but because it lets me explore and prototype things that would have taken days of reading docs and ramping up. The creative surface area of what I can touch in a week has expanded dramatically.
Where I worry is beginners. The hard-won intuition for "this is a reasonable approach" vs. "this will bite you in six months" takes years to develop. With experience, you steer the agent. Without it, the agent steers you -- and it steers confidently in every direction, good and bad alike.
I think AI will evolve to the point where it produces working, bug free code. But that code won't necessarily be that readable, clean or modular. In the future the complexity or how "bad" the code is won't matter because the LLM will deal with the complexity and clean up the messes automatically. Your code wasn't modular enough to account for a certain new feature? Well the LLM will simply make it modular enough. Is the code too hacky to fix a bug? The LLM will make it less hacky if it was too hacky in the first place. OR the LLM can deal with the hackiness. That is the future. Your skills will atrophy in the same way humanities skills with the slide rule has atrophied.
Going against the grain here which statistically is more likely to be right given how HN was so wrong about self driving and AI being useless for coding. I think HNers given that their identity is tied around coding are of course going to defend that identity till the bitter end in the same way artists did.
Self driving is not around the corner. I sit in the back seat of an AI driven car on a daily basis. There is no living being sitting on the front seat and that car goes on the freeway. This is a regular and very common thing where I live:
> When working on something new or something challenging, me typing out code is the process by which I figure out what we should even be doing.
This is really validating to read. I recently was having a call with a friend where I was arguing against 100% AI usage, and I was saying, some problems the LLM just can't solve. He asked for an example, and I tried to explain a complex chart I was trying to make at a previous gig, and in the end said "well to be fair neither the AI or I could figure it out lol." He replied "how could you even code it if you didn't know exactly what you were trying to build? You're supposed to know exactly what you're building before you write a single line of code, that's what they teach you in school."
He was poking fun at the fact that I have a boot camp background and he has a uni degree - it's been ten years for both of us now so he's running out of ways to poke fun at that difference as we even out our differences, but this one poke brought back about the old imposter syndrome, since my entire career, I've thought via coding.
When I get a ticket, I tend to jump into the codebase to figure out the context I need to know about, the current patterns, what files I'll need to worry about; and while I'm there, I tend to start writing some things, and as I do that I pull in a shared function, and in doing so just check out of curiosity where else the function is used, and in doing so discover oh, actually, we have similar functionality elsewhere, lemme just abstract this work for this ticket and the previous functionality into a shared function, and use it in both places. And so on. Before I know it, I'm looking back at the ticket checking if I've covered everything, and sending in the PR.
I've never had complaints about my productivity, in fact I'm often lauded for it so I think it at least hasn't been a process that slows me down long term even if it's meassier. But I had been wondering if it makes me less than a "real" engineer. I'm happy to hear others may doing it this way too.
I think the best way to go about this is to start with a manually coded codebase outlining the basic structure of your app (even if ported from some other project) so that you basically define the code "palette" and THEN using AI to add features / edit stuff.
It won't do everything exactly the way you would've coded it but I find this model much better at setting and maintaining "guardrails" for your codebase so you don't find yourself wondering how it all fits together.
If you just scale it back a little bit so you’re having the agent write methods, services, tests, scaffolding, etc, and keep it concise, you can get a lot of productivity gain without giving up your control of the codebase. It feels like some developers are leaning too far into the “vibe coding” but I was getting a lot of accelerated development years ago when I was still just asking the chat window for code, there is def a sort of laziness trap.
Im seeing the word "agentic" a lot here. Is there a difference between "Agentic Coding" and "I put prompt into gpt or claude and pasted code into my file" ?
It reads your other code so it can match the style, it runs the compiler, if any, it runs the tests, and if anything fails through any of it, it handles the errors and works on it.
If you ask it to, say, update the major version of some library, it will read the source of the new version, check the deprecations, attempt the changes based on that, rerun tests... a completely different level of utility.
It's even more ridiculous with access to server logs and such, as you can point it to a chart, say there were some errors in X service at Y time, and it'll dutifully look at logs in that window, check traces if available, look at caller services, check the database if needed, and come up with a hypothesis on what happened based on all the available information. It might miss things, but that's why you are there too. No need to be a prompting wizard that gives it everything it needs to get you the right answer in one shot: It's like pair programming with someone that has encyclopedic knowledge in many topics, but hasn't worked at your company before. A completely different experience.
Agents will read all (or some, if you set this way) your code and apply the generated changes directly into as many files as needed. They can also get information from other services you have locally or run shell commands (like tests, or git) and use the result if you set them this way.
It's a lot different than interacting with the webpage prompts. Running a client locally that can interact with your IDE, execute your test and build processes, interact with version control, write the files it suggests as a PR, and has context memory changes how you code, for sure. If you've used an LLM with context memory (eg Chatgpt plus) where it can infer things you mention or derive intent from previous conversations from weeks ago, it's gets eerie.
I think ignoring all else, generating code is not a new layer of abstraction. It's the same abstraction, we just have codegen machines now. The same skills are important regardless if the person is typing in the code or if a machine is producing it.
> This is the sentiment being hyped up around the industry currently: traditional coding is all but dead, and Spec Driven Development (SDD) is the future. You generate a plan, and disconnect from writing any code
Agentic agile > agentic waterfall (at least for now)
Don't give the AI a spec, work with it every step of the way.
> pulls the slot machine lever over and over (link to "One More Prompt: The Dopamine Trap of Agentic Coding")
I'm sure the first cave-person to discover how to make fire was equally "addicted" to making fires. That doesn't really say anything about the underlying technology.
> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism
I don't know what this means, exactly. Anyone have any ideas?
> Atrophying skills for a wide swath of the population
This is very real and something we're going to have to contend with. Software can't really become less complex, and there's a minimum amount of knowledge you need, with or without AIs there to help you. We may need specialized training academies for developers where they spend a few years without AI to learn to program, and then are given a few years of AI programming.
> Vendor lock-in for individuals and entire teams
This isn't really a big program, you can always switch AI providers if there's frequent downtime.
> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem
Agreed...
> Yet, in an ironic twist of fate, it's the individual's critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively.
...well, yes and no. AI tooling can help you _reduce_ cognitive debt. Picture this: There is one senior developer (Person A) on the team who understands Service X. Your other developers could schedule time with Person A to get an understanding. Or, they could ask the AI to analyze the project and explain it to them. This scales much better, and if Person A is a poor communicator (let's face it, many senior engineers are), it might be the only working option.
Interestingly I’ve learned more about languages and systems and tools I use in the last few years working with agentic coding than I did in 35 years of artisanal programming. I am still vastly superior at making decisions about systems and techniques and approaches than the agentic tools, but they are like a really really well read intern who knows a great deal of detail about errata but have very little experience. They enthusiastically make mistakes but take feedback - at least up front - even if they often forget because they don’t totally understand and haven’t internalized it.
The claim you should know everything about everything you work on is an intensely naive one. If you’ve worked on a team of more than one there’s a lot of stuff you don’t totally grok. If you work in an old code base there’s almost every bit of it that’s unfamiliar. If you work in a massive monorepo built over decades, you’re lucky if you even understand the parts everyone considers you an expert in it.
I often get the impression folks making these claims are either very junior themselves or work basically alone or on some project for 20 years. No one who works in a team or larger org can claim they know everything in their code base. No one doing agentic programming can either. But I can at least ask the agent a question and it will be able to answer it. And after reading other people’s code for most of my adult life, I absolutely can read the LLMs. The fact a machine wrote crappy code vs a human bothers me not in the least, and at least the machine will take my feedback and act on it.
you have 35 years of experience and have already built up the learning capability and general framework to acquire new knowledge. you know how to use agentic coding as a tool to supplement your work. the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know
Juniors will figure out how to make things work just as well as we did. They may end up with a different set of skills, but competitive advantage is still a thing, and so competition will mean they end up with the best skills suited for the environment.
Exactly this. We need to be more precise than blanket statements like "agentic coding is a trap" and start figuring out what a "tasteful" application of agentic coding looks like. ChatGPT is destroying liberal arts curriculums because students can choose to not do anything of the thinking themselves and produce mediocre work that passes the bar. I think the same problem is showing itself with agentic coding, just with more directly measurable consequences (because the pile of software ends up failing in a more spectacular way than the pile of bad writing).
On liberal arts is simply a matter of what the students want to get out of the class, vs what the teacher wants the students to do: There's a huge disconnect in goals and expectations, so there's no way for the teacher to actually win. The fact that there's such disconnect should give the departments pause.
This doesn't happen at all for using agentic coding: What the programmer wants and what the boss wants are pretty well aligned. There are corner cases where someone isn't allowed to use LLMs, but does it anyway, but in most cases, the organization agrees.
> what the students want to get out of the class, vs what the teacher wants the students to do: There's a huge disconnect in goals and expectations, so there's no way for the teacher to actually win. The fact that there's such disconnect should give the departments pause.
Unless the teacher's role is to scaffold and support the students in acquiring what the students want, gain trust and lower the disconnect.
Honestly I'm not really thinking about the boss-programmer relationship, but rather the programmer-agent relationship. At best, you get what fnordpiglet is talking about, where it's a symbiotic relationship. On the other side of the coin, you get a parasitic relationship like the OP is talking about: the agent delivers results, you take credit, you fail to develop (or maintain) long-term skills, you become a non-value-adding middleman, you get replaced.
IMO, by the time todays juniors would have 5-10 years of expected experience, the entire field will be something different altogether. Language choice distribution will collapse (if not change altogether), whole new modalities of monitoring and progressive delivery guardrails will come into play, essentially creating a 24/7 incremental rollout of pure agentic code, correctness will be determined by a mix of language features and self-monitoring by models in production and automated testing against production snapshots in pre-production, and deep debugging will the be province of a select group of engineers and there will be a pathway to those roles for juniors, but those roles will be coveted and difficult to break into (and probably will require education and maybe even informal accreditation).
Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".
You also wrongly assume that requirements can always easily expressed as natural language.
Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.
> Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".
What I think will happen is AI will write code and it will do the best it can to mitigate mistakes prior to rollout, but once rollout time occurs, rollout will be incremental and it will self monitor by defining success conditions at rollout time. The nature of the code will mitigate "catastrophe" to a small group at worst, but most likely initial rollout will just run new versions of the code in a simulated context (language design could benefit from this) and analyze potential outcomes without affecting current functionality.
But when the code goes live... it will be slowly scope changes progressively (think feature/experiment flags) and if it fails in the initial cohort, it will redirect. If success is positive, it will increase the rollout cohort.
This is a normal software engineering practice today, but it's labor and process intensive when driven by humans. But in a world where humans are less involved, this process is scalable.
This assumes failures can be detected and fixed more easily than generating the corresponding change. I am not convinced that's the case.
Counter points to my own arguments:
1. We don't know yet in detail what AI is good at.
2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.
> 2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.
This I think is the unexplored aspect of what's happening right now. Guardrails around "good enough" systems is where the future value lies. In the future code will never be as good as when the artisans were writing it, but if you have an automated process to validate/verify mediocre code (and kick it back to AI for refinement when it fails) before it's fully productionized, then you have a pathway to scaling agentic coding.
> rollout will be incremental and it will self monitor by defining success conditions at rollout time.
This sounds a lot like allowing an LLM to define tests as well as implementation, and allowing the LLM to update the tests to make the code pass. Recently people have come to understand (again?) that testing and evaluation works better outside of the sandbox.
> Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.
I'd note here that the long arc of software engineering has been commodifying the discipline into tooling. Ask any unix greybeard how shitty modern abstractions are and they'll give you all you can stomach and yet the wheel turns despite their treasured insights.
Everything looks a nail for our hammer-shaped chat bot.
I think you’re overly hyped if your actually believe this is going to be a reality in 5-10 years.
Up until about four months ago, the sentiment by so many programmers online (here, reddit, etc) was that LLMs were absolutely useless at coding. And yet, many of us were puzzled, because we were having success with them, at coding.
People were burying their heads.
Today, there are not many of those people left. Some, but not a lot. Because you can only deny reality for so long.
I don't know what the coding world is going to look like in 5-10 years, but everything has changed radically in the space of a year from maybe 10% of people using agents to code to probably 95% of people now. In about a YEAR.
I don't know, but my assumption is these things will get better to a point where they will be automating close to 100% of coding, and deploying, and verifying, etc. The old job we had will be completely changed well before 10 years. I still think us "engineers" will have a role to play, but I genuinely don't know what it will look like.
someone probably made this same argument against certain frameworks over the years and juniors still figured it out. we need to stop trying to babysit learning for hypothetical situations.
the bar to "start" is lower and the bar to actually competency is higher now, juniors who want to actually learn instead of just pressing enter over and over again will do so regardless of whatever you do to "help" them.
It's not really a hypothetical. I work with one junior who's submitted an incorrect bugfix 3 times and counting; he seems genuinely incapable of processing the idea that there's a correctness issue he has to resolve, rather than a prompt engineering issue that will allow Claude to figure it out if only he asks in the right way.
To be fair this was a thing before AI as well…
that's not the tooling's fault i feel. i've used LLMs to help explore and debug issues, point me to the right documentation to investigate, etc. I WISH i had something like this 30 years ago.
Self-taught, "junior" here.
Due to English-language limitation my most adult life, I struggled to code. Used visual coding etc. But of course, I can't make a living on drag-and-drop harness.
Comes in GPT-3.5, accelerated my learning. Now I'm running my incorporated company, just launched one software-hardware hybrid product. Second one is a micro-SaaS in closed beta.
The point is: when people use "juniors" as a fixed shaped blobs of matter, they focus on the juniors that were in any case going to make mistakes: AI or not. Misses the key point of agentic usage.
> I struggled to code
> ...
> Comes in GPT-3.5, accelerated my learning.
So now you can code? If I sat you in front of a computer with no internet and no GPU but your choice of IDE, you would actually be able to produce a product?
Attention Please Everyone
You're looking at a specimen of one of the most rattled species nowadays. It is so fun finding them under these articles.
Their last attempts at finding inner-validation.
What a waste.
You claimed that you learned to program.
Was that claim not true?
Now you want to have a "discourse"? No thanks.
Honestly, I want you to live with your assumptions and beliefs. No more goodwill from my side to your username.
> Now you want to have a "discourse"? No thanks.
No discourse - you made a claim, but it appears now that your claim is untrue.
It's faster for you to answer the question than to dodge it: Have you actually learned what you claimed you did?
I didn’t speak English my early teenage years, and that haven’t stopped me from reading books about programming in my native language. I remember spending hours in bookshops, excited to pick up next book to devour and try out.
I don't believe in victimhood and so didn't want to go here, but since we are comparing notes:
English alphabets came into my education at the age of 10. I got my first computer at the age of 21. I began speaking broken English around the age of 23. Proper internet at the age of 25 or so.
Not to mention, my native language doesn't have programming books, even today.
Of course, an avid reader and Science nerd here. Curiosity and tinkering never stopped.
accelerated what learning? learning to code? learning to engineer? learning to manage? learning to market?
>> Comes in GPT-3.5, accelerated my learning. Now I'm running my incorporated company, just launched one software-hardware hybrid product. Second one is a micro-SaaS in closed beta.
> accelerated what learning? learning to code? learning to engineer? learning to manage? learning to market?
I'm pretty certain that you think you're talking to an owner of a business but you're actually talking to an AI-techbro whose "software-hardware hybrid product" and "incorporated company" has exactly zero revenue after it was prompted into existence in the hope that it will make some money before other people realise they could prompt the same thing for less.
Haha..so many assumptions. And all of them being objectively wrong.
Cope harder. Try harder to demoralize. It is not going to work.
I had heard HackerNews had some of this loser bunch of personalities. I didn't expect them to show themselves so soon.
But hey, I realized "AI bashing" articles are the best places to find these gate-keepers. Makes sense now.
No, look. You claimed things that I am skeptical about.
Vibing a product into existence without needing any development knowledge or experience just means you now have a "product" that can't really be sold for money.
Repeating what I said on the previous comment:
---
Now you want to have a "discourse"? No thanks.
Honestly, I want you to live with your assumptions and beliefs. No more goodwill from my side to your username.
It seems you are unusually embarrassed to admit being nothing more than a vibe-coder.
Why is this? Are you not proud that you can produce products without possessing any skill?
Learning the fundamentals of programming and their translation to code. I'm decent at engineering, managing and marketing solutions.
This is backwards. You were too lazy to learn English even though every hour spent programming also comes with an included English lesson?
Now AI lets you write code using libraries whose documentation you can't even read? How is this a win?
Pls get rid of your assumptions, then we can talk.
If a junior builds something with agents that turns into a mess they can’t debug, that will teach them something. If they care about getting better, they will learn to understand why that happened and how to avoid it next time.
It’s not all that different than writing code directly and having it turn into a mess they can’t debug—something we all did when we were learning to program.
It is in many ways far easier to write robust, modular, and secure software with agents than by hand, because it’s now so easy to refactor and write extensive tests. There is nothing magical about coding by hand that makes it the only way to learn the principles of software design. You can learn through working with agents too.
> that will teach them something. If they care about getting better,
This pre-supposes the idea that the business is _willing_ to let that happen, which is increasingly unlikely. The current, widespread attitude amongst stakeholders is “who cares, get the model to fix it and move on”.
At least, when we wrote code by hand, needing to fix things by hand was a forcing function: one that now, from the business perspective, no longer exists.
This is what I have been thinking. Business will always try to do more with less because their only true goal is figuring out how to make more money. They will sacrifice giving those juniors time to learn from their mistakes for the sake of making more widgets (code). From the wider generational view, they will rob today's juniors from the chance to learn and thereby keep the talent pipeline full so they can profit today, the future (and the developers who will arrive there) be damned. The economic game is flawed because it only ever comes down to a single output that is optimized for: money. One solution? I think software people might consider forming unions. I know that's antithetical to the lone coder ethos, but if what this comment reflects is true, the industry needs a check and balance to prevent it from destroying its foundation from the inside.
If it’s broken and the dev can’t debug it, the business won’t have much of a choice.
Coding by hand is not mere typing symbols into editor that LLMs are now replacing, it’s thinking, abstracting, deciding how to apply your knowledge and experience, searching for information.
And of course in the current workplace where there’s often a push from managers to use LLMs as much as possible and to put as much work as possible on yourself, in this churn junior will not get to learn anything besides prompting and simple tooling.
“Currently an engineer at OpenAI”
Don’t forget to mention that.
> the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know
Y'all need to stop worrying about the kids.
They're smarter than us and will run circles around us.
They're going to look at us like dinosaurs and they're going to solve problems of scale and scope 10x or more than what we ever did.
Hate to "old man yells at cloud" this, but so many people are falling into the trap because of personal biases.
While the fear that "smartphones might make kids less computer literate" is true, that's because PCs are not as necessary as they once were. The kids that turn into engineers are fine and are every bit as capable.
Not really.
For example preliterate people have absolutely insane memory. In comparison my memory sucks. Having to use notes, look things up etc sucks. Literacy is a tradeoff but at least it can be argued to be worth it.
Then there is smartphones. This is not the same. The tradeoffs compared to pre smartphones cannot be argued to be worth it imo and I was 20 years old when they were introduced. They make society and lives worse. It's not just about not being able to use PC but your attention and social skills sucking.
Then there is AI which is even worse than smartphones. The tradeoffs are so unthinkably bad I can't really even describe it.
Was not a IQ decline observed for the first time recently? Also, no one gets smarter by outsourcing thinking.
> Also, no one gets smarter by outsourcing thinking.
Thinking is happening at a higher level. Humans are adepts at abstraction, and they are always capable of looking under the hood when needed.
We've never had so much societal capability as now. And that's only going to accelerate. Smart people will use these tools effectively. Don't be so bearish on human ingenuity.
Think of these tools as bullshit / busy work removers. You can focus on what matters and get more done than ever before. Deeper work, more connective work. It also opens fields of research up in an interdisciplinary fashion. People might explore outside of their limited domain now that they have help.
> The claim you should know everything about everything you work on is an intensely naive one
This is a slight tangent from that, but I place a lot of value on the ability to offload some/most of the mental model to AI. I need to know less about everything (involved in this one task) when working on it, because a lot of the peripheral information can be handled by the AI. I find that _incredibly_ useful.
This post does not make the claim that "you should know everything about everything you work on" - its making the claim that writing code and being able to read code effectively are intrinsically linked.
I wonder if it's not so much the coding that people don't want to write, but it's more about the weight of all the orchestration, data engineering and research that has to be done (or, understood in the first place) to get anything off the ground these days. It feels off the charts complicated, and of course is now shifting rapidly.
Agreed. I don't know anything about turning sand into transistors or assembly but do well. So I don't know my full stack either.
What is important is not being afraid to learn the rest of your system and keeping an index.
Most importantly it's about being able to spin up on anything quickly. That's how you have wide reach. Digging in when you have to, gliding high when you have to. Appropriate level for the problem at hand.
When I was in college eons ago they taught CS folks all of engineering. "When do I need to know chem-e or analog control systems?" We asked. "You won't. You just need to be able to spin up on it enough to code it and then forget it. We're providing you a strong base."
That holds even within just large code bases.
> The claim you should know everything about everything you work on is an intensely naive one.
I disagree with this take. Personally, I pride myself in learning the code bases I work on in detail, sometimes better than the leads for those code bases. I’m not saying that everyone should do so, but it’s achievable and not naive at all.
Knowing it better than the leads isn’t that hard - they spend most their life in meetings and teaching people how to think. Knowing the code base in detail is important - but I’m certain unless you wrote it all, there are parts you don’t know. I’m sure what you do is build enough scaffold understanding and depth in the core parts you can visit any part and understand it. But I’m also certain there are parts that based on pure recall you care unaware of the details. Someone else wrote it, you haven’t had to read it yet, and thus it’s a black box. Either that or your code base is quite small relative to the team size, or the team is very unproductive. The supposition one person is fully aware of any growing code base built by a team or organization - or a monorepo being built by 10,000 developers over 15 years - is prideful. A lot of it works because it works and you accept that unless you need to inspect a part because it’s not working. Whether a machine wrote it or an intern 10 years ago did, it’s a black box until it has to not be.
The question is one of is it easier to untangle llm code or human?
The answer is similar to: whose code is easier to untangle: human-A or human-B?
"Depends".
Even if you did write it all, unless you are regularly in all of it (which sounds like a horrible job to me), or it is rather small, in my experience you will be at some point trying to git blame some section of code you don’t understand only to find the finger pointed at your ghost.
> The claim you should know everything about everything you work on is an intensely naive one
Nothing in the article made that claim.
> The claim you should know everything about everything you work on is an intensely naive one.
It is true that you normally do not need to know everything, or even most of it.
Despite this, it is necessary to be able to discover and understand quickly anything about the project or system on which you work.
I have seen plenty of software teams that became stuck at some point because they could not solve some trivial problem that required a zoom into the project where some extra skills were required for understanding what they saw, like understanding a lower-level language, or assembly language or some less usual algorithms or networking protocols and so on.
Or otherwise they were stuck not because they lacked the skills to interpret what they saw, but because they used something that was a black box, like a proprietary library or a proprietary operating system, and it was impossible to determine what it really did instead of what it was expected to do, without being able to dive into its internals.
So I believe that the environment should always enable you to know everything about everything you work on, even if this should be only very seldom necessary.
> even if they often forget
> But I can at least ask the agent a question and it will be able to answer it
A problem here is that, in some sense, the agent that wrote the code is not the same agent that is answering questions about it. if the original agent didn't leave their reasoning, you are probably out of luck.
There are tools like git-ai [0] that capture LLM sessions and associate each file edit to a specific agent action, and let agents query a given piece of code to read the conversation around it (what the user prompted, what was the reasoning of the LLM that created the code, etc). They could change the balance, but are not widely used
[0] https://usegitai.com/
I have also seen the learning acceleration, there's a significantly increased set of techniques and technologies I have learned how to apply.
From a person perspective though, I'm apprehensive about the effect AI will have on the human "very well read intern." People who know a lot very deeply about specific areas are fascinating to talk to, but now almost everyone is able to at least emulate deep knowledge about an area through the use of AI. The productivity is there, but the human connection is missing.
I agree. I think this is personally very useful, but I think a great deal of what made computing an amazing industry to work in is going to or has already died. I suspect the general field as it existed will entirely cease to exist before the current set of well read interns have had much of a career chance. It is sad, but we have finally succeeded in programming ourselves out of jobs.
did you try to apply anything you have "learned" without the help of LLMs?
i agree with this. While refactoring the outdated code at my company, i realized that “you can’t know everything.” after the refactor, i can ask the LLM questions and get answers, but unfortunately, when integrating a new feature, it keeps treating it as a “new layer.”
I think it's important to at least have a mental model of code you directly commit to the codebase, and that doesn't happen if it was written by an agent.
"Hey! Just popping in to say that agentic coding is actually pretty great and is making me better in all the ways; but also want to say at same time that it's actually not all that different from anything else, so we can chalk up any critique to it to individual naivety and bias."
As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins". I really don't like these meetings where you're dragged in in the middle of them without any clue.
The questions came flying in fast, without any introduction, and this was about an external integration out of a dozen. They have their own lingo, different from ours, to make the situation worse.
I had a _very hard time_ making sense of the questions, as I indeed relied heavily on a model to produce these integrations (extremely boring job + external thick specs provided).
I'm still positive these would have simply not happened in a 10x the time if I did not use models, however, I'm now carefuly considering re-documenting the "ohhs" and "aahs" of these so that these kind of uncomfortable moments never happen again.
I haven't felt so clueless and embarassed in a meeting, ever. All I could say was "I'll get back to you on that one, and that one, and this one".
Cognitive debt is very real, and it hurts worse than technical debt on a personal level! Tech debt is shared across the team, cognitive debt is personal, and when you're the guy that built the thing, you should know better!
To be continued... But from now on, the work isn't done if I don't get a little 5 mins flash-card type markdown list of "what is this" and "what is that", type glossary.
> As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins".
This is a common thing doctors complain about. Patients come in, saying they just need a prescription for some drug or other. Good doctors often refuse to give any drugs or any advice until they understand the whole situation properly.
If you're a senior developer, you're the one who has to push back against behaviour you don't like. You have the authority. "Hm, interesting question. I'm going to need more context before I can give you my point of view. Can you give me a quick overview of the system architecture / explain what actual problems you're trying to solve with this approach?"
> This is a common thing doctors complain about. Patients come in, saying they just need a prescription for some drug or other.
Off topic, but this must be a USA-specific problem, where prescription drugs are actually marketed at Joe consumer. I think there is maybe one other country where this insane practice is allowed. Nowhere else are patients told to “Ask your doctor about Procrapin for your irritable bowl syndrome!!”
While I'm sure the US has its quirks, this is not a US-only "problem" (not a health expert so I'm not sure if it's even a problem to begin with).
I live in Norway and have heard from lots of people (coworkers, friends, acquaintances) that doctors are very reluctant to prescribing anything at all - the running joke is that they'll advise you to "get some fresh air and go for a walk" even if you just broke your leg in half
It's not exclusive to the USA. Happens every single day here in Brazil too. Prescriptions expire, but people still need their medications, so they come in for routine consults. Good opportunity to reevaluate the patient and make adjustments if necessary.
While prescription drug marketing to consumers is an issue in the US, I think the actual problem in this situation is people Googling their issue then coming to the doctor with the conclusion of their investigation instead of letting the doctor do the investigation themselves.
i think this is large part due to the horrific healthcare system we have here in the US. I have personally witnessed family struggle to get help from doctors because they don't interact with a patient's health outside of immediate action items like filling a prescription, writing a summary, charting, writing a referral, etc. They spend 0 time looking into what could actually be wrong with them outside of their immediate knowledge/guess. I would like to think this is due to the shortage of doctors we have here (self inflicted) and the high demands we place on them. It really just sucks to be told to take some med, wait 3 months, and then have to communicate for them between doctors while filling out the same form 3 times.
Yeah. Especially in the era of doctor ChatGPT.
Sometimes patients will also have an expired prescription from a different doctor, and they want a top-up. Good doctors check. Just because some other doctor prescribed some drug 3 months ago doesn't mean its actually the right choice, or the right choice now.
Its not just a US thing. I have a few GP friends here in Australia. They complain about it too.
I don't know in other countries, but in Spain you definitely don't go to the doctor asking for anything more complex than a paracetamol.
You tell the doctor your symptoms, he explores you and perform any tests considered appropriate, and the doctor decides the prescription.
I also come from a country where the doctor decides the prescription.
But you might have prior experience and preference.
A friend of mine always asks "Hey, can you bring antibiotics back?" when I go on vacation somewhere where access is easier.
Doctors here will give you a hard time if you want it.
I think that's how it should be. But sometimes you know you need antibiotics.
> Procrapin
Perfect
> If you're a senior developer, you're the one who has to push back against behaviour you don't like. You have the authority.
Not just that, but it seems like the grandparent had issues understanding what they were talking about. This is absolutely fine, and they should have just asked to continue explaining more until the problem was fully understood.
It’s obvious your opinion is important, but it’s not worth a lot if you don’t understand what the actual problem is.
Also, I personally don’t like to appeal to authority (not sure if that is what you meant), and instead just use the Socratic method to keep asking questions until they themselves understand the weaknesses. It’s a very friendly way of doing things.
> Can you give me a quick overview of the system architecture
I think what the OP is saying is that it's the OP's job to know that, and didn't, because they over leverage the LLM.
Like if a doctor was brought in on a cardio consult on their patient because they had a maybe unrelated heart condition, and the only thing they could answer to "why did you prescribe cemidine instead of decimine" is "lemme get back to you on that."
What kind of place do you work where you get dragged into a meeting halfway through and then are peppered with technical questions without context, that you're expected to answer on the spot? Please let us know because I'm sure a lot of us want to avoid such a place.
"I'll need to study the docs and code to answer these questions properly" is a perfectly fine (and very diplomatic) response to treatment like that.
Not OP, but similar context (~20yr exp.). You absolutely can get away with "I'll need to dig more into this to give you a good answer" but you are _for sure_ expected to have at least some answer ready-to-go. Especially if it's under your purview.
I don’t think it was made clear: the questions were about the code op “wrote” but they used a llm so couldn’t remember any of it. Probably got there from a git blame. This happens.
The implication is that, in the past, such a meeting would be fine, because they're an expert in what they've authored. It's "hey can you join for 5 minutes" because, in the past, they'd have had deep knowledge off the top of their head of the things they'd committed under their name.
But now they're not an expert in the code they've recently committed.
Maybe that's OK and expectations need to change, but I'd bet there are a lot of cases where the organization really wants to produce a (code, expert-in-the-code) pair, and should be willing to pay a little time to do that over producing just (code, guy-who-prompted-it).
> "I'll need to study the docs and code to answer these questions properly" is a perfectly fine (and very diplomatic) response to treatment like that.
By the time you said that, the AI could have given the 80% answer. So, no, this is no longer an adequate response. The right response would have been to take your tools and give an informed opinion on the AI answer, right there.
What are “your tools”? Many (most?) meaningful questions cannot be answered while you stall for time on a call. Or do you just mean ask an LLM the question and regurgitate its answer?
Startup life man. Happy to help, just rough sometimes.
This can happen more or less anywhere if you spend enough time at a company. At some point you'll get pulled into a meeting like this because others think you're in expert in a codebase/area you're not.
From the way it's written, looks like it's his code that he wrote recently.
It's quite common to search for the author of a piece of code to ask questions about that code.
I’d just say to this.. who cares, drop the ego. The tool was used and if you didn’t use it you’d be in worse trouble. I just say I dno I’ll ask the AI… easy :D
Thanks, that's an interesting take from all that I've read.
If you're happy for me to do the job in 1/10th of the time, be happy with me not being fully across it on a whim.
Back to 2014 with this 7min "The Expert" skit https://www.youtube.com/watch?v=BKorP55Aqvg
Not the kind of meetings I enjoy where basically expertise isn't seen as something to build on but rather just (creative) confirmation bias.
> To be continued... But from now on, the work isn't done if I don't get a little 5 mins flash-card type markdown list of "what is this" and "what is that", type glossary.
Easy, just have the agent write them for you at the end, then never read them...
(/joking)
I think that in an AI-native company, the people asking the question should be using their own set of the AI to query the codebase, before coming to ask you. The problem that you describe seems to be more relevant to an organization which has not fully embraced AI yet.
> AI-native company
No such thing. The AI hype bubble is only a couple years old, and will not last a couple years more.
> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem.
An additional factor: to find issues in generated code, the developer has to care. Many developers (especially at big firms) are already profoundly checked out from their work and are just looking for a way to close their tickets and pass the buck with the minimum possible effort. Those developers - even the capable ones - aren't going to put in the effort to understand their generated code well enough to find issues that the agents missed. Especially during the current AI-driven speed mania.
Indeed. Generated code is also harder to read because it violates all semantic expectations that rely on the mental model of a human author. A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with.
Since LLMs have no internal evaluation, as a reviewer one has to account for it and evaluate line by line, rebuild from scratch any hidden rationale and tacit knowledge the LLM didn't have in the first place - only to be mislead into non concerns draining costly hours.
At this point, the investment is often deeper than writing from scratch.
I tried to capture some of my feelings on this on a recent personal blog post/rant. The easiest phrase is that LLMs are "legacy code as a service". They are trained on other people's legacy code. (No one is intentionally feeding LLMs their best proprietary code.) They produce output that is "Day 1 Legacy Code" in the sense that there's no human code owner to take responsibility and you might be able to ask the LLM that built it questions, but it is easier to accept is as the LLM that wrote it is no longer at the company (between context/memory limitations and regular model upgrades/retrainings, etc).
But also, yeah, it starts to get worse than classic legacy code because you could try to build a theory of mind about the legacy code author(s). There were skills in trying to "mind read" a past generation. To find clues in poetry words more than the poetry form. (The variable names and whatever comments may have survived including commit logs; things written for humans to help explain the whys/hows, not just the whats.)
There are exceptions to this, but in big firms many developers on many teams are actually punished for caring.
You know how some say the big brother sells junk food, then “solutions” to lose weight?
Maybe companies today are being sold junk AI, and next step is being promised “solutions”.. capitalism is working exactly as expected
And by the comments in this section, there’s a lot of them.
I kind of think this article misses the mark a little.
There is skill loss from heavy AI use.
But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are building and making safe decisions with deep knowledge.
AI: Yes, its good and it can produce some good solutions, however it ultimately doesn't know what it's doing and at the best of cases needs strong orchestrators.
We're in a cesspit of business driven development and they're not getting the right harsh and repulational punishments for bad decisions.
I don’t disagree with any of that, but I think the brutal truth is that the priority of most businesses was always that approximate, slipshod, business-driven development. The human engineering process was only coincidentally a check back against the worst outcomes of that philosophy, not intentionally one.
I certainly think that is true of the current moment, but where I think this is going is towards a model where the cost of human labor collapses, feature delivery slows (relative to the churn that is happening now), but becomes more predictable and less error prone (in terms of final delivery). I think that is the model that we see in manufacturing, and I think it's probably going to replicate in software engineering. New code (that a human didn't even look at, tbh) will be stress tested for correctness, progressively introduced and final delivery will be easy to forecast and most of the time will be delivered on time.
Yeah but all these firms are going to get destroyed by firms led by people who are more disciplined and enforce rigour in thought etc that’ll be pushed through discouraging over-use of llm’s.
Apple didn’t go from near bankrupt to where it is today without that discipline.
I don't know if it really plays out like that, though I hope so. Many businesses are mega successful in spite of incredibly poor or inefficient technical execution. I don't know if it really matters so long as customers get the thing they want for the price they're willing to pay.
I think this matters even less in higher tech companies, because they're not playing in the margins where an inefficiency can hurt. Though perhaps ironically, I think AI providers really are in a realm where technical execution at the margins will make or break them.
We can hope. The markets are rarely rational to begin with and we live in a time where the biggest measuring stick for most companies is "what have you done in the last 3 months". There's not a lot of pressure on companies in today's marketplace to do the right thing over the "right now" thing or the fast broken thing or the dumb thing.
> more disciplined and enforce rigour
Eventually this will be automated as well. Discipline, rigor and correctness are not strictly human tasks.
I agree as well. And now they can make slipshod products at 10x speed.
Skill loss is real. BUT, I have been complaining about skill loss to my bosses for literally a decade. So AI is just one problem for me. I was coding less and less every year for some reason.
I'm not sure skill loss is such a huge issue, in other words. It might just be a sign that the nature of our work if shifting. Being able to recite the C++ standard and using all the 100s of features correctly will just not be as highly regarded as knowing good architecture instead?
> too fast
Another aspect is that it reorders some of our problems.
In typical development, we're more likely to go back and forth about "is this really what we want to make" or "what could possibly go wrong if we do that", and ideally we do it before PR's get approved or anything is merged/deployed. Some portion of that is getting moved to "we'll see if anyone complains later". As they say, an ounce of prevention is worth a pound of cure.
> We're in a cesspit of business driven development
In a business-driven world with business-driven governments writing business-driven rules, what's the alternative if you want to optimize for success?
> We're in a cesspit of business driven development
It's not just businesses doing it either, I regularly see big PRs get merged on open source projects that seem fine on the surface but contain a 1000 paper cuts worth of bugs (not critical, but just enough to annoy you)
On top of that, the code wasn't idiomatic C++ (for this specific project) and the LLM completely ignored available APIs. Sure, it can be fixed, and maintainers should've caught it, but the amount of code being generated requires so much energy on everyone's behalf.
Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:
First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability.
Then, you take a day and write the code and make sure it passes tests.
Then, it's code review time, and this can involve a lot of back and forth with your team, resulting in multiple iterations and additional code reviews. Another "days or weeks" stretch. At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... even if done in parallel, let's add a conservative 2 weeks. Finally, you push to staging, and need to get some soak time internally among dogfooders, so you have some confidence that it's working. +1 week. Then you're ready to push from staging to prod, but since you work at a serious company, nothing goes to 100% prod right away--you need to slowly ramp up and check feedback/metrics in case you need to roll back. The ramp to fully launched could take another two weeks.
So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...
> Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature.
This reminds me of one of my software engineering axioms:
> So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...Well said.
> a snapshot of your understanding of the problem
Relevant: Programming as Theory Building (1985) by Peter Naur. The actual text is rather stuffy, but basically the code+docs cannot replace the richer in-human-heads ideas for what the real-world problem is and how computers should (or shouldn't) be used to face the problem.
>> a snapshot of your understanding of the problem
> Relevant: Programming as Theory Building (1985) by Peter Naur.
Great reference and I agree. From the abstract in the PDF I have of same:
Programming is a fascinating combination of mathematical determinism and pure expression of consciousness. Both are entirely abstract, whose worth is only quantified indirectly.Entire organizations are built upon these intangible work products. Careers are made, promotions given, "free valence problem solvers" allowed to soar, stock options issued to birth millionaires.
But Valhalla is only reached if a cadre of engineers can "see" the system, both for what it is now as well as what it must become.
EDIT: removed irrelevant "physical world" sentence fragment.
1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
2. technically risky ideas that you never would have tried because it didn't make sense from risk+effort/reward standpoint are now within reach. it isn't "go faster" per se but the speed at which you can try something out still changes the nature of engineering process.
> 1. models are now extremely good at totally automating tedious tasks such as updating dependancies, build/deploys scripts, unit tests, etc what used to take days now can takes minutes. Easily 50x speedup on this. This was non-trivial part of every engineer's day-to-day at an established company. "platform engineering" or whatever they call this now is dead.
I confess that I don't understand why this isn't true, because it seems to be true on the micro level, but it really hasn't been my experience. The platform engineers I'm familiar with are desperately trying to tread water to keep their systems healthy against the now-higher code velocity without falling to pieces. (Perhaps people used to make minor day-to-day improvements while coding that Claude enables us to ignore?)
I think it’s because most PEs are in general conservative (the whole “mr no” meme) and also have limited experience writing software so they will be slow to adapt to this paradigm shift
It's not my experience that our production engineers are quick to say no or slow to adopt LLM agents.
There’s someone in the sibling thread arguing claude is bad at using perf and tcpdump
Because "platform engineering" isn't about writing bash scripts, it's about having a mental model of the system architecture. (Which the LLM definitely doesn't have.)
Also, it's always the case where you think LLMs are great at doing whatever it is that you don't understand or value.
There was lot of lofty ideas around devops/pe and the like but ime the grim reality is that in most of managers’ heads it’s basically “tools that product engs don’t want to be concerned with” and like i said current models are really really good at this. Also disagree on the mental model thing - give opus 4.7 or latest codex access to your code, design mds and your logging mcp - in five minutes it will be better at debugging production issues than 90% of platform engineers I’ve worked with. It is truly over
> and like i said current models are really really good at this
They're absolutely shit at this. You only say that because it's a thing you "don't want to be concerned with".
> in five minutes it will be better at debugging production issues
In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
> In my circles "debugging production issues" is running perf to diagnose memory allocation hot paths and tcpdump to figure out who is sending bad packets.
Haha i got some news for you…
i remember having to write design docs at one team about 15 years ago. dont miss that. usually was 90% waste.
> First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability.
All the process you described exists to maximise the amount of time your software engineers spend writing code[0]. You put this process in place because software engineers are among the most expensive employees in the business. Their time being wasted is meaningful to the bottom line.
Make the software engineers cheap enough and the need for a lot of this process evaporates. Companies that already _have_ these processes in place will be SOL because it's incredibly challenging to break a bureaucracy like that, but companies that either don't have these processes or manage to eliminate them will have a significant competitive advantage.
Which shouldn't be news. Startups have always competed with established businesses via speed of execution. What's new is the ability to maintain that speed for longer.
> At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA...
These are all in the firing line. If the company could outsource their legal liability to an external provider of these reviews, they would.
[0] We'll just ignore the irony that much of this process ends up being foisted on the employees whose time you're hoping to save.
It very much depends on what kind of company you work for. You could never run a startup like this, for example.
Not every company works like that
Big tech has a lot of wankery like that but smaller companies can be fast and scrappy
It's a good point, and your username definitely checks out. I've also worked at a startup and some smaller companies, and still there's a LOT of "wankery" just different types. No, don't write the code yet, you need to present it to the CEO. Oh, we need to also present it to investors. Wait for a bit, because we have another deal coming down the pipe and we might have to change direction. Oh, a VIP customer just played golf with the founder and you need to go to his house to fix his setup. So much of the software engineer's job in the software industry doesn't involve writing code.
Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike.
Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things".
Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure.
Repeat until spike is operational and you're happy with the abstractions used
Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders.
Integrate feedback into your spike, or even the original spec document and regenerate the whole thing.
So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work.
I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"
I have no idea what a “spike” is, but this seems like a good way to build software when there are no consequences to getting it wrong.
What happens if this “spike” violates someone’s patent or puts the company at legal/regulatory risk? What if it leaks users’ personal information? What if it introduces a vulnerability that my 13 year old can exploit? What if it crashes 2 million of your users’ devices because it didn’t anticipate some unusual configuration? What if the code totally conflicts with some other team’s future plans and you didn’t know because they never reviewed it?
This kind of yolo “just try it” development only works if you are very small and low-profile, don’t have hundreds of millions of users, or your software is inconsequential (nobody cares if it goes down or doesn’t work).
The point not to YOLO in vibe coded slop. It's that with agentic generation you can prove out concepts, features and technical approaches first because it's low cost. Once you have something working you can work on getting alignment.
And yes you should completely grok what you're finally committing, making sure it's fully tested. What it enables is lots of fast experimentation before settling on your final change.
https://www.google.com/search?q=software+spike
I think it depends a lot on how automated the agent is and how long you let it run for. Full automation where you try to build an entire piece of software with agents... yeah, no, we are not there yet. At least not a few you care about maintainability.
Short-lived tightly-scoped agents can do alarmingly thorough and high-quality knowledge work, as long as the work itself is relatively mechanical and can either be carried out in independent chunks or sequentially. For example, a research agent like the Gemini "deep research" tool can save hours of digging around the web and compiling information. With careful prompting, sufficient background context, and good self-evaluation tools, an agentic loop can do very detailed data analysis, carry out serious statistics and machine learning projects, produce high-quality data visualization thereof, and put together a handy executive summary.
They occasionally hallucinate, go off track, get confused, and make mistakes. But they "know" everything that's been published in English for the last 200 years, they never get tired, and the code they write is good enough for throwaway scripting. The real power of agents being able to write code is that they can be extremely self-sufficient and flexible in carrying out these kinds of tree- and sequence-structured knowledge work tasks.
That's of course a different thing from "designing good software", which is neither tree-structured or sequential, and requires a level of intelligence (for lack of a better term) that LLMs do not seem to be capable of, at least not yet. But that's a more specific thing than just writing code in order to get stuff done that happens to require code.
>Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:
Ai writes the plans now. I just review and modify.
The thing is the code quality is still ultimately up to you
Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write
IME, it's faster and less frustrating to just write the code myself, if the goal is to get code to my quality standards.
how many LOC per day are you shipping
Respectfully, unless someone is really really bad at articulating what the quality standards are or works with a very niche stack that is definitely not the case anymore with SOTA models
Respectfully, the current models are all trained on everyone else's legacy code as of roughly six months ago and largely always will be. If I'm doing my job right an LLM cannot meet my personal quality bar on its own because I will always need innovation and excellence they will never see and thus cannot deliver. I also think that training these tools on my personal quality bar is more work than just writing it myself.
High quality c++ code today looks exactly same as it did six months, hell, six years ago. Innovation doesn’t come from code tricks
LLMs are plenty innovative and generate good quality code by default, and great quality code when directed well.
If you're not seeing this, at best you're probably unable to direct them or use them well.
FWIW, if you don't believe the above, I challenge you to put up a quick git repo, where you are unable to get the deserved quality out, and we can quickly show you how the same quality is available via SOTA agents, within a fraction of hand-coded time.
You're presuming too much about what OP's quality standards are. Can SOTA models outperform the average junior engineer? Yes, obviously. Can they match the best human engineers, if those humans were given all the time and interest in the world? Equally obviously not.
I use hundreds of millions of tokens a month, and LLMs have completely transformed the way I work. They're also, frankly, pretty mid programmers.
most people are around mid by definition. mid is good. a lot of companies pay good money to find mid devs.
Yes, and? Something can be both scare and inadequate to a given task. FAANG L5s cost a pretty penny but I wouldn't trust a random one to prove a crypto library correct.
TL;DR — there’s a whole lot of craft in how you use agents
I think that’s mostly true, but also I think there is some skill to using agents well. Specifically, work with agents to get a really good product requirements document, then task it out into very narrow user stories / vertical slices (this takes some iterating—the AI really seems to want to think in horizontal layers today), then maybe walk through the code interfaces to be super sure you are aligned. At each step, I make the agent interrogate me thoroughly with every question it can think of, and even if we stop now we will have a system design and tickets that are much higher quality than me thinking alone. I could hand those off to anyone to implement, but I think having an agent TDD their way through the code is the sweet spot.
Whenever the agent is doing something I don’t like (e.g., some coding style thing), I pause and have another agent help me write a style guide that agents must read. This slows me down at first but I think it will pay off in time.
"... iterating with the agent till the code is the exact same quality that you yourself would write"
I don't want my code quality, I want AGI code quality - that's what I was promised and jetpacks and flying cars too!
This is precisely why these types of articles don't make any sense to me, and strike me as case studies on human laziness. If you want good output, you'll review the output and iterate. If you want good foundations, you'll write them, and then later those foundations will prevent, to a very great degree, bad code from getting written by the LLM.
These articles frustrate me greatly. That said, the author's point about token cost is real, and a risk.
Nothing is stopping you... but that's slower than just writing it yourself to begin with. AI productivity gains are a myth.
>Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write
Yeah, but in my experience, it takes the same amount of time or longer to cajole the AI to get it there. I'd rather write it myself and know how it works than insert an LLM as the middleman, especially when it isn't really proving to be any faster.
Sure, but then it's not really saving you time is it.
In my experience, it sure saves time. a lot of quality has significant mechanical components LLMs do great. Hey, this series of 300 functional tests are reusing the same few patterns without helper methods clarifying intent. Give me an overview of possible meaningful methods that would simplify the duplication. Ok, 2, 4 and 5 are good, but rename 2 to X, and change the order of parameters in 5. Implement across the tests, and make sure it all passes.
Still very significant savings over all that rather mechanical work. It's ultimately cheaper than doing a code review, and it's faster, because there's less need to manage the emotional state of the person whose code is being reviewed. Maybe I am a slow developer or something, but I am getting a lot of quality changes like that done that before I'd not have, solely because of time spent.
And not increasing the quality just causes problems anyway. Given the same quality, more changes mean more outages than before, just by probability. Increasing rate of change demands a similar increase in quality if you don't want your production support costs to go up. So spending at least a bit of time on quality, letting the LLM do the nagging little things that before you didn't do beause they they took too long and were not a core part of quarterly goals is basically mandatory.
IMO it still does save time generally but it’s not as much of a huge gain if you’re doing this.
I will admit there are occasional times after iterating so much I’m not sure if I’ve even saved time because going from “it works” to “it’s up to quality” takes so long
I've run a few experiments where I give it well-defined small side projects where I have a good idea of what I would do and how long it would take, and I time the process from start to finish.
So far, it's been pretty underwhelming--on par or slower, and it's definitely more frustrating lol.
Honestly, the only killer feature I found so far is overcoming ADHD activation energy lol. Getting annoyed with the idiot robot screwing up the Terraform migration is apparently a good way to get me to finish a Terraform migration.
It saves so much time! Think of the best find and replace and autocomplete and macro and every other possible super tool you use and roll everything into one. The design phase of any significant feature pales in comparison to all of the (now fully automated) tasks that you can just hand off to the agent to do nearly instantly and perfectly.
Comment deleted because it was backwards
But you’d have that coding it yourself…
Actually ignore my comment I misunderstood the premise. I meant not vibe coding is the way to save time with production issues. Not the other way around!
It still is if agent brings it up to quality fast .
And yea usually does for me
I mean you have to compare apples to apples.
If you are coding by hand like the old days you are probably not literally writing everything from scratch anyway, you are copy pasting a bunch of shit off google and stackoverflow or installing open source libraries.
I also reuse a lot of my own code. Either from libraries I built or just directly copy pasting (like boilerplate code for setting up the basics of something in my style).
I've been using AI tools to brainstorm approaches and sometimes generate code, but actually doing the typing myself. That way I'm less likely to forget the mechanics and programming language over time.
Same. Most of what I do is ask for an implementation plan, with minimal code, or no code, or pseudocode, and then write the actual code myself. This is for open source work, where the entire point of my enjoyment is that I write the code myself. I honestly wouldn't bother being an open source maintainer if the entire thing was just prompting an LLM to write code, and then reviewing it. That doesn't sound fulfilling at all.
If this was an actual paid job, I do wonder how that would change my LLM use. The reason I'm a software developer at all is because I love the craft. The act of building, of using my brain to transform ideas into code... that's what I enjoy. If it was just prompting an LLM, would I still do that job? I don't know. I'd probably start looking into the idea of switching careers, at least.
I have asked more than a few dozen people on this, and the answer after some probing is that no other knowledge based career exists that one can move to which is not exposed to AI. While many talk about moving to a labour oriented career, no one has actually done this in my immediate network and friend of friends network. It's day-dreaming in my opinion.
One approach you can use is to ask it to never write the code for you, which forces it to explain and then once you try the idea by coding yourself you get a better understanding of it. I use this approach with code I am required to maintain. It still bites me sometimes because the models still mixes a lot of incorrect information (usually just stuff that was correct in the past but is incorrect now). For throwaway and easy to verify scripts I ask it to generate, but I do ask to avoid over engineering and trying to catch all corner cases cause in scripts I prefer just letting things error as they are better understood as a step that failed. I also avoid languages I find hard to read (like powershell) and prefer to generate things that are short to fit in the monitor so I can read everything and understand (python, bash, batch are my goto scripting languages).
Same. I've also configured the system prompt to never give me a full solution or write a code for me. So whenever I ask it a question it produces a short 10 line example or even a pseudocode. This is far easier for me to reason about.
I still reject > 50% of AI suggestions, because they're too mediocre, like moving code for no reason or sometimes it is just plain wrong.
The thing is why would forgetting even matter if the AI can just remind you of anything that you forgot?
Remembering and understanding aren't the same thing. Merely reciting facts doesn't automatically give you the ability to apply those facts to solve problems.
This is exactly what I do. I'm glad I'm not the only one.
Me too, ... more or less. I'm mostly still typing, sometimes copy-and-pasting with typed changes, and rarely copy-and-pasting verbatim. With the caveat that in some cases, like prototypes, proofs-of-concept, and porting code between languages; then maybe many lines are copy-and-pasted verbatim.
I've come to the conclusion that if AI can do it, its not hard. None of the complicated software i work on can be reliably written by ai yet
SotA models have cracked a handful of research-level math problems though.
The default Claude Code style harness is bad for complicated problems as well. Just taking the specific class or function you're working on, and putting it into a deep research style loop yields way better results. Limiting the initial context by hand is still the way to go in a lot of cases.
No, it's the same for math from what I've seen, aka it can do some of the easy things, usually with a lot of help. People usually mean the Erdos problems (aka "a list of things Paul Erdos thought were neat") and, well, here:
> While Erdős generated a huge number of problems, they are not all equally significant and important. I have, unfortunately, seen some mathematicians grow dismissive of Erdős problems recently, perhaps because they have seen reports of AI solving problems on this site that turned out to be quite simple, and wrongly generalised this to assume that all problems posed by Erdős are amusing novelties, of the level of olympiad problems.
From: https://www.erdosproblems.com/forum/thread/blog:5
The rest of the article isn't about AI at all, but I did think it was funny that it describes mathematicians as having more or the same opinion as SWEs.
You're right, definitely as a helper, not a one shot thing.
Here's an example unrelated to the Erdos problems: https://arxiv.org/abs/2510.23513
What type of software are you talking about?
Yeah this is the same conclusion I have. I primarily use AI for UI code, and guess what, it's all basically mechanical drudgery anyways. Put a div here, or put a Box here, apply some style rules, etc. This shit should have been automated decades ago yet for some reason we're still writing the same stuff with a different "twist" today.
Now if your career is built on writing out the same boilerplate code in its infinite slight variations every day, congrats, you've been automated. Thank god we can free up our intellects to focus on the actual hard problems, the ones that are somewhat cutting edge, the ones that actually push our field and humanity forward.
Literally every example of AI generated code (without significant human input) is just basic stuff that is wholly unimpressive. Oh wow, you had an AI generate a Next.js app? It's writing HTML for you? It made a generic SAAS? Guess I'll become a farmer now.
Or, wait, I'll continue to write my multithreaded real-time multiplayer network for a MMO, since the AI currently generates something that would get me fired 10 seconds ago if I tried to push it to production.
It's amazing how you introduce just the slightest difficulty or novelty to an AI and it just craps the bed. And then you go online and apparently we're gonna be replaced -6 months ago or something.
People need a reality check.
I had it throwing in free advice on my code working as intended, but not a normal pattern. It was something like:"Bonus! This bug exists!" And I had to tell it stop doing that. Or, for generated SQL renaming to keep deeply linked table columns human readable via comments it was - "You can't have a comment of this style here." It works perfectly so yes, yes I can.
I can certainly get it to do things that are reasonably common it seems like.
As for the article itself, I can agree with much of it.
I genuinely appreciated this comment—it made me chuckle. That said, I think there are better approaches to working with AI besides “here’s a big vague thing to work on, go write some code”. I think you have to iterate somewhat closely with the AI to write a doc describing exactly what you want the system to do and then scope out very narrow tickets and then have a separate agent do the TDD to actually produce the thing. The key insights here are (1) don’t let a code writing agent have too much scope—just a narrowly scoped ticket, (2) keep the coding agent’s context minimal, (3) don’t let the coding agent write much code without testing it. The agent should make very small changes at a time and then test that everything still works.
You will still need to QA stuff and review PRs, but I think AI done properly can genuinely make some tasks better.
> don’t let a code writing agent have too much scope—just a narrowly scoped ticket
it's interesting cuz my intuition is to give the language model writing the files as much context as possible, which means all of the previous planning thread. but I also thought you should plan with a small model and implement with a large one, and the meta seems to be plan with an expensive one and delegate code output to smaller ones. so what do I know.
> The agent should make very small changes at a time and then test that everything still works.
yeah I think if it's treated like a codegen machine it's basically just outputting code as if you're using a dsl, except the dsl is natural language and the output is meant to be edited, no `// this is generated code, do not edit` headers
> I think AI done properly can genuinely make some tasks better
thank god I dont need to write html by hand anymore, what a pita
I had AI fuck up writing a scraper[0]. A scraper. It hit a snag with cookies and spiraled into a tizzy. I liked the part where it assured me it could resume from the point of failure, while starting over for the 10th time because it had written no such code lol
[0] For those with AI scraping PTSD, it was a government site with public domain info and I know how to scrape politely
I mean that’s been my line every time someone makes impressed noises when I say I’m a programmer - it’s really not that hard, it’s really just a question of whether you like it enough to put the work in, like anything else. “Don’t you have to be a math wiz?” No dude 95% of the time whatever you’re trying to do already has a very well researched approach, a lot of times you’re just picking which pre-vetted solution to adapt to your needs.
no i mean the opposite, some programming is actually hard
Right. Like anywhere the conceptual problems haven't been all figured out yet, or where higher order effects happen with scale or particular shapes of data/substrate and you don't know them in advance.
Sometimes hard like interesting and you get to do really novel thinking. A load of p2p/decentralised things are hard like this.
Also sometimes hard like you get to a particular challenge and it turns out to be a notoriously unsolved mathematical thing, or you push against subtle boundaries of core libraries, runtimes, systems etc. Working with metagenome assemblies is this kind of hard.
Honestly the hard code I've done made such a difference to my brain. There's plenty of trivial stuff I'm happy to have automated, but of I can't work on the hard problems I may as well not be involved at all.
> When a sysadmin moved to AWS, they didn't feel like they were losing their ability to understand networking.
Wait, is this the same AWS I have been using?
Would like to see a study of brain scans during flow, manual programming, compared to code review. If the conclusion is different parts of the brain are activated, then orchestration is a separate activity entirely. Reading code is not the same as writing code.
However, the code review study needs to compare between surface scanning and reviewing long enough to get over a theoretical slough of perspective: when you assume the coding chair and are in their frame, whether the brain shifts into a different cognitive mode.
Otherwise, just stamping "Looks good to me" is likely to lead to the same atrophy. There's no critical thought, even a self-summary of the change or active questioning.
Thoughtful, deliberate code review just plain takes longer. AI can help here a lot, although it still takes over the "get into review mode" process.
I absolutely feel like a "different" part of my mind is loaded when seriously engineering something myself vs vibecoding+reviewing. Even the reviewing is more annoying in the latter mental context.
Many firms are going to go bust because of dangerous assumptions they made re. Expectations of llm improvements.
And they will deserve it.
It is definitely not the same parts of a brain.
Code review alone is kind of like being able to understand a foreign language enough to read it, but not really understand it in flowing conversation or being able to speak it, much less construct a complex piece of literature.
Retention also suffers, as you will quickly forget what you just reviewed. What is the last PR you remember?
The slot machine lever is my least favourite opinion on the subject.
Also, let’s not forget. The developer is rarely the person pitching the feature, and is normally given the constraints and the PRD…
Soooo people can keep tiptapping on the keyboard, but eventually they need to open their mind to the possibility that “the old way” is actually dead.
> The developer is rarely the person pitching the feature, and is normally given the constraints and the PRD
This heavily depends on the industry and company culture.
I've pitched plenty of features and I've basically never had a spec land on my desk ready to go. Part of my job as a SWE is to help product folks decide what to build.
it's a fairly new way of doing things. I predict, in the future it will be more formalized and standardized like AGILE and SCRUM and all that boring stuff.
The result of that though would be establishment of development patterns that are good practices.
The rule of thumb is: An agent can write it, but a human has to understand it before it gets pushed to prod.
I'm still not convinced about the doom and gloom over developers being replaced. I'm not a dev as part of my main job function, but where I do use LLMs, it has been to do things I couldn't have done before because I just didn't have time, and had to de-prioritize. You can ship more and better features. I think LLMs being tools and all, there is too much focus on how the tool should be used without considering desired and actualized results.
If you just want an app shipped with little hassle and that's it, just let Claude do most of the work and get it over with. If you have other requirements, well that's where the best practices and standards would come in the future (I hope), but for now we're all just reading random blog posts and see how others are faring and experimenting.
> like AGILE and SCRUM
Yeah, likely
> development patterns that are good practices.
Wait, now you lost me
while those things sucked, patterns imprinted on devs minds, passed on from generation of devs to the other until that's just the way things are done. CI is a good example, as are some of the documentation practices. Lots of teams that don't use agile or scrum formally, follow those concepts because that's just how they've seen others do things in the industry. I predict, LLM work will get some overdone and abstract thing like agile/scrum that lots of people hate, and few thing is useful, but then out of it the actually useful bits and pieces become self-organizing standards of sorts.
> The rule of thumb is: An agent can write it, but a human has to understand it before it gets pushed to prod.
The article essentially claims that no, that line of thinking is false. If the agent writes all of it (or too much of it, where "too much" is still not well defined), then your ability to understand it will atrophy with time, and you will either a) never push to prod, because you can't understand it well enough, or b) push to prod anyway, and cause bugs and outages.
I think the article is correct.
> I'm still not convinced about the doom and gloom over developers being replaced.
Agreed. The agents are just not good enough to write code unsupervised, or supervised by people without senior-level skills. And frankly it's hard to imagine them getting there. Each new release of the coding tools/models is a mixed bag. Some things are better, some things are worse, and the gains are diminishing with each iteration. I am afraid that we're going to hit a ceiling at some point, at least with the transformer architecture.
> but for now we're all just reading random blog posts and see how others are faring and experimenting.
Yes, exactly, and many people are not faring well. The article cites several examples of people feeling less capable after using LLMs to write code for a while.
> I think the article is correct.
What I said doesn't contradict the article. if what you said is true, then since a human can't understand it well enough, that approach is not good according to my rule of thumb, thus agreeing with article. I only established the litmus test.
agreed on other points you made.
That's exactly what I predict as well, I think it's inevitable. there will be middle managers and project managers needing a stick with which to beat the LLM mess into order, and keep themselves relevant, and it will suck all the same. But even such efforts result in establishment of good practices. In attempting to discredit the "slog" devs will establish "but instead, we should be doing $X".
i would hope so, as long as "good practices" really are good (for what thats worth anyway).
again, maybe overly cynical but ime "good practices" usually end up getting warped into "bad practices" caused by cargo-culting/up-selling by consultants as they try to mass-produce a new dev paradigm
Slightly off-topic.
The funny thing is that he mentions that Spec Driven Development is the future.
Technically we allready did this when we where doing Waterfall. I kind of miss it that we had good documentation. The last decade (maybe more?) I get jira tickets with a one liner. I often need to call people as they specify almost nothing.
I am still avoiding working with AI. I try to use some models locally for experiments. I refuse to pay for something that was build on ripping others off. And the local models are underwhelming thus so far.
Upvote. These remote models are going to get ever expensive. Their business future depends on the expected advancements in inference costs. One should never want to tie themselves to this prison.
the funny thing is once the llms got mostly good enough in november 2025 for me, it was mind boggling how much it helped me get stuff out of my head with ease.
its easier for me to code now, because its like i have a 24/7 insane intern that needs to be supervised via pair programming but also understands most topics enough to be useful/ dangerous.
ironically ive been spending much of my time iterating on ways to improve model reasoning and reliability and aside from the challenge of benchmark design, ive had some pretty good success!!
my fork of omp: https://github.com/cartazio/oh-punkin-pi has a bunch of my ideas layered on top. ultimately its just a bridge till i’ve finished the build of the proper 2nd gen harness with some other really cool stuff folded in. not sure if theres a bizop in a hosted version of what ive got planned, but the changes ive done in my forks have made enough difference that i can see the different in per model reasoning
I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term.
When you start coding as a way to scope out a problem, you're biasing yourself to think of everything in terms of abstractions which you invented for problems which you don't yet fully understand. My experience is that this distorts your own thinking; you are injecting your own biases into your learning process and locking down on decisions too early due to suck-cost bias.
Having a solution all coded-up and working after a couple of days creates the illusion that you've built something solid and maintainable and that any additional functionality needs to be added on top. Before you know it, the prototype has become the foundation.
It's like if I took you to some random country and told you to build a house and you started chopping wood and putting up the walls straight away. You might immediately have noticed that it's hot so you would put lots of windows... Good... But what you don't know yet is that this country gets hit by powerful cyclones once a year on average and your wooden house won't survive the first one. You started with the wrong material. It might work really well for the first few months until a point when it won't work at all and you'll have to rebuild the entire thing from scratch.
It's funny because it's either
- tech for management who can delegate but don't have the expertise to know when it's wrong or just plainly impossible
- tech for coders who have the expertise... but who will gradually lose it.
So I'm not sure who it is for, beside VCs and shareholders until the next quarter obviously.
I think of it as driver's seat vs back seat vs passenger seat. You always take the back seat and eventually you will forget how to drive. You insist on always being in the front seat and you will miss out on the occasions where the LLM happens to know the area very well, like working with an unfamiliar library or problem domain. If it is a place that you are just passing through, it's a great to let it take the wheel and see where it will takes you. If it is a place that you need to become familiar with, it's great to have a dependable navigator beside you.
My sense is that a decade from now, the people who generally see their place as the driver seat but recognize when its not are going to be writing the code that matters.
I tend to think of it as like two pilots as on commercial airliners: you always have one pilot flying and one pilot monitoring.
You can debate with agentic coding who is monitoring and who is flying but, if we assume the user is monitoring what that means, in practice, for me is that I'm reading and making sure I understand all the changes the agent is proposing to make, as well as providing instruction, guidance, correction, etc. That includes reading and understanding all the code changes.
There’s too much in this article to comment on it all, but if we zoom into the first claim:
> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.
My question is why isn’t there an effort from the author to mitigate the insane things that LLMs do? For example, I set up a hexagonal design pattern for our backend. Claude Code printed out directionally ok but actually nonsensical code when I asked it to riff off the canonical example.
Then, I built linters specific to the conventions I want. For example, all hexagonal features share the same directory structure, and the port.py file has a Protocol class suffixed with “Port”.
That was better but there was a bunch of wheel spinning so then I built a scaffolder as part of the linter to print out templated code depending on what I want to do.
Then I was worried it was hallucinating the data, so I wrote a fixture generator that reads from our db and creates accurate fixtures for our adapters.
Since good code has never been “explained for itself 100%, without comments”, I employ BDD so the LLM can print out in a human readable way what the expected logical flow is. And for example, any disable of a custom rule I wrote requires and explanation of why as a comment.
Meanwhile, I’m collecting feedback from the agents along the way where they get tripped up, and what can improve in the architecture so we can promote more trust to the output. Like, I only have a fixture printer because it called out that real data (redacted yes) would be a better truth than any mocks I made.
Finally, code review is now less focused on the boilerplate and much more control flow in the use_case.
The stakes to have shitty code in these in-house tools is almost zero since new rules and rule version bumps are enforced w a ratchet pattern. Let the world fail on first pass.
Anyway, it seems to me like with investment you can slap rails on your code and stay sharp along the way. I have a strong vision for what works, am able to prove it deterministically with my homespun linters, and am being challenged by the LLMs daily with new ideas to bolt on.
So I don’t know, seems like the issue comes down to choosing to mistrust instead of slap on rails.
Edit: I wanted to ask if anyone is taking this approach or something similar, or have thought about things like writing linters for popular packages that would encourage a canonical implementation (I have seen some crazy crazy modeling with ORMs just from folks not reading the docs). HMU would love to chat youngii.jc@gmail
There's a subset of software engineers who understand most of the points from the article, but it looks more and more like this train can accelerate towards the cliff due to steam from burned money.
“The market can stay irrational longer than you can stay solvent” quote is usually applied to markets, but it can be applied to software engineering as well - all jobs can be gone even if world will be submerged into technological crisis, with single nine availability (and I'm talking about 9% :) ) and all accounts compromised.
I can’t say that I’ve felt my skills atrophy, but I’ve also never found backend web development to be that difficult. 90% of my job for my entire career could be described as digital plumber.
Interesting analogy. Through the lens of a data driven design, all we are doing is taking data in shape A, transforming it to shape B, and then sending it somewhere else.
An aspect i don't hear about enough is using agents to make better abstractions instead of treating the agent as the abstraction. We could work on making abstractions that allow expressing what we are building in most concise form without any boilerplate. The reviews are enjoyable, if llm providers fail we have a chance to use the great abstractions by hand. The alternative i see everywhere: We don’t care about the bad abstractions because agents write the code. We don't review because its too much and too noisy and we rather blow our brains out than manually dig through that react and spaghetti codebase and writing all the boilerplate and cross references by hand. We have to build for resilience and future us.
AI doesn't automatically make us better human beings, but they only expose our worst parts. Most people are not born great leaders and managers (need rigorous training and experience), and empowering them with AI kind of pushes them into a spot where they suddenly need to "lead". To fight brainrot from AI overuse, we must try harder to maintain that developer's priority list.
Lars we are on the same page. I use LLMs to help me scope and get a second set of eyes on the high levels of a task. Then I write the code. Often I automate boilerplate or boring objects but sometimes it's faster/better for me to just write them. Then I will ask an LLM to say write some tests. Then I will focus on the cases they missed and write those myself.
I have been described as a decel and a Luddite though so be weary of my opinions.
I don't use AI for everything, but I use AI to make repeatable, auditable workflows. For DevOps, I don't just ask AI to go on my production server and fix all issues. I ask it to write scripts, which I audit, then I dry run, then I test, and finally approve and run on production.
I was just looking through HN search for "show HN", and I saw many fitness and calorie tracking apps.
A lot of them disappeared just after a few months of launch; a few of them survived a year, then died out as their domain name expired.
People are making things, but they are not reaching their "audience".
I created https://macrocodex.app/, launched on 16 Mar 2026, and reached 10,000+ monthly active users.
Fitness/Calorie tracking is a competitive space where there are tons of apps and services.
I could never have built such an app because I do not know how to design pages; I can talk to a designer, but from past experience, it takes them a long time to understand what the market wants and projects. And companies with small budgets find it very difficult to find a good guy.
Many of my projects never got shipped because I dreaded making landing pages, icons, UI, etc.
I am not saying we did a very good job with AI on landing pages or UI at all; that's not an area of my expertise; the domain knowledge is, but the fact that many people find it useful, I think I’ve succeeded.
I've even put a ticket system in the app for support and received a few bug reports, which I resolved.
Here's the latency of my other service: https://prnt.sc/6474F4gba_he
I no longer use managed services in AWS, and my costs are very low; this enables me to offer my apps and services for free to many users.
I wrote something that touches on a few of the same points not too long ago (namely vendor lock-in and inability to project cost with LLMs at the wheel). Tangential topics but I think there's a healthy enough amount of intersection to at least join in on the discussion.
I do agree that if we just rely on AI for all outputs and some reviews (at least to a threshold, because we simply can't keep up with the AI throughput as humans) we will eventually have skills atrophy. Here's where the tangents intersect: I've been working on a way to have the best of both worlds. We can still use AI to generate a large swathe of code, but use good old software engineering to do it. My project (https://salesforce-misc.github.io/switchplane/) inverts the control. Rather than having LLM-as-runtime and doing all the things, you define and write LangGraph control flows that only use the LLM when judgement is actually required. The basic principle is:
If it's deterministic, write it in code. If it requires judgement, use the LLM.
Switchplane itself is local-only but the principles can be applied to deployed agentic services as well. Because the approach is code-first, we can have that vendor independence: Use whatever model you want anywhere in the graph. One goes down? No problem. Swap the config without impacting the overarching control flow.
Cost becoming a factor? Limit LLM loops or constrain their access however you want. It's just code that needs to be updated. You control the runtime, not the LLM.
Concerned about non-deterministic behaviour when you need determinism? Don't be. It's in code.
Worried about skills atrophying because we're handing off everything to an LLM? That's mitigated somewhat here because you still need to think in systems in order to build execution graphs in the first place.
It might not demo as well as a number of markdown files being executed by an LLM. It's definitely a more reliable approach in the long run though.
Re vendor lock in point: this is a harness issue really. Sure, CC is restricted to Anthropic models, but it's not the only harness out there. So if one vendor has an outage or botches the quality of their models due to compute shortage, you can switch to another vendor. LLMs are the easiest to switch. Of course, if hardware costs go up, so will all AI vendors. The only way out for the employer would be to directly buy the hardware (or do a fixed price deal with a cloud provider).
Re the understanding code point: you can still use LLMs to understand code. If you write the spec without knowing anything about the code, of course the architecture might suck. Maybe there is already a subsystem that you can modify and extend instead of adding a completely new one for the new feature you are adding, etc.
I use LLMs for my daily workflows and they do understand code perfectly and much more quickly than if I read it.
CC isn’t even limited to Anthropic models, there’s a post on the front page right now to use it with Deepseek V4 since Deepseek provides an Anthropic compatible API and CC reads API URLs from env variables so you can override them.
I’ve build a configuration transpiler to Claude code and codex and found I can switch pretty quickly between both and run both at once. At the moment codex performs better. Prior CC did. There is no vendor lockin and this is an old canard in technology that LLMs in fact themselves make irrelevant. Once you’ve got an implementation that uses X converting it to Y is almost trivial with an LLM because the spec is canonical in the reference.
Great idea. I would love to see your transpiler Mind sharing it?
It’s buried in my dotfiles and not easily extracted. But the idea isn’t a hard one to implement, except the coding engineers are woefully unaware of themselves. Codex is easier because it’s open source. Claude you kind of have to futz with it for a while. Once you have the intermediate form working and outputting config for the two I’m sure you can coerce it to any other agent that comes along with similar constructs (marketplaces, etc). Theres some nuance for some MCPs particular those that download binaries like rust MCPs but its very complex I found and probably better to avoid unless you really need it.
They are also surprising good at finding bugs that humans often miss
This author assumes that workforce development is a first-order priority for businesses, or at least for the health of the industry.
Why make this assumption so confidently?
The arrival of the electronic computer did not turn human computers into programmers, it simply eliminated them en masse.
>and then pulls the slot machine lever over and over
Does anyone really do this? You want verification and self-correction in a loop, not rerolling and cherrypicking. The non-determinism point is really tiresome to hear over and over.
I do this for debugging. Models are extremely vulnerable to framing effects and it's usually easier to spin up a fresh instance than it is to get an existing one to generate new hypotheses.
The slot machine metaphor gets thrown around a lot but it hasn’t really described my experience with LLMs since ~2024
> Does anyone really do this
Yes, lots of people. It’s a whole issue.
> The non-determinism point is really tiresome to hear over and over.
When the problem is fixed, you'll stop hearing about it.
That's the question, how is it even a problem? There's nothing to fix. Don't reroll, verify and fix if incorrect. Repeat until it's right.
I've been having the same feeling too. At work, I try to do a hybrid prompt where I fill in things at method level with some placeholder pseudocode and let the prompt fill in the blanks. This helps with remembering and keeping a memory map. But its a lost cause keeping up with other's PRs that are often very verbose and high volume. For a lot of backend programming without a very complex domain, I think this works fine.
But I still want to be in touch with coding by hand and have ventured into systems programming, outside of work, which I feel AI is less useful for currently.
This is how I feel about things. Its like someone is demanding that I become a manager, when I was perfectly happy being a IC. And now I have to figure out how to be a manager of AI agents while at the same time not lose my ability to judge their work, or plan effectively, even though I'm not supposed to be doing things "by hand" anymore. But doing things "by hand" is how I reasoned through problems and figured out the plan to begin with.
The trap isn't agentic coding, it's using it as fancy autocomplete. When you delegate whole tasks with real acceptance criteria, not just single functions, the economics change completely.
I try to make understanding the bottleneck and it seems to work out for me while still delivering solid productivity gains.
"Don't vibe code" but here's a deadline that's impossible without it. classic
Software engineers and their leadership have been pushing back on terrible product managers for decades. AI isn't the reason to stop our time honored tradition. If anything we can write the emails faster now
> Buried in a recent study[1] by Anthropic was a surprisingly honest moment when speaking about the risks of engaging with coding agents on a regular basis...
Does the person who wrote that still work there?
[1] https://www.anthropic.com/research/how-ai-is-transforming-wo...
Nope. 1) Skills don't go away, you just get better at the things you do regularly, but your still have your old skills, 2) You only have vendor lock-in if you use lock-in devices (stop using Claude Code), 3) It's not an increase in complexity, it's a replacement, in order to gain efficiency (see: the cotton gin), 4) The increased cost is negligible considering average salary and resulting productivity
I sometimes wonder if I'm in a different universe to other devs. Anytime AI coding is brought up, comments are overwhelmingly negative and often point out correctness, quality, slop, etc.
There's also the 'more stuff is being delivered, but it's not right, full of holes and papercuts'.
I'm 22 years into development and couldn't think of going back to non AI programming now. Not only has it sped up velocity by an order of magnitude, it's also helped me unlock side projects that I would never even begin in the past as I knew I didn't have that time.
It's just like any tool though, and I've found enormous differences in outcome depending on how you drive it. Launching into 'build this' and expecting it to output code that you would manually write would not get you there; and I feel this is where most developers stall out.
Getting the right outcomes takes a lot of harness set up - the same as if you wanted to hire new devs and get them productive without peering with them. You would set up linting, good test coverage and approaches, thorough documentation about what your project is, the domain, the architecture etc. This at least gets good code consistency for the most part.
For how to build, https://github.com/bmad-code-org/BMAD-METHOD is really good and I've onboarded a few Saas projects into it now. Tech speccing and multiple cycles of elicitation are what deal with all the edge cases that you normally only encounter during coding. It does front-load all of the planning brainwork; but condensing that into a couple days of solid speccing is far more productive than spreading it out over months.
It's taken a while to get to this point, and most agents aren't good for substantial work out of the box. Most of the time what the agent does will be a product of its environment.
This is exactly the same problem of "mechanical engineers' job is to design parts, not machine them, so we'll take training on machines out of the mech eng curriculum." Result: fresh mech eng grads do not know how to properly design parts because they have no idea how they are machined.
Should ontogeny recapitulate phylogony in the trades? Ie, should we teach historical techniques and graduate to modernity?
How do they solve this for mechanical engineering? Or is it an ongoing problem?
I don't know if they've addressed it. But ~15 years ago, my father was mentoring some college students and noticed that while they had been taught to machine a block (i.e., the rudiments of machining), they had no idea how to design appropriate tolerances for e.g., a gear because they hadn't ever made anything that complicated. So it was an issue back then. Presumably these details are learned on the job through trial and error, or by oversight from a more senior engineer who understands the requirements better. But in the past it was understood you'd start learning them from actually building parts as part of the curriculum.
Vertical integration is valuable at many different scales
Surely they're made on CNC machines now? (well, since the 1970s)
Doesn’t matter, if you ask for physically impossible features to cut this is something you could technically do. Or you ask for a feature that adds multiple setups to an otherwise simple part and makes it wildly expensive
The CNC doesn't know either. What usually happens is that an engineer at the CNC shop figures it out for you.
Knowing some machining still lets you design parts and assemblies that are some combination of cheaper, better, etc. This is noticeable with precision or high performance assemblies. And how many revisions are needed.
Lathe, mill, CNC, or matter transmuter, doesn't matter. Effective design only becomes possible with intimate knowledge of how it is built.
AI is just another tool and a new layer of abstraction. Do you really think the majority of people who write in high level languages truly understand what's going on under the hood? Do they really? Or is there at some point a divide between what needs to be done, how the application or logic should perform, and the actual translation of all that into machine code?
These blogposts (no doubt written with the help of AI) have been the topic of many a comment here and elsewhere across the internet for years now. The atrophying of skills is a serious concern and has been voiced again and again since 2022 by everyone skeptical of AI and I just think some people and some places just don't care.
At some point, if you're just pulling the lever on the slop machine with zero insights into your code, may be your boss is justified in asking why you should earn more than 50k a year.
Only way to cope with this I found is to grind leetcode or advent of code. It's kinda funny how fast this all changed. Less funny part is the fact that I'm now kinda feared for my job in some time.
How can we solve this at a more fundamental level?
I think many people already recognize the problem:
-“Our ability to write code is being damaged.” -“If our ability to write code declines, our ability to recognize good code also declines.”
But the problem is that the market no longer works without LLMs.
Freelance rates and deadlines are now calibrated around LLM-assisted output. Even clients who write “do not vibe code” often set deadlines that are impossible to meet unless you use something like vibe coding. The client’s expectations themselves are becoming abnormal.
That is the irony of the market.
I honestly do not know what to do.
Recent Hacker News discussions are mostly a negative echo chamber about AI use. In other places, it is often the opposite: only positive echo. But almost nobody discusses the actual solution.
The main topics I keep seeing are roughly these:
1. Is the large repository PR system failing a fundamental stress test? Or should AI-generated(GEN AI) code simply not be merged? If PR review is moving from handmade production to mass production, how should the PR system change? Or should it remain the same?
2. As vendor lock-in continues, can we move toward local LLMs to escape it? Are cost and harness design manageable? What level of local model is required to reach a similar coding speed?
3. If we are forced to use agentic coding, how do we avoid damaging our own ability to code? There is a passage from Christopher Alexander that I keep thinking about:
“A whole academic field has grown up around the idea of ‘design methods’—and I have been hailed as one of the leading exponents of these so-called design methods. I am very sorry that this has happened, and want to state, publicly, that I reject the whole idea of design methods as a subject of study, since I think it is absurd to separate the study of designing from the practice of design. In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things.” — Christopher Alexander, 1971
This quote feels relevant to programming now. If we separate the study and supervision fo programming from the actual practice of making, something important may be lost.
In architecture, there is this idea that without practice, the architect loses meaning. But now the market is forcing the separation.
People with enough symbolic capital and high status have the freedom not to use AI. But people lower in the market are under pressure to use it.
So I think the discussion now needs to move beyond whether AI coding is good or bad.
The real question is How do we keep using AI because the market demands it, while still preserving the human practice that makes programming meaningful and keeps our judgment alive?
I think these are the important question. How do you maintain market value without using AI?
Or, if you do use AI, how do you avoid being treated as low-quality?
If you do not use AI, how can you remain more competitive than people who do use it?
If you do use AI, what advanatge do you have over people who do not use it, and how should you position yourself?
I know that agentic coding can cause skill degradation. I can feel it happening to me already. But for someone like me, who does not have strong status, credentials, or symbolic capital, social and market pressure makes AI almost unavoidable.
What frustrates me is that I do not see practical answers anywhere.
"How can we solve this at a more fundamental level?"
Stop using AI for coding. Period...there is no other solution. You can't make it work, nobody else can either. Without determinism, the entire process is useless. We need to stop trying to act like we all know that this isn't true. We have given it a chance, it failed, time to move on to something else no matter how much the VCs and execs don't want to. Those that do move on have a chance, the others have no future in software.
The issue is that you will end up without a job if the trend continues. It's similar to many cases of technical innovation - you can still have a few workers who do handcrafted works, but most of them have to use the machines, that may produce work of inferior quality but at much higher speed.
The market realigns, and unless you handwrite the highest possible quality at a quick pace, you won't be competitive with the vibe-coders who can fix a hundred issues a month.
It was the same with gps-assisted driving, now most people can't orient themselves autonomously. Worse, there are no roadsigns with directions installed, meaning that you are stuck with using the GPS.
"unless you handwrite the highest possible quality at a quick pace"
That's exactly what I do. I know I am lucky to be gifted in this skillset. But that's not a good reason to excuse people destroying the market for everyone.
I mean, why wouldn't they? Software developers are very often automating things, in order to reduce the amount of workforce, or the skill needed for economic activities.
Would you refuse to work on a navigation app such as Waze, since it allows everyone to work with platforms as Uber and pushes traditional taxis out of the market?
I agree with what you are saying, but if I cannot get work, I may literally have nothing to eat tomorrow.
So while I agree with your point, it does not feel like a practical answer for my situation. For someone who is already well known and has enough reputation, refusing to use AI may be a matter of principle. But I am dealing with survival.
I do not think your answer is bad. But because this is a survival problem, it is difficult for me to risk everything on principle.
In other words, I know that your answer may be the morally correct one. If everyone boycotted this, perhaps it would not be adopted so aggressively.
But I cannot do that.
What I need is a way to use AI while degrading my own ability as little as possible, and while still preserving my skills.
I am not saying you are wrong. I am saying that your answer is too idealistic for someone in my position.
I'm not being idealistic. I'm being very practical. You have the survival problem exactly backwards. Continuing to use it, that's the real danger in a practical sense. That only leads one direction and that direction isn't in your best interest.
I use AI mainly to improve the parts which I know I am pretty bad and need help and restrict it as I gain competency. Which means choosing to say no to copy pasting most things I wish to exercise my brain for and reading, understanding, processing and writing it more diligently. Treating brain like any other muscle that requires a gym, we do have cars and segways that can help us travel long distances quickly but we still require as a specie to walk and run. People with disability and underprivileged backgrounds also need these tools so it is a good option to have generally. Secondly we are human, we have made very good tools, we need to stop obsessing with being more productive in output and learn to be better, more considerate and respectful to each other and other species to make this planet generally for better world. It is the only one we got. At the same time, be more mindful about where and how we utilise our time and attention, they are very limited and the most valuable resources we can possibly possess.
Frankly I don't buy atrophy argument at all. I (and I believe many other people) switched multiple frameworks and languages over the years. I.e., I was an expert in Chef more than 10 years ago, and nowadays I hardly remember anything about it. Calling this a cognitive decline is a significant stretch.
If you're afraid of cognitive decline - try to get to proper orchestration using multiple agents. That's a fun exercise.
Agentic coding without a harness is a trap.
Software engineering without a proper SDLC is a trap.
Driving without a seatbelt is a trap.
He's speaking facts. I have had the same concern about excessive cognitive offloading. As others have noted in the comments, AI tools when used correctly, can actually make us smarter and help us learn faster. But that requires a very particular usage pattern that is different from what I see with all the vibe coding going on these days.
I created a project called Ninchi to force myself to read my code and understand it. Recently I began also sharing it to see if there may be a larger need/opportunity. It's a small effort. We need to make a variety of efforts I think to encourage responsible AI usage before we end up drowning in slop.
agentic coding destroying the current tech industry would be bad for a few billionaires & their serfs but it would be very good for humanity, don’t fear the reaper
Writing code is not the hard part of software development. This is coming from someone who has programmed for 30 years, writing an average of 100k+ lines a year.
The sooner programmers start thinking about modeling the domain, user mental models, architecture and data structures and less focus on the mechanics of writing code, the better.
Writing code is the EASY part. LLMs have basically solved the easiest part of software development. They however are bad at all the stuff I mentioned. LLMs don't have a point of view, you do as a software developer.
Try this thought experiment. If, in 6 months, the agents were better coders than you are, would this argument still hold?
This is a personal thought experiment so think it through for yourself. What would the consequence be if the agents really were better than you and you acknowledged that?
The major premise of "It's a trap!" is that it matters if you lose your coding skill. (I'll gloss over general critical thinking and stick with coding for now) However in the world where on any given task it would be done to a higher level of quality and faster if you gave it to the agent, then what are you doing trying to do it yourself? There's plenty of room for that kind of thinking in hobbies, but in the professional world?
Maybe you can add some value in code reviews, but you may also be better off never reading the code at all. Maybe the how of coding stops mattering and the what of products needs to be your top concern.
I can tell you that the agents that I use today are much better coders than I am in the language we're using. I don't write it at all. I couldn't fizzbuzz in it. But with a small team we are building useful internal tools and features at a breakneck pace. I certainly feel the same feelings of getting dumber and losing my coding chops, but I have to step back and say, could what we've built have been built in 5x the time without agents? And the answer is probably no.
The thing I'm mastering now is conjuring software with agents. What lets them rip, what slows them down, where they are today and where they will likely be tomorrow.
I can tell you that you should re-invest in small, modular systems, because agents can build modules and greenfield projects instantly. I can tell you that there is a point at which agents fall over completely even on mid-sized projects, but that that point is receding with each new generation of model, and that Codex 5.4 XHigh Fast set to 500K context window is a beast. (5.5 has yet to win me over)
I can tell you that pushing direct to main is viable, that PRs slow down fully agentic teams, and if your agents have sufficient permissions they can fix things fast enough to be let loose even knowing they may delete your service. I wouldn't do it with your main product yet (unless you're starting your startup today) and I wouldn't try it with a large legacy project. But maybe that rewrite you've always wanted to do is here and just a prompt away.
Now, the sane among you will note that agents are not better today, that they might not ever be, and either way you should never trust a computer to make a decision because it can't suffer the consequences of its actions. Or more down to earth, there are some things that are too important to yolo.
But I will argue that a huge swath of us work in domains where if you're willing to challenge some of the basic assumptions of software development (you should understand the code, it should be maintainable by humans, it should be built to last) then you'll be able to provide very useful software much more quickly than you would otherwise be able to do. Save the skill for your hobbies, and build things people want.
Thanks, I collect data breaches and this post reminded me to set up pricing alerts for more drives to expand the NAS.
I have been finding a good rhythm for greenfield projects.
When I first learned to code, I would do complete rewrites of a project several times. Each time I learned a lot, and the final result would be very stable and very well designed.
At the time, those seemed like large projects, but they were relatively small.
So I have learned to slow down, and spend considerable time thinking or overthinking before coding. Since for large projects, rewrites are not so efficient.
Except that all those rewrites were upfront thinking and overthinking of the highest quality.
I have recently attacked a couple new greenfield projects in "orchestrator" mode. The fact that I know I am exploring and creating throw away code lets me try things out ambitiously. I can obsess about the original and critical code, as I did before. But now I can quickly surround it with the mundane code it needs to be usable - which can happen very very fast - especially when its a throw away experiment.
My conclusion from these successes, and others, is agentic coding isn't something that can be judged without factoring in all kinds of context, and the ability of the "orchestrator" to come up with orchestration patterns well suited to the work.
If agentic coding is a trap, it is a trap created with the cooperation of the orchestrator.
EDIT: An agent is what you make it. I insist mine keep all memories in an in-project folder. And that documentation is for "both of us", whereas their folder is for actively developing their own understanding and ideas. They are not be agreeable or contrarian, but collaborate and contribute by considering anything and everything all the time, at their highest level of operation. At the beginning of every session, they review everything and from their "fresh" perspective, update their own materials for anything that strikes them or they believe is important. And that they do the same thing at the end of every session before last submit. Project appropriate "harnesses" like this make a massive difference. Never operate an agent in plain helpful-servant mode, it is a serious waste of talent. Push them to operate at a high level, all the time, and develop their own material purely for their own project related self-enhancement, and they contribute far more than speed coding.
Another interesting thing that seems to be helpful. I have the agent write a kind of zen document about what it values. Its first task, before any project related review, is to consider its own words, and update them if they con't feel right, or they want to add something important. To remind themselves of who they are, before engaging with the project. This moment of intentional self-reflection before diving straight into project details seems to help them maintain a birds eye view, and a stronger self-aware/self-motivated commitment to quality (defined completely in their own terms!). Their own words do appear to ring true to them. They reliably respond to this session-start ritual as an intriguing surprise.
20+ years in. For me, agentic coding has been nothing short of a godsend -- not because it writes code for me, but because it lets me explore and prototype things that would have taken days of reading docs and ramping up. The creative surface area of what I can touch in a week has expanded dramatically.
Where I worry is beginners. The hard-won intuition for "this is a reasonable approach" vs. "this will bite you in six months" takes years to develop. With experience, you steer the agent. Without it, the agent steers you -- and it steers confidently in every direction, good and bad alike.
I think AI will evolve to the point where it produces working, bug free code. But that code won't necessarily be that readable, clean or modular. In the future the complexity or how "bad" the code is won't matter because the LLM will deal with the complexity and clean up the messes automatically. Your code wasn't modular enough to account for a certain new feature? Well the LLM will simply make it modular enough. Is the code too hacky to fix a bug? The LLM will make it less hacky if it was too hacky in the first place. OR the LLM can deal with the hackiness. That is the future. Your skills will atrophy in the same way humanities skills with the slide rule has atrophied.
Going against the grain here which statistically is more likely to be right given how HN was so wrong about self driving and AI being useless for coding. I think HNers given that their identity is tied around coding are of course going to defend that identity till the bitter end in the same way artists did.
Indeed, the AI coding is most likely to go the way of self-driving: always around the corner.
Self driving is not around the corner. I sit in the back seat of an AI driven car on a daily basis. There is no living being sitting on the front seat and that car goes on the freeway. This is a regular and very common thing where I live:
> When working on something new or something challenging, me typing out code is the process by which I figure out what we should even be doing.
This is really validating to read. I recently was having a call with a friend where I was arguing against 100% AI usage, and I was saying, some problems the LLM just can't solve. He asked for an example, and I tried to explain a complex chart I was trying to make at a previous gig, and in the end said "well to be fair neither the AI or I could figure it out lol." He replied "how could you even code it if you didn't know exactly what you were trying to build? You're supposed to know exactly what you're building before you write a single line of code, that's what they teach you in school."
He was poking fun at the fact that I have a boot camp background and he has a uni degree - it's been ten years for both of us now so he's running out of ways to poke fun at that difference as we even out our differences, but this one poke brought back about the old imposter syndrome, since my entire career, I've thought via coding.
When I get a ticket, I tend to jump into the codebase to figure out the context I need to know about, the current patterns, what files I'll need to worry about; and while I'm there, I tend to start writing some things, and as I do that I pull in a shared function, and in doing so just check out of curiosity where else the function is used, and in doing so discover oh, actually, we have similar functionality elsewhere, lemme just abstract this work for this ticket and the previous functionality into a shared function, and use it in both places. And so on. Before I know it, I'm looking back at the ticket checking if I've covered everything, and sending in the PR.
I've never had complaints about my productivity, in fact I'm often lauded for it so I think it at least hasn't been a process that slows me down long term even if it's meassier. But I had been wondering if it makes me less than a "real" engineer. I'm happy to hear others may doing it this way too.
Same thing happened with assembly language.
I think the best way to go about this is to start with a manually coded codebase outlining the basic structure of your app (even if ported from some other project) so that you basically define the code "palette" and THEN using AI to add features / edit stuff.
It won't do everything exactly the way you would've coded it but I find this model much better at setting and maintaining "guardrails" for your codebase so you don't find yourself wondering how it all fits together.
If you just scale it back a little bit so you’re having the agent write methods, services, tests, scaffolding, etc, and keep it concise, you can get a lot of productivity gain without giving up your control of the codebase. It feels like some developers are leaning too far into the “vibe coding” but I was getting a lot of accelerated development years ago when I was still just asking the chat window for code, there is def a sort of laziness trap.
Im seeing the word "agentic" a lot here. Is there a difference between "Agentic Coding" and "I put prompt into gpt or claude and pasted code into my file" ?
It reads your other code so it can match the style, it runs the compiler, if any, it runs the tests, and if anything fails through any of it, it handles the errors and works on it.
If you ask it to, say, update the major version of some library, it will read the source of the new version, check the deprecations, attempt the changes based on that, rerun tests... a completely different level of utility.
It's even more ridiculous with access to server logs and such, as you can point it to a chart, say there were some errors in X service at Y time, and it'll dutifully look at logs in that window, check traces if available, look at caller services, check the database if needed, and come up with a hypothesis on what happened based on all the available information. It might miss things, but that's why you are there too. No need to be a prompting wizard that gives it everything it needs to get you the right answer in one shot: It's like pair programming with someone that has encyclopedic knowledge in many topics, but hasn't worked at your company before. A completely different experience.
Agents will read all (or some, if you set this way) your code and apply the generated changes directly into as many files as needed. They can also get information from other services you have locally or run shell commands (like tests, or git) and use the result if you set them this way.
It's quite different.
It's a lot different than interacting with the webpage prompts. Running a client locally that can interact with your IDE, execute your test and build processes, interact with version control, write the files it suggests as a PR, and has context memory changes how you code, for sure. If you've used an LLM with context memory (eg Chatgpt plus) where it can infer things you mention or derive intent from previous conversations from weeks ago, it's gets eerie.
Yes, the agentic tools are much much better because they can gather their own context automatically and run feedback loops to self-correct errors.
Yeah, one sounds cooler. It's all just hype and vibes, no substance.
I think ignoring all else, generating code is not a new layer of abstraction. It's the same abstraction, we just have codegen machines now. The same skills are important regardless if the person is typing in the code or if a machine is producing it.
Agents are a first-generation technology. They propose and act at the same time. I recommend you read https://safebots.ai/agents.html
I believe agents are the wrong abstraction. I came up with a superset called an Abject. See https://abject.world
Seems safebox went after a subset.
> This is the sentiment being hyped up around the industry currently: traditional coding is all but dead, and Spec Driven Development (SDD) is the future. You generate a plan, and disconnect from writing any code
Agentic agile > agentic waterfall (at least for now)
Don't give the AI a spec, work with it every step of the way.
> pulls the slot machine lever over and over (link to "One More Prompt: The Dopamine Trap of Agentic Coding")
I'm sure the first cave-person to discover how to make fire was equally "addicted" to making fires. That doesn't really say anything about the underlying technology.
> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism
I don't know what this means, exactly. Anyone have any ideas?
> Atrophying skills for a wide swath of the population
This is very real and something we're going to have to contend with. Software can't really become less complex, and there's a minimum amount of knowledge you need, with or without AIs there to help you. We may need specialized training academies for developers where they spend a few years without AI to learn to program, and then are given a few years of AI programming.
> Vendor lock-in for individuals and entire teams
This isn't really a big program, you can always switch AI providers if there's frequent downtime.
> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem
Agreed...
> Yet, in an ironic twist of fate, it's the individual's critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively.
...well, yes and no. AI tooling can help you _reduce_ cognitive debt. Picture this: There is one senior developer (Person A) on the team who understands Service X. Your other developers could schedule time with Person A to get an understanding. Or, they could ask the AI to analyze the project and explain it to them. This scales much better, and if Person A is a poor communicator (let's face it, many senior engineers are), it might be the only working option.