What a reductive world view that is.

Nothing ever was solved without reductivity.

At least it shows some attempt on reflection/introspection which is rare.

As for the OP - life is negenthropy. It is by definition a complication. I don't get the complaint - if you want max simplicity just convert yourself into least possible energy state. You will lose agency but that is the point, right?

What an amazing article. I really like the presentation of text scrolling together with the code. Wonder how this is done under the hood.

Thanks a lot! The left column containing the text is sticky, The right column is absolute and translate on Y and depend on an intersection observer triggered by each scroll section from the left.

Super cool, thanks for explaining! Is the code available somewhere?

No, unfortunately, my website is not open source. I may consider externalizing the blog in the future, while keeping all the internal article modules.

But you have to know all of them to read other people's code.

To answer your question: I would immediately get rid of guard.

Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.

internal should definitely go though.

The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.

I think the ?: operator ends up being a decent alternative, e.g.

  // Swift
  guard let foo = maybeFoo else {
    print("missing foo")
    return false
  }

  // Kotlin
  val foo = maybeFoo ?: run {
    print("missing foo")
    return false
  }

Unless there's a use case for guard I'm not thinking of

It’s a decent alternative, but to someone not familiar with the language what’s going on isn’t as clear.

Could this be used for creating video editing software?

Imagine a Premiere plugin where you could say "remove all scenes containing cats" and it'll spit out an EDL (Edit Decision List) that you can still manually adjust.

Yeah, this is a great idea, I’ve actually been thinking about exactly this as the next logical step.

SentrySearch already returns precise in/out timestamps for any natural-language query and uses ffmpeg to auto-trim clips. Turning that into an EDL (or even a direct Premiere plugin that exports an editable cut list) feels natural.

I’m not a Premiere expert myself, but I’d love to see this happen. If you (or anyone) wants to sketch out a quick EDL exporter or plugin, I’ll happily review + merge a PR and help wherever I can. Just drop a GitHub issue if you start something!

Genuine question, will this actually give you the latest solid local model?

I would've thought no, because of the knowledge cutoff in whatever model you use to download it.

I think it will give you a good "starter model". But then, it ultimately depends on what you want to do with the model exactly and your computer's specs.

For example, I needed a local model to review some transactions and output structured output in .json format. Not all local models are necesserily good at structured outputs, so I asked grok (becuase it has solid web search and is up to date), what are the best recommended models given this use case and my laptop's specs. It suggested a few models, I chose one and went for it and now it's working.

To summarise, - find model given use case and specs. - trial and error - test other models (if needed) - rinse repeat - because models are always coming out and getting better

What knowledge cutoff? They all have web agents to Google it.

They all do, true. But some are better than the others in how they retrieve, digest and present you with the information. Boils down to personal preferences and experimenting.

I think this could be very useful even for regular old programming. We could treat the diffs to the code as the main source of truth (instead of the textual snapshot each diff creates).

Jonathan Edwards (Subtext lang) has a lot of great research on this.

The author never suggested to eliminate code reviews entirely. Just to give individuals more autonomy, which is great in my book.

PRs don’t really hurt autonomy if stacked branches are used routinely. Those do hurt speed, yes, but not autonomy. PRs are so important that I‘d never skip them within a team.

If you have a policy in place that forces engineers to wait for review before merging each PR, then yes, by definition they have less autonomy. It might still be worth the trade off in your situation, but I like the suggestion in the article where senior devs can decide themselves whether they want their code reviewed or not.

Hard no buddy. Junior dev means junior code and junior judgement. Countless times we had prod issues because some dev thought the change was harmless and they didn't need review.

In the article, they specifically exclude juniors and people who are still being onboarded.

I can’t find that disclaimer in the article.

OP here. In this one the closest is probably: "I love the process at Pylon: engineers merge their own code and only request reviews if they need input, think they have a risky change, or are still onboarding. "

But I fully agree that for juniors it makes sense to have it mandatory.

Your point of view is based on extreme reductionism.

It's nature.

Whether that word is reductionism is an exercise left to Chomsky?

Models are emphatically not nature.

They are at best an attempt to use our tools of reason and observation to predict nature, and you can point to thousands of examples, from market crashes to election outcomes, to observe how they can be flawed and fail to predict.

> the future is made up of 8B+ independent actors and they're going to react to incentives

= “nature”, if you're an evolutionist

as for models, all models are wrong etc.

Game theory is no more a description of nature than Euclidian geometry is.

Sure, but go try to build a house while ignoring what Euclidean geometry tells you about it.

I agree that both geometry and game theory are very useful tools.

> I've had Claude Code write an entire unit/integration test suite in a few hours (300+ tests)

I'd love to see someone do this, or a similar task, live on stream. I always feel like an idiot when I read things like this because despite using Claude Code a lot I've never been able to get anything of that magnitude out of it that wasn't slop/completely unusable, to the point where I started to question if I hadn't been faster writing everything by hand.

Claiming that software is now 90% cheaper feels absurd to me and I'd love to understand better where this completely different worldview comes from. Am I using the tools incorrectly? Different domains/languages/ecosystems?

100% agreed. I use Claude Code to write 90% of my code at this point, but have found that it is genuinely worse than a junior at writing meaningful test cases. Most of the time it will make up interfaces or mock things incorrectly etc to the point where I just give up and write them myself. The bulk of the “tests” it writes test things which are meaningless (does the interface exist etc). This is with typescript + vitest with opus 4.5.

Genuine question, if you already own an Index, why would you also get this? Wireless functionality, or something else?

I only own Index controllers, not the headset. I have a mixed tracking Pico 4 setup and wireless functionality is definitely one of the pluses; the higher resolution panels also make a significant difference (the Frame and the Pico 4 seem to have the same resolution). This is basically an open Steam-backed Pico 4 that's superior to my hardware and definitely superior to the Index. Here's a comparison:

https://vr-compare.com/compare?h1=0jLuwg808-j&h2=w8xCM-oPA

The 1000hz tracking frequency is from the Lighthouse tracking system, which the Frame loses. For that and other reasons, I am not convinced the controllers are better than the Index controllers. Personally I think it's likely I will keep using the Index controllers, since I have the whole lighthouse setup and I own trackers as well.

Thanks!

Wireless, weight, no lighthouses, standalone use, more polished rendering. It won't be prefect, but it'll be a heck of a lot better experience than what came before.