azuanrb

Cross-post from the 1.0 thread. I’m currently building a harness for Slack to support our on-call and support channels. It’s been working great so far.

The harness is built on top of the Pi SDK. I initially used Codex, but Pi seems more hackable, and I like that it’s vendor-agnostic by default.

Running it on Kubernetes works, but dealing with the JSONL session files and making sure sessions survive pod interruptions adds some complexity. I’m using DBOS for that right now, which works well, although it still feels like overkill.

This came at just the right time. I’m looking forward to removing the pieces I no longer need and simplifying the architecture. Thanks Pi team!

I’m currently building a harness for Slack to support our on-call and support channels. It’s been working great so far.

The harness is built on top of the Pi SDK. I initially used Codex, but Pi seems more hackable, and I like that it’s vendor-agnostic by default.

Running it on Kubernetes works, but dealing with the JSONL session files and making sure sessions survive pod interruptions adds some complexity. I’m using DBOS for that right now, which works well, although it still feels like overkill.

The 1.0 release came at just the right time. I’m looking forward to removing the pieces I no longer need and simplifying the architecture!

So many negative comments here. Among my circle, it’s not uncommon for people to have multiple $200 accounts. This seems like it would make things easier for them by letting them use one account instead of juggling two or more.

What they’re doing with billions of tokens every week, beats me. But these users absolutely do exist.

Unless you’re using frontier models like Astra, Sol, Fable, or Opus, I think you’re often better off using Chinese models for a fraction of the price. I’m not sure people realises just how competitive they’ve become.

GLM and DeepSeek are great examples. They’re a bit like Linux or Android in that there isn’t necessarily one best provider. You need to do some research, try a few, and pick whatever works best for your use case.

I think that’s partly why Anthropic has been pushing its most expensive models so heavily for a while now. Sonnet and Haiku were great, but at that level of intelligence it’s becoming much harder for them to compete on price with Chinese models that have largely caught up.

The main reason to use frontier models from Anthropic or OpenAI now is the combination of intelligence and speed. Chinese frontier models still struggle to match that, possibly in part because of hardware constraints. But judging by the recent GLM releases, they seem to be moving in the right direction.

Clients paid us just fine. It really isn't that hard or expensive. It's not rocket science.

Put aside the usual web-dev perspective for a moment. As developers, we build for our users.

The web and native apps serve different purposes. Users do not use a website the same way they use a mobile app, and the trade-offs are different.

I’m getting tired of web developers failing to acknowledge that and treating web technology like a hammer that needs to be applied to every nail they come across.

And especially when people say “the web”, what they often really mean is Chrome and the Chromium ecosystem. A lot of web apps barely get tested properly on Firefox or Safari, which only reinforces Google’s monopoly over the web platform.

Yes, app stores have their problems. That does not make the web the right answer for every product.

Most devs I know who hate native apps are either web devs trying to embed web tech into everything they touch, or they just hate Apple.

Most users don’t care. What they do care about is performance, and native is usually the easiest way to get there.

For your AI workflow questions, it depends. With or without AI, those decisions depend on the organisation’s direction, the team’s capabilities, and their preferences. Did your org have a single answer for the best programming language, framework, or workflow even before AI? There was never a single right answer to any of that.

Not sure if you’re speaking from experience or just being theoretical here. We’re using Rails and it’s been great. Maintenance and upgrades have been a breeze.

All this static vs dynamic stuff doesn’t really matter anymore. AI doesn’t care. You just need to close the feedback loop with tests, linting, a compiler, or whatever else gives it a clear signal.

Simple as that.

At least within my circle, that’s not really the case. Instead, what I’m seeing is more of a hiring freeze, with the budget being used to empower existing employees through AI. Which I think is a more reasonable take.

I’ve made a similar point to my colleagues recently about cross-platform vs native apps. If we’re using AI anyway, do the arguments we made years ago still hold today?

I know some people might disagree, mainly because AI isn’t a new architecture or a new programming language in the traditional sense. But I still think it’s worth revisiting the assumptions and having the discussion.

The AI features arrived with the recent v2 release. Raycast originally became popular as a better Spotlight replacement. As you can see, the idea was never entirely original, since Apple and other apps already offered many of the same features. Raycast’s strengths are its extensibility, lightweight design, speed, and excellent UI/UX. It’s a well-polished app.

That was Raycast v1, though. I don’t like the direction they’ve taken with v2, so I uninstalled it and switched to Tinycast.

Terra is in a weird spot for me. I used to run it as my main driver at medium/high, but after Luna's price drop and some experimenting, I switched to Luna xhigh. If I need extra juice, I just use Sol. Intelligence-wise, Luna xhigh is more than good enough for me. Speed is the only downside. Terra/Sol might be similarly intelligent, but they can get things done faster.

Looking through the replies, the theme seems pretty clear. Everyone has their favorite distro, which is great btw. But that is the issue imo.

If you just want something stable and boring, Linux is just not it. Every distro has its own goals and target users, so a lot of the effort gets spread across the ecosystem.

With macOS or Windows, for better or worse, everyone is working on the same platform. So more people are working on the same problems. With Linux, everyone is kind of doing their own thing.

It is basically the same Android versus iPhone argument. More choice and freedom on one side, more consistency on the other.

Any mainstream language can be reliable. Java is a good choice for greenfield projects when it fits the organisation’s existing stack, expertise, or the broader industry ecosystem. Just like any other language.

Banks, telcos, etc. aren’t monoliths either. They use plenty of different languages depending on the team, system, and requirements. Java isn’t inherently the choice for greenfield software just because reliability matters.

I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc.

https://mise.jdx.dev/bootstrap/packages/brew.html

Forgot the source but DHH mentioned it's not all, just most. Still makes sense to have on some scenario, just not all, or the default anymore

It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.

In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.

I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.

https://guides.rubyonrails.org/testing.html?#when-to-use-sys...

I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background.

Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.

With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.

At the end of the day, both approaches work.

Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.

Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.

It’s detectable and has been known to result in account bans. People have been doing it since the early days of Gemini, when the ToS was still unclear, and some only found out after their accounts were banned. There have been multiple GitHub issues and reports to Google about it. It’s not worth the effort unless you’re willing to risk a secondary Google account.

This anti-DHH movement is so weird to me. People seem to read summaries of his views, often based on interpretations that get exaggerated from one article to another until they become something else entirely. At least read the articles yourself, including his other work, so you don’t just cherry-pick the ideas that conform to your existing beliefs. Then form your own opinions.

With the recent videos, I think there are multiple selling points.

* General performance. * Run the server and client everywhere. There are already multiple libghostty clients for mobile. Native terminal support on mobile is great, especially for coding agents. * Native sessions. The lack of sessions in terminals is part of the reason why some people went with tmux in the first place. * Multiplexer performance isn’t noticeable until you start running multiple sessions with multiple agents. Sometimes half of my RAM ends up being allocated to Ghostty/Alacritty + tmux. * As for rendering, performance is one thing. But the multiplexer tax is really, really annoying. For example, some features are available in Ghostty but not tmux, and vice versa. It’s the little things that pile up.

Another point is that, for some reason, multiplexers and terminals often diverge in terms of feature implementation. Probably because one traditionally focuses more on remote workflows, while the other focuses on local workflows. With AI, though, it makes a lot more sense to have both. Running long-lived sessions with agents is becoming normal, so the line between those use cases is getting thinner. That’s probably why they’re focusing on this approach.

Sure, if the kids want to learn. But let’s be honest, most of them, or even us, are just going to use the chatbot directly for the answer.

We rarely upgrade our phones or MacBooks because the newer version can do something the previous one literally couldn’t. Often it’s the efficiency, speed, battery life, etc, combined, that lets us push the hardware further.

I get your point, but we can only have groundbreaking leaps once in a blue moon. That doesn’t mean incremental improvements aren’t useful.

Imo, you already lost the argument when you have to explain that PWA is the "app". For most users, app is something they install from App Store or Google Play. I get the point of view from developers point of view, but unless the majority of the users are technical people, there's no reason to use PWA these days.

I’m building an internal tool for our company, basically an agent to help with on-call and alerts via Slack. I have evals running across a few scenarios, and my favorite models so far are Sol medium and Luna xhigh.

Sol medium has been a nice balance between intelligence and response time. Luna xhigh can achieve similar scores on the evals, but it takes noticeably longer. My impression is that the higher reasoning effort helps compensate for the lower base intelligence.

Cost is definitely a big factor, but latency and intelligence matter too. If I had the budget, I’d take Sol medium over Luna xhigh.

From using both on real scenarios, Sol is noticeably better at navigating around issues, exploring alternatives, and being creative when the obvious approach doesn’t work. That matters quite a bit when you’re investigating live alerts, where the path to the root cause isn’t always straightforward.

I’ve been experimenting with this for a while, and right now I’m using Luna xhigh as my default. Previously I was using Sol medium.

Sol medium is a great balance between speed and being thorough, but it’s quite expensive. Luna xhigh seems to compensate for slightly lower intelligence by thinking and reasoning for longer, so tasks can take more time to complete. But it’s crazy cheap.

I also have some custom evals using promptfoo to make sure I’m not introducing regressions when switching models. So far, Luna xhigh has been really, really good for the price.

Don’t sleep on it. Give Luna a try.

People love taking generic engineering problems and somehow spinning them as Ruby specific issues. None of the issues you mentioned have anything to do with Ruby. They’re problems you can run into in any engineering project.

It’s 2026 and we’re still benchmarking Ruby using Twitter’s 2008 architecture. It was less about a language choice and more about years of architectural redesign. I thought we were past this by now.

> running them on terminal

That is the value. You can run them remotely from your phone and set them up on a headless machine too. You’re not bound to your terminal.

My usual workflow is to still use the terminal for heavy work. But sometimes I just want to prompt from my phone and run a few tasks or do some planning. Then I can simply resume the session in the terminal later. It's the flexibility.

It’s just a personal preference, to be honest, so I wouldn’t overengineer it yet. In my case, I run it in a VM behind Tailscale. The main reason is that I want it to be able to install or use whatever tools it needs without contaminating my main machine. It can expose anything I need over Tailscale. So for me, it’s basically just a cheap, throwaway machine.