Live data from Hacker News

The End of Programming

pauldix.com

101–110 of 124 posts

Re: The End of Programming

#101
> Broader, cheaper access to frontier intelligence at incredible speeds is coming.

OP's entire argument rests on this presumption, and while it certainly sounds like the industry is headed in this direction, it's definitely way too early to equate the success of building proofs of concept with success at maintaining mission-critical production systems across industry verticals, as OP attempts to:

> The prototype is working software. And the improvement and testing of that prototype is further enabled by more improvement loops with the AI. It gets better with more testing and verification, not through human code review, but through usage and testing.

Who drives usage and testing today? Who takes user feedback from the "usage and testing" and translate it into something that The Machine can use for improvements? Humans do. There is no agentic harness for managing at the level of the product itself, and I'm not convinced that there ever will be, because it's a fundamentally political concern. And not the low-stakes intra-team kind like tabs vs. spaces - the high-stakes, do-we-close-the-deal-or-not kind. Even if agents hypothetically could handle that level of stakes - they simply lack the context to do so, and will continue to lack the context to do so, at least until we get AGI in a humanoid robotic form factor.

Software engineering isn't dead. As a separate field with a dedicated job title, it's arguably dying in a world where it becomes a table-stakes skillset for Product roles. It is simply cheaper to employ 2x Product Engineers at $300k/year each, armed with $200k/year each in tokens, than it is to staff out a team of eight Software Engineers at $150k/year each. And this is before a hypothetical crash in API token pricing, or agility benefits from aligning fewer humans.

It's happening slowly in smaller companies, and hasn't happened yet at scale because, while you can teach Product skills to most Software Engineers and can't teach Software skills to most Product folk, most big-cap executives haven't gotten this memo yet. But the economic pressures are there.

Re: The End of Programming

#102
post #76

I don't know if this is the end of programming, but i can clearly observe the gradual end of expertise in my company - people slowly forgetting architecture, principles, and how stuff works in general, in favor of code delivery speed. And without expertise you end up asking stupid things to a token producer machine, however godlike it can be. It's hard not to extrapolate...

I really do think that people who rely on AI to make architectural dissensions will simply have a bad time later down the road when it turns out that the AI made a stupid decision. I have noticed myself a 3 months or so ago sometimes asking AI questions for things that I knew the answer to (but had to think about) and my solution would have been better. Once I realized it I realized how despite always telling my self…

Also, handing over the work to AI robs you of learning and understanding. Let’s say you write a ticket for a feature and that description is good enough that an AI agent can implement it from start to finish. The AI will then discover things while implementing the feature, and will use those learning to make the feature work. That learning will then be discarded once the AI is done. No one will be able to partake or share the knowledge with others. Sure, some of it can be saved in form of comments, but not everything.

Re: The End of Programming

#103
post #64
post #59

Earlier quoted context omitted.

I see a lot of enthusiasm from people who work alone or who have total control over a project and nothing but abject misery from people who work in a professional setting with a group of people using coding models. I'm just building some data points.

I don't work with a large team, so I don't personally experience the hell of coworkers dumping thousands of lines of unreviewed slop on me. (I get a bit of exposure to that from my open source projects but it's much easier to close or ignore those.)

Thanks for answering in good faith.

Yeah so unverified PR's is super annoying, but people using LLMs to answer things incorrectly they could look at themselves is a big issue too.

I often hear this get dismissed along the lines of "oh you didn't context engineer hard enough" - but the default state of the model is to very confidently state a thing to be true when it hasn't searched correctly.

That is a trait of a very junior engineer - one who, if they never learned to fix this behaviour would be fired.

It seems objectively _worse_ than what we had before - trained engineers who gained wisdom over a long time horizon and had a reputation they'd lose if they kept incorrectly stating things.

Re: The End of Programming

#104
post #34

Earlier quoted context omitted.

So you are suggesting we will soon drop the "vibe" from "vibe coding"?

I think we have been doing that for a while already. Seems like almost every major company is using LLMs for coding internally and people dont consider that vibe coding. Culturally, it feels like we've already speedran the pipeline of "vibe coding is using LLMs without reading the code" to "vibe coding is using LLMs for code" to "using LLMs is just a tool for coding". LLMs seems to now be mostly accepted for coding (…

Yeah, but the semantic question is whether LLMs being accepted to use for coding means that the software engineer who merely instructs the LLM is thereby also "coding" (similar to how someone who merely writes Fortran, rather than machine code, is nowadays also described as "coding") or whether the only entity that is described here as "coding" is the LLM.

Re: The End of Programming

#105
Bob Martin spent about half his life talking about an eventual coding error that will kill 10000 of people, and how we must be responsible with our code because of this.

When it eventually happens and it is AI generated... who gets the stick?

Re: The End of Programming

#107
When i look around my programming coworkers i feel this shift poses a problem to many of them. Not so much because AI now does all programming but more because they are so used to working through tasks someone else creates for them.

Re: The End of Programming

#108
Rewriting something from one language to another is not really the height of software development.

When you have an extensive testing suite, I would claim it's the ideal scenario for LLM's, next to crunching out small tools and MVP's.

Let's first see how it handles the architecture in a 1 year old project of 3 developers, before we make such claims as "the end of programming".

I love LLM's, they save me a lot of time and effort. But their autonomy degrades quickly when you keep adding context and complexity, which a medium codebase clearly has.

Re: The End of Programming

#109
post #59
post #46

Earlier quoted context omitted.

Yes, why do you ask?

I see a lot of enthusiasm from people who work alone or who have total control over a project and nothing but abject misery from people who work in a professional setting with a group of people using coding models. I'm just building some data points.

It's a learning curve, but it can work, you just need to be comfortable with large (and likely quite negative) reviews for the inevitable large MRs that will get generated.

The important things to get right are the same as they were before though. Work from well refined stories that are not too broad in scope. Ensure you have enough good acceptance criteria that will help prove that the code works as intended.

Re: The End of Programming

#110
post #45

Earlier quoted context omitted.

This is cope. There is no going back to artisan programming. Any issues will also be fixed by ai agents.

Patching over the architectural nightmares LLMs pour out is I think the opposite of artisan programming.

it does not have to be patching over the existing system. Of course you need someone experience in the loop, but it is not that someone needs to manually refactor everything by typing every line. One approach that works quite well is like this.

"give me all the specs in a list" -> "which architectural changes would simplify the implementation based of these specs" -> delete everything -> "implement the new specs"

Post reply on HN