dluxem

I try to use passkeys when possible as I'm also a 1Password user, but this hardly "just works". Firefox on Windows often triggers the Windows password manager for passkeys (some how this is only on some sites), making it impossible to use 1Password.

I've seen the same on Android too, and I think there's a difference in how Chrome and Firefox are handling the requests.

Then you get in to cases like a Microsoft Account. You need to use your account to log in to the device that has the passkeys, so the workflow never works properly and you have to fall back to another method.

Amazon is another one. If an app like Libby redirects to Amazon, I get a different, passkey-less password prompt, so I need to have a password readily available.

It's great when it works, but honestly 1password with straight up username/passwords is probably just a better UX in the end.

Similar story here. I was dealing with headaches every weekend, and it turns out that not sitting at a desk and drinking coffee on the weekend was the cause.

I gave up caffeine completely, and after a week and a half of headaches, the problem was gone. This has been about 4 years now.

I consume some caffeine now but try to keep it under 60mg a day or so.

Same mindset here. I really like the ability of having OpenAI, Anthropic and other models available.

For my personal work, I still use Claude Code as its cheaper and the limits don't bother me to much, but it feels a bit like being handcuffed to Anthropic vs being at work and freely selecting models.

I think this (for me at least) is the biggest pain point. Use styles and practices from this existing code base, even if they aren't documented explicitly in AGENTS.md or something. If we're importing a library somewhere that does what the agent is doing, reuse that same library - don't chose another one. If we have a pattern for unit tests, follow the same style. Etc. etc.

That issue, and the issue of "aesthetics", are the biggest complaints I have today. I don't know exactly how to define aesthetics, but it's when AI is making decisions that no experienced developer or designer would. They may be functionally correct but "ugly" to another developer or and end user.

An example is an case I ran in to yesterday where parsing a config, and failing and logging on a configuration error. It logged a specific item where the config was invalid but not what group or any notion of where in the config this error was. Of course, specific item names could be duplicated in different parts of the config. It's small, but correcting these minor things take time and they are the types of decisions no one would have made who had any experience writing code and debugging a config problem. This was Opus 4.8/max too.

I am of the same mindset as you, but you also have to look at PE multiples of Cisco in 1999 and Nvidia today. One being the "ammunition" supplier in the battle for the Internet, and the other supplier in the battle for AI.

Cisco was over 400 at one point and Nvidia is around 30. Not quite the same.

Other players today: - Digital Realty 48x - Equinix 75x - CoreWeave (still losing money)

There is likely a bubble of some type here, but I don't think this is the same as the Dotcom bubble.

I believe using a skill here is the wrong approach. LLMs already know what TDD is and how to do it, just like object oriented programming.

If this is encoded in a skill, that skill essentially has to be loaded for everything thing your LLM is doing. This is probably one of the few areas where direct instructions via AGENTS.md is best, and I don't believe it requires much direction here to force the issue.

But I think the OP is just trying to have their agent work in a very specific way -- that is fine too.

5. Show me the test and ask for approval before continuing

My purely unfounded, gut reaction to Opus 4.7 being released today was "Oh, that explains the recent 4.6 performance - they were spinning up inference on 4.7."

Of course, I have no information on how they manage the deployment of their models across their infra.

Escrow used to be something we would see in large Enterprise software contracts. We would need to place the "gold" build of the software and associated source code on CD (or tape, depending on the year) and ship it to a third-party escrow service. Should our company go out of business, now former-customers could access the source through the escrow.

It's kind of crazy to think about the process actually working though. The likelihood of a customer being able to recreate the build environment properly and produce a working release of our quite complex software seems low. It would probably be cheaper to putting that effort in to ripping out the solution then trying to patch some bug in a defunct vendor's solution.

As someone who works in the B2B SaaS space...

- If our customers vibe coded better integration points for us, it probably improves our overall value to our customers.

- The software industry, especially startups, is such an insignificant portion of the market, its not really worth worrying about. But, I can tell you from experience, that even large software companies don't want their own developers spending much time on accounting, ERP, or HRIS systems and they "outsource" this to SaaS companies.