Not a day goes by that a fellow engineer doesn't text me a screenshot of something stupid an AI did in their codebase. But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
The catch about the "guided" piece is that it requires an already-good engineer. I work with engineers around the world and the skill level varies a lot - AI has not been able to bridge the gap. I am generalizing, but I can see how AI can 10x the work of the typical engineer working in Startups in California. Even your comment about curiosity highlights this. It's the beginning of an even more K-shaped engineering workforce.
Even people who were previously not great engineers, if they are curious and always enjoyed the learning part - they are now supercharged to learn new ways of building, and they are able to try it out, learn from their mistakes at an accelerated pace.
Unfortunately, this group, the curious ones, IMHO is a minority.
I am going to try to put this kindly: it is very glib, and people will find it offensive and obnoxious, to implicitly round off all resistance or skepticism to incuriosity. Perhaps to alienate AI critics even further is the goal, in which case - carry on.
But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"? Is it possible that they are not enthusiastic for the change in the nature of the work? Is it possible they are concerned about "automation complacency" setting in, precisely _because_ of the ratio of "hundreds of times" writing decent code to the one time writing "something stupid", and fear that every once in a while that "something stupid" will slip past them in a way that wipes the entire net gain of AI use? Is it possible that they _don't_ feel that the typical code is "better than most engineers can write"? Is it possible they feel that the "learning" is mostly ephemera - how much "prompt engineering" advice from a year ago still holds today?
You have a choice, and it's easy to label them (us?) as Luddites clinging to the old ways out of fear, stupidity, or "incuriosity". If you really want to understand, or even change some minds, though, please try to ask these people what they're really thinking, and listen.
My feeling is that the code it generates is locally ok, but globally kind of bad. What I mean is, in a diff it looks ok. But when you start comparing it to the surrounding code, there's a pretty big lack of coherency and it'll happily march down a very bad architectural path.
In fairness, this is true of many human developers too.. but they're generally not doing it at a 1000 miles per hour and they theoretically get better at working with your codebase and learn. LLMs will always get worse as your codebase grows, and I just watched a video about how AGENTS.md actually usually results in worse outcomes so it's not like you can just start treating MD files as memory and hope it works out.
I don't think that people who don't want to use these tools or clean old ways are incurious. But I think these developers should face the fact that those skills and those ways they are reticent to give up are more or less obviated at this point. Not in the future, but now. It's just that the adoption of these tools isn't evenly distributed yet.
I think there's a place for thoughtful dialogue around what this means for software engineering, but I don't think that's going to change anything at this point. If developers just don't want to participate in this new world, for whatever reason, I'm not judging them, but also I don't think the genie is going back in the bottle. There will be no movement to organize labor to protect us and there be no deus ex machina that is going to reverse course on this stuff.
It's important to point out that you're the one working hard to define AI critics as a camp/group/class when a stronger argument can be made that we're all in the same camp/group/class. I use agentic LLMs for coding every day and I think that it's incredibly important to maintain a critical lens and be open to changing our minds.
However, history suggests that creating artificial divisions is the first step towards all of the the bad things we claim not to like in this world.
Tech adoption generally moves like Time's Arrow. People who use LLMs aren't geeks who changed; we're just geeks. If you want to get off the train, that's your call. But don't make it an us vs them.
Underlying this and similar arguments is the presumption that the "old way" was perfect. You or your colleagues weren't doing one mistake per 100 successful commits. I have been in an industry for decades, and I can tell you that I do something stupid when writing code manually quite often. The same goes for the people that I work with. So fear that the LLM will make mistakes can't really be the reason. Or if it is the reason, it isn't a reasonable objection.
I read the parent comment as calling the majority of AI users "incurious", and not referring to us who resist AI for whatever reasons. The curious AI users can obtain self-improvement, the incurious ones want money or at least custom software without caring how its made.
I don't want the means of production to be located inside companies that can only exist with a steady bubble of VC dollars. It's perfectly reasonable to try AI or use it sparingly, but not embrace it for reasons that can be articulated. Not relevant to parent commenters point, though. Maybe you are "replying" to the article?
Time and time again that I observe it is the AI skeptic that is not reacting with curiosity. This is almost fundamentally true, as in order to understand a new technology you need to be curious about it; AI will naturally draw people who are curious, because you have to be curious to learn something new.
When I engage with AI skeptics and I "ask these people what they're really thinking, and listen" they say something totally absurd, like GPT 3.5-turbo and Opus 4.6 are interchangeable, or they put into question my ability as an engineer, or that I am a "liar" for claiming that an agent can work for an hour unprompted (something I do virtually every day). This isn't even me picking the worst of it, this is pretty much a typical conversation I have on HN, and you can go through my comment history to verify I have not drawn any hyperbole.
I simply have no need for these things. I am faster, smarter, and I understand more. I syntesize disparate concepts your SoT models could never dream of. Why should I waste the money? I have all that I need up in my brain.
When everyone forgets how to read, I'll be thriving. When everyone is neurotic from prompting-brain, I will be in my emacs, zen and unburdened.
I love that yall have them though, they are kinda fun to mess with. And as long as I can review and reject it, all yalls little generations are acceptable for now.
you make it seem like ai hesitation is a misunderstood fringe position, but it's not. i don't think anyone is confused about why some people are uninterested in ai tooling, but we do think you're wrong and the defensive posturing lines in the sand come off as incredibly uncurious.
> But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"?
I'd argue these are good questions to ask in general, about many topics. That it's an essential skill of an engineer to ask these types of questions.
There's two critical mistake that people often make: 1) thinking there's only one solution to any given problem, and 2) that were there an absolute optima, that they've converged into the optimal region. If you carefully look at many of the problems people routinely argue about you'll find that they often are working under different sets of assumptions. It doesn't matter if it's AI vs non-AI coding (or what mix), Vim vs Emacs vs VSCode, Windows vs Mac vs Linux, or even various political issues (no examples because we all know what will happen if I do, which only illustrates my point). There are no objective answers to these questions, and global optima only have the potential to exist when highly constraining the questions. The assumptions are understood by those you closely with, but that breaks down quickly.
If your objective is to seek truth you have to understand the other side. You have to understand their assumptions and measures. And just like everyone else, these are often not explicitly stated. They're "so obvious" that people might not even know how to explicitly state them!
But if the goal is not to find truth but instead find community, then don't follow this advice. Don't question anything. Just follow and stay in a safe bubble.
We can all talk but it gets confusing. Some people argue to lay out their case and let others attack, seeking truth, updating their views as weaknesses are found. Others are arguing to social signal and strengthen their own beliefs, changing is not an option. And some people argue just because they're addicted to arguing, for the thrill of "winning". Unfortunately these can often look the same, at least from the onset.
Personally, I think this all highlights a challenge with LLMs. One that only exasperates the problem of giving everyone access to all human knowledge. It's difficult you distinguish fact from fiction. I think it's only harder when you have something smooth talking and loves to use jargon. People do their own research all the time and come to wildly wrong conclusions. Not because they didn't try, not because they didn't do hard work, and not because they're specifically dumb; but because it's actually difficult to find truth. It's why you have PhD level domain experts disagree on things in their shared domain. That's usually more nuanced, but that's also at a very high level of expertise.
I am solidly in this "curious" camp. I've read HN for the past 15(?) years. I dropped out of CS and got an art agree instead. My career is elsewhere, but along the way, understanding systems was a hobby.
I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language design, compiler optimization, and open source politics in my free time.
There are many bits of tacit knowledge I don't have. I know I don't have them, because I have that knowledge in other domains. I know that I don't know what I don't know about being a "real engineer."
But I also know what taste is. I know what questions to ask. I know the magic words, and where to look for answers.
For people like me, this feels like an insane golden age. I have no shortage of ideas, and now the only thing I have is a shortage of hands, eyes, and on a good week, tokens.
But that knowledge was never hidden or out of reach. Why not read books, manuals, or take online classes? There is free access to all these things, the only cost is time and energy.
Everyone has tons of ideas. But every good engineer (and scientist) also knows that most of our ideas fall apart when either thinking deeper or trying to implement it (same thing, just mental or not). Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
You think you know what taste is. Have you been cranking on real systems all these years, or have you been on the sidelines armchairing the theoretics? I'm not trying to come across as rude, but it may be unavoidable to some degree when indirect criticism becomes involved. A laboring engineer has precious little choice in the type of systems available on which to work on. Fundamentally, it's all going to be some variant of system to make money for someone else somehow, or system that burns money, but ensures necessary work gets done somehow. That's it. That's the extent of the optimization function as defined by capitalism. Taste, falls by the wayside, compared to whether or not you are in the context of the optimizers who matter, because they're at the center of the capital centralization machine making the primary decisions as to where it gets allocated, is all that matters these days. So you make what they want or you don't get paid. As an Arts person, you should understand that no matter how sublime the piece to the artist, a rumbling belly is all that currently awaits you if your taste does not align with the holders of the fattest purses to lighten. I'm not speaking from a place of contempt here; I have a Philosophy background, and reaching out as one individual of the Humanities to another. We've lost sight of the "why we do things" and let ourselves become enslaved by the balance sheets. The economy was supposed to serve the people, it's now the other way around. All we do is feed more bodies to the wood chipper. Until we wake up from that, not even the desperate hope in the matter of taste will save us. We'll just keep following the capital gradient until we end up selling the world from under ourselves because it's the only thing we have left, and there is only the usual suspects as buyers.
So from my perspective as a professional programmer, my feeling is good on you, like, you're empowered to make things and you're making them. It reminds me of people making PHP sites when the web was young and it was easier to do things.
I think where I get really irritated with the discourse is when people find something that works for them, kinda, and they're like "WELL THIS IS WHAT EVERYONE HAS TO DO NOW!" I wouldn't care if I felt like "oh, just a rando on the internet has a bad opinion", the reason this subject bothers me is words do matter and when enough people are thoughtlessly on the hype train it starts creating a culture shift that creates a lot of harm. And eventually cooler heads prevail, but it can create a lot of problems in the meantime. (Look at the damage crypto did!)
Ok fella. But show me something then. This is all talk.
Personally I have been able to produce a very good output with Grok in relation to a video. However, it was insanely painful and very annoying to produce. In retrospect I would've much preferred to have hired humans.
Not to mention I used about 50 free-trial Grok accounts, so who knows what the costs involved were? Tens of thousands no doubt.
But that's the problem. Something that can be so reliable at times, can also fail miserably at others. I've seen this in myself and colleagues of mine, where LLM use leads to faster burnout and higher cognitive load. You're not just coding anymore, you're thinking about what needs to be done, and then reviewing it as if someone else wrote the code.
LLMs are great for rapid prototyping, boilerplate, that kind of thing. I myself use them daily. But the amount of mistakes Claude makes is not negligible in my experience.
> I've seen this in myself and colleagues of mine, where LLM use leads to faster burnout and higher cognitive load.
This needs more attention. There's a lot of inhumanity in the modern workplace and modern economy, and that needs to be addressed.
AI is being dumped into the society of 2026, which is about extracting as much wealth as possible for the already-wealthy shareholder class. Any wealth, comfort, or security anyone else gets is basically a glitch that "should" be fixed.
AI is an attempt to fix the glitch of having a well-compensated and comfortable knowledge worker class (which includes software engineers). They'd rather have what few they need running hot and burning out, and a mass of idle people ready to take their place for bottom-dollar.
This is a fair observation, and I think it actually reinforces the argument. The burnout you're describing comes from treating AI output as "your code that happens to need review." It's not. It's a hypothesis. Once you reframe it that way, the workflow shifts: you invest more in tests, validation scenarios, acceptance criteria, clear specs. Less time writing code, more time defining what correct looks like. That's not extra work on top of engineering. That is the engineering now. The teams I've seen adapt best are the ones that made this shift explicit: the deliverable isn't the code, it's the proof that the code is right.
This is a fair point. The cognitive load is real. Reviewing AI output is a different kind of exhausting than writing code yourself.
Even when the output is "guided," I don't trust it. I still review every single line. Every statement. I need to understand what the hell is going on before it goes anywhere. That's non-negotiable. I think it gets better as you build tighter feedback loops and better testing around it, but I won't pretend it's effortless.
One issue is that developers have been trained for the past few decades to look for solutions to problems online by just dumping a few relevant keywords into Google. But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).
> the ability to formulate your thoughts in a clear manner, have become essential skills for engineering
<Insert astronauts meme “Always has been”>
The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.
And
Some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.
Dijkstra (1976-79) On the foolishness of "natural language programming" (EWD 667)
> But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).
That's probably why spec driven development has taken off.
The developers who can't write prompts now get AI to help with their English, and with clarifying their thoughts, so that other AI can help write their code.
You are correct. You absolutely must fill the token space with unanbiguous requirements, or Claude will just get "creative". You don't want the AI to do creative things in the same way you don't want an intern to do the same.
That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.
Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?
Engineers will go back in and fix it when they notice a problem. Or find someone who can. AI will send happy little emoji while it continues to trash your codebase and brings it to a state of total unmaintainability.
I agree on the curiosity part, I have a non CS background but I have learned to program just out of curiosity. This led me to build production applications which companies actually use and this is before the AI era.
Now, with AI I feel like I have an assistant engineer with me who can help me build exciting things.
I'm currently teaching a group of very curious non-technical content creators at one of the firms I consult at. I set up Codex for them, created the repo to have lots of hand-holding built in - and they took off. It's been 4 weeks and we already have 3 internal tools deployed, one of which eliminated the busy work of another team so much that they now have twice the capacity. These are all things 'real' engineers and product managers could have done, but just empowering people to solve their own problems is way faster. Today, several of them came to me and asked me to explain what APIs are (They want to use the google workspace APIs for something)
I wrote out a list of topics/key words to ask AI about and teach themselves. I've already set up the integration in an example app I will give them, and I literally have no idea what they are going to build next, but I'm .. thrilled. Today was the first moment I realized, maybe these are the junior engineers of the future. The fact that they have nontechnical backgrounds is a huge bonus - one has a PhD in Biology, one a masters in writing - they bring so much to the process that a typical engineering team lacks. Thinking of writing up this case study/experience because it's been a highlight of my career.
> But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
Your experience is the exact opposite of mine. I have people constantly telling me how LLMs are perfectly one shotting things. I see it from friend groups, coworkers, and even here on HN. It's also what the big tech companies are often saying too.
I'm sorry, but to say that nobody is talking about success and just concentrating on failure is entirely disingenuous. You claim the group is a minority, yet all evidence points otherwise. The LLM companies wouldn't be so successful if people didn't believe it was useful.
The K-shaped workforce point is sharp and I think you're right. The curious ones are a minority, but they've always been the ones who moved things forward. AI just made the gap more visible :)
Your Codex case study with the content creators is fascinating. A PhD in Biology and a masters in writing building internal tools... that's exactly the kind of thing i meant by "you can learn anything now." I'm surrounded by PhDs and professors at my workplace and I'm genuinely positive about how things are progressing. These are people with deep domain expertise who can now build the tools they need. It's an interesting time. please write that up...
This is my experience too. Also, the ones not striving for simplicity and not architecting end up with giant monsters that are very unstable and very difficult to update or make robust. They usually then look for another engineer to solve their mess. Usually, the easy way for the new engineer is just to architect and then turbo-build with Claude Code. But they are stuck in sunk cost prison with their mess and can't let it go :(
I have LLMs write code all day almost every day and these days I really haven't seen this happen. The odd thing here and there (e.g. LLM finds two instances of the same error path in code, decides to emit a log message in one place and throw an exception in the other place) but nothing just plain out wrong recently.
Maybe. The reality of software engineering is that there's a lot of mediocre developers on the market and a lot of mediocre code being written; that's part of the industry, and the jobs of engineers working with other engineers and/or LLMs is that of quality control, through e.g. static analysis, code reviews, teaching, studying, etc.
The "most engineers" not "most engineers we've hired".
But also "most engineers" aren't very good. AIs know tricks that the average "I write code for my dayjob" person doesn't know or frankly won't bother to learn.
>But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write.
Are you serious? I've been hearing this constantly. since mid 2025.
The gaslighting over AI is really something else.
Ive also never seen jobs advertised before whose job was to lobby skeptical engineers over about how to engage in technical work. This is entirely new. There is a priesthood developing over this.
I wrote code by hand for 20 years. Now I use AI for nearly all code. I just can’t compete in speed and thoroughness. As the post says, you must guide the AI still. But if you think you can continue working without AI in a competitive industry, I am absolutely sure you will eventually have a very bad time.
They will never admit it, but many are scared of losing their jobs.
This threat, while not yet realized, is very real from a strictly economic perspective.
AI or not, any tool that improves productivity can lead to workforce reduction.
Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
You have a choice: fire 5 people, or produce 2,000 loaves per month. But does the city really need that many loaves?
To make matters worse, all your competitors also have the same semi-automatic ovens...
> Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
That is actually the case with a lot of bakeries these days. But the one major difference being,the baker can rely with almost 100% reliability that the form, shape and ingredients used will be exact to the rounding error. Each time. No matter how many times they use the oven. And they don't have to invent strategies on how to "best use the ovens", they don't claim to "vibe-bake" 10x more than what they used to bake before etc... The semi-automated ovens just effing work!
Now show me an LLM that even remotely provides this kind of experience.
Eh accuracy and reliability is a different topic hashed out many times on HN. This thread is about productivity. I’m a staff engineer and I don’t know a single person not using AI. My senior engineers are estimating 40% gains in productivity.
A bit simplistic. The bakery can just expand its product range or do various other things to add work. In fact that's exactly what I would expect to happen at a tech company, ceteris paribus.
This is what I find interesting - the response from most companies is "we will need fewer engineers because of AI", not "we can build more things because of AI".
What is driving companies to want to get rid of people, rather than do more? Is it just short-term investor-driven thinking?
On another note, if you had 100 engineers and you lay almost all of them off and keep 5 super-AI-accelerated engineers, and your competitor keeps 50 of such engineers, your competitor is still able to iterate 10x as fast. So you still lay people off at the risk of falling behind.
Writing software isn't like a small bakery with fixed demand. There are always more features to build and improvements to do than capacity allows. For better or worse software products are never finished.
I'm starting to think for software it's produce 2,000 loaves per month. I'm realizing now software was supply-constrained and organizations had to be very strategic about what apps/UIs to build. Now everything and anything can be an app and so we can build more targeted frontends for all kinds of business units that would've been overlooked before.
It’s kind of funny seeing all the AI hype guys talking about their 10 OpenClaw instances all running doing work and when you ask what it is, you can never get a straight answer..
For the record though, I love agentic coding. It deals with the accumulated cruft of software for me.
If execution no longer matters, then what possible ideas exist out there that both are highly valuable as well as only valuable to the first mover? If the second person to see the value in the idea can execute it in a weekend using AI tools, what value is there in the idea to begin with?
In fact the second mover advantage seems to me to be even larger than before. Let someone else get the first version out the door, then you just point your AI bot at the resulting product to copy it in a fraction of the time it took the original person to execute on it.
If anything, ideas seem to be even cheaper to me in this new world. It probably just moves what bits of execution matter even more towards sales and marketing and hype vs. executing on the actual product itself.
I think there might be some interesting spaces here opening up in the IP combined with "physical product" space. Where you need the idea as well as real-world practical manufacturing skills in order to execute. That will still be somewhat of a moat for a little while at least, but mostly at a scale where it's not worth an actual manufacturer from China to spin up a production line to compete with you at scale.
Eventually you will have to tell people what the idea is, even if it is at product launch. And then, if execution is as cheap and easy as they claim, then anyone can replicate the idea without having to engage with the person in the first place.
While that’s theoretically correct, as soon as your idea is a product, that’s done deal now everyone can just execute at a stupid speed.
You might get head start but just like a bicycle race the one behind you will be more efficient because you already solved the domain problems and figured out the UX.
Fair enough. I know how that reads. But when anyone with a laptop and a subscription can ship production software in a weekend, the architecture and the idea start to matter a lot more. The technical details in the post are real. I just can't share the what yet. Take it or leave it.
This has been a fallacy for as long as businesses have been built, and it will still be a fallacy in the AI era.
Ideas are cheap and don't need to be protected. Your taste, execution, marketing, UX, support, and all the 1000 things that aren't the code still matter. The code will appear more quickly now: You still need to get people to use it or care about it.
I've found almost without fail that you have more to gain in sharing an idea and getting feedback (both positive and negative) before/while you build the thing than you do in protecting the idea with the fear that as soon as someone hears it they'll steal it and do it better than you.
(The exception I think is in highly competitive spaces where ideas have only a short lifetime -- eg High Frequency Trading / Wall Street in general. An idea for a trade can be worth $$ if done before someone else figures it out, and then it makes sense to protect the idea so you can make use of it first. But that's an extremely narrow domain.)
I've heard this a thousand times and I have not once seen a person give an example of this actually happening. I'm more likely to believe the crocodiles coming out of sewer pipes urban legend at this point.
I understand your concern. The copycat problem is real.
But if you come from a technical background and this is your first time building a product, you'll soon learn that it is so damn hard to get users, especially *paying* ones.
I was there. I built something, shared it, prayed people would notice. The truth is most of the time your product fails. Better explore the problem you are trying to solve first, share your idea if necessary, and collect feedback. You'll have a much clearer picture of what you need to do from there.
I don't think it's about ideas or even the code. It's about execution, marketing, talking to your customers and doing sales. This is something AI can't do...yet
"You can learn anything now. I mean anything." This was true before before LLMs. What's changed is how much work it is to get an "answer". If the LLM hands you that answer, you've foregone learning that you might otherwise have gotten by (painfully) working out the answer yourself. There is a trade-off: getting an answer now versus learning for the future. I recently used an LLM to translate a Linux program to Windows because I wanted the program Right Now and decided that was more important than learning those Windows APIs. But I did give up a learning opportunity.
I'm conflicted about this. On one hand, I think LLMs make it easier to discover explanations that, at least superficially, superficially "click" for you. Sure, they were available before, but maybe in textbooks you needed to pay for (how quaint), or on websites that appeared on the fifth page of search results. Whatever are the externalities of that, in the short term, that part may be a net positive for learners.
On the other hand, learning is doing; if it's not at least a tiny bit hard, it's probably not learning. This is not strictly an LLM problem; it's the same issue I have with YouTube educators. You can watch dazzling visualizations of problems in mathematics or physics, and it feels like you're learning, but you're probably not walking away from that any wiser because you have not flexed any problem-solving muscles and have not built that muscle memory.
I had multiple interactions like that. Someone asked an LLM for an ELI5 and tried to leverage that in a conversation, and... the abstraction they came back feels profound to them, but is useless and wrong.
This. I feel this all the time. I love 3Blue1Brown's videos and when I watch them I feel like I really get a concept. But I don't retain it as well as I do things I learned in school.
It's possible my brain is not as elastic now in my 40s. Or maybe there's no substitute for doing something yourself (practice problems) and that's the missing part.
One factor in favor of the use of LLM as a learning tool is the poor quality of documentation. It seems we've forgotten how to write usable explanations that help readers to build a coherent model of the topic at hand.
> On one hand, I think LLMs make it easier to discover explanations that, at least superficially, superficially "click" for you.
The other benefit is that LLMs, for superficial topics, are the most patient teachers ever.
I can ask it to explain a concept multiple times, hoping that it'll eventually click for me, and not be worried that I'd look stupid, or that it'll be annoyed or lose patience.
It always comes down to economics and then the person and their attitude towards themselves.
Some things are worth learning deeply, in other cases the easy / fast solution is what the situation calls for.
I've thought recently that some kinds of 'learning' with AI are not really that different from using Cliffs Notes back in the day. Sometimes getting the Cliffs Notes summary was the way to get a paper done OR a way to quickly get through a boring/challenging book (Scarlet Letter, amirite?). And in some cases reading the summary is actually better than the book itself.
BUT - I think everyone could agree that if you ONLY read Cliffs Notes, you're just cheating yourself out of an education.
That's a different and deeper issue because some people simply do not care to invest in themselves. They want to do minimum work for maximum money and then go "enjoy themselves."
Getting a person to take an interest in themselves, in their own growth and development, to invite curiosity, that's a timeless problem.
So I've actually been putting more effort into deliberate practice since I started using AI in programming.
I've been a fan of Zed Shaw's method for years, of typing out interesting programs by hand. But I've been appreciating it even more now, as a way to stave off the feeling of my brain melting :)
The gross feeling I have if I go for too long without doing cardio, is a similar feeling to when I go for too long without actually writing a substantial amount of code myself.
I think that the feeling of making a sustained effort is itself something necessary and healthy, and rapidly disappearing from the world.
I’ve always like the essential/accidental complexity split. It can be hard to find, but for a problem solving perspective, it may defines what’s fun and what’s a chore.
I’ve been reading the OpenBSD lately and it’s quite nice how they’ve split the general OS concepts from the machine dependent needs. And the general way they’ve separated interfaces and implementation.
I believe that once you’ve solve the essential problem, the rest becomes way easier as you got a direction. But doing accidental problem solving without having done the essential one is pure misery.
That's not what the author means. Multiple times a day, I have conversations with LLMs about specific code or general technologies. It is very similar to having the same conversation with a colleague. Yes, the LLM may be wrong. Which is why I'm constantly looking at the code myself to see if the explanation makes sense, or finding external docs to see if the concepts check out.
Importantly, the LLM is not writing code for me. It's explaining things, and I'm coming away with verifiable facts and conceptual frameworks I can apply to my work.
Yeah, it's a great way for me to reduce activation energy to get started on a specific topic. Certainly doesn't get me all the way home, but cracks it open enough to get started.
I've managed to go my whole career using regex and never fully grokking it, and now I finally feel free to never learn!
I've also wanted to play with C and Raylib for a long time and now I'm confident in coding by hand and struggling with it, I just use LLMs as a backstop for when I get frustrated, like a TA during lab hours.
I am beginning to disagree with this, or at least I am beginning to question its universal truth. For instance, there are so many times when "learning" is an exercise at attempting to apply wrong advice many times until something finally succeeds.
For instance, retrieving the absolute path an Angular app is running at in a way that is safe both on the client and in SSR contexts has a very clear answer, but there are a myriad of wrong ways people accomplish that task before they stumble upon the Location injectable.
In cases like the above, the LLM is often able to tell you not only the correct answer the first time (which means a lot less "noise" in the process trying to teach you wrong things) but also is often able to explain how the answer applies in a way that teaches me something I'd never have learned otherwise.
We have spent the last 3 decades refining what it means to "learn" into buckets that held a lot of truth as long as the search engine was our interface to learning (and before that, reading textbooks). Some of this rhetoric begins to sound like "seniority" at a union job or some similar form of gatekeeping.
That said, there are also absolutely times (and sometimes it's not always clear that a particular example is one of those times!!) when learning something the "long" way builds our long term/muscle memory or expands our understanding in a valuable way.
And this is where using LLMs is still a difficult choice for me. I think it's less difficult a choice for those with more experience, since we can more confidently distinguish between the two, but I no longer think learning/accomplishing things via the LLM is always a self-damaging route.
Is this maybe more about the quality of the documentation? I say this 'cause my thinking is that reading is reading, it takes the same time to read the information.
How is this faster than just reading the documentation? Given that LLMs hallucinate, you have to double check everything it says against the docs anyway
I don't know, most shit I learned programming (and subsequently get paid for) is meaningless arcana. For example, Kubernetes. And for you, it's Windows APIs.
For programming in general, most learning is worthless. This is where I disagree with you. If you belong to a certain set of cultures, you overindex on this idea that math (for example) is the best way to solve problems, that you must learn all this stuff by this certain pedagogy, and that the people who are best at this are the best at solving problems, which of course is not true. This is why we have politics, and why we have great politicians who hail from cultures that are underrepresented in high levels of math study, because getting elected and having popular ideas and convincing people is the best way to solve way more problems people actually have than math. This isn't to say that procedural thinking isn't valuable. It's just that, well, jokes on you. ChatGPT will lose elections. But you can have it do procedural thinking pretty well, and what does the learning and economic order look like now? I reject this form of generalization, but there is tremendous schadenfreude about, well the math people are destroying their own relevance.
All that said, my actual expertise, people don't pay for. Nobody pays for good game design or art direction (my field). They pay because you know Unity and they don't. They can't tell (and do not pay for) the difference between a good and bad game.
Another way of stating this for the average CRUD developer is, most enterprise IT projects fail, so yeah, the learning didn't really matter anyway. It's not useful to learn how to deliver better failed enterprise IT project, other than to make money.
One more POV: the effortlessness of agentic programming makes me more sympathetic to anti intellectualism. Most people do not want to learn anything, including people at fancy colleges, including your bosses and your customers, though many fewer in the academic category than say in the corporate world. If you told me, a chatbot could achieve in hours what would take a world expert days or weeks, I would wisely spend more time playing with my kids and just wait. The waiters are winning. Even in game development (cultural product development generally). It's better to wait for these tools to get more powerful than to learn meaningless arcana.
I do disagree with the notion that you have to slog through a problem to learn efficiently. That it's either "the easy way [bad, you dont learn] or the hard way [good you do learn]" is a false dichotomy. Agents / LLMs are like having an always-on, highly adept teacher who can synthesize information in an intuitive way, and that you can explore a topic with. That's extremely efficient and effective for learning. There is maybe a tradeoff somewhat in some things, but this idea that LLMs make you not learn doesn't feel right; they allow you to learn _as much as you want and about the things that you want_, which wasn't before. You had to learn, inefficiently(!), a bunch of crap you didn't want to in order to learn the thing you _did_ want to. I will not miss those days.
I don't think your saying the same thing. Ai can help you get through the hard stuff effeciently and you'll learn. It acts as a guide, but you still do the work.
Offloading completely the hard work and just getting a summary isn't really learning.
I am running local offline small models in the old fashioned REPL style, without any agentic features. One prompt at a time.
Instead of asking for answers, I ask for specific files to read or specific command line tools with specific options. I pipe the results to a file and then load it into the CLI session. Then I turn these commands into my own scripts and documentation (in Makefile).
I forbid the model wandering around to give me tons of irrelevant markdown text or generated scripts.
I ask straight questions and look for straight answers.
One line at a time, one file at a time.
This gives me plenty of room to think what I want and how I get what I want.
Learning what we want and what we need to do to achieve it is the precious learning experience that we don’t want to offload to the machine.
> I ask straight questions and look for straight answers. One line at a time, one file at a time.
I've also taken to using the Socratic Method when interrogating an LLM. No loaded questions, squeaky clean session/context, no language that is easy to misinterpret. This has worked well for me. The information I need is in there, I just need to coax it back out.
I did exactly this for an exercise a while back. I wanted to learn Rust while coding a project and AI was invaluable for accelerating my learning. I needed to know completely off-the-wall things that involved translating idioms and practices from other languages. I also needed to know more about Rust idoms to solve specific problems and coding patterns. So I carefully asked these things, one at a time, rather than have it write the solution for me. I saved weeks if not months on that activity, and I'm at least dangerous at Rust now (still learning).
This. I'm also using an LLM very similarly and treat it like a knowledgeable co-worker I can ask for an advice or check something. I want to be the one applying changes to my codebase and then running the tests. Ok, agents may improve the efficiency but it's a slippery slope. I don't want to sit here all day watching the agents modify and re-modify my codebase, I want to do this myself because it's still fun though not as much fun as it was pre-AI
Strangely we never hear gushing pieces on how great gcc is. If you have to advertise that much or recruit people with AI mania, perhaps your product isn't that great.
I'm glad I am no longer in tech because I just don't want to do this.
This is not a dig at AI. If I take this article at face value, AI makes people more productive, assuming they have the taste and knowledge to steer their agents properly. And that's possibly a good thing even though it might have temporary negative side effects for the economy.
>But the AI is writing the traversal logic, the hashing layers, the watcher loops,
But unfortunately that's the stuff I like doing. And also I like communing with the computer: I don't want to delegate that to an agent (of course, like many engineers I put more and more layers between me and the computer, going from assembly to C to Java to Scala, but this seems like a bigger leap).
I'm a developer who was made redundant, and I'm now casting around for an entirely new job because, likewise, I have no interest in working with AI. It sounds boring, and the concept squicks me out, to be honest.
I work in tech, and I think the worst part is seeing all the pieces of catastrophe that have had to come together to make AI dominate
There's several factors which are super depressing:
1. Economic productivity, and what it means for a company to be successful have become detached from producing good high quality products. The stock market is the endgame now
2. AI is attempting to strongly reject the notion that developers understanding their code is good. This is objectively wrong, but its an intangible skill that makes developers hard to replace, which is why management is so desperate for it
3. Developers had too much individual power, and AI feels like a modern attempt at busting the power of the workforce rather than a genuine attempt at a productivity increase
4. It has always been possible to trade long term productivity for short term gains. Being a senior developer means understanding this tradeoff, and resisting management pressure to push something out NOW that will screw you over later
5. The only way AI saves time in the long term is if you don't review its output to understand it as well as if you'd written it yourself. Understanding the code, and the large scale architecture is critical. Its a negative time savings if you want to write high-long-term-productivity code, because we've introduced an extra step
6. Many developers simply do not care about writing good code unfortunately, you just crank out any ol' crap. As long as you don't get fired, you're doing your job well enough. Who cares about making a product anymore, it doesn't matter. AI lets you do a bad job with much less effort than before
7. None of this is working. AI is not causing projects to get pushed out faster. There are no good high quality AI projects. The quality of code is going down, not up. Open source software is getting screwed
Its an extension of the culture where performance doesn't matter. Windows is all made of react components which are each individually a web browser, because the quality of the end product no longer matters anymore. Software just becomes shittier, because none of these companies actually care about their products. AAA gaming is a good example of this, as is windows, discord, anything google makes, IBM, Intel, AMD's software etc
A lot of this is a US problem, because of the economic conditions over there and the prevalence of insane venture capitalism and union busting. I have a feeling that as the EU gets more independent and starts to become a software competitor, the US tech market is going to absolutely implode
Readit News
The catch about the "guided" piece is that it requires an already-good engineer. I work with engineers around the world and the skill level varies a lot - AI has not been able to bridge the gap. I am generalizing, but I can see how AI can 10x the work of the typical engineer working in Startups in California. Even your comment about curiosity highlights this. It's the beginning of an even more K-shaped engineering workforce.
Even people who were previously not great engineers, if they are curious and always enjoyed the learning part - they are now supercharged to learn new ways of building, and they are able to try it out, learn from their mistakes at an accelerated pace.
Unfortunately, this group, the curious ones, IMHO is a minority.
But if you are genuinely confused by the attitudes of your peers, try asking not "what do I have that they lack" ("curiosity"?) but "what do they see that I don't" or "what do they care about that I don't"? Is it possible that they are not enthusiastic for the change in the nature of the work? Is it possible they are concerned about "automation complacency" setting in, precisely _because_ of the ratio of "hundreds of times" writing decent code to the one time writing "something stupid", and fear that every once in a while that "something stupid" will slip past them in a way that wipes the entire net gain of AI use? Is it possible that they _don't_ feel that the typical code is "better than most engineers can write"? Is it possible they feel that the "learning" is mostly ephemera - how much "prompt engineering" advice from a year ago still holds today?
You have a choice, and it's easy to label them (us?) as Luddites clinging to the old ways out of fear, stupidity, or "incuriosity". If you really want to understand, or even change some minds, though, please try to ask these people what they're really thinking, and listen.
In fairness, this is true of many human developers too.. but they're generally not doing it at a 1000 miles per hour and they theoretically get better at working with your codebase and learn. LLMs will always get worse as your codebase grows, and I just watched a video about how AGENTS.md actually usually results in worse outcomes so it's not like you can just start treating MD files as memory and hope it works out.
I think there's a place for thoughtful dialogue around what this means for software engineering, but I don't think that's going to change anything at this point. If developers just don't want to participate in this new world, for whatever reason, I'm not judging them, but also I don't think the genie is going back in the bottle. There will be no movement to organize labor to protect us and there be no deus ex machina that is going to reverse course on this stuff.
However, history suggests that creating artificial divisions is the first step towards all of the the bad things we claim not to like in this world.
Tech adoption generally moves like Time's Arrow. People who use LLMs aren't geeks who changed; we're just geeks. If you want to get off the train, that's your call. But don't make it an us vs them.
I don't want the means of production to be located inside companies that can only exist with a steady bubble of VC dollars. It's perfectly reasonable to try AI or use it sparingly, but not embrace it for reasons that can be articulated. Not relevant to parent commenters point, though. Maybe you are "replying" to the article?
When I engage with AI skeptics and I "ask these people what they're really thinking, and listen" they say something totally absurd, like GPT 3.5-turbo and Opus 4.6 are interchangeable, or they put into question my ability as an engineer, or that I am a "liar" for claiming that an agent can work for an hour unprompted (something I do virtually every day). This isn't even me picking the worst of it, this is pretty much a typical conversation I have on HN, and you can go through my comment history to verify I have not drawn any hyperbole.
When everyone forgets how to read, I'll be thriving. When everyone is neurotic from prompting-brain, I will be in my emacs, zen and unburdened.
I love that yall have them though, they are kinda fun to mess with. And as long as I can review and reject it, all yalls little generations are acceptable for now.
There's two critical mistake that people often make: 1) thinking there's only one solution to any given problem, and 2) that were there an absolute optima, that they've converged into the optimal region. If you carefully look at many of the problems people routinely argue about you'll find that they often are working under different sets of assumptions. It doesn't matter if it's AI vs non-AI coding (or what mix), Vim vs Emacs vs VSCode, Windows vs Mac vs Linux, or even various political issues (no examples because we all know what will happen if I do, which only illustrates my point). There are no objective answers to these questions, and global optima only have the potential to exist when highly constraining the questions. The assumptions are understood by those you closely with, but that breaks down quickly.
If your objective is to seek truth you have to understand the other side. You have to understand their assumptions and measures. And just like everyone else, these are often not explicitly stated. They're "so obvious" that people might not even know how to explicitly state them!
But if the goal is not to find truth but instead find community, then don't follow this advice. Don't question anything. Just follow and stay in a safe bubble.
We can all talk but it gets confusing. Some people argue to lay out their case and let others attack, seeking truth, updating their views as weaknesses are found. Others are arguing to social signal and strengthen their own beliefs, changing is not an option. And some people argue just because they're addicted to arguing, for the thrill of "winning". Unfortunately these can often look the same, at least from the onset.
Personally, I think this all highlights a challenge with LLMs. One that only exasperates the problem of giving everyone access to all human knowledge. It's difficult you distinguish fact from fiction. I think it's only harder when you have something smooth talking and loves to use jargon. People do their own research all the time and come to wildly wrong conclusions. Not because they didn't try, not because they didn't do hard work, and not because they're specifically dumb; but because it's actually difficult to find truth. It's why you have PhD level domain experts disagree on things in their shared domain. That's usually more nuanced, but that's also at a very high level of expertise.
I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language design, compiler optimization, and open source politics in my free time.
There are many bits of tacit knowledge I don't have. I know I don't have them, because I have that knowledge in other domains. I know that I don't know what I don't know about being a "real engineer."
But I also know what taste is. I know what questions to ask. I know the magic words, and where to look for answers.
For people like me, this feels like an insane golden age. I have no shortage of ideas, and now the only thing I have is a shortage of hands, eyes, and on a good week, tokens.
Everyone has tons of ideas. But every good engineer (and scientist) also knows that most of our ideas fall apart when either thinking deeper or trying to implement it (same thing, just mental or not). Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.
The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.
I think where I get really irritated with the discourse is when people find something that works for them, kinda, and they're like "WELL THIS IS WHAT EVERYONE HAS TO DO NOW!" I wouldn't care if I felt like "oh, just a rando on the internet has a bad opinion", the reason this subject bothers me is words do matter and when enough people are thoughtlessly on the hype train it starts creating a culture shift that creates a lot of harm. And eventually cooler heads prevail, but it can create a lot of problems in the meantime. (Look at the damage crypto did!)
Personally I have been able to produce a very good output with Grok in relation to a video. However, it was insanely painful and very annoying to produce. In retrospect I would've much preferred to have hired humans.
Not to mention I used about 50 free-trial Grok accounts, so who knows what the costs involved were? Tens of thousands no doubt.
Dead Comment
LLMs are great for rapid prototyping, boilerplate, that kind of thing. I myself use them daily. But the amount of mistakes Claude makes is not negligible in my experience.
This needs more attention. There's a lot of inhumanity in the modern workplace and modern economy, and that needs to be addressed.
AI is being dumped into the society of 2026, which is about extracting as much wealth as possible for the already-wealthy shareholder class. Any wealth, comfort, or security anyone else gets is basically a glitch that "should" be fixed.
AI is an attempt to fix the glitch of having a well-compensated and comfortable knowledge worker class (which includes software engineers). They'd rather have what few they need running hot and burning out, and a mass of idle people ready to take their place for bottom-dollar.
Even when the output is "guided," I don't trust it. I still review every single line. Every statement. I need to understand what the hell is going on before it goes anywhere. That's non-negotiable. I think it gets better as you build tighter feedback loops and better testing around it, but I won't pretend it's effortless.
But that won't generate the returns Model producers need :) This is the issue. So they will keep pushing nonsense.
<Insert astronauts meme “Always has been”>
Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.And
Dijkstra (1976-79) On the foolishness of "natural language programming" (EWD 667)That's probably why spec driven development has taken off.
The developers who can't write prompts now get AI to help with their English, and with clarifying their thoughts, so that other AI can help write their code.
That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.
Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?
Because the instances of this happening are a) random and b) rarely ever happening ?
Now, with AI I feel like I have an assistant engineer with me who can help me build exciting things.
I wrote out a list of topics/key words to ask AI about and teach themselves. I've already set up the integration in an example app I will give them, and I literally have no idea what they are going to build next, but I'm .. thrilled. Today was the first moment I realized, maybe these are the junior engineers of the future. The fact that they have nontechnical backgrounds is a huge bonus - one has a PhD in Biology, one a masters in writing - they bring so much to the process that a typical engineering team lacks. Thinking of writing up this case study/experience because it's been a highlight of my career.
I'm sorry, but to say that nobody is talking about success and just concentrating on failure is entirely disingenuous. You claim the group is a minority, yet all evidence points otherwise. The LLM companies wouldn't be so successful if people didn't believe it was useful.
Your Codex case study with the content creators is fascinating. A PhD in Biology and a masters in writing building internal tools... that's exactly the kind of thing i meant by "you can learn anything now." I'm surrounded by PhDs and professors at my workplace and I'm genuinely positive about how things are progressing. These are people with deep domain expertise who can now build the tools they need. It's an interesting time. please write that up...
I have LLMs write code all day almost every day and these days I really haven't seen this happen. The odd thing here and there (e.g. LLM finds two instances of the same error path in code, decides to emit a log message in one place and throw an exception in the other place) but nothing just plain out wrong recently.
It's some cousin of the Fundamental Attribution Error.
Deleted Comment
But also "most engineers" aren't very good. AIs know tricks that the average "I write code for my dayjob" person doesn't know or frankly won't bother to learn.
Are you serious? I've been hearing this constantly. since mid 2025.
The gaslighting over AI is really something else.
Ive also never seen jobs advertised before whose job was to lobby skeptical engineers over about how to engage in technical work. This is entirely new. There is a priesthood developing over this.
Dead Comment
This threat, while not yet realized, is very real from a strictly economic perspective.
AI or not, any tool that improves productivity can lead to workforce reduction.
Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people.
You have a choice: fire 5 people, or produce 2,000 loaves per month. But does the city really need that many loaves?
To make matters worse, all your competitors also have the same semi-automatic ovens...
That is actually the case with a lot of bakeries these days. But the one major difference being,the baker can rely with almost 100% reliability that the form, shape and ingredients used will be exact to the rounding error. Each time. No matter how many times they use the oven. And they don't have to invent strategies on how to "best use the ovens", they don't claim to "vibe-bake" 10x more than what they used to bake before etc... The semi-automated ovens just effing work!
Now show me an LLM that even remotely provides this kind of experience.
What is driving companies to want to get rid of people, rather than do more? Is it just short-term investor-driven thinking?
Where is this expanded demand coming from?
Dead Comment
> If I don’t understand what it’s doing, it doesn’t ship. That’s non-negotiable.
Holy LinkedIn
Hmm, I wonder why!
For the record though, I love agentic coding. It deals with the accumulated cruft of software for me.
And creates more at record speeds!
Personally I'm quite pleased with this inversion.
If execution no longer matters, then what possible ideas exist out there that both are highly valuable as well as only valuable to the first mover? If the second person to see the value in the idea can execute it in a weekend using AI tools, what value is there in the idea to begin with?
In fact the second mover advantage seems to me to be even larger than before. Let someone else get the first version out the door, then you just point your AI bot at the resulting product to copy it in a fraction of the time it took the original person to execute on it.
If anything, ideas seem to be even cheaper to me in this new world. It probably just moves what bits of execution matter even more towards sales and marketing and hype vs. executing on the actual product itself.
I think there might be some interesting spaces here opening up in the IP combined with "physical product" space. Where you need the idea as well as real-world practical manufacturing skills in order to execute. That will still be somewhat of a moat for a little while at least, but mostly at a scale where it's not worth an actual manufacturer from China to spin up a production line to compete with you at scale.
Eventually you will have to tell people what the idea is, even if it is at product launch. And then, if execution is as cheap and easy as they claim, then anyone can replicate the idea without having to engage with the person in the first place.
Ideas will never not be cheap.
You might get head start but just like a bicycle race the one behind you will be more efficient because you already solved the domain problems and figured out the UX.
Deleted Comment
Ideas are cheap and don't need to be protected. Your taste, execution, marketing, UX, support, and all the 1000 things that aren't the code still matter. The code will appear more quickly now: You still need to get people to use it or care about it.
I've found almost without fail that you have more to gain in sharing an idea and getting feedback (both positive and negative) before/while you build the thing than you do in protecting the idea with the fear that as soon as someone hears it they'll steal it and do it better than you.
(The exception I think is in highly competitive spaces where ideas have only a short lifetime -- eg High Frequency Trading / Wall Street in general. An idea for a trade can be worth $$ if done before someone else figures it out, and then it makes sense to protect the idea so you can make use of it first. But that's an extremely narrow domain.)
But if you come from a technical background and this is your first time building a product, you'll soon learn that it is so damn hard to get users, especially *paying* ones.
I was there. I built something, shared it, prayed people would notice. The truth is most of the time your product fails. Better explore the problem you are trying to solve first, share your idea if necessary, and collect feedback. You'll have a much clearer picture of what you need to do from there.
On the other hand, learning is doing; if it's not at least a tiny bit hard, it's probably not learning. This is not strictly an LLM problem; it's the same issue I have with YouTube educators. You can watch dazzling visualizations of problems in mathematics or physics, and it feels like you're learning, but you're probably not walking away from that any wiser because you have not flexed any problem-solving muscles and have not built that muscle memory.
I had multiple interactions like that. Someone asked an LLM for an ELI5 and tried to leverage that in a conversation, and... the abstraction they came back feels profound to them, but is useless and wrong.
It's possible my brain is not as elastic now in my 40s. Or maybe there's no substitute for doing something yourself (practice problems) and that's the missing part.
The other benefit is that LLMs, for superficial topics, are the most patient teachers ever.
I can ask it to explain a concept multiple times, hoping that it'll eventually click for me, and not be worried that I'd look stupid, or that it'll be annoyed or lose patience.
I could not agree more.
Some things are worth learning deeply, in other cases the easy / fast solution is what the situation calls for.
I've thought recently that some kinds of 'learning' with AI are not really that different from using Cliffs Notes back in the day. Sometimes getting the Cliffs Notes summary was the way to get a paper done OR a way to quickly get through a boring/challenging book (Scarlet Letter, amirite?). And in some cases reading the summary is actually better than the book itself.
BUT - I think everyone could agree that if you ONLY read Cliffs Notes, you're just cheating yourself out of an education.
That's a different and deeper issue because some people simply do not care to invest in themselves. They want to do minimum work for maximum money and then go "enjoy themselves."
Getting a person to take an interest in themselves, in their own growth and development, to invite curiosity, that's a timeless problem.
I've been a fan of Zed Shaw's method for years, of typing out interesting programs by hand. But I've been appreciating it even more now, as a way to stave off the feeling of my brain melting :)
The gross feeling I have if I go for too long without doing cardio, is a similar feeling to when I go for too long without actually writing a substantial amount of code myself.
I think that the feeling of making a sustained effort is itself something necessary and healthy, and rapidly disappearing from the world.
I’ve been reading the OpenBSD lately and it’s quite nice how they’ve split the general OS concepts from the machine dependent needs. And the general way they’ve separated interfaces and implementation.
I believe that once you’ve solve the essential problem, the rest becomes way easier as you got a direction. But doing accidental problem solving without having done the essential one is pure misery.
Importantly, the LLM is not writing code for me. It's explaining things, and I'm coming away with verifiable facts and conceptual frameworks I can apply to my work.
Selectively pick and struggle through things you want to learn deeply. And let AI spoon-feed you for things you don't care as much about.
I've also wanted to play with C and Raylib for a long time and now I'm confident in coding by hand and struggling with it, I just use LLMs as a backstop for when I get frustrated, like a TA during lab hours.
For instance, retrieving the absolute path an Angular app is running at in a way that is safe both on the client and in SSR contexts has a very clear answer, but there are a myriad of wrong ways people accomplish that task before they stumble upon the Location injectable.
In cases like the above, the LLM is often able to tell you not only the correct answer the first time (which means a lot less "noise" in the process trying to teach you wrong things) but also is often able to explain how the answer applies in a way that teaches me something I'd never have learned otherwise.
We have spent the last 3 decades refining what it means to "learn" into buckets that held a lot of truth as long as the search engine was our interface to learning (and before that, reading textbooks). Some of this rhetoric begins to sound like "seniority" at a union job or some similar form of gatekeeping.
That said, there are also absolutely times (and sometimes it's not always clear that a particular example is one of those times!!) when learning something the "long" way builds our long term/muscle memory or expands our understanding in a valuable way.
And this is where using LLMs is still a difficult choice for me. I think it's less difficult a choice for those with more experience, since we can more confidently distinguish between the two, but I no longer think learning/accomplishing things via the LLM is always a self-damaging route.
It also gives you an avenue to accelerate your learning if that is your goal.
You could learn the windows APIs much faster if you wanted to learn them
Take it with a grain of salt..
Dead Comment
- Socrates
(I think something like this comes up in the Phaedrus)
For programming in general, most learning is worthless. This is where I disagree with you. If you belong to a certain set of cultures, you overindex on this idea that math (for example) is the best way to solve problems, that you must learn all this stuff by this certain pedagogy, and that the people who are best at this are the best at solving problems, which of course is not true. This is why we have politics, and why we have great politicians who hail from cultures that are underrepresented in high levels of math study, because getting elected and having popular ideas and convincing people is the best way to solve way more problems people actually have than math. This isn't to say that procedural thinking isn't valuable. It's just that, well, jokes on you. ChatGPT will lose elections. But you can have it do procedural thinking pretty well, and what does the learning and economic order look like now? I reject this form of generalization, but there is tremendous schadenfreude about, well the math people are destroying their own relevance.
All that said, my actual expertise, people don't pay for. Nobody pays for good game design or art direction (my field). They pay because you know Unity and they don't. They can't tell (and do not pay for) the difference between a good and bad game.
Another way of stating this for the average CRUD developer is, most enterprise IT projects fail, so yeah, the learning didn't really matter anyway. It's not useful to learn how to deliver better failed enterprise IT project, other than to make money.
One more POV: the effortlessness of agentic programming makes me more sympathetic to anti intellectualism. Most people do not want to learn anything, including people at fancy colleges, including your bosses and your customers, though many fewer in the academic category than say in the corporate world. If you told me, a chatbot could achieve in hours what would take a world expert days or weeks, I would wisely spend more time playing with my kids and just wait. The waiters are winning. Even in game development (cultural product development generally). It's better to wait for these tools to get more powerful than to learn meaningless arcana.
But no amount of politics and charisma will calculate the motions of the planets or put satellites in orbit.
A nation needs more than just influencers and charlatans.
Offloading completely the hard work and just getting a summary isn't really learning.
Instead of asking for answers, I ask for specific files to read or specific command line tools with specific options. I pipe the results to a file and then load it into the CLI session. Then I turn these commands into my own scripts and documentation (in Makefile).
I forbid the model wandering around to give me tons of irrelevant markdown text or generated scripts.
I ask straight questions and look for straight answers. One line at a time, one file at a time.
This gives me plenty of room to think what I want and how I get what I want.
Learning what we want and what we need to do to achieve it is the precious learning experience that we don’t want to offload to the machine.
I've also taken to using the Socratic Method when interrogating an LLM. No loaded questions, squeaky clean session/context, no language that is easy to misinterpret. This has worked well for me. The information I need is in there, I just need to coax it back out.
I did exactly this for an exercise a while back. I wanted to learn Rust while coding a project and AI was invaluable for accelerating my learning. I needed to know completely off-the-wall things that involved translating idioms and practices from other languages. I also needed to know more about Rust idoms to solve specific problems and coding patterns. So I carefully asked these things, one at a time, rather than have it write the solution for me. I saved weeks if not months on that activity, and I'm at least dangerous at Rust now (still learning).
https://gist.github.com/ontouchstart/bc301a60067f687b65dad64...
(This is an ongoing experiment, it doesn't matter what model I use.)
This is not a dig at AI. If I take this article at face value, AI makes people more productive, assuming they have the taste and knowledge to steer their agents properly. And that's possibly a good thing even though it might have temporary negative side effects for the economy.
>But the AI is writing the traversal logic, the hashing layers, the watcher loops,
But unfortunately that's the stuff I like doing. And also I like communing with the computer: I don't want to delegate that to an agent (of course, like many engineers I put more and more layers between me and the computer, going from assembly to C to Java to Scala, but this seems like a bigger leap).
I expect there are going to be a bunch of people in similar situations to you over the next few years, I'm interested to know where they end up.
There's several factors which are super depressing:
1. Economic productivity, and what it means for a company to be successful have become detached from producing good high quality products. The stock market is the endgame now
2. AI is attempting to strongly reject the notion that developers understanding their code is good. This is objectively wrong, but its an intangible skill that makes developers hard to replace, which is why management is so desperate for it
3. Developers had too much individual power, and AI feels like a modern attempt at busting the power of the workforce rather than a genuine attempt at a productivity increase
4. It has always been possible to trade long term productivity for short term gains. Being a senior developer means understanding this tradeoff, and resisting management pressure to push something out NOW that will screw you over later
5. The only way AI saves time in the long term is if you don't review its output to understand it as well as if you'd written it yourself. Understanding the code, and the large scale architecture is critical. Its a negative time savings if you want to write high-long-term-productivity code, because we've introduced an extra step
6. Many developers simply do not care about writing good code unfortunately, you just crank out any ol' crap. As long as you don't get fired, you're doing your job well enough. Who cares about making a product anymore, it doesn't matter. AI lets you do a bad job with much less effort than before
7. None of this is working. AI is not causing projects to get pushed out faster. There are no good high quality AI projects. The quality of code is going down, not up. Open source software is getting screwed
Its an extension of the culture where performance doesn't matter. Windows is all made of react components which are each individually a web browser, because the quality of the end product no longer matters anymore. Software just becomes shittier, because none of these companies actually care about their products. AAA gaming is a good example of this, as is windows, discord, anything google makes, IBM, Intel, AMD's software etc
A lot of this is a US problem, because of the economic conditions over there and the prevalence of insane venture capitalism and union busting. I have a feeling that as the EU gets more independent and starts to become a software competitor, the US tech market is going to absolutely implode
This like how my grandpa said he was glad to get out of engineering before they started using computers.
The technology i used was the fun technology. The technology you use is the un-fun technology.