Once I had that working, I realized I had enough data to add ticket tracking. It uses the data it gathers from the package manager to keep Linear or GitHub issues updated. And by auto-assigning those issues to coding agents, I get a Dependabot-but-better experience: agents keep up with API updates in addition to just bumping versions, and group related updates automatically.

It's still early days, but it's working really well for us and I think people will find value in it, so I'm sharing here!

Comments URL: https://news.ycombinator.com/item?id=47781933

Points: 6

# Comments: 1

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!

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!

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

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.

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.

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

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.

Lovely project!

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.

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.

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.

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.