Every time I read stuff like this I honestly wonder if the author is using the same tools I am. I can have Claude Code bang out everything from boilerplate to a working prototype to a complex algorithm embedded in a very complex and confusing code base. It’s not correct 100% of the time but it’s pretty damn close. And often times it comes up with algorithms I would have never thought of initially. These things are at…
The difficulty is we skeptics have read claims like yours tens of times, and our response is always, "please share a repo built this way and an example of your prompts," and I at least have never seen anyone do so. I'd love for what you say to be possible. Comments like yours often cause me to take another crack at agentic workflows. I'm disappointed every time.
The AI coding trap
311–320 of 424 posts
Re: The AI coding trap
#312Earlier quoted context omitted.
I don't think that is a problem with AI, it is a problem with the idea that pure vibe-coding will replace knowledgeable engineers. While there is a loud contingent that hypes up this idea, it will not survive contact with reality. Purely vibe-coded projects will soon break in unexplainable ways as they grow beyond trivial levels. Once that happens their devs will either need to adapt and learn coding for real or be P…
On vibe coding being self-correcting, I would point to the growing number of companies mandating usage of AI and the quote "the market can stay irrational longer than you can stay solvent". Companies routinely burn millions of dollars on irrational endeavours for years. AI has been promised as an insane productivity booster. I wouldn't expect things to calm down for a while, even if real-life results are worse. You c…
At the same time, I'll also admit that AI resistance is real; we see it in the comments here for various reasons -- job displacement fears, valid complaints about AI reliability, ethical opposition, etc. So there could be a valid need for strong incentives to adopt it.
Unfortunately, AI is also deceptively hard to use effectively (a common refrain of mine.) Ideally AI mandates would come with some structured training tailored for each role, but the fact that this is not happening makes me wonder about either the execs' competency or their motives.
Re: The AI coding trap
#313AI has been insanely helpful for a couple of reasons, but not for writing code.
I discuss my plans with AI and check if I missed out on edge cases I develop to the most common conventions, I ask AI for better naming, ideas for abstractions, to explain me frameworks, find me packages.
But the lease couple of days I’m having sanity problems because there is one AI tool after the other coming up with a new plan on how to use AI efficiently but once you’ve solved a problem is it really much work to type it out?
It shouldn’t be too much code if correctly using orchestration.
It’s almost like all the beautiful conventions and patterns are forgotten.
Good Code is most of the time less code. Yes imho most important is readability or digestibility or even diagnosability like all of these things get completely forgotten when we start talking about AI and I see AI far off in writing such code. Good frameworks and packages will be faster.
AI is a good sparring partner and encyclopaedia especially living in terminal but I just don’t see it should writing a lot of code (except maybe landing pages with css animations) that don’t live in a complex application
Re: The AI coding trap
#314I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…
Though I will also dogpile on the "thankless tasks" remark and say that the stuff that I have AI blast through is very thankless. I do not enjoy changing 20 different files to account for a change in struct definition.
Re: The AI coding trap
#315I think what the article gets at, but doesn't quite deliver on, is similar to this great take from Casey Muratori [1] about how programming with a learning-based mindset means that AI is inherently not useful to you. I personally find AI code gen most useful for one-off throwaway code where I have zero intent to learn. I imagine this means that the opposite end of the spectrum where learning is maximized is one where…
"learning is maximized is one where the AI doesn't generate any code for me" Obviously you have to work to learn, but to me this is a bit like saying learning is maximized when you never talk to anyone or ask for help — too strong.
On the other hand you have AI which, out of the box, seems content to go along with anything and will happily write code for me. And I've never seen it have a single insight on the same level as my teammates. All of which is to say, AI doesn't really feel like something you can properly "ask" something. It's especially far away from that when it's just generating code and nothing else.
Re: The AI coding trap
#316Earlier quoted context omitted.
I don't think that is a problem with AI, it is a problem with the idea that pure vibe-coding will replace knowledgeable engineers. While there is a loud contingent that hypes up this idea, it will not survive contact with reality. Purely vibe-coded projects will soon break in unexplainable ways as they grow beyond trivial levels. Once that happens their devs will either need to adapt and learn coding for real or be P…
> The real problem we should be discussing is, how do we convince students and apprentices to abstain from AI until they learn the ropes for real. Learning the ropes looks different now. You used to learn by doing, now you need to learn by directing. In order to know how to direct well, you have to first be knowledgeable. So, if you're starting work in an unfamiliar technology, then a good starting point is read what…
My current project is in a technical domain I had very little prior background in, but I've been getting actual, visible results since day one because of AI. The amazing thing is that for any task I give it, the AI provides me a very useful overview of the thing it produces, and I have conversations with it if I have further questions. So I'm building domain knowledge incrementally even as I'm making progress on the project!
But I also know that this is only possible because of the pre-existing foundation of my experience as a software engineer. This lets me understand the language the AI uses to explain things, and I can dive deeper if I have questions. It also lets me understand what the code is doing, which lets me catch subtle issues before they compound.
I suppose it's the same with reading books, but books being static tend to give a much broader overview upfront, whereas interacting with LLMs results in a much more focused learning path.
So a foundation is essential, but it can now be much more general -- such as generic coding ability -- but that only comes with extensive hands-on experience. There is at least one preliminary study showing that students who rely on AI do not develop the critical problem solving, coding and debugging skills necessary to be good programmers:
Re: The AI coding trap
#317Earlier quoted context omitted.
I agree that commercially operated LLMs undermine the entire idea of IP, but it is one of the problems with them, not with the concept of intellectual property, which is an approximation of what has been organically part of human society motivating innovation since forever: benefits of being an author and degree of ownership over intangible ideas. When societies were smaller and local, it just worked out and you woul…
> IP is an approximation of what has been organically part of human society and drove innovation since forever: benefits of being an author and degree of ownership over intangible ideas. It is not! It's a very recent invention. Especially its application to creative works contradicts thousands of years of the development of human culture. Consider folk songs. > I doubt anyone would consider it a problem if large-scal…
First, let’s note that creative work includes a lot more than just arts (crucially, invention).
In music, by your logic you may disagree with recognising song composition as IP, but you have to agree that being able to earn royalties from businesses playing your performance (even if it is a cover) serves as a proxy to people coming to listen and express their appreciation to a performer back when audio recording didn’t exist.
Also, let’s distinguish IP in general and its current legal implementation, such as protections lasting longer than author’s life. It should be noted that complexity in art did also grow since then, but it may or may not (I have no strong opinion here) make sense to grant the author post-humous protections.
> you run into different contradicting conclusions about how LLMs should interact with copyright depending on exactly what line of logic you follow, so the courts will never be able to resolve how it should work.
The courts can identify which ways of LLM use follow the spirit of the IP framework, encouraging innovation and creativity. As it is, current commercial LLMs slowly erode it, creating a feeling of “nothing belongs to anyone in particular, so why bother putting in the hard work”, profiting a minority of individuals while harming society over longer term. It is not difficult to see how applying the copyright as is could put an end to this, ensuring authors have control over their work, with the only consequence being slightly worse bottom lines at a handful of corporations with market caps the size of countries.
Re: The AI coding trap
#318Earlier quoted context omitted.
Here we're really arguing about his first chart, which I agree with, and you do not.
I’m not following. It seems straightforward enough, and consistent with both charts, that a dramatic speedup in coding yields a more modest improvement in overall productivity because typing code is a minority of the work. Is your contention here that the LLM not only documents, but accelerates the thinking part too?
Re: The AI coding trap
#319Earlier quoted context omitted.
> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…
> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…
In 1969 as a newly hired graduate working for the largest construction company in the country, one of my first assignments was to read through a badly formatted COBOL source code listing on paper, line by line, with 2 others. Each of us had a printout of a different version of the software, trying to discover where exactly the three versions were giving different outputs. Plus ça change, plus c'est la même chose
Re: The AI coding trap
#320Earlier quoted context omitted.
> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…
> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project. This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing. There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it see…
In my experience, the type of messes created by humans and the type of messes created by genAI are immensely different, and at times require different skill sets to dissect.