virgilp

I wonder how knowledgeable in compilation was the engineer that attempted this. I'm pretty confident that I could produce a decent C compiler in a few weeks (or less), if given Opus 4.7 + unlimited tokens + a good test suite. (and this is not blind unsubstantiated belief in AI, I've recently rewritten a somewhat sophisticated interpreter in a week with AI; and have worked on several C++ compilers in the past, including a GCC port to a custom DSP, so I have a bit of an idea about what this would take).

But yeah, this is not a "one shot" project, none of it is. One shot doesn't work even with humans - after all, this is exactly what killed waterfall as a methodology.

you can absolutely know. they do suspiciously well. you just give harder problems until they can't solve it. how they react/approach a problem that they can't immediately solve _is_ the interview - not the "how many things they solved correctly" part.

That said - I seldom need people to be hardcore algorithm solvers What I typically did was a variation of fizzbuzz (can the candidate code very basic logic?) and then finding a bug or minor requirements extension in their online screening test/"homework" and asking them to solve that on the spot (did they write the code themselves/can they modify it). It's typically enough, there's diminishing returns to test more in-depth the programming skills - the rest you can discuss domain knowledge, general experience, working style etc.

To be fair it doesn't say "you can't score a goal" or "you can't kick the ball", it says you can only decide to _try_ to do that. But agree it's not that deep as they seem to think, you can take this line of thinking further as much as you want (you can try to move your leg but perhaps due to injury or external blockage it won't move; so all you can really do is "desire" not "decide"? Is there some very deep meaning to this? And what even is this "you" that we are talking about?)

One thing that is worth pondering is what parts of the "old wisdom" (if any) are no longer true. Because the set of "common sense knowledge" has a tendency to mutate in time. Take the first statement:

> Impactful software tends to be written by many humans that need to collaborate.

This was definitely true. Is it still true to the same extent/ in the same way? Not obvious...

In Romania I think they just gave back the money (or maybe it was on a voucher with "if you don't use the voucher by date X, we'll refund the money"). which is in stark contrast with how other low-cost airlines like WizzAir behaved. Perhaps it was regional policy; or perhaps it was due to their previous interactions with UK regulators? But for me, they gained a lot of respect for them back then (whereas WizzAir is on the "only if absolutely no other choice" list - and I think I only used it once, for a business trip where it had a good direct flight AND I didn't care if I actually made it to the destination, or if I got stranded there for a few days - since the company would've been paying)

I kinda' like Ryanair as lowcost airline? They're fairly efficient (boarding, serving etc), they _actually fly_ the advertised flights (with relatively few exceptions), and the food is reasonably priced. During COVID they would just give your money back, no shenanigans like "they're in our company wallet". Sure they have their quirks but they don't seem to go out of their way to deceive you, they're pretty open about what you pay and what you get.

Now Wizzair is "mostly not an airline" for me, because they have all the negative traits I hinted above. E.g. they'll happily advertise flights they have no intention of flying, make refunds hard, are as misleading as they can be about pricing, make it impossible to checkin online a few hours before the flight so that you have to pay their high fees, etc.

I wouldn't want the Ryanair experience for long-haul flights; but for short 2-3h ones within Europe, they're fine, I'm always considering them. Not for the perceived cheapness, but for the "I expect them to actually fly AND be on time" part.

If your feedback loop is hours or days, I don't think it's bad you spend some time thinking ahead of doing. Oh, you missed the unknown unknowns? You'll hit them soon enough anyway, this is not a model that encourages abstract planning with no action taken, for extended periods of time....

The problem with "AI zealots" is seldom that they spend too much time planning ahead. If anything, it's the opposite.

Waterfall was bad due to the excessively long feedback loops (months-to-years from "planning" to "customer gets to see it/ we receive feedback on it"). It was NOT bad because it forced people to think before writing code! That part we should recover, it's not problematic at all.

qa has long ago merged with programming in "unified engineering". Also with SRE ("devops") and now the trend is to merge with CSE and product management too ("product mindset", forward-deployed engineers). So yeah, pretty much, that's the trend. What would you trust more - an engineer doing project management too - or a project manager doing the engineering job?

I honestly don't see how this is related? Nothing says "one shot a full system from a perfect specification", I don't think this was ever a goal (or that it will be practical to do so)

Actually, no. We always needed good checks - that's why you have techniques like automated canary analysis, extensive testing, checking for coverage - these are forms of "executable oracles". If you wanted to be able to do continuous deployment - you had to be very thorough in your validation.

LLMs just take this to the extreme. You can no longer rely on human code reviews (well you can but you give away all the LLM advantages) so then if you take out "human judgement" *from validation*[1], you have to resort to very sophisticated automated validation. This is it - it's not about "inventing a new language", it's about being much more thorough (and innovative, and efficient) in the validation process.

[1] never from design, or specification - you shouldn't outsource that to AI, I don't think we're close to an AI that can do that even moderately effective without human help.

Also: if that one particular AI-produced compiler has nothing innovative, that only means that the human "director" behind the AI didn't ask it to produce anything innovative; what it does not mean is that AI can never produce anything innovative in a compiler.

"Waterfall" got a bad rep because it meant "we stay months in the requirements gathering, then months design phase, then months in development, then months in validation". If you compress "months" to days/hours, what you obtain is something that nobody from the 90s would recognize as "waterfall"; it is not the end of agility, far from it.

Cool but it is not a framework for working with AI, it is an _opinionated_ framework for building full-stack apps right? As in, I can't use any of it if I'm building, say, a Spark data processing pipeline. Or a ML framework. Or automation software that runs on custom processors.

The idea of "guardrails outside the model" is definitely appealing but I wonder if you can make it generalize well.

No, OP literally claims "you can't spec out something you have no clue how to build"; I claim that on the contrary, you absolutely can - you don't need to know "how to build" but you need to clarify what you want to build. You can't ask AI to build something (and actually obtain a good "something") until you can say exactly what the said "something" is.

You iterate, yes - sometimes because the AI gets it wrong; and sometimes because you got it wrong (or didn't say exactly what you wanted, and AI assumed you wanted something else). But the less specific and clear you are in your requirements, the less likely it is you'll actually get what you want. With you not being specific in the requirements, it only really works if you want something that lots of people are building/have built before, because that will allow the AI to make correct assumptions about what to build.

Nothing of what you write here matches my experience with AI.

Specification is worth writing (and spending a lot more time on than implementation) because it's the part that you can still control, fully read, understand etc. Once it gets into the code, reviewing it will be a lot harder, and if you insist on reviewing everything it'll slow things down to your speed.

> If the cost of writing code is approaching zero, there's no point investing resources to perfect a system in one shot.

THe AI won't get the perfect system in one shot, far from it! And especially not from sloppy initial requirements that leave a lot of edge (or not-so-edge) cases unadressed. But if you have a good requirement to start with, you have a chance to correct the AI, keep it on track; you have something to go back to and ask other AI, "is this implementation conforming to the spec or did it miss things?"

> five different versions of the thing you're building and simply pick the best one.

Problem is, what if the best one is still not good enough? Then what? You do 50? They might all be bad. You need a way to iterate to convergence

> Nothing persists after the session ends.

Does that mean that if I exit claude code and then later resume the session, the database is already lost? When exactly does the session end?

> after my old Volvo dies

That's another 20 years mate.

It's relative, not absolute. It's definitely more dangerous to not know how to make your own food than to know something about it - you _need_ food, so lacking that skill is more dangerous than having it.

That was my point, really - that you probably don't need to know "materials science" to declare yourself competent enough in cooking so that you can make your own food. Even if you only cooked eggs in teflon pans, you will likely be able to improvise if need arises. But once you become so ignorant that you don't even know what food is unless you see it on a plate in a restaurant, already prepared - then you're in a lot poorer position to survive, should your access to restaurants be suddenly restricted. But perhaps more importantly - you lose the ability to evaluate food by anything other than aspect & taste, and have to completely rely on others to understand what food might be good or bad for you(*).

(*) even now, you can't really "do your own research", that's not how the world works. We stand on shoulders of giants - the reason we have so much is because we trust/take for granted a lot of knowledge that ancestors built up for us. But it's one thing to know /prove everything in detail up until the basic axioms/atoms/etc; nobody does that. And it's a completely different different thing to have your "thoughts" and "conclusions" already delivered to you in final form by something (be it Fox News, ChatGPT, New York Times or anything really) and just take them for granted, without having a framework that allows to do some minimal "understanding" and "critical thinking" of your own.

That's not how things work in practice.

I think the concern is not that "people don't know how everything works" - people never needed to know how to "make their own food" by understanding all the cellular mechanisms and all the intricacies of the chemistry & physics involved in cooking. BUT, when you stop understanding the basics - when you no longer know how to fry an egg because you just get it already prepared from the shop/ from delivery - that's a whole different level of ignorance, that's much more dangerous.

Yes, it may be fine & completely non-concerning if agricultural corporations produce your wheat and your meat; but if the corporation starts producing standardized cooked food for everyone, is it really the same - is it a good evolution, or not? That's the debate here.

I'm wondering about that. I think with the advent of AI, we might see a new kind of successful software company - one that doesn't sell a single solution to many customers, but instead has the building blocks, prompts (agents skills etc) & processes to quickly build very custom solutions for each customer - using a new blend of engineers that are not exactly "customer support" nor traditional "sw eng", but more around the emerging "forward-deployed engineer" role.

This is an interesting thing that I'm contemplating. I also do believe that (perhaps with very few exceptions) there are no "10x engineers" by themselves, but engineers that thrive 10x more in a context or another (like, I'm sure Jeff Dean is an absolutely awesome engineer - but if you took him out of Google and plugged him into IBM - would he have had the same impact?)

With that in mind - I think one very unexplored area is "how to make the mixed AI-human teams successful". Like, I'm fairly convinced AI changes things, but to get to the industrialization of our craft (which is what management seems to want - and, TBH, something that makes sense from an economic pov), I feel that some big changes need to happen, and nobody is talking about that too much. What are the changes that need to happen? How do we change things, if we are to attempt such industrialization?

Definitely not a visionary. This is how you do it in 2025: https://imgur.com/rWiP90P

Yeah but you can also have a disaster strike in that place (say, a nuclear accident) that will obliterate your real-estate value. Or general society changes that will make a city much less desirable (see the "rust belt"). Of course, nothing is without risk - so in that sense, it's not surprising that real-estate has risks. But that's what I wanted to underline, nothing is "inflation-proof". There's no guaranteed way to preserve wealth (much less increase it). None.

This is some data about US:

https://today.yougov.com/ratings/entertainment/fame/people/a...

Zuckerberg is 49, Sheeran is 169 (Taylor Swift is on 4; Bieber, Lady Gaga and Beyoncé are also more famous than Zuckerberg; the rest in the list are less famous)

a million ways, but e.g: once in a while, add a "challenge" header; the next request should contain a "challenge-reply" header for said challenge. If you're just reusing the access token, you won't get it right.

Or: just have a convention/an algorithm to decide how quickly Claude should refresh the access token. If the server knows token should be refreshed after 1000 requests and notices refresh after 2000 requests, well, probably half of the requests were not made by Claude Code.

Because of many reasons. It's not practical to have a Starlink antenna with you everywhere. And then yes, cost is a significant factor too - even in the dialup era satellite internet connection was a thing that existed "everywhere", in theory....

I never claimed "hardest". And yes, block3 being as of right now still unproven is another reason to say "not almost done with the hard parts yet".

I wouldn't say "almost done" - orbital refueling is likely one of the hard parts, and it wasn't attempted yet.

No, they are quite identical. Both cases logically lead to "now everything has the same priority". There's nothing about generalism in there.