Correctamundo. That's EXACTLY what I just wrote about. And how we'll create the next generation of people who know how to evaluate responses when we're creating a generation of people who are increasingly reliant on LLMs to do the work makes for a strange paradox.
It's so obvious to some and may never be considered by others.
If someone asks about AI I tell them step 1 is ask it how to do something you know all about. Step 2 is consider everything else you ask will be that inaccurate.
As a dev with three decades experience writing code, I use it for stuff I know all about all the time. And these days, the majority of the time it is more correct than I would've been without a few iterations of trial and error.
>The skills to do so, however, are a function of someone who has experienced the friction and challenges over time that culminate in "good taste".
It's certainly sometimes true, but I don't think it's a general rule. Sometimes friction is just friction and sometimes you spend 1000 hours learning something that disappears and becomes obsolete or at least irrelevant to the goal.
Programmers used to need to know the instruction set of the CPU, assembly language and so on. Some still do but for most developers today that's not useful. Everything you know about 6800 assembly will not make your note-taking app any better.
I think we are in a state where AI tools so easily mimic what we used to do by hand that we think the friction is gone, but that's because we haven't raised the bar yet. One day we'll look at the Fable one-shot that's better than anything we ever made by hand ourselves and say "It could be even better".
And then the friction is back, just on a new level.
> Everything you know about 6800 assembly will not make your note-taking app any better.
It could. It could make a simple note-taking app not take gigabytes of memory and take visible delay on each click. Most people don't bother of course because simple note-taking app is not worth the effort. It's possible to do better, it's just often not practical.
>It could. It could make a simple note-taking app not take gigabytes of memory and take visible delay on each click.
But the taste that tells you a note taking app should be fast doesn't come from your knowledge of assembly. It comes from using the app.
Being able to have an AI generate 8 variants of an UI and 5 variants of a storage mechanism is more helpful to reach the goal of a good note-taker. Trying out those prototypes and tweaking them to perfection is also friction, only it happens closer to your actual goal than doing quicksort in assembly.
There are of course examples where the friction does help, and where the "aid" of the tool deteriorates useful skills, but I think that will sort itself out over time. Useful skills will remain, useless ones will disappear, as they always have.
Question from the peanut gallery here. Why not just train an LLM to write in Assembly? Or bare metal? Validate by compiling. Or binary, no compilation needed. Can't a frontier LLM find the bugs better than we? As long as the program is built from small, verifiable subunits, the pragmatic problem of creating an efficient program is in every careful planner's reach. Seems the friction is nearly gone.
I have no skin in the game here, but this is a developing (no pun intended) expectation for me.
> Everything you know about 6800 assembly will not make your note-taking app any better.
For most apps, it makes sense to profile your app for expected use cases. Put even minimal thought into making the hot codepaths faster by moving unnecessary operations out of it.
Great article… been worrying about this one quite a bit:
> If these tools demand expertise, yet the tools can actively circumvent the friction that cultivates expertise, then what is the path for one to become an expert so they can effectively use these tools?
I am not sure if I'm ignorant or have too much self esteem, but in cases where domain is not my expertise I try to cross challenge using different models to get less-biased and hopefully more correct insights.
I’m not trying to be snarky, but.. I wouldn’t try to upgrade an answer from a stranger you can’t fully trust to an expert answer you can trust by asking more strangers who have all only read the same books and use the same system for summarizing the books.
Similarly, sometimes I have to manually validate the output of an ai tool, analyzed over a large text I can’t practically read and understand, and best way I’ve found is to ask the tool (or another ai) to ‘show your work,’ ie make it help me make the determination by showing places in the text I have to read to follow its reasoning. We can never trust another ai directly to assess the validity of another ai.
This is some work that I want to see in education. How do you validate if something is true or not.
A lot of times that will take physical tests. Or in the case of math/logic, tests to validate each line or validated sources of previously proved theorems
You use the scientific method. Make a guess about how the system works, do experiments aimed to show that's not the case, adjust guess accordingly, and repeat
This works only when the inputs and conditions are all the same. In the real world, that isn't really possible anymore for a lot of things, like data sciences operating within a large pulsating mass of live net.
The paradox is analogous to AI poisoning its own training data as more and more AI generated content is released on the Internet. Indeed, I see a hard terminus for both man and machine at some point.
Absolutely right. First gen models are trained on 'virgin' non-LLM output. Subsequent models are tainted by ingesting AI replies. Rinse and repeat, and all you end up with is AI copies of AI replies, and the noise will completely overtake the signal.
Industry reality is that for bespoke software solutions we have been running for decades on non-technical people straight out of a 5 day "boot camp" copy/pasting together "solutions" from SO, or "Sharepoint Configurators" cobbeling together a LoB process where is takes 3 minutes to get to the next screen with a 10% error rate etc.
If someone asks about AI I tell them step 1 is ask it how to do something you know all about. Step 2 is consider everything else you ask will be that inaccurate.