But this doesn't seem to make sense when someone comes to a topic with an LLM in-hand. They need to know high-level techniques, architecture, best practice, etc. As they pursue the topic they start to get down into the details, although probably never learn to do it fully independently.
I quite like this view because it paints a somewhat optimistic way forward from where we are now.
High-level techniques were never a problem. You could Google tens of articles on this topic. They are useless too, it's like learning how to drive a racing bicycle from reading a book. Sure, you will know a lot about nuances, but you will fail miserably when it comes to a real race.
I had the experience to keep calling out AI to simplify and downgrade the solution to something primitive, which ended up smaller, faster, easier to maintain. Juniors with real world experience would not bother, they’ll take the first working AI result.
I disagree, the definers of taste; art and food critics, movie and book reviewers, don’t need to have learned the craft by doing. Taste is a separate skill.
Taste in coding is a combination of insight, experience, native talent, technical skill, and flair. Tasteful coding produces clever but straightforward minimal elegant solutions that an average developer can't imagine but can adapt and maintain.
Taste implicitly requires discipline of what one chooses to expose themself to and what not to.
I hope this isn’t the case. It is the route I took, but it also doesn’t seem to be a likely route going forward. Strong CS grounding is feasible for sure, but I have a hard time believing that a meaningful number of people will be spending the requisite years coding manually.
e.g. The "group" abstraction requires one see a lot of int, polynomial, modular arithmetic etc. before knowing why we want such a thing. It's unskippable.
It's hard to claim one has mastered a subject without independent command of its fundamentals. A less charitable take on this future is that students only learn to hand-wave answers and correspondingly cannot evaluate statements beyond "sounds about right".
If that's happening, that would be a weird way to teach CS in my opinion.
In my undergrad program, languages and syntax were learned on your own. Class material and lectures were all conceptual.
That awareness of how to structure the English language, it will benefit those who use LLMs.
Then again, maybe someone will just make a LLM that’s built to turn poor English and poor reasoning into excellent English and excellent reasoning. Maybe this is just a technical puzzle that needs solving.
> Then again, maybe someone will just make a LLM that’s built to turn poor English... into excellent English
That's already been done, for some (pretty weird) definition of "excellent".
I work with, or at least in the vicinity of, someone who is very good at getting work out of LLMs. He has a whole system of CLAUDE.md files and skill files and things. He makes TONS of typos. When I first saw that, I was itching to go in and fix them all, it seemed viscerally wrong to be adding an extra layer of correction required between the instructions and the LLM's behavior. But in practice, I don't think it mattered at all. The LLM didn't care. Typos in particular might require a bunch of RLHF in the chatbot, but my hypothesis is that the LLM is already mapping messy human input to the nearest surface of some high-dimensional manifold and the added noise of typos is inconsequential to where it ends up (as long as there isn't any real ambiguity -- though even there, you could probably construct cases where that would help rather than hurt!)
Typos are different from sloppy writing, but I think the AI companies have put a lot of work into training these chatbots on dealing with typical non-English major writing with all of its imprecision. Also, it's easier to construct cases where that imprecision and sloppiness would help rather than hurt: a mistake in the input that is common enough to show up in the training data is going to be a good match for the needed correction as well as associated corrections. The precise language could easily result in the LLM overestimating the user's competence.
That doesn't address whether an English major's careful composition would help for hard tasks where getting the specification right really matters -- perhaps that was your point? I guess it's an open question whether "boiling away the typos" and "boiling away a poorly articulated specification" are related enough.