←back to thread

358 points andrewstetsenko | 6 comments | | HN request time: 0.939s | source | bottom
Show context
agentultra ◴[] No.44360677[source]
… because programming languages are the right level of precision for specifying a program you want. Natural language isn’t it. Of course you need to review and edit what it generates. Of course it’s often easier to make the change yourself instead of describing how to make the change.

I wonder if the independent studies that show Copilot increasing the rate of errors in software have anything to do with this less bold attitude. Most people selling AI are predicting the obsolescence of human authors.

replies(6): >>44360934 #>>44361057 #>>44361209 #>>44361269 #>>44364351 #>>44366148 #
soulofmischief ◴[] No.44360934[source]
Transformers can be used to automate testing, create deeper and broader specification, accelerate greenfield projects, rapidly and precisely expand a developer's knowledge as needed, navigate unfamiliar APIs without relying on reference, build out initial features, do code review and so much more.

Even if code is the right medium for specifying a program, transformers act as an automated interface between that medium and natural language. Modern high-end transformers have no problem producing code, while benefiting from a wealth of knowledge that far surpasses any individual.

> Most people selling AI are predicting the obsolescence of human authors.

It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.

This replacement might not happen tomorrow, or next year, or even in the next decade, but it's clear that we are able to build capable models. What remains to be done is R&D around things like hallucinations, accuracy, affordability, etc. as well as tooling and infrastructure built around this new paradigm. But the cat's out of the bag, and we are not returning to a paradigm that doesn't involve intelligent automation in our daily work; programming is literally about automating things and transformers are a massive forward step.

That doesn't really mean anything, though; You can still be as involved in your programming work as you'd like. Whether you can find paid, professional work depends on your domain, skill level and compensation preferences. But you can always program for fun or personal projects, and decide how much or how little automation you use. But I will recommend that you take these tools seriously, and that you aren't too dismissive, or you could find yourself left behind in a rapidly evolving landscape, similarly to the advent of personal computing and the internet.

replies(5): >>44361398 #>>44361531 #>>44361698 #>>44362804 #>>44363434 #
johnnyjeans ◴[] No.44361531[source]
> That's simply a reality, just as weavers saw massive layoffs in the wake of the automated loom, or scribes lost work after the printing press, or human calculators became pointless after high-precision calculators became commonplace.

See, this is the kind of conception of a programmer I find completely befuddling. Programming isn't like those jobs at all. There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys." Did CAD kill the engineer? No. It didn't. The idea is ridiculous.

replies(1): >>44361608 #
1. soulofmischief ◴[] No.44361608[source]
> Programming isn't like those jobs at all

I'm sure you understand the analogy was about automation and reduction in workforce, and that each of these professions have both commonalities and differences. You should assume good faith and interpret comments on Hacker News in the best reasonable light.

> There's a reason people who are overly attached to code and see their job as "writing code" are pejoratively called "code monkeys."

Strange. My experience is that "code monkeys" don't give a crap about the quality of their code or its impact with regards to the product, which is why they remain programmers and don't move on to roles which incorporate management or product responsibilities. Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.

> Did CAD kill the engineer? No. It didn't. The idea is ridiculous.

Of course not. It led to a reduction in draftsmen, as now draftsmen can work more quickly and engineers can take on work that used to be done by draftsmen. The US Bureau of Labor Statistics states[0]:

  Expected employment decreases will be driven by the use of computer-aided design (CAD) and building information modeling (BIM) technologies. These technologies increase drafter productivity and allow engineers and architects to perform many tasks that used to be done by drafters.
Similarly, the other professions I mentioned were absorbed into higher-level professions. It has been stated many times that the future focus of software engineers will be less about programming and more about product design and management.

I saw this a decade ago at the start of my professional career and from the start have been product and design focused, using code as a tool to get things done. That is not to say that I don't care deeply about computer science, I find coding and product development to each be incredibly creatively rewarding, and I find that a comprehensive understanding of each unlocks an entirely new way to see and act on the world.

[0] https://www.bls.gov/ooh/architecture-and-engineering/drafter...

replies(3): >>44361671 #>>44362193 #>>44362739 #
2. bcrosby95 ◴[] No.44361671[source]
My father in law was a draftsman. Lost his job when the defense industry contracted in the '90s. When he was looking for a new job everything required CAD which he had no experience in (he also had a learning disability, it made learning CAD hard).

He couldn't land a job that paid more than minimum wage after that.

replies(1): >>44361765 #
3. soulofmischief ◴[] No.44361765[source]
Wow, that's a sad story. It really sucks to spend your life mastering a craft and suddenly find it obsolete and your best years behind you. My heart goes out to your father.

This is a phenomenon that seems to be experienced more and more frequently as the industrial revolution continues... The craft of drafting goes back to 2000 B.C.[0] and while techniques and requirements gradually changed over thousands of years, the digital revolution suddenly changed a ton of things all at once in drafting and many other crafts. This created a literacy gap many never recovered from.

I wonder if we'll see a similar split here with engineers and developers regarding agentic and LLM literacy.

[0] https://azon.com/2023/02/16/rare-historical-photos/

4. johnnyjeans ◴[] No.44362193[source]
> Actually, the people who are "overly attached to code" tend to be computer scientists who are deeply interested in computation and its expression.

What academics are you rubbing shoulders with? Every single computer scientist I have ever met has projects where every increment in the major version goes like:

"I was really happy with my experimental kernel, but then I thought it might be nice to have hotpatching, so I abandoned the old codebase and started over from scratch."

The more novel and cutting edge the work you do is, the more harmful legacy code becomes.

replies(1): >>44363503 #
5. mondojesus ◴[] No.44362739[source]
"I saw this a decade ago at the start of my professional career and from the start have been product and design focused"

I have similar view of the future as you do. But I'm just curious what the quoted text here means in practice. Did you go into product management instead of software engineer for example?

6. soulofmischief ◴[] No.44363503[source]
I think we are operating under different interpretations of what "overly attached to code" means, leading to a misunderstanding about my comment.

In my case, I am referring to a deep appreciation of code itself, not any particular piece of code.