Jensen Huang says the junior developer problem ends in two years
thenewstack.io
thenewstack.io
AI is just software, nothing new to see here.
AI safety is primarily a sandboxing problem.
There is no collective action problem, and every company should just slow down if they think they need to slow down.
There is no need for regulation because the existing incentives in the market keep companies from acting badly, which is why no company has ever done anything bad.
If something bad does happen, then we can regulate after the fact.
We will end up creating more jobs than we destroy, so don't worry about it.
Our kids might forget a whole bunch of stuff or never learn it in the first place. But don't worry, they'll come up with new things to learn instead.
The only way to get safety is to move faster because then we will more quickly arrive at safety.
Recursive self-improvement is just what we've always done.
The real danger is alarmism that might scare the public and the young people.
Nothing bad can happen, it can only good happen.
The destroyed jobs and the persons doing them will be different from the new ones created..
>If something bad does happen, then we can regulate after the fact.
How does regulating after the fact undo the harms caused?
> they'll come up with new things to learn instead.
Like they forgot how to communicate face to face, but have learned to communicate via social media?
2008 triggered a glut of cheap experienced workers that slowly reengaged juniors but this time that the entire ladder is going to be more valuable than any grad.
How many of them can read x64 or ARM assembly emitted by their compilers?
How many of them will ever need to?
There's your answer.
It’s how I deeply understand what a RAM lookup vs having it already in a register means for optimization.
These are things you need to know if you want to work on high performance applications or in limited embedded systems.
So, yes, many of us need to and it’s important we keep teaching it to future students.
Me, too, but we should both understand what we're talking about: a hobby.
It's like teaching cursive to schoolkids. All well and good, but don't you dare complain about limited classroom time for instruction in other, more important subjects.
I built and deployed embedded systems robotics that protect water and oil pipeline infrastructure that costs billions of dollars if there is a failure.
That is not a hobby, that’s a career.
The tools I built just helped fix the fresh water access for my entire city of 2 million people. Explain to me what’s more important than people having access to water.
Humans put the tool in the pipe and analyse the data. This isn't newfangled shiny tech, it's old stuff designed and maintained from a decade ago.
There's no fancy AI, no magical automated robots. Just humans using EM tools to scan pipes.
This is a category error. LLMs are probabilistic. The ones run by an AI company over API, even more so.
Compilers are not.
Nobody cares. Deal with it and get over it.
>Nobody cares.
That is a different matter. And you are probably wrong here as well. Plenty of people care about a program doing exactly what they want. Nothing more, nothing less. If not every one would have been writing programs in Ruby (not that Ruby is non-deterministic) .
Get over that camperbob2
When I say that nobody cares about determinism, that's what I mean. Determinism is indeed important, but only at the delivery level. There are many routes to achieving it, none of which require you to write low-level code yourself. If you insist on doing that, you have a hobby, not a profession.
What exactly do you mean by this? Can you give an example..
My workflow used to be:
1. Draft rough spec
2. Write a bunch of C/C++ code
3. Test manually
1. Put some actual care into a detailed spec
2. Write equally detailed test harness spec
3. Hand both specs to clanker. Surf HN for a while
4. Review target code casually
5. Review test harness very carefully
6. Run test(s) manually (or, lately, get the clanker to do that too)
7. Iterate if necessary, going back to step 1, 2, or 3 as appropriate
The analogy I like to use is Harold Black's work in the 1930s, trying to convince the patent office and his peers that yes, negative feedback is a huge, huge F'ing deal, because it only takes a small amount to make a large improvement in linearity. Anytime you have something that is 95% as good as it needs to be, it will be good enough if you can wrap a loop around it.
Lol, you are in for a world of pain when you run out of prompts!
But you can always throw the entire program, and start from scratch...You have every behavior captured in tests, right?...right?
Not necessarily. I'm still learning how to do that, just like the rest of the industry will have to. TDD in the age of AI is a skill that will emerge from disciplined practice as well as a lot of trial-and-error.
As for digging in manually, right now I still have to keep a pretty close eye on the C code the clankers emit, but then I'm old enough to remember when we had to debug compiled C code by stepping through x86 opcodes in Turbo Debugger. That need went away, frankly sooner than I thought it would. I almost never need to look at x64 assembly anymore, and I can't sight-read ARM at all. The same thing will happen with what we call high-level languages today.
At some point last year I noticed that I was finding fewer bugs in AI-generated parts of the code than the AI was finding in my own, and that trend clearly isn't going to reverse itself. When the clanker screws something up, it's usually because I gave it flawed or incomplete instructions, not because it's incapable of doing the job right.
Not always, but usually.
Wait, how do you debug now? Do you mean because of LLM assistance?
This is an introductory programming course, designed for non-CS students e.g. engineers and scientists.
> Learning outcomes
> 2. Explain key concepts in AI-assisted programming, including Large Language Models (LLMs), prompting, problem decomposition, and top-down design.
> 3. Apply the workflow of AI-assisted programming and prompt-engineering techniques to guide and improve code generated by AI assistants.
This course used to be non-AI (last year), and they rewrote recently to incorporate AI tools, as they realised the writing's on the wall for non-programmers.
It must be quite challenging to write curriculum when the underlying technology (AI) is changing so quickly.
Jensen Huang has been CEO of NVIDIA for 33 years. That is a role with a very specific type of information environment. He is sort of this weird combination of specialist and - he necessarily has to operate within a certain level of abstraction.
I’m somewhere in the middle, I’m a high achiever but not the highest. I would say I’m above average in my usage of AI at my tech job. The way I’ve learned systems thinking is by being a bit non-specific in what I learn. British history, psychology, software engineering, queuing theory, cooking.
The idea of learning systems but not basic math - the idea of being too discerning in what I’m willing to learn. The entire idea of passing up the ability to learn something like basic math.
So many mental models of the world are developed by engaging with things like basic math. How do you learn systems without learning patterns behind numbers?
If the whole argument is something like it’s now about taste or creativity or being a builder? The way you learn those skills is engagement with all the things. It’s not abandoning all the things to read a book on systems thinking and product management.
It’s not never focus, but if your default position is “maybe I shouldn’t be curious about that”. You’re operating from a deficit.
Jensen gets it!
Related:
https://en.wikipedia.org/wiki/Coupling_(computer_programming...
https://en.wikipedia.org/wiki/Abstraction_layer
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
It is so, so easy to pick up LLM aided development.
What is way harder is self-managed slop mitigation which is only achieved with employees who know the A,B,C's of software development.