Is hand coding becoming obsolete?
deusinmachina.net
deusinmachina.net
Back in the early 80s, for example, the hot thing was 4GLs, which was supposed to allow such a high level of abstraction as to put development into the hands of business analysts. Obviously that went nowhere. And LLM AIs are just one more step in this, albeit a potentially large one.
As Carmack says, the real skill is to understand what you're trying to develop, how it relate to the needs of your users, and to apply this systematically. That understanding might be replaced at some point in the future, but that is not today.
Instead you're glueing together stuff that barely works on its own
Makes me glad I didnt get too invested in the previous hacky solution.
Relying on the likes of Google, Facebook, Twitter, and Microsoft to do your thinking for you turns the very act of development into an app store submission. If they don't like what you're doing or think you're too much of a competitor, they will lock you out. They will take your work and either discard it or use it for their own purposes. Leaving you dead in the water because you don't have anyone that knows how to do anything because they let the AI do their thinking for them.
Does it not strike anyone else how terrifying it is that we are headed toward a future where everything you do is owned by big tech? Or how we are being conditioned to think how big tech says we should think, or else you don't get to play?
Say we do wind up using something like ChatGPT for everything. In a generation, everyone's mind will have atrophied to the point that even the most basic tasks will be impossible. Most people already can't do basic arithmetic in their head, spell, count change, read a clock, or remember their schedule because of the reliance on computers and phones. Without people having to engage their brain to do anything, it will turn into some kind of Zombieland.
And the irony is, this is all going into a LLM as well! (hey future model, name the countries responsible for the finnish-italian war of 2020, be as verbose as you can, please state the name of the war repeatedly)
Also attempts for "pausing" for 6 months will fail, because this is Internet and even if OpenAI, Google, Facebook and etc... decide to honor this pledge (and lose competitive age) Chinese government/companies won't stop.
The same discussion was held at the dawn of atomic age after the scientists saw what it may lead to. Never worked in the age of paper communication. Won't work on the age of instant information distribution.
The game is clear now: anyone who invested heavily into data harvesting (illegal or otherwise) is going to come up on top and there's very little people can do about it. Using models trained on the outputs of LLMs might feel cool but it's in no shape equivalent to what the real models are capable of.
explain npm then…
I think they need to be roughly 3 orders of magnitude better than they currently are to meaningfully replace engineers. Managing architecture across many classes is a clear step change up from one class (or your language abstraction of choice). Managing state, persistence, consistency concerns, are another significant step-change in ability – not at the level of 3 interdependent variables, but more like 100s of data structures across asynchronous code. And lastly, debugging all of this and understanding how the system works as a whole is another significant step change.
It's not obvious to me that a large _language_ model has the ability to understand these abstractions. I suspect LLMs will therefore max-out for programming applications (and others) "soon", and that we'll need another technological leap to get there.
Given fine-tuning of the model, and improvements allowing for a much larger context window size, I think it'll be possible for LLMs to be able to turn a class inside out and then refactor its code and translate it into another language, while generating unit tests that prove it all still works correctly.
How much faster could programming language design iterate if legacy code compatibility wasn't an issue?
When engineers are producing any significant increase in productivity by use of any tool, this tool is statistically replacing engineers.
And, with what is currently happening in AI (going by the self reported numbers that I picked up) the former seems to be true to a wild degree.
And unlike the era of the arrival of compilers, we're not in an rapidly-expanging-computer-market stage either. Only the "replace programmers with AI" segments are growing.
And a short term business cycle is not very relevant either. By the time practical tools are read the cycle may have inverted.
Increasingly more tools aimed at that are produced, and they are increasingly adopted. From CoPilot to specialized tools for end users to do what programmers (and other jobs like graphic designers) did for them.
>And a short term business cycle is not very relevant either. By the time practical tools are read the cycle may have inverted.
Who said it's short term?
For example, I have a friend who owns pub that wanted a membership loyalty program customized to his business.
He had a lot of great ideas, but I told him that this project is too big for the benefit he will get out of it; he would need to get 4 or 5 other bar owners together with similar needs.
I believe there is a lot of software to be built if we radically change productivity.
I believe This will keep the engineering demand up, and people employed.
Programmers who can understand a real problem and come up with a good way to solve it using software will still be needed. "Programmers" who are glorified human clipboards just copying and pasting all day will be less needed. But those jobs were already at risk from the next library or scaffolding tool anyway long before the current generation of AI-based tools came along.
> Programmers who can understand a real problem and come up with a good way to solve it using software will still be needed.
This keeps coming up in my own circles, including with non-technical folks. The best way I've heard it put is "you know, these AIs only know what we've already figured out."
The newest contingent of AI technologies is impressive for what they are, but what they are is both somewhat inevitable and not truly intelligent in the way most businesses require of their technical people in order to succeed. Of course we can automate away the basics, we've been doing that with successive technologies and challenges for a very long time.
Someone up-thread mentioned AI replacing automation folks as an easy example, but I don't see that happening so quickly. I do a lot of automating, and for a start there's so much automation "left to be done in the world" that there are no shortages of hard challenges left that AI couldn't (yet?) crack. There's a huge amount of business<->technology synthesis that has to happen to automate beyond the basics.
But more expansively speaking, writing off humans being in the loop is ridiculous on its face. Humans will _always_ be in the loop somewhere, unless of course we take EM Forster's _The Machine Stops_ as an instruction manual rather than the warning it is. I don't mean that in a doom-and-gloom way but rather that I just don't think humans will ever give up enough control to enable something like that. I don't think that's such a bad thing, either.
It's as ridiculous to say that human programmers are obsolete as it is to say we're that we're anywhere near computers developing complete, new computers for other humans to use.
If your soft skill is turning requests into tickets and looking at PRs to figure out which tickets are already closed, yeah things ain't looking good.
I've worked with some interesting front end applications that made their moderately complex backends look like trivialities, and I've seen whole teams of mostly useless CRUD API developers who struggle with minimal business logic complexity who are going to be made redundant by one good AI assisted backend dev.
Maybe you should introspect a bit.
I like the summary regarding front-end here [0].
[0] https://www.joshwcomeau.com/blog/the-end-of-frontend-develop...
The programming industry went through a similar existential crisis back in the 1990s, when pundits predicted outsourcing/offshoring would eliminate our jobs (in the US, anyway). And some jobs did go to Bangalore and Karachi. Programmers didn't get hit as hard as the manufacturing sector, and the work seemed to expand to create more demand. Eventually companies figured out that outsourcing introduces different inefficiencies and problems, often more than it solves.
In one of his long articles about LLMs Stephen Wolfram made an interesting point: LLMs apparently show us that we have over-estimated the complexity of human language. Human beings tend to have a high opinion of their own intelligence so that seems very likely. Now that we have software that can produce human-like language we can either tell ourselves the AI overlords have arrived and give up, or we can revise what we think we know about learning human language. Likewise, now we have programs that can write passable code, and here on HN you have to wade through all of the "What do I do now?" posts. Another interpretation: a whole lot of code available to the training models doesn't need much actual intelligence to decipher or write, and we as programmers have solved the same handful of similar problems millions of times.
Writing passable code, while not easy to learn, represents the easiest and most replaceable part of developing useful software that has value for the business that paid for it and the customers that use it. And it represents one of the least efficient and least predictable parts of the development process. Imagine framing carpenters just throwing up their hands and fretting about their future when nail guns took over from hammers. The new tool made the carpenters more efficient in some tasks. I expect LLM coding assistants can do the same, but since they can only regurgitate code already written by human programmers they will show apparent skill at solving common problems in common ways, and no skill at anything beyond that.
When I switched to full-time freelancing about 15 years ago I stopped using a resume, I stopped highlighting my "technical skills" (e.g. languages, frameworks, tools, etc.). When talking to a prospective client I immediately focus on their business problems rather than whatever things I have used before. They pay me to solve problems with technology. If that means I need to learn something new, I will do that (and fast). I have 40 years experience in the software business, very little actually new or novel happens in the world of programming. If all I could offer to a client came down to "I know Python" I would limit myself, and I would make myself replaceable by a cheaper programmer or an LLM because knowing Python makes very little difference in the big picture -- a necessary but not sufficient skill because I solve business problems, I don't only write Python code. Now that an LLM can write passable Python the people who only offer that skill should worry, and they should expand their skills to include things LLMs can't do and likely won't do anytime soon. That will apply to other fields, not just programmers, but since I know programming I'll stick to what I know.
Here is the answer I got:
Sure, here's an example implementation of the optimized Newton-Raphson algorithm in GNU assembly (also known as GAS) for x86 architecture using the SSE2 instruction set:
perl
.section .data
.float constant, guess, tolerance
.section .text
.globl main
.type main, @function
main:
movl $0, %eax # set loop counter to 0
movl $100, %ebx # set maximum iterations to 100
movl $1, %edx # initialize sign flag
movss constant, %xmm0 # load constant
movss guess, %xmm1 # load initial guess
movss tolerance, %xmm2# load tolerance
negl %edx # negate sign flag
jmp .loop_start # jump to loop start
.loop:
addl $1, %eax # increment loop counter
comiss %xmm2, %xmm1 # compare guess with tolerance
jbe .done # jump to done if guess is within tolerance
movss %xmm1, %xmm3 # copy guess to xmm3
divss %xmm0, %xmm3 # xmm3 = guess / constant
subss %xmm3, %xmm1 # xmm1 = guess - (guess / constant)
movmskps %xmm1, %ecx # get sign mask for xmm1
testl %edx, %ecx # test sign flag against mask
jne .negative # jump to negative if sign flag matches mask
jmp .positive # otherwise, jump to positive
.negative:
addss %xmm2, %xmm1 # xmm1 = xmm1 + tolerance
jmp .loop_end # jump to loop end
.positive:
subss %xmm2, %xmm1 # xmm1 = xmm1 - tolerance
jmp .loop_end # jump to loop end
.loop_end:
negl %edx # negate sign flag
.loop_start:
cmpl %eax, %ebx # compare loop counter with maximum iterations
jb .loop # jump to loop if loop counter is less than maximum iterations
movl $-1, %eax # set return value to -1 if maximum iterations exceeded
ret
.done:
movl $0, %eax # set return value to 0 if success
ret
The tradeoffs involved in using GAS for implementing the Newton-Raphson algorithm include the complexity of the code and the potential for portability issues across different architectures. Additionally, the performance of the algorithm can be affected by the availability of the SSE2 instruction set on the target architecture.
Coding may move up the abstraction hierarchy a bit more, but high level languages are already in a pretty good spot: much more abstraction and it's hard to understand the ramifications of particular code changes.
We will certainly have more crappy generated code that no one understands, which may replace some crappy copy-and-paste jobs from Stack Overflow that no one understands.
https://en.wikipedia.org/wiki/The_Feeling_of_Power
The twist is that this allows the replacement of expensive computerised missiles with inexpensive manned ones ...
There's no way any digital society loses record like that naturally since it's so cheap to store such information and have it last a long period of time and there's always enthusiasts that keep such things alive where sufficient advancements in technology mean people have more spare time.
Also, it's way more unbelievable that an AI so advanced wouldn't be able to design simple manned machines.
It may be cheap, but when YouTube (as one example) takes down a channel that may have thousands of hours of content, that's gone forever unless someone archived it and is willing to make it available.
I've tried so many times to get ChatGPT to generate code and every time it produces something that looks like code, looks like it would work but doesn't work - for fundamental reasons, like it's made up APIs that don't exist.
It might make getting some small functions or one liners in place quicker, especially for someone in a language they're unfamiliar with. But IME it falls apart pretty quickly and can cost you a lot more time figuring out why its fantasy code doesn't actually have a hope.
Coding will become more generic and less innovation solutions will be standard.
Well, that... is a non sequitur. Jevons paradox is a thing that exists, after all.
https://en.m.wikipedia.org/wiki/Betteridge's_law_of_headline...
Do you mean "able to produce better error messages, and suggest fixes"? Sure, that would be great.
Do you mean "able to decide what it thinks I meant, and compile that, rather than error out on what I actually said"? I absolutely do not want that. Or at least, I want a flag to turn it off.