I spent way too much money on a Peak Design backpack. 4 years in, the zipper broke. They honored the lifetime warranty, and swapped me for a brand new one.
That was my first time ever dealing with such a high-end product and a lifetime warranty.
Gonna echo that I love my Peak Design backpack. Only backpack I’ve ever owned that delighted me so much I told others and showed it off.
The design is a little dorky, especially now that every techbro in SF has one, but my god that thing has pockets and little details in all the right places. Been using mine for years and looks almost new.
One downside of high quality gear: Velomacchi (motorcycle bags/backpacks) seems to have gone out of business. Been using their stuff for almost 10 years. Feels indestructible, works great, but I’m never getting a replacement and I guess any warranty lasts only as long as the company …
Peak Design is the rare travel backpack I could find that has one massive storage compartment instead of 5+ small compartments. So you can really pack that thing efficiently.
And the 45L variant is the biggest thing you can use as a carry-on.
I've never spent $300 on a backpack before. It kinda stung. It's well-thought-out though. I've had it five years and it's been through a lot.
The FAQ says to hand-wash it which is annoying though. There's no way you're gently washing out the sort of grime that my human oil leaves on the straps from real use, like clinging to your bare shoulders during a long sweaty trip through Mexico.
So I feel a lil mischievous tossing the thing into the washing machine every year. Same way I feel using an alcohol wipe on my Macbook screen.
Echoing the efficiency. I just returned from a 1mo trip living out of the 45L, including a supply of dead-tree books.
That said, I've only had it a year and it's clearly not new anymore. Paint wear on the rivets, for example. I expect it'll be in rough shape when it's accumulated as many miles as the travel bag it's partially replacing.
+1 for Peak Design. I have yet to use the warranty, but the thing still looks new after lots and lots of travel, shoving under seats, tossed into train and bus overhead bins. The only real wear is the corners of the metal clip for the flap. Expensive, but in this case, you get what you pay for.
Yeah, they didn't question my warranty claim at all IIRC, and breaking the zipper was actually my fault. I had overstuffed the bag while in a giant hurry.
Hah, around the time of COVID, I was in SF renewing my Australian passport. Went into the Peak Design store, and was talking about my V1 Backpack, and the employee there was basically intimating that [my extremely trivial issue], if it somehowwww got just a little worse, would be covered by their lifetime warranty and also, just FYI, since we're out of stock on them, I'd get a V2 instead.
Here is the question for which I cannot find an answer, and cannot yet afford to answer myself:
In Claude Code, I use Opus 4.6 1M, but stay under 250k via careful session management to avoid known NoLiMa [0] / context rot [1] crap. The question I keep wanting answered though: at ~165k tokens used, does Opus 1M actually deliver higher quality than Opus 200k?
NoLiMa would indicate that with a ~165k request, Opus 200k would suck, and Opus 1M would be better (as a lower percentage of the context window was used)... but they are the same model. However, there are practical inference deployment differences that could change the whole paradigm, right? I am so confused.
Anthropic says it's the same model [2]. But, Claude Code's own source treats them as distinct variants with separate routing [3]. Closest test I found [4] asserts they're identical below 200K but it never actually A/B tests, correct?
Inside Claude Code it's probably not testable, right? According to this issue [5], the CLI is non-deterministic for identical inputs, and agent sessions branch on tool-use. Would need a clean API-level test.
The API level test is what I really want to know for the Claude based features in my own apps. Is there a real benchmark for this?
I have reached the limits of my understanding on this problem. If what I am trying to say makes any sense, any help would be greatly appreciated.
If anyone could help me ask the question better, that would also be appreciated.
2 parent comments above say that you can use older version of claude code with opus 200k to compare.
my guess is that eventually you’ll be able to set it in model settings yourself
There are all kinds of memory hacks, tools that index your code, etc.
The thing I have found that makes things work much better is, wait for it... Jira.
Everyone loves to hate on Jira, but it is a mature platform for managing large projects.
First, I use the Jira Rovo MCP (or cli, I don't wanna argue about that) to have Claude Code plan and document my architecture, features, etc. I then manually review and edit all of these items. Then, in a clean session, or many, have it implement, document decisions in comments etc. Everything works so much more reliably for large-ish projects like this.
When I first started doing this in my solo projects it was a major, "well, yeah, duh," moment. You wouldn't ask a human dev to magically have an entire project in their mind, why ask a coding agent to do that? This mental model has really helped me use the tools correctly.
edit: then there is context window management. I use Opus 4.6 1M all the time, but if I get much past 250k usage, that means I have done a poor job in starting new sessions. I never hit the auto-compact state. It is a universal truth that LLMs get dumb the more context you give them.
I think everyone should implement the context status bar config to keep an eye on usage:
But even spec-first, using opus4.6 with plan, the output is merely good, and not great. It isn't bad though, and the fixes are often minors, but you _have_ to read the output to keep the quality decent. Notably, I found that LLM dislike removing code that doesn't serve active purpose. Completely dead code, that they remove, but if the dead code have tests that still call it, it stays.
And small quality stuff. Just yesterday it used a static method where a class method was optimal. A lot of very small stuff I used to call my juniors on during reviews.
On another hand, it used an elegant trick to make the code more readable, but failed to use the same trick elsewhere for no reason. I'm not saying it's bad: I probably wouldn't have thought about it by myself, and kept the worse solution. But even when Claude is smarter than I am, I still have to overview it.
(All the discourse around AI did wonder for my imposter syndrome though)
Doesn't require Jira but yes, specification-first is the way to get better (albeit still not reliably good) results out of AI tools. Some people may call this "design-first" or "architecture-first". The point is really to think through what is being built before asking AI to write the implementation (i.e. code), and to review the code to make sure it matches the intended design.
Most people run into problems (with or without AI) when they write code without knowing what they're trying to create. Sometimes that's useful and fun and even necessary, to explore a problem space or toy with ideas. But eventually you have to settle on a design and implement it - or just end up with an unmaintainable mess of code (whether it's pure-human or AI-assisted mess doesn't matter lol).
I used to manually curate a whole set of .md files for specs, implementation logs, docs, etc. I operated like this for a year. In the end, I realized that I was rolling my own crappy version of Jira.
One of the key improvements for me when using Jira was that it has well defined patterns for all of these things, and Claude knows all about the various types of Jira tickets, and the patterns to use them.
Also, the spec driven approach is not enough in itself. The specs need sub-items, linked bug reports and fixes. I need comments on all of these tickets as we go with implementation decisions, commit SHAs, etc.
When I come back to some particular feature later, giving Claude the appropriate context in a way it knows how to use is super easy, and is a huge leap ahead in consistency.
I know I sound like some caveman talking about Jira here, but having Claude write and read from it really helped me out a lot.
It turns out that dumb ole Jira is an excellent "project memory" storage system for agentic coding tools.
This will probably make people laugh, but I just had claude make me one. It’s simpler than jira, but it’s good enough without the 10,000 things I don’t need.
I wouldn’t use it for work but it’s good enough to track my projects, note what’s in each release, has simple user and service account key issuance for api access, user roles and access control, project level configuration for kanban lanes and status mapping, claude can access everything via the api, simple project level document library with live preview markdown editing, etc.
I am not personally partial to Jira at all, I just already had a free account, they have a production-ready MCP, and exact Jira usage patterns are very well represented in the training data.
Have you been using Claude Code/whichever tool you use, to read and write from OpenProject directly? I do like self-hosting data like this. I used to self-host Jira back in the day.
What would a responsible on-boarding flow for all of these tools look like?
> Welcome to VibeToolX.
> By pressing Confirm you accept all responsibility for user data stewardship as regulated in every country where your users reside.
Would that be scary enough to nudge some risk analysis on the user's part? I am sure that would drop adoption by a lot, so I don't see it happening voluntarily.
We require someone with a professional engineering designation from an accredited engineering body to sign off and approve before a building can be built. If it is found to have structural issues later, that person can be directly liable and can lose their license to operate. Why this is not the case with health software I cannot explain. Every time I propose this the only argument I recieve against it is people who are mad that their field might dare to apply the same regulation every other field has.
Oh man, I have gone off on rants about software "engineering" here in the past.
My first office job was as an AutoCAD/network admin at a large Civil and Structural engineering firm. I saw how seriously real engineering is taken.
When I brought up your argument to my FAANG employed sibling, he said "well, what would it take to be a real software engineer in your mind!??"
My response was, and always will be: "When there is a path to a software Professional Engineer stamp, with the engineer's name on it, which carries legal liability for gross negligence, then I will call them Software Engineers."
People like to make this point, but traditional engineering has the opposite problem: insanely overwrought processes and box-checking that exists for no reason and slows everything down to a snail's pace. Yes there are safety-critical parts, but they surrounded by a ton of bullshit.
It's also absurd to think that there is no company which does genuine software "engineering". If you break ads at Google/Meta, streaming at Netflix, etc there are massive consequences. They are heavily incentivized to properly engineer their systems.
The main thing that governs whether time is spent to well-engineer something is if there is incentive to do it. In traditional engineering that incentive is the law (Getting council approval, not getting sued, etc). In software engineering that incentive is revenue.
That's quite the take. Throughout human history there were lots of instances of vibe-engineering and vibe-architecting, in the physical world.
Since the failings of not doing proper engineering is far more evident, the reasons for the "insanely overwrought processes and box-checking that exists for no reason and slows everything down to a snail's pace" go back to the earliest written law, AKA the Code of Hammurabi, circa 1754 BC! These rules are part of the core of our functional civilization.
Examples:
- Law 229 (Death of Owner): If a house collapses and kills the owner, the builder is put to death.
- Law 230 (Death of Owner’s Son): If the collapse kills the owner's son, the builder's son is put to death.
- Law 232 (Property Damage): The builder must replace any destroyed property and rebuild the collapsed house at their own expense.
- Law 233 (Structural Defects): If a wall "shifts" or is not built properly before completion, the builder must strengthen or repair it using their own silver/means.
No point in discussing with someone who is arguing in bad faith. I already agreed that some parts of the engineering process are safety critical. If you think there is no bullshit in the process you don't have enough knowledge about the requirements imposed by e.g. building regulations.
Totally agree - not just medical software either. See replies to my other comment threads. Software engineers really don’t like the idea that they might have to show they can perform at a certain standard to be able to work as a software engineer.
Typically arguments come up:
“that’s gatekeeping” - yes, for good reason!
“Laws already exist” - yeah, and that’s not the same as professional accreditation, standards and codes of practice! Different thing, different purpose. Also the laws are a mishmash and not fit for purpose in most sectors.
It is getting more and more difficult for me to see moderation here as unbiased. The charitable take is that people are often not aware of their biases. I am sure I suffer from that to some extent, though I really try to go out of my way to be self-aware about this. And yes, of course this comment could be evidence of my own bias.
> Right now, as I'm writing this comment, AI = LLMs and image generation. That's it. It's as simple as that
I think agentic harnesses add a lot to LLMs, even if many are just simple loops. They are a separate thing from LLMs, are they not?
I get the feeling that even if we stopped shipping new models today, new far more useful products would be getting shipped for years, just with harness improvements. Or, am I way off base here?
Is this as crazy as it seems? Like everyone else, I am working on agents, and making one in this space would terrify me. But this implementation seems a bit nuts, does it not?
> In the tested path, there was no built-in human-in-the-loop confirmation for dangerous actions such as native_transfer, approve, or SSH-relevant operations.
I would love to know how this decision was made at an org like Coinbase.
That was my first time ever dealing with such a high-end product and a lifetime warranty.
Just sharing because it was a good experience.
reply