xda is older than github and has a lot of institutional inertia. Also I get the impression that many of the people involved in the xda ecosystem are hobbyists that just kind of learn things as they go along and have less exposure to bigco software engineering practices.
I've been using cmux for a long time too but am pretty happy with it. It's not perfect but much better than plain tmux/ghostty. I'll give herdr a shot too.
You can find drawstring threaders (bodkins?) on amazon pretty cheaply - if you have clothes with drawstrings it's handy to have one of these around the house.
I am a casual American football viewer but my understanding is that the kneel ends the current play but keeps the clock running. Each team has something like 40s to setup their formation and snap the ball after the previous play has ended. If the game clock is still running (this is concurrent to their 40s of "setup time"), the team that is in possession of the ball can just use the full setup time (idk the formal term for this) to just run out the game clock.
Each team has 4 attempts to move the ball forward 10 yards, where if the ball moves >= 10 yards they get a fresh set of 4 attempts. These are called "downs".
If the team has any downs left when they kneel then they can maintain possession of the ball and can thus run out the clock. Most (all?) of the time the teams end the game even if there is time left on the clock.
Note that either team can call a timeout pre-snap which freezes the game clock. Certain plays also result in the game clock freezing between plays. There is also a 2-minute warning at the end of the 2nd/4th quarter that also freezes the game clock.
IMO clock management adds a very interesting strategic layer to NFL football.
The conspiracy theorist in me says that LLM providers do this regularly (or at least, don't bother optimizing for it) beyond some arbitrary "$/task" metric. I am not sure of there is enough SOTA model competition to avoid this.
I've played a little bit of Dead Cell's but it hasn't stuck with me yet.
I have to admit the game is a little overwhelming but maybe I need to stick with it a bit more.
Part of PoP's charm is that the game is very simple, yet the parry mechanic has nuance - you can buffer parry/attack/parry/attack/... sequences and the timing is just a bit faster than normal enemies, meaning you can wear them out (these fights have a very Errol Flynn Swashbuckler feel to them). Eventually your attack lands before they can begin their parry animation.
Later in the game you meet enemies that hit faster than you can respond to with a parry, so you need to change up your tactics.
I will always have a soft spot for the original Prince of Persia. It was one of those games I played constantly as a child, although only when my dad would let me use his Apple ][c.
I only realize it now but it had some very unique game mechanics that even today you don't see very often (ok maybe that's a bit of a stretch but the mechanics were novel to me back then):
- Notably you have 60 minutes to finish the game. Dying doesn't reset the timer, so there is constant pressure to keep moving.
- There is a satisfying parry mechanic. This is still rare to see in 2d platformers.
- Incredibly smooth animation. This could be nostalgia goggles but the rotoscoped animation really stood out compared to other games of the era.
> Watching it do log file analysis in seconds that would have taken me hours (edit: days really), and which I would therefore never have done in the first place.
Just today I had my agent diff two logs to find a very nitpicky difference that was the cause of a problem, I pointed it at a ADO extension that was having issues, it downloaded the VSIX and decompiled the .NET binary to verify. Based on that information it suggested a workaround which I was very skeptical of, but well it worked.
All of this I technically could have done but I probably wouldn't because it would have taken too long without a clear payoff.
Anecdotally Windows ARM works fine for me, although to be honest most of my work is command line + browser anyway. WSL works like a treat. Steam installs and most lower end games also play fine on my ARM laptop too. Games that require kernel anticheat don't work.
I think they make a great "second device" where you have something meatier to fall back to if something doesn't quite work right. I'm not sure if it's ready to take on the "main device" role just yet. But it's a far far better experience than the Surface RT days.
> Also I just find it a little insulting if someone sends me an AI response
I run into this with AI-generated PR comments. I think where I work we are still grappling with the "right point", because LLMs can certainly provide valuable feedback, but they are not at the point where they can do so unsupervised, and to do so just feels unprofessional.
And there's another layer where it is even worse when a colleague spends the time critiquing code and someone (or something) replies to the comment with mostly useless filler. It's like being handed a small hand-crafted gift and then throwing it into the garbage in front of them.
I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.
I'm certain there are a non-zero number of TVs that either attempt to auto-join popular wifi hotspots (xfinity/tmobile/starbucks/etc.) and/or have cellular connections for telemetry.
Thinking more on this I think a business opportunity in the future will be companies that design hardware stacks that can go in random appliances that can gather usage information in the name of telemetry.
I give it +/- 5 years before an OTS coffee maker at walmart phones home.
Anecdotally from people I know from MS is that adhoc slack usage was popular up until lockdown, at which point more resources was poured into Teams due to everything going remote and internal slacks were frowned upon.
I see a parallel here where a competitor's product is taking over and MS leaders see it becoming an existential problem and are putting their foot down and pushing internal users to the company's products.
Also if half the company don't even want to use something made by the other half it's a bad look lol
The premise of this article is incorrect - MS isn't cancelling Claude code internal usage because of AI costs too much, they're cancelling it because GitHub copilot is the compete product and they want their employees to use their product.
It's the same reason Teams got so much attention during lockdown.
> The first half is a constant flood of footage from the iPhone, the DJI Pocket, the drone, the Nikon Z8, and lately the Ray-Ban Metas too. There's always something being recorded. Every photographer or videographer I know is sitting on the same problem: an archive that grows faster than they can edit it. The second half is why mine never gets touched.
This is your second paragraph but reads awkwardly. You mention two halves in the previous paragraph, so I kind of try to map those two halves to the halves in this paragrpah. But I don't understand what the second half is in this second paragraph.
> Three months ago the lodge's social channels went dark. Not for lack of content; the lodge has years of raw footage across multiple SSDs. The bottleneck was editing time, and my time disappeared. Claude Code with Opus 4.5 (and then 4.6) hit the point in February where you could leave agents running for hours and come back to merged PRs. KaribuKit was going live with its first paying property in the same window. I stopped sleeping properly, started running three or four agents in parallel in the background, and the months when I would have cut reels turned into months when I shipped software instead.
I don't fully understand this paragraph either. Your time disappeared? Into what? Was it the lack of sleep? I don't know what KaribuKit is.
> I asked it out loud: how does the agent know what's in each clip?
Did you? Really?
> Four bugs, four lessons
I've noticed that AI tends to rathole into random things when summarizing a piece of work, so I'm skeptical that these were actually the most four interesting bugs you could have shared.
I would recommend you just remove this section or take the time to actually think about some learnings you had from this project. Syntax errors or missed CLI params are mildly interesting but what makes these four bugs interesting to your readers?
> The actual take
The same criticism here applies. Are these your real takes, or did Claude make these up too?
Some obvious tells to me of things that AI likes to write that humans rarely ever say:
> Both real, both consuming attention.
> Four constraints set the shape:
There's way more than just this (the writing style of nearly the entire post screams Opus 4.7), but that's just what jumped out at me when I started reading your post.
I don't mind you used AI to write this but in the future when you write using AI, take the time to read the entirety of the article and consider the goals of what you want to write and if the AI achieved that. Take out what doesn't belong and make sure that what you have left says things in your voice.
I maintain a part of my team's CD process and I've observed a 30% increase in PR velocity since we started adopting agentic tools but it was a "one-off" increase (as-in, it hasn't continued to increase beyond that since about a half-year ago).
I'm guessing though that there are other improvements in code quality and feature velocity. I've noticed personally that AI is really good at catching smaller things that are easy to miss (e.g., if you ask it to rename fooTheBars it also updates all the relevant comments or enums that you might have missed).
I suspect at some point AI-written code will be eventually artifacts generated build-to-build. The design docs and UI tests are the source and the model follows instructions to generate the product. If you make the models deterministic then model improvements give you code improvements across your entire codebase "for free".