Oh my god thank you. I have been trying to put into words what is so draining about pair programming with claude, and “doing creative work to impart meaning to the words” is exactly it.
this seems like more anthropomorphizing. even if it has similar results often enough to be useful, next token prediction is not searching a solution space.
you even end with a paragraph saying “it’s not too dissimilar from what we do”. how is that not anthropomorphizing?
and if what we do isn’t “thinking” then what is or ever has been?
> next token prediction is not searching a solution space.
Interesting take. Next token prediction (via the attention mechanism) is a "walk" through the token embedding space. Searching the solution space is what it does, mathematically. It's how we take tokens x context length possible combinations and prune them to converge on viable answers so quickly.
Does it look like search at inference time? No.
With given weights, a given prompt, and a given random seed, you get the exact same answer. There's not much searching happening at inference...
The key is that most of that space is searched at training time. The weights implicitly prune the search space, blocking off or make certain token combinations effectively impossible. It's easy to think "we're just applying weights at inference time" without considering all the pre-work that's done to prune that search space.
Which is exactly why "thinking" traces (and randomization) are useful! They bust out of any local optima created by too-tightly-constrained models or system prompts. It's both useful and technically correct to speak of the process as a high-dimension combinatorial search.
I agree with the idea that the taste, for lack of a better word, was the only thing that ever mattered. What I disagree with is the idea that slop that is “good enough” is indistinguishable from something that is crafted is “indistinguishable by the market”. I think it is indistinguishable in the short term, but very distinguishable on a long enough time span. The same way that hacked together slop has always been “good enough” to close a ticket and even get someone a promotion, but later costs the company thousands of engineering hours to rewrite once it becomes completely unreliable, slow and impossible to modify. We’re just speed running that now. It’s the same battle engineers with “taste” have been fighting with sales teams and product managers and lazy teammates before LLMs, just in fast forward.
I started toying with perlin vector fields as a level design tool for a game idea, then became more interested in visualizing them than the game they were meant to support. this weekend i realized i think im making a (short) ~game in which you control a dust mote riding air currents, trying to gather enough water to fall back to earth as a raindrop
In the 1990's and early 2000's I loved building web and flash games, people had lower expectations, getting notice was easy (StumbleUpon etc) and there wasn't a lot other choices.
Does anyone here know any mathematicians who can’t do long division or basic algebra?
Probably not, because they *don’t exist because learning basic math is necessary to learn higher level math*. Whether or not we have calculators to do basic math is irrelevant if you want to become a mathematician.
I’d argue that “whether or not the average dev will be writing any code by hand in 5 years” is irrelevant to whether or not one should learn to code *if they want to master designing and building complex software* using whatever method they will be using.
I take the opposite view but to the same conclusion. I've heard the joke "the more advanced you get the worse you get at math" from a lot of mathematicians. I'd bet most mathematicians can't do a long division problem without having to think pretty hard about it, because they've long since moved past that skill.
All that said, people still learn and do manual math at all levels in order to advance the field even though calculators and python notebooks exist.
I think people get too wrapped up in LLMs being the entirety of the future when the LLMs themselves are entirely a product of the past. An LLM is less a thinking machine than a lossy JPEG for language and to an extent, knowledge represented in language. As such, if you want to expand the field and move into the future you aren't going to rely solely on an algorithm that reverts to the mean.
I think a major difference between math and software development is that software development tends to get easier after one gets through the educational barrier to entry, whereas math (and many other topics) become more complex/puzzly. Something that could highly accurately revert to the mean would be insanely useful when the overwhelming majority of what you're doing is mundane and has been done a million times before - the analog of something like basic arithmetic or calculus.
Take for instance most CRUD apps. They're all doing basically the same stuff just with variations on interface/schema. And that's a huge chunk of all professional software development. We're already at the point where you can describe said schema/interface and get a pretty good implementation of it, and things will likely continue to only get better. I think the job-apocalypse is unlikely, but I also think it's unlikely that 'manual coding' will be anywhere near as significant a part of the economy in the future as it is today.
I agree with the second part, 90% of apps are just a vague rehashing of 100 other apps, very little novel software ever gets written, especially at the component level. The point being that if you want to create truly novel systems you best know how to program, even if an LLM is writing the less novel parts of that system.
If we're smart about this, maybe it means we get to do novel work a little more frequently. That said, I fear that a lot of people don't look at every single LLM output and think "Eh it's workable but it doesn't spark joy" and anyone who doesn't think that is likely going to be seeing their QOL decreasing. At that point your time might be better spent learning how to make Molotovs.
I'm in the same boat! It's a reasonable stance but the specific examples aren't air tight. I'm a Mathematician and I can't do long division, I could probably work it out? Like you say, long division was part of a journey that made me very mathematically capable, even if it's no longer an active contributor. My capacity for pencil and paper calculus is undoubtably many many fold worse than my peak around undergraduate studies!
I'm not anymore, but I used to be a research mathematician. I absolutely cannot remember how to do long division, though I was certainly competent at it at one point. I'm also terrible at mental arithmetic these days.
These things were still indispensable on my path to being a mathematician though, they just ceased to be relevant as abstraction increased.
I feel like "I can do X" always comes with an implied timescale and a degree of confidence. For example, I "can" speak Chinese, in the sense that I have no reason to believe I cannot: Chinese people do not have fundamentally different mouths or brains to me. But still, even after many years of study and practice, you might be disappointed in my ability. If I were you I would not have any confidence in my ability in Chinese.
On the other hand, if I were to hire you to perform long division I would have complete confidence in you turning in your first calculation within an hour given your research background. So I would definitely say you can do long division.
If software were a purely mechanistic task like long division then I'd have confidence in anyone being able to turn out working code within an hour too. But we can't just keep turning out new programs every time we want to change them. Even with LLMs this is prohibitively expensive. So software is really about being able to build things and maintain them over time which requires a much deeper understanding. Long division is like snakes and ladders. Software is like chess.
i don’t think anything in the article advocates for not prioritizing “single source of truth”, as in, if we know that there are multiple sources of truth for something, it should absolutely be deduped. the article is more saying “be a bit more skeptical of any two pieces of code actually representing the same thing” and “be more willing to break apart an abstraction that is trying to represent multiple truths.”
