For some of us, writing code is a big part of how we think through a problem. It's like playing an instrument—or using a DAW—for a musician; the mundane mechanics, the part you dismiss as a mere means to an end, is the engine that gets us there. If a musician were provided a service by which they didn't have to sit around noodling on the guitar or piano, finding out which melodies or chords sounded good together, but instead just have to tell the service "write me an upbeat pop/rock song, 130 beats per minute, F# major key, emphasis on the drums and electric guitars, and the lyrics should be about a woman named Alice and how the singer longs for her exquisite beauty"—are they really composing? Are they a musician at that point? Or are they a client commissioning music?
Working with AI tools is like trying to eat with silicone rubber chopsticks. You're so removed from the point of contact that you no longer have effective haptic feedback for the problem you're trying to solve. You're not doing the work, you're commissioning and checking someone else's work. It's an entirely different job now.
I appreciate the response and I get it. Something was lost in this transition and you explained it well.
The only pushback I can think of is that I do feel coding, which is a list of instructions to a computer, differ from music. With LLMs the translation work between English and coding primitives and concepts was reduced significantly. I think that took the challenge and the sense of control/mastery out of the craft.
There is something lost in that transition. I remember my university professor used to equate coding with poetry. But after decades of working on corporate codebases, I personally welcomed the automation. I always wanted to build ambitious and quality software and this was nearly impossible with the level of abstraction we had before. So something was lost but also a lot was gained.
Programming is like music in that the act of producing it is itself a medium for thought. Any but the lowest level languages are not just instructions for a computer, they're a formalism for abstract procedures rigorous enough to be executed by computers in a predictable, repeatable way (what you put into an LLM is emphatically NOT this) but expressed in a form that can be reasoned about and shaped readily by humans. If you take away the mundane doing of the thing, you don't just remove the challenge or sense of control, you take away the entire craft.
So it's a bit strange to treat composing program code as something that's incidental or ancillary to what software engineers do. A software engineer solves problems through writing code. If you make the writing of code go away, you're no longer building software. You're a product manager or a systems analyst, delegating the building of the software to someone or something else. If that's what you want to do, go nuts. But say what it is.
What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent? What about codebase architecture? The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products?
Is none of this part of the artistic side of the craft? If I tell an LLM, 'Connect to DB X, pull data from Y, and display it in table Z,' is that really less of a craft than manually referencing API docs, wiring up data pipelines, and serializing objects? Is telling an LLM 'Do X, then Y, then Z' truly that different from writing if X do Y or while X do Z? It reminds me of the pushback against Java and other high-level languages when they were first introduced—people panicked over losing low-level control.
I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English), but to say the entire craft is lost and what we had before was "music" relative to the nothing now, I believe it is a narrow take on what is happening.
> What about product vision? The taste, and the hundreds—if not thousands—of micro-decisions required to build something decent?
That's what Steve Jobs brought to the table. Was Steve Jobs a software or hardware engineer? I would argue no—he was fundamentally doing product design and management. You can argue this is a craft as well, but it's a fundamentally different one from software engineering.
> What about codebase architecture?
LLMs are getting good at this too. Within a few years we may not need humans for this. If you're hoping that "architecture" will be your moat, well, I'm sorry...
> The user experience, and how using the software makes someone feel? What about the narrative and mental models the software offers users? How does it shape the way they think? What about expanding into adjacent, bigger, or deeper products?
Again, these are largely product design concerns. Software engineers can do them, sometimes even well, but they alone do not constitute software engineering.
> Is none of this part of the artistic side of the craft?
You seem to be getting hung up on my music analogy as some sort of "code as art" thing. While I agree that code can be artistic, that's not where I was going with it at all. I mean that in order to compose, a musician usually picks up and plays an instrument, or simply sings in order to play with melodies and harmonies to determine what sounds right. They set up a sort of ear/brain/muscular system feedback loop to shape how a song sounds and feels in real time. If you have them specify what kind of song they want in English, you've cut out that feedback loop. They're not really being a musician anymore, they're commissioning music. They're more of a musical director. It's the same with programmers. Programmers work and think in code. Code becomes a medium of exchange of ideas about procedure between each other, their future selves, and the machine. I learned a lot about this writing Lisp, but even in a stodgy language like Ada, I can get a lot of thinking through of a solution done by writing what types I want to be working with, in Ada. If you take the code away and say "here, specify the program you want in English", you're basically asking the software engineer to stop being a software engineer and start being a product manager or business analyst. Which is fine, you know, maybe we just don't need software engineers anymore.
> I do recognize something is lost by moving to a higher abstraction (e.g. from JS/Java/PHP to English)
No, it's not "just another layer of abstraction". It's fundamentally different. Generally speaking, software abstractions are transparent homomorphisms from the constructs in the language of expression (e.g., Java, PHP) to instructions the computer can execute. How an LLM converts your prompt into code is both opaque and unstable. I get that we're really not supposed to care about that, nor did many people care exactly how the compilers they used work. But with a compiler, if you do care, you can examine it and it'll make sense, or you can write your own. An LLM, not so much really.
Again, you are no longer building the software yourself. You're asking a teammate to. It's just that your teammate exists in silico now. This becomes more true, not less, as LLMs become more capable of the grunt work of, you know, engineering, freeing you for the more important business of stating what you want in vaguer and looser terms. I guess the dream is that we'll all become business founders, with the LLM as our founding engineer, and we can just ask them to build what we think the business needs, and go through them to make refinements and changes.
"I guess the dream is that we'll all become business founders, with the LLM as our founding engineer, and we can just ask them to build what we think the business needs, and go through them to make refinements and changes."
That's pretty much what I'm doing after 20+ years of writing code.
They do feel like teammates sometimes, though I tend to give them much more explicit instructions. It feels less like complete outsourcing and more like declarative programming in English.
Where we differ is that you seem to see code as this rigorous medium of thought that defines the craft, whereas I don't. I've always viewed code as a translation layer between human intent and machine execution. That layer has simply dissolved. Viewing code this way might feel less romantic and more pragmatic, but I think it’s more accurate. You can think, reason, and make decisions just as rigorously in plain English. The skill of translating English into code was what got automated—the true craft lives way above and beyond that layer.
But I don't think I can convince you on HN if you have such a strong views on coding. And I'm left to wonder, how are you feeling about the craft if what you perceiveD as the core activity (I thinking coding was at best 20% of the craft) got fully automated? Have you tried to build a really complex software with LLMs over few months? I think that might give you more clear picture of what truly happened.
Alright - the internet is vast place, and there are many places I wouldn't want to visit.
The internet is growing with some ugly parts - but there are other people generating more interesting content precisely because their abilities are amplified with LLMs.
In other words, maybe we ought to focus on the positive possibilities instead of doom and gloom all day long, we will be all dead in 10 years or the internet will be dead, or I and you will be dead, or my dog will be dead or the universe will expand to cold death, or whatever..
Its a bit sus since there doesn't really seem to be much discourse on this either. Like okay, it solved the puzzle but the puzzle was just a key cipher with plain text? And how is this verified or even matter in terms of what it reveals? Seems more like a marketing fun post than anything susbtantial.
They published this on 31 aug and nobody in that community cared and no news covered how this 300+ years mystery was solved?
I don't think a single person reading or upvoting had ever heard of this extremely obscure cipher until this post hit the front page, it's not "cope" to use basic critical thinking to ask questions like "was this cipher well known" and "were there many attempts to solve it before now"... that's pretty much Information Literacy 101.
I think the point is that rather than YOU finding out the answers to those questions, and post only if the answers were indicative of some "gotcha", someone ALWAYS posts something similar to your OP as a lazy/low-effort way to discredit LLMs.
Right, with the amount of data these models are trained on, somewhere someone may have solved it and it was in some obscure text/page no one looked at or care about. We'll probably never know.
I griefed a bit myself for the effort I put to learn programming, I do enjoy the concepts and theories, it was playground for my mind.
But the way I see it, is that I got a matching partner, that is also very good at programming. And there is a strange sense of excitement when I watch the LLMs struggle were I used to struggle and excel in many other areas I'm poor at.
But I got into coding to build products/software that I can share with others, and this has accelerated, so that is also exciting, I decided to put the money and fear aside and do what I love..build things.
"And if you can do it, people think you're clever, and respect you." - that is the main issue here..personally, in where I come from the work was never respected and also never paid well, so I always did it because I like to create/build and keep my mind engaged.
Let me ask you, have you noticed that all the major labs are releasing models very similar in gains and performance? How do you explain that other than juicing the max out of the current architecture and processes.
They have been releasing similar gains/performance for years now... Pretty much never has one company been dominant for a long time (except the initial GPT3/4 release I suppose. That period took a while for others to catch up)
Yeah - that's why I think they are basically squeezing the scaling laws and the current architecture with incremental innovations.
I expect they will continue optimizing and improving for the current use cases/benchmarks. But the core capabilities will stagnant, that's why they will be forced to slow down until another major breakthrough happens.
I personally don't think LLMs have any understanding of the world, nor any imagination or even agency. I think it got very good as recognizing patterns and shapes in human thinking, language and knowledge, but that's pretty much it.
I bet anything you never ran a small business of any sort.
reply