My parents didn't have a lot of money, but my great-grand father passed and they used some of the inheritance to buy the computer. I was instantly hooked. In hindsight I see how much of a gift my family gave me.

The announcement reminded me of article John Dvorak wrote around the same time. 1GB hard drives had just come out, and he asked what all the extra space would be used for. Even as a young teenager, I remember thinking how short sighted that comment was. That was before I realized how the tech press tends to get stuck in local optimizations, and can't understand the bigger picture.

It's all a good reminder that cutting edge today doesn't stay cutting edge very long, and the world figures out how to squeeze every ounce ounce of power out of hardware. (Also, yes, that leads to bloat...)

[1] https://en.wikipedia.org/wiki/I486SX

[2] https://en.wikipedia.org/wiki/John_C._Dvorak

Thanks for sharing. :-)

I am using a variation of spec-driven development.

It ended up being a missing semicolon in an odd spot and the compiler was just confused.

I remember walking homing thinking, "hey, if I can survive that, maybe I can just hack this CS thing..."

To clarify my question: Based on my experience (I'm a VP for a software department), LLMs can be useful to help a team build a theory. It isn't, in and of itself, enough to build that theory: that requires hands-on practice. But it seems to greatly accelerate the process.

I also strongly agree with Lamport, but I'm curious why you don't think Ai can help in the "theory building" process, both for the original team, and a team taking over a project? I.e., understanding a code base, the algorithms, etc.? I agree this doesn't replace all the knowledge, but it can bridge a gap.

100%. Again, if we only focus on things like context windows, we're missing the important details.

> For me it’s meant a huge increase in productivity, at least 3X.

How do we reconcile these two comments? I think that's a core question of the industry right now.

My take, as a CTO, is this: we're giving people new tools, and very little training on the techniques that make those tools effective.

It's sort of like we're dropping trucks and airplanes on a generation that only knows walking and bicycles.

If you've never driven a truck before, you're going to crash a few times. Then it's easy to say "See, I told you, this new fangled truck is rubbish."

Those who practice with the truck are going to get the hang of it, and figure out two things:

1. How to drive the truck effectively, and

2. When NOT to use the truck... when talking or the bike is actually the better way to go.

We need to shift the conversation to techniques, and away from the tools. Until we do that, we're going to be forever comparing apples to oranges and talking around each other.

"Review and create a spec for "

It gives you a good starting point to jump off from.

I've been building a programming language using Claude, and this is my findings, too.

Which, after discovering this, makes sense. There are a LOT of small decisions that go into programming. Without detailed guidance, LLMs will end up making educated guesses for a lot of these decision, many of which will be incorrect. This creates a compounding effect where the net effect is a wrong solution.

> I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.

I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.

Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!

I would argue we still need the knowledge: the principles aren't changing, and they are needed to be truly productive in certain things. But the application of those principles _are_ changing.

The section "What Even Is Programming Anymore?" hit on a lot of the thoughts and feels I've been going through. I'm using all my 25+ years of experience and CS training, but it's _not_ programming per se.

I feel like we're entering an era where we're piloting a set of tools, not hand crafting code. I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse. We'll still need to craft things by hand, but we're opening some doors to new methodologies.

And, right now, those methodologies are being discovered, and most of us are pretty bad at them. But that doesn't mean they're not going to be part of the industry.

This isn't to say we shouldn't think critically about the use and performance of models, but "Not Even Bronze..." turned me off to this critique.

https://newsletter.pragmaticengineer.com/p/code-review-on-pr...

1. Write plan 2. Ask Claude to review for understandability 3. Update as needed until it's clear 4. Execute the task(s) in the plan.

I'm finding Claude gets much further on the first pass. And I can version the plans.