Hacker News new | ask | show | jobs
by sushshshhs 26 days ago
If your project contained original thought does it matter if the IFs and the ELSEs were generated?

I sometimes wonder if people get into this to create an actual working something or they just enjoy sorting colored blocks for the heck of it.

I am on the other extreme end: I don’t give a rat’s ass about the code itself. The spec, the intent, the architecture, the contracts are what I find interesting. All the “file handling” and “logging” and syntax wrangling and caring if some “variable” is on the “stack” or the “heap” I can live without very happily. It’s not that they are uninteresting in and of themselves but I find it hard to justify keeping my focus on these microscopic issues again and again and again and again.

8 comments

I have landed here myself. I have always enjoyed writing code, but I find lately that I am getting so much more satisfaction from the process of exploring and designing systems more, and code is simply the substrate.

I am becoming a better architect with AI, because I am spending more mental energy in that lane, getting less embroiled in the nitty-gritty of the code.

I had that the first few months, but that feeling doesnt stay forever. I think a difficulty with that discussion is that some are still in the honeymoon stage, while others are at the “wtf is the point” stage of the relationship with coding harnesses. In my case that took ~1y from using tools like Claude code daily to the point where I lost interest and motivation once I understood the technology contributed negatively to my personal growth.
> I understood the technology contributed negatively to my personal growth.

If your goal is to become better at writing code, it almost certainly is a net negative.

If you define growth as shipping stuff and getting things done that you previously wouldn’t have had the time for, then it might be a positive.

Hell, it’s probably both at the same time and what each person cares more about is the deciding factor.

Programming/software engineering isn't writing code. It's understanding and designing systems. The code is the way we encode the logic. The runtime/compiler of your language is one system among many engineers have to understand and develop expertise in. When working yourself on problems you learn about the various protocols, interfaces, past design decisions and their trade offs, tooling, and develop your general system thinking. When you delegate to AI you get the resulting artifact but none of the personal growth that comes with developing it.

Think of the recent bun rewrite from zig to rust, around 1M lines of code. If you would have a team do that migration they would very likely have to become close to Rust expert, and develop an intimate knowledge of the codebase, its tradeoffs, have ideas for future improvements, good understanding of the technical debt they accepted, reliability of tests, etc. That's A LOT of expertise you can then apply to other things in your professional life.

Instead they went the AI way. The got the artifact (the migration) in ~1 week. But that's pretty much it? What did they learn from that project, other than the fact the AI can do that work? My guess would be pretty much nothing. And pretty much any other software engineer could have done the same migration. There is zero personal growth here.

How is bun going to progress from here, though? Is it feature complete, never to need another update? No. So are they just going to vibe code in Rust now? Keep developing in zig and convert each merge to Rust? Or hire/become the Rust experts they need to maintain the project?
We will see, I personally expect they will continue the vibe coding approach. So, just throw mythos at the reported issues, with some high level guidance
There was a thread[1] about this the other day! People have different goals, motivations, and reasons for developing. I guess I just like sorting colored blocks. I'll agonize over the code... I really will go back to a class I wrote months ago and ask "Do I really need this member variable?" and "Does this really need to go on the heap or can it live on the stack and be automatically cleaned up?" "Can I use a pImpl C++ pattern here and reduce the number of headers that this header file includes?"

1: https://news.ycombinator.com/item?id=48316056

> I am becoming a better architect with AI, because I am spending more mental energy in that lane, getting less embroiled in the nitty-gritty of the code.

I don't believe this, every architect ive ever worked with that was not regularly in the weeds on various things in the codebase were universally terrible and out of touch.

That's probably all true. But I wonder if brains are just wired differently. I was never the developer that cared much about the particular shapes of any concrete IF/ELSE blocks in the code, so initially I was very bullish on using Claude Code a year ago. I realized that I'm the kind of guy who discovers the high-level architecture by writing the low-level code though. I'm not always sure what that architecture is up front, but the sheer act of writing code into a specific module sets off an internal background task probing the specific invariants of the module with respect to the architecture I have in mind, allowing me to revise and improve the design. That is all lost. All my agentically engineered projects look crude from an architectural perspective.
> I am becoming a better architect with AI

Be careful with that claim. Abstractions more or less leak especially in CE where the OS and hardware you built on are already full of leaky abstractions, e.g. performance traits. It is still important to look through and comprehend code.

I agree. I use the grill me skill and superpowers brainstorming to learn different methods of building stuff as far as architecture goes. Stuff I wouldn't normally think of if I just continued being "just a FE engineer"
ai can do architecture too.
On the one hand, this feels very pragmatic.

On the other hand, it feels like what people who weren't great software engineers say.

It's kind of a craft. I can't imagine an exceptional artist saying "screw the craft, I just want the painting that vaguely resembles what I requested".

I _can_ imagine artists that were not exceptional saying "it's so great that I can just prompt and get the damn painting, who care about how it's put together".

Up next, an architect who doesn't understand how concrete pours or how steel bends under stress? Hope the AI gets it perfect?

Interesting times we live in - and I realize this is an elitist take.

I think you are right, but I still care. I want to write software that is immortal. My dream is to write code that people would be happy to read and easy to understand. It is also some kind of meditation. I can zone into something and "get my hand dirty".

> I sometimes wonder if people get into this to create an actual working something or they just enjoy sorting colored blocks for the heck of it.

So yes, to be honest, some people write software for the "heck of it". Will my implementation of Lisp interpreter matter at all in the grand scheme of things? No. It is in fact a waste of time, because you _could_ have learnt how it works and implement it in less than an hour with LLM.

> The spec, the intent, the architecture, the contracts are what I find interesting.

To me, this is like saying the financial of the company is what determines the company's success, not whatever the engineering team is doing. So instead of thinking about the "The spec, the intent, the architecture, the contracts", just give the right monetary incentives and you will come up with a successful project.

From this perspective, can you empathize with the "low level" developers?

If a photo has strong composition and symbolism, does it matter if the photographer took the photo as opposed to prompting it into existence?
The entire purpose of a photo is to capture a moment. What 'moment' is AI capturing? Do the books in the background represent the 'moment'? The adverts? The furniture? The clothing? The hairstyle? These are all 'parts of the moment'. When we look at old pictures, these details are the parts people LOVE going over. None of that is there in AI, and in 20 years, no one will care go look it over, because it's meaningless, unintentional slop. Not a haircut someone picked out. Funny hiphugger/mom waist/tight/loose/bellbottoms. Not currated books in the background that represent thought of the time in which the picture was taken.

There is nothing in the AI photo worth re-looking at later, because there is nothing there. There is nothing to take from any of the 'details' in the image.

Does it matter if the moment is real? What makes you think that all of the photos that have been taken thus far are real? What makes you think that the photographer chose a certain angle to craft a story? Is that moment real? When people say "cheese" in photos to make them smile, are those real?

I am not a proponent of AI images, believe me, but I find it interesting to think that people would not like AI images. People don't really care if something is real or not. They just want to be told a good story.

i.e. we are fucked, but we have already been fucked for years without knowing. Call me a luddite but selfies is the fakest shit ever. I would rather take pictures of plants, rocks and animals than people.

That's a purpose of a photo, not the purpose. As an art form, there's a lot more to it, and much of it happens after the shutter closes.
If the realism is important, it does matter. If realism is not important("strong symbolism"), then it is not important.
An interesting question because photos are mostly machine-generated to begin with. The photographer just hits a button.
"Just hits a button" is an incredibly reductive way to look at photography
The work of a photographer is to put something interesting in front of the lens before pressing the button.
Your comment captures the most objectionable mentality behind AI zealotry so well. So much display of hubris, no appreciation of science, engineering, art, or anything at all.
to many, it does not.
"original thoughts" are not accessible to 99 percent of ppl. doenst mean they have to live a life of zero fulfillment.
I enjoyed writing code because it felt like playing Lego. Just putting stuff together. Now I do let AI code, and it's like putting together different Lego.

That said, I wouldn't let AI build my Lego sets for me because the point of that is the building. But for work? As long as my boss is happy enough to keep funding my Lego hobby, I'm happy.

You should try a higher level language. Go has no concept of stack or heap neither does Java.
To me, English is just another programming language. Some of us will always be better at it than others, and the ones that know other programming languages well will always have an advantage over those who do not.

When you are good at it there can be craft in it still.

English is not a programming language though. I don’t understand how such an obviously false sentence can be so persistent.
I'm not even sure what you mean. Of course it is.

A programming language is a formal intermediate language for turning human comprehensible instructions into machine instructions by means of an interpreter or compiler. We've now allowed that intermediate language to be English, because that's preferable to most people, and the "compiler" has become very complicated indeed as a result of that.

You still have to be able to express what it is you want in a way the machine can understand, it's just both simpler and less deterministic now.

This. Just because an llm can translate any language into a programming language doesn’t suddenly make all languages programming languages. Until I can ‘brew install englishc’ and so on, it’s not a f**ing programming language.
Can you define programing language in a way that includes all the current programming languages and excludes English? I kind of doubt it unless you just define it as "anything that isn't a human language", which would be silly.
Natural language is full of ambiguities and redundancies which makes it a poor fit for a programming language, which is why it is never used as such.

You don’t need a precise definition of a term to know what a thing is and isn’t (Wittgenstein has taught us that much at least). We just need to know that programming languages are used to express an executable computer programs (usually by translating to simple machine instructions) and that a natural language has never been used in this way in a significant manner.

A case in point. I bet you can‘t find a definition for a fish which includes cods and sting-rays, but excludes dolphins and shrimp. And similarly the IAU were unable to come up with a definition of a planet which included Pluto and Mercury but excluded Ceres and Sedna.

> Natural language is full of ambiguities and redundancies which makes it a poor fit for a programming language, which is why it is never used as such.

I mean, a quarter century ago Dijkstra argued your point compellingly, and he was right back then. If you read his "On the foolishness of “natural language programming”" (1978) you'll find that all of his most compelling arguments are gone now. Things have changed, and the machines can now largely cope with the ambiguity of language as well as the average human being can.

Since human language is the original source for the specifications we turn into formal code most of the time anyhow, we're really just asking if that original specification the programmers turn into formal symbolism is a form of code or not, and whether a good spec is equivalent to good code. I think it's difficult to argue that it's not, especially given that we now have these handy Natural Language to Formal Symbolism compilers.

> We just need to know that programming languages are used to express an executable computer programs (usually by translating to simple machine instructions) and that a natural language has never been used in this way in a significant manner.

I did that like 30 times today. Maybe it wasn't in the past, today it is. The path is now Specifications->LLM->Formal Symbolism->Machine Code, it used to be Specifications->Human->Formal Symbolism->Machine Code. The inputs and outputs are the same, and I would argue that the process is still "programming" regardless of syntactic games with semantics.

Eventually we'll find a more efficient version of that formal symbolism and stop using code designed to be human readable at all. Still nothing will really changed besides the input method.