Live data from Hacker News

The End of Programming

pauldix.com

51–60 of 124 posts

Re: The End of Programming

#51

LLMs are scarily good at translation, whether between natural or between programming languages. Also very good at re-implementing the stuff that has been provably done before. And, arguably, 90-95% of writing code is exactly that.

In my experience they still struggle a lot though. They're great at 1 to 1 translations but they will fight the target language to get there tho. A lot of the rust rewrites I've seen done by AI contain a lot of patterns that any rust dev worth it's salt will scoff at.

Re: The End of Programming

#52
It's just another tool. Programming is/can be fun. People still hand turn wood, and make their own furniture, even though Ikea exists.

Or maybe 'code' just gets pushed down a level like assembly did when C was invented, for example. As a percentage very few people look at assembly in comparison to the 1960s-80s.

Re: The End of Programming

#53

The article gives the example of Bun's successful Zig to Rust of why this is the end of programming. I think that rewrite is a perfect example of why it's NOT the end of software engineering. A non-programmer could not have prompted AI to do that rewrite, and in fact a non-programmer would not have even conceived of the idea of doing that rewrite in the first place. Somebody is still needed to 1. come up with the ide…

Yes but those are all semantic tasks which can be done and understood in time by the next iteration of models training at that meta-level of architectural analysis. AI deeply understands what Bun, Zig and Rust are, how they work, can conceive of the before and after architecture (probably the hard step here), can conceive of the goal of the rewrite, and can verify (using Lean and machine-checked proofs of the before…

Sure, maybe step 2 can eventually be replaced by AI. But step 1? Why would the AI even conceive of the idea of doing a rewrite in the first place?

And rewriting is just an example. There are tons of architectural decisions that need to be made every day in the building of advanced software. This is no "correct" way to do it that the AI can know in advance, it's a technical decision to be made by an engineer.

Re: The End of Programming

#54

Earlier quoted context omitted.

I guess in most industries speed was always the primary concern. Things like architecture and principles were there only to prevent things slowing down to a crawl. A way to protect that speed

And who will fix the slop? Not Silicon Valley programs being paid $200K or whatever. We stand on the verge of a golden age of outsourcing in software which will make all previous phases of outsourcing look like trial runs.

Project "Death by a thousand cuts"

Re: The End of Programming

#55
post #9

This is a strong article with a distracting headline. Challenge for commenters: can you discuss the content without getting caught up in the headline? My favorite paragraph: > The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. And you can say, “wel…

To me it’s a purpose fit solution that does actually show what LLMs are capable of. Just in the best case, with the most well defined constraints one will be able to work with.

It proves that with a sufficient spec, it can do a lot of work. The spec is always the problem though - to make the spec correct enough, one has to go thru the same process as coding it. Will LLMs surface the right tradeoffs, let alone make them? Working w frontier models all day, I can say resoundingly no, and not for a long while I think. Always looking for examples of things going well though if folks have some to share.

Re: The End of Programming

#56

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 do see this as good... for my personal future career. Currently AI has caused a massive hiring stop in Consulting which is the area I want to go into. However the more terrible AI decisions there are in the future the more need for a human that can scrutinize those decision there is again. Aka Consulting will boom in a few years. (Is my hope)

Re: The End of Programming

#57

From TFA: "What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction." “Since FORTRAN should virtually eliminate coding and debugging…” -- FORTRAN report, 1954 [1] And the FORTRAN report was both right and wrong. What was meant by "coding" back then, carefully crafting machine instructions from higher level specif…

Big difference is that now C level management really tries to push this narrative down to our throats. People who are writing and claiming thing like this should be held accountable for it. It is easy to try to scare developers that their job is going away. Especially for gaining attention. Currently I don't see difference between these claims and conspiracy theories...

Re: The End of Programming

#58
I'm going to separate this from the title, versus the contents on the post

on the bun rewrite, this matches my experience

it's always been worth completely ignoring people that had a negative experience with AI-assisted coding, because others of us have been entirely functional. the slow trickle of examples has always been because it was counterproductive to tell anyone that your project or service was AI-assisted in coding or entirely vibe coded.

but now, with bun being an Anthropic project and their whole thing is showing examples that would speed up everyone else, the truth is out there. good move by them.

bun is a fast runtime and will save millions of projects time and compute costs in CI/CD and redeployments

on the title, I disagree, but with a twist. manually coding is just not necessary, but the ability to get results, and use available compute resources efficiently and at low cost are still disciplines. I don't just mean "architecture", I mean a more specific part of architecture like knowing that your postgres instance can already be an event based architecture and you don't need the cloud provider's pub/sub arrangement at all.

right now, AI isn't going to do that for you. but regarding the discipline, I don't have pride over that, I think that's a major point for people, a level of gatekeeping and pride. this isn't what we need, this isn't what companies need, everyone always needed results.

people in this career are concerned about the billable rate when people with less familiarity with the discipline can deliver results, and thats where I also see a different outcome: delivering results in software still has some unique attributes compared to almost every role in an organization.

A, it just has to be done. B, it's still one of the only roles where your workers can compete directly against you whenever they feel content enough to do so, or discontent with how you are paying them.

Software engineers have little to no overhead costs of running their own thing, they have no licenses and hence no geographic limitation compared to your accountants and lawyers, and they also have enough money to cover the little overhead costs they do incur, something even your sales team doesn't have before getting caught in a lead trading ponzi scheme. The major markets for software engineers (California) nullifies any non-compete you were relying on. It doesn't matter who is doing the software, whether it was someone that was previously doing HR, or someone that built an identity around coding, it just has to be done.

But this should translate into hiring, right now, the importance and cost reinforces teams to want to interview for something that they think "should" be gatekept. multi week, multi month, hiring processes to prove someone has a cognitive ability. but this isn't necessary, people should be able to come into the effort, the same way someone can pick up a broom. the same way a sailor on an old expedition picked up an oar and splits the bounty during the trip.

Re: The End of Programming

#59
post #46
post #40

Earlier quoted context omitted.

Simon - I hope this is not a rude question, but do you work with other engineers?

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.

Re: The End of Programming

#60

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...

If you care about architecture and principles, the AI is excellent in architecting around that goal too and/or helping you articulate your own intuitions. You just need to be willing to sacrifice code delivery speed. It's far from an either/or.
Post reply on HN