Devils advocate: Are they? Why? If LLM's are capable of taking absolute crap and iterating on it to achieve a purpose, then does readability really matter?

Awesome. Similar experience to me. Was selling some sim racing gear, and he mentioned he was in fabrication. Now he's my fab guy and we chat heaps.

Most of my local music production buddies I've met by selling and purchasing second-hand music hardware, as I always sell/buy stuff in driving range, and it's a nice excuse to meet people who like the same stuff as you :) Lots of ways to meet people like this, depending on what you're into.

How does one even go about finding a root cause so exotic?

I'd bet lots of telemetry, comprehensive design and change documentation, along with engineers tacit knowledge.

Something like:

telemetry shows dramatic drop of temperature on this, that given the location of the sensor could only be caused by a specific LOX line leak, and vibration sensors show data compatible with friction as the ignition event and not a short circuit because the relevant telemetry doesn't show any electrical abnormality, so, by exclusion, given no other anomalies, give that computer simulations show it is a feasible scenario, followed by lab work with a physical model, this must be the cause of the accident.

Engineering cameras all over the bottom of the pad will probably be what they use. I'm sure they have high speed cameras looking directly up at the bottom of the engines like SpaceX has. They'll watch frame by frame and then confirm with sensor data or the other way around. Maybe a manufacturing defect caused a turbopump housing to rupture? The energy densities are so crazy in rocket engines that would probably be like 3 sticks of TNT going off. The propulsion engineers are intimately familiar with the engines they probably already have a good idea.

Yeah, but at the end of the day you can't be sure right? That doubt would eat away at me

The doubt is supposed to stay with you! You need to make sure there aren't other causes or contributing factors hiding behind 'the obvious'. There have been notorious cases in spaceflight where the issue was 'identified' and 'fixed', only for the same thing issue to happen in the next mission.

> There have been notorious cases in spaceflight where the issue was 'identified' and 'fixed', only for the same thing issue to happen

In software development this is your average weekday.

Nothing of the level of rocket failure, but I've tracked down issues where you are never sure of the cause. You keep the doubt and let it drive you. You aren't as much sure of a theory, as you have the theory you most want to disprove and keep failing to do so. The more you fail to disprove a given theory while other people with their own personal 'targets' do end up disproving them, the more you can report that the theory is the reasonable conclusion. But you never given up the idea of looking to disprove it. Eventually others join you and work to disprove your theory. As the group continues to fail to disprove it, it becomes the officially stated cause unless someone can provide evidence otherwise.

Sometimes I'll have one that I'm stuck on for a month before finally disproving it, and it is an interesting feeling. There is some level of happiness I succeeded at my goal, but it is very bittersweet because it normally was my last working theory and now I'm simply lost until I can formulate a new one. Sometimes disappointment in myself that I might've missed some easy way to disprove it for so long, but other times the way to disprove it was sufficiently hard enough that I just accept it is what it is.

I love it. Easy to write and understand

Maybe I'm solving different problems to you, but I don't think I've seen a single "idiot moment" from Claude Code this entire week. I've had to massage things to get them more aligned with how I want things, but I don't recall any basic syntax or logic errors.

With the better harness in Claude code and the >4.5 model and a somewhat thought out workflow we’ve definitely arrived at a point where I find it very helpful. The less you can rely on one-shot and more give meaningful context and a well defined testable goal the better it is. It honestly does make me worry how much better can it get and will some percentage of devs become obsolete. It requires less hand holding than many people I’ve worked with and the results come out 100x faster

I saw a few (Claude Sonnet 4.6), easily fixed. The biggest difference I’ve noticed is that when you say it has screwed up it much less likely to go down a hallucination path and can be dragged back.

Having said that, I’ve changed the way I work too: more focused chunks of work with tight descriptions and sample data and it’s like having a 2nd brain.

Very good way to describe it. I am enjoying Opus a lot.

I've been on the site for 10m, and I'm loving it. I find the interface quite confusing. I'm getting value from the theory tidbits, and the scenarios. The simulation was confusing and i just noped out. I'd say the UI is a bit too overdone

Thanks for investing 10 minutes! Hearing that the theory and scenarios provide value is huge for me.

I suspected the UI might be too "loud." It’s a delicate balance between style and usability, and I might have pushed the brutalism too far.

Regarding the Simulation "nope out" moment — was it simply unclear what to do (lack of buttons/direction), or was the screen just too overwhelming with numbers?

Unclear what to do. I obviously could have invested another 30s and figured it out.

I really like the scenarios - i think there's a lot of value there. I wonder if you can double down on that somehow.

Ah, got it.

Thanks again, I still need to work on the user interface to make things clearer and more understandable.

I don't code in Python much. Are those type annotations really how people are using them, or is it just for the example?

    def list_files_tool(path: str) -> Dict[str, Any]:

And it returns

    {
        "path": str(full_path),
        "files": all_files
    }

Is that useful?

We do this via run in TS:

    export const run = <T>(f: () => T): T => {
      return f();
    };

Can you clarify why do you prefer this over an IIFE `(() => {...})()`?

I like it. IIFEs always make me nervous because they look like they beg to be removed if you don't know why they are used. Using an explicit function such as `run` looks much more intentional, and provide a single intuitive place (the documentation of the `run` function) to explain the pattern.

Do you use plan mode? Do you link specific files as reference using @? Those two alone make a big difference for me.

Yeah that is the thing that has me confused. I specify the exact files with the @ sign and it still gets caught up on wanting to run batch commands to search for specific patterns. Do you use Sonnet or Opus?

I've never used it, but watched from afar. So many interesting ideas. The website is also really good. Congrats Paul and team