irskep

Skip the rehash and read the official announcement https://blog.kagi.com/update-orion-linux-windows

Coming from Instruments (Apple) and Chrome Dev Tools, I found the Godot profiler to be hilariously hard to get useful results out of because of its simplistic presentation of information that you can't drill down into.

I use git worktrees daily. I'm surprised by how hard it can be to explain them to people who have never used them. Lately I've settled on "like clones, but sharing a .git directory." The article tries to get this across by comparing them to branches, but I think clones are a more intuitive concept to compare against.

To solve some of the ergonomics issues (command verbosity, manual commands to copy over .env files and install dependencies), I wrote autowt, which is a lightweight but powerful worktree manager: https://steveasleep.com/autowt/

Once I dialed in the cli experience, I basically stopped typing 'git checkout <branch>' to change tasks, because it's easier to ignore working directory state when flipping between tasks.

aube was about 30% slower than pnpm in my testing on our hundreds-of-dependencies monorepo, but I'm giving it time and keeping a testing branch around. (hi jdx yes I am that guy.) Honestly this speaks to how good pnpm is more than saying aube can't get there.

I'm still opening pnpm-behavior bug reports against aube daily (boo) but they are getting fixed very quickly (yay). I'm really looking forward to seeing if it's worth rolling out once he catches up with the long tail of subtle behaviors we rely on.

Again, pnpm sets a high bar, so even if aube ends up getting faster, it's not a sure thing.

Working on mrjob was a big part of my first job out of college. Fun to see it get mentioned more than ten years later.

What some commenters don't realize about these bureaucratic IO-heavy expensive tools is that sometimes they are used in order to apply a familiar way of thinking, which has Business Benefits. Sometimes you don't know if your task will take seconds, minutes, hours, days, or weeks on one fast machine with a well-thought-out program, but you really need it to take at most hours, and writing well-thought-out-programs takes time you could spend on other stuff. If you know you can scale the program in advance, it's lower risk to just write it as a Hadoop job and be done with it. Also, it helps to have an "easy" pattern for processing Data That Feels Big Even If It Isn't That Big, Although Yelp's Data Actually Was Big. Such was the case with mrjob stuff at Yelp in 2012. They got a lot of mileage out of it!

The other funny thing about mrjob is that it's a layer on Hadoop Streaming, which is a term for when the Java process actually running the Hadoop worker opens a subprocess to your Python script which accepts input on stdin and writes output on stdout, rather than working on values in memory. A high I/O price to pay for the convenience of writing Python!

Today I'm hacking on automate-terminal, a command line program and Python library that abstracts the various terminal emulator automations (iTerm2, WezTerm, Kitty, tmux) into a single API. Mostly made for use by other tools. https://github.com/irskep/automate-terminal

I'm really excited by this development! Material for MkDocs has raised the quality level of so many projects' docs, my own included, by making good navigation the default. It's by far my favorite system to browse as a reader, and use as a project maintainer.

I hope the new theme allows for more customization than the old Material theme. It was really hard to create a unique brand identity within the constraints of Material; it just wasn't built with customization in mind beyond a color. The "modern" theme looks minimal in a way that gives me some hope for this.

Looking forward to kicking the tires on Zensical!

I'm working on autowt, a git worktree manager that happens to make LLM coding workflows easier. https://steveasleep.com/autowt/

It has some rough edges, but I use it a ton and get a lot of value out of it.

> AI editors should look into letting you operate on multiple git branches simultaneously

Git worktrees are great for this. I built a little tool to make them more ergonomic: https://steveasleep.com/autowt/

You really don't need every LLM vendor to build their own version of worktrees.

Letting Cursor pick the model for you is inviting them to pick the cheapest model for them, at the cost of your experience. It's better to develop your own sense of what model works in a given situation. Personally, I've had the most success with Claude, Gemini Pro, and o3 in Cursor.

I was once a heavy user of Cursor with Gemini 2.5 Pro as a model, then a Claude Code convert. Occasionally I try out Gemini CLI and somehow it fails to impress, even as Cursor + Gemini still works well. I think it's something about the limited feature set and system prompt.

I'm working on a little wrapper that solves this problem. I have similar needs with .env files, and in my case running 'uv sync' to install dependencies. I linked it elsewhere in this thread so I won't repeat the URL (autowt). It's definitely possible to make this workflow effective with some scripting.

I've been working on a tool for exactly this purpose: https://steveasleep.com/autowt/

I'm the only user at the moment, and I really enjoy the workflow. I run about four claude-codes at once this way. It's a little underbaked but I think this is the way a lot of people are going to go. Seems like the 'par' tool in a sibling comment is a similar approach.

Containers do make things easier, especially since agents can see the log output of any service super easily. To do the same thing outside a container you need to send logs somewhere the agent can see.

"Compactions" are just reducing the transcript to a summary of the transcript, right? So it makes sense that it would get worse because the agent is literally losing information, but it wouldn't be due to context rot.

The thing that would signal context rot is when you approach the auto-compact threshold. Am I thinking about this right?

I threw together a vibecoded tool to do this, as a personal experiment. It splits the guide into several runs, each focusing on a different style guide section. Here's the diff it gave for the Claude-authored README for the tool, which I called 'edit4style': https://gist.github.com/stevelandeydescript/14a75df1e02b5379...

And here are its style comments: https://gist.github.com/stevelandeydescript/a586e312c400769b...

I don't plan to release the code, since I don't really want my docs to be written in this voice. But it doesn't feel entirely unhelpful, as long as I'm personally curating the changes.

What advantage do you get from this being an MCP server rather than simply a command line tool? Genuinely curious, as I'm trying to develop my mental model of when to use one or the other.

Lovely project!

It was actually about customers and incentives. You're right that I shouldn't have said "users;" I should have said "customers."

It's rational for businesses to do things that make them money, and to not do things that don't make them money or make them lose money. SaaS business believe that spending R&D budgets on growth hackers and web product engineers is a better return than spending those same budgets on macOS engineers. I suspect they are right.

It doesn't matter to these businesses that you personally avoid Electron apps. They don't care, and Apple has made it easy and rewarding for them not to care.

Which apps do you avoid in particular which are associated with a service you are required by your job to use? Or, what purchasing decisions have you made on behalf of your company that took Electron-ness into account?

Electron apps are already out of place. In the space of Mac-apps-for-SaaS-products such as Linear, Slack, Notion, Asana, Figma, GitHub, and Spotify, they inflict the company's own design system on Apple's OS rather than try to ship Apple's design system applied to their product. Even the most popular IDE, VSCode, is just a wrapper around a web page.

And they're rational to do it this way. These companies shipping apps to millions of people all came to the conclusion that investing in native Mac software is not worthwhile to their business. Users don't avoid Electron-based products, and building native Mac apps slows you down. It's easier both technologically and organizationally to ship your web site as an Electron app. It costs less and you don't lose any users.

So I would be surprised to see _any_ popular Electron app get design updates to accommodate these changes.

As a user it makes me sad, but I find myself blaming Apple for losing this fight, not the hundreds of successful companies that all somehow make the same choice. If building native were an advantage, people would take it.

One thing I do to avoid this problem is to ask the LLM to make a plan and write it to a doc. Then in a new session, have it read the doc and tell it to implement a specific part of the plan. It saves you almost as many brain cycles as just having the LLM do it all in one go, but gives you direct control over how things happen and how much gets done at once. You can also tweak the plan by hand or iterate on it with the LLM.

I see you're getting downvoted (wrongly, because you're discussing in good faith), but I agree with the sentiment. 5% is a bit harsh, but having been on multiple iOS teams where AutoLayout is essential, it has always been a challenge to get people to understand what's going on, do the correct thing, and write code that doesn't barf constraint conflict warnings to the console. Seasoned iOS engineers have learned to do the right thing, but it's easy for one person to introduce a new conflict that nobody notices until months later when it's tedious to debug.

A shorter way of saying this is that the ergonomics of the most broadly-deployed constraint solving UI layout system—AutoLayout for iOS—still cause pain. It's not better pain than the massive complexity of CSS, it's just different pain. And it's also not sufficient; Apple themselves introduced collection views and stack views, each of which has its own special behavior. Their new framework, SwiftUI, does not use AutoLayout. Even the maintainers don't consider AutoLayout "superior" enough to adopt in a fresh UI framework.

It's a shame, because there is elegance in having a layout system you can explain in one or two pages, with enough power to almost support an entire OS and ecosystem of apps. It's just not quite across the finish line for developer experience and education.

In my case, it's because all my client devices are laptops, or locked down like Apple TV. It's nice to have a low-stakes experimentation box that can also be a Jellyfin server.

On the other hand, I don't go to the trouble this guy goes to. I just have a cheap mini PC plugged into Ethernet sitting on top of my router.

In that case, I apologize for misunderstanding, and would edit my original comment if I could.

It sounds like you're referring to app-launch time, which is different from screen-load time. Very different things!

It all depends on whether the number includes network roundtrip or not, which they don't state. I read it as not including a network request, i.e. all CPU and local I/O.

Replying to myself for clarification: I did not read their 500ms number as including waiting for a network. It sounded like that's how long it was taking React Native to load local data and draw the screen. If that's not the case, it's a very different story.

From another comment by seemack (https://news.ycombinator.com/item?id=42730348):

> For example, I just recorded myself tapping on a product in the Product list screen and the delay between the pressed state appearing and the first frame of the screen transition animation is more than half a second. The animation itself then takes 300ms which is a generally accepted timeframe for screen animations. But that half second where I'm waiting for the app to respond after I've tapped a given element is painful.

I agree with most of the other comments here, and it sounds like Shopify made sound tradeoffs for their business. I'm sure the people who use Shopify's apps are able to accomplish the tasks they need to.

But as a user of computers and occasional native mobile app developer, hearing "<500ms screen load times" stated as a win is very disappointing. Having your app burn battery for half a second doing absolutely nothing is bad UX. That kind of latency does have a meaningful effect on productivity for a heavy user.

Besides that, having done a serious evaluation of whether to migrate a pair of native apps supported by multi-person engineering teams to RN, I think this is a very level-headed take on how to make such a migration work in practice. If you're going to take this path, this is the way to do it. I just hope that people choose targets closer to 100ms.

racenis, what program did you use to draw the header graphic?

I dream of a Mac port, but it's beyond my skills.

This is my favorite syntax for technical writing, but unfortunately the only complete implementation is in Python. There are half-finished JS projects (last I checked) but nothing else. I really wish they were complete so we could use this in more places.

I opted for Djot (https://djot.net) as a second-place alternative with support for many more languages. My use case was attempting a Sphinx alternative in TypeScript. (Link for the curious: https://steveasleep.com/djockey/)

It's not really true to say "very little has been done." Thousands of person-hours have been invested into this problem! But the results have been mixed.

At least uv is nice! https://docs.astral.sh/uv/