I used to think you’d struggle to replace an actual illustrator/artist because clients always want something specific. But really it isn’t about you giving them what they want it’s about them having to deal with you at all.
Why would I message the illustrator, negotiate rate, have a meeting then have back and forths trying to get what I want when AI can be running from the first moment without interacting with anyone else and it can be spitting out versions of the thing before you have the actual person in a video call.
It can do this all day and all night then someone just had to choose what version of the thing they want or nudge it closer.
It happened to art and I don’t see why devs think they’re immune.
On a long enough timeline, there may only be unfortunately project managers.
(Still think building great and opinionated work has value. But low level generic work is on the chopping block as far as I can see today)
You won't need those either. AI will be able to just use your neuralink implant to build a complete product based on some vague ideas, in minutes. Goodbye daily scrum meetings and quarterly planning.
In all seriousness now - who is going to be building this "AI"? What about the platforms it has to run on (both software and hardware)? The tools that team has to use?
Will AI find new ways to implement AI? Will AI research and implement ways to optimize itself across the whole stack?
Are you just going to let AI spin VMs for you in your multi-cloud Azure subscription with uncapped spend, if that's what it takes to build your product? Maybe AI will also investigate customer escalations and bug reports? Or memory corruption issues?
Look, I get it. You're excited about a computer computing. And maybe you've gotten used to the idea that engineering ends with being a code-monkey stitching together CRUD APIs in Python.
Nothing wrong with being excited. But please, have a bit of respect for the craft.
Probably because it's a different problem domain that actually requires precision and the requirements often are unexpressable in natural language.
Also, it has not happened in art. You can say it has happened in art when 50% of currently salaried graphic artists are unemployed.
https://www.amazon.com/Mattel-Games-Magic-Ball-Retro/dp/B014...
> Author Pamela McCorduck writes: "It's part of the history of the field of artificial intelligence that every time somebody figured out how to make a computer do something—play good checkers, solve simple but relatively informal problems—there was a chorus of critics to say, 'that's not thinking'." Researcher Rodney Brooks complains: "Every time we figure out a piece of it, it stops being magical; we say, 'Oh, that's just a computation.'"
Here is what really happens. People who are not familiar with programming assume that some mental faculty is necessary to solve a particular problem. Indeed, it is required for a person to succeed at the problem. That mental faculty is often general and can be applied to other tasks. It's some aspect of what we consider general intelligence.
Instead, software engineers look at a problem and solve it by changing its representation to fit the capabilities of a pre-existing algorithm. The solution has nothing to do with mental faculties in the general population. The solutions ends up being specific. If you want to apply it to another problem, you need to transform that problem into some clever representation as well.
People notice the lack of generality and say "no, this is not what we had in mind". It's an entirely reasonable sentiment.
At some point, we should learn and try to manage expectations, by using less emotionally charged words.
Look at those systems that generate images or text from a prompt. Usually the results are good, and sometimes they are totally bogus.
As I point out occasionally, the big hole in AI is "common sense", defined as not screwing up big-time in the next 30 seconds. Until that gets solved, AI systems can't be trusted very far.
The control theory people are trying to fix this, so they can use ML to build control systems with safe behavior. The math is really tough. Way beyond me. See IEEE Transactions on Control Systems Technology to follow this. People are trying to make control theory math and ML math play together. Control theory usually has continuity - if it does the same right thing at 0.21 and 0.22, you can be confident it will do the same right thing at 0.215. ML systems do not have that property. Which is why we see those image recognition demos where some minor change in the background noise totally changes the result.
A better approach is good uncertainty quantification (this is not at all trivial) to quantify when the model is and isn't qualified to be making a prediction.
Agreed, but how is the different from humans?
Do you remember how Googling was a skill?
Learning to Copilot, Stable Diffusion, GPT are exactly the same thing.
Copilot's full power (at this time) does not exist in generating reams of code. Here are a few things it excels at:
- Snippet search: Say you can't remember how to see if a variable is empty in a bash conditional, ask.
- Template population: Say I have a series of functions I need to write in a language without good meta programming facilities. I can write a list of the (all combinations), write one example, the ai will pick up on the rest.
- Rust: If I get trapped because of some weird borrow checker issue with `fn doit(...`, I begin rewriting the function `fn fixed_doit(...`, and 9/10 times Copilot fixes the bug.
This blew my mind. Thank you for sharing, I never thought of approaching it that way.
If you are coding in a language that requires tons of boilerplate, the solution is to use a different language that require less boilerplate.
a) Downplay the tool. Use it internally to completely crush competition by writing amazing software. License for exorbitant price to a select few partners, who will also crush their competition.
b) Hype it up as much as possible and license it to anyone who's willing to pay $10/month.
I think the rational choice is obvious, which also makes it blatantly obvious that Copilot is not seen as any kind of competitive advantage by Microsoft itself.
Microsoft has long taken the position that its interests are served by there just being more computers being used by more people to do more things (‘a computer on every desk’ etc) - not by monopolizing all computer activity. That’s more IBM’s style.
Why I’d it better to ship it than keep it?
If you have a widget that makes software developers 10% more efficient, sure you can use it to make your own developers more efficient, but if your developers currently account for 1% of all the programming productivity on the planet you just realized a value equivalent to 0.1% of global programming potential.
On the other hand if you ship it as a product in exchange for, say, 10% of the increase in value produced, you contributed a value increase to the world equivalent to 9.9% of programming output, and captured .99% of the value of the market for yourself. That’s much more than the value you could have captured yourself and you grew the market meaning you can extract even more value on the next go around.
You employ faulty economic reasoning here. Most MS tools are not unique and aren't even best in their class. In cases where they are close, MS charges a lot of money for the privilege to use them.
To put it in simple terms, if Copilot worked as advertised it would cost significantly more than VS enterprise. At some point of usefulness the logic related to selling vs using it internally would work exactly like I described. This is why many companies develop their own software and don't sell it at all even if they could charge for it.
https://blogs.microsoft.com/blog/2020/09/22/microsoft-teams-...
Microsoft is way too big to be able to make finely grained strategic decisions like that.
If a team within Microsoft want to ship something hard enough - and they can get sponsorship from the right execs (MS has thousands of execs) - they'll ship it.
I think this is bad UX actually. It should be obvious to the programmer what the arrow key will do next, the programmer shouldn't have to guess what the AI is thinking. Navigation should be predictable
The reason for this is that the IDE is an extension of the arm. The brain literally treats it as an extension of its own capabilities though processes like transactive memory. It can only reliably integrate and achieve a state of deep flow if it can form a reliable model of your external brain. If actions don't always give the same result, there's no model to integrate.
That is the whole point of the AI. It should match the user's prediction on what will happen.
Even weak/incomplete AI results tends to fuel the imagination, we can easily fill the gaps with anything from fiction or our own dreams.
On the contrary, when AI works and is strong (like with chess) we stop calling it AI and start seeing it for what it is.
Stockfish is called a chess engine. Not an AI.
And the algorithm behind current chess engines is not super smart, it is mostly brute force.
The trick is to avoid doing brute force at every move, but instead doing the grunt work once a huge computer and store everything in a compact form.
That said, Stockfish NNUE took the heart of AlphaZero (the evaluation neural net), ripped it out, refined and shrunk it, and stuck it back into Stockfish, and now Stockfish is clearly back on top and is still clearly an "engine" and not an "AI" as you say.
It seems like this will be the case for AI vs. Engine in a lot of fields going forward. A bio-inspired "AI" approach will do well. Then that thing will get stripped down and refined to the bare minimum to do some particular task, and it will then be more of an "engine".
It will be very interesting to see what this looks like for "general intelligence". That is, how many components of intelligence are separable and distillable into engines? E.g. reasoning, creativity, knowledge, foresight, etc.
And this can clearly be done to cover a wide range of useful things.
But I would make two observations, first, neural nets are much more closely related to applied statistics than biology mimicry. The historical name should not matter much but it does because humans are driven by emotions, even in research.
Second, AGI is still too badly defined to be seriously discussed.
Every time people can observe some progress in the AI field, they are tempted to make predictions that, in my opinion, are impossible to make.
We're getting closer. That's all.
Stockfish NNUE is a much simpler neural net that's just a really strong, static evaluation function, not doing its own search and therefore the engine can search further and get the most out of the data(transposition table, continuation tables etc) generated by that search.
I think the AlphaGo architecture makes more sense for Go than the chess family of games, but that's a different discussion altogether.
1) have the software requirements codified to a near-coded state already
2) have a validation/verification test suite that validates the software generated works correctly
Both of which increase the overall complexity to the point that the AI will be of minimal value-add.
The input specification isn't the documentation. Requirements are problem specification/description, AIs can't read mind.
AI generated documentation is an interesting idea. Like unit tests for AI code, it would still require perusal/editing.
I don't think people are just sitting around. From my observations, there's a mad race happening right now.
Disagree based on my own experience using CoPilot, but it would be interesting to think about ways to fairly test this.
> Reweighting these potential choices with the most likely given the current context and showing only the most likely is a solvable AI problem.
Not sure about other editors, but for JetBrains IDEs at least this has been a thing for a while: https://www.jetbrains.com/idea/guide/tips/enable-ml-code-com...
And here in lies the rub, 90% of the time, the engineers intent is wrong. That’s what real pair programming will help you with and what an ‘ai pair programmer’ will not. It just helps you build something that’s probably wrong faster.
It takes some time to learn what copilot is capable of and how best to prompt it, but I'm my experience it very quickly pays off.
The linked video seems like most comedy - optimized for laughs instead of describing reality, I don't think it is relevant.
You cannot serialize your brain and transmit it around the world in 5 seconds, but AI will.
What a human can do is encode thoughts into words, and transmit them to people one word at a time with the hope they will understand them, but it's incredibly inefficient.
Humans have infinitely shitty and limited I/O. AI will have any I/O it wants.
AI won't need to encode their thoughts into words. They will be able to send a neural circuit directly to their peers over the network.
The handicap will be so absurd that we will be their pets.
I use CoPilot in all or my development modes except for the LispWorks IDE. I find it very useful, especially when I toggle over multiple code completions, picking the best one. It is not as much about writing code for me as it is saving time looking up documentation. I usually work in Emacs with a REPL so checking generated code is quick.
You can let it draft an initial approach to a small task and then you refine it, I've found this works well, and in practical terms, I end up less tired after working in collaboration with Copilot.
I don't expect it to give me the perfect answer, and it doesn't remove the need for tests (which it can also help creating). But as an assistant? It rocks.
I don’t dismiss them, but I do put a low weight on arguments of the form “AI is not there yet” give how far it has come in the last 5 years. By 2030, I can see a product understanding the context of a system from multiple repos and, given an intent, producing code and deployment infra that adds new features respecting constraints
This is good. A single dev will be able to do the work of a full team and then every small business will be able to develop software that suits their specific needs with a couple of dedicated employees
The pure programming people have trouble scoping out which solutions to try due to lack of experience. The pure ML people code in Python notebooks and have little visibility into these issues.
Both folks could easily learn the other side and help, but it’s surprisingly rare to see.
Matt Calder thinks he's teaching us something about AI, but he's really just teaching us something sad about Matt Calder.
[1] Report: http://www.chilton-computing.org.uk/inf/literature/reports/l...
[2] Video of the public debate: https://www.youtube.com/watch?v=03p2CADwGF8&t
