kellros

Consider that as of (always and) 2026 you are held accountable for whatever AI-slop* you produce. Will that change within 5 years? The mindset is shifting from doing the right thing, to instructing the AI to do the right thing. Even if you're not responsible for the instructing part (e.g. using AI export feature drafts, to use an AI software factory to refine and implement), you're still owning said implementation in the end because you're responsible for the refinement and review. You should know how to do the work and reason about it—but you're also responsible now for correcting AI—less work but more responsibility.

As someone building AI software factories for the greater part of a year, I can share some learnings: - Smart models like Claude Opus cannot be replaced with dumber models at a reasonable expenditure with similar cost by iterating multiple times. Mythos will be the same cost or more expensive. Don't think you can throw enough funding at qwen-next-coder to rival Opus at a similar price. - Mythos (like Opus) will change the way we work, but not in the way you think. The use case for Opus is narrowing in comparison to Sonnet - a lot of what Opus used to do, Sonnet can do for cheaper, and sometimes better too. Opus is great at exploring a problem space and filling in the gaps - but any agent harness will not leave such intelligence to fate—they'll do fine-tuning or add specific instructions and possibly guardrails. Lazy (but long-term optimal) solutions will leave more reasoning to smarter models and dictate less. - A lot of what we do (and should do) is a cost optimization problem. Categorizing what we do (exploration vs. reasoning) tends to be structural (like Haiku), logical (like Sonnet instruct/non-thinking), and reasoning-driven (like Opus/thinking). Sometimes the challenge is long context-based reasoning, e.g. when planning a vision breakdown encompassing 50+ features, Sonnet could* do it given 1M context, but it struggles to reason about long context problems (Opus long-term reasoning drops off less) e.g. first 5 features are accurate, but the further you go, the less accurate it becomes (near-sighted vision). - If Mythos has like a 10m context size long reasoning window, Mythos would become the go-to model for medium-term planning (3-6 months). Opus 1m doesn't cut it for 3m-6m horizon planning, not to mention long-term (1y+ with 100++ features). The industry is in need of a x10 compression/context size improvement to tackle bigger problems. One of the challenges right now is we (as humans) can't refine and reason about features fast enough to keep pace with what AI can deliver—until AI has the ability to perform longer-term reasoning, we can't trust it to plan things longer term. There's another problem with this long-term reasoning in that we (as humans) can't (easily) reason so far ahead, but AI could if it could keep the entire context in mind.

In short, unless Mythos is cheaper than Sonnet (which is 3-5x more expensive than what is out there today, e.g., GPT Mini, Minimax 2.7, GPT-OSS 120b), it's unlikely it would become the go-to model.

I'd add that a smarter reasoning model can only be better if you provide relevant context and reasoning constraints — otherwise, you can't expect it to behave better (in actual terms) compared to a slightly dumber model. When you start reasoning about the future in terms of AI, it's turtles all the way down (i.e. need AI to efficiently reason about the choices made by AI)

I'll tell you later :)

I've always been fond of Rethinkdb, but never actually used it. Perhaps if I came across pragmatic examples of how to do x with y, like you typically see with Redis, I could have convinced my team/s otherwise.

One of the aspects of Rethinkdb I admire most is the tooling. I find myself often trying out something new with React, Postgres, ASP.NET Core, Elm, Go, Kotlin or what not and biasing my experience getting started with preference to use.

I recond Rethink as Pied Piper in Silicon Valley; a great product ultimately being misunderstood. I'm relieved to hear Rethinkdb will live on under the Linux Foundation (and applaud them for doing so) and earnestly hope it re-establishes itself in a niche, such as that of Firebase/Parse, with partnerships and a legacy to rival that of Postgres one day.

Looks to be the case based on the config. I'm suprised storage wasn't abstracted to accommodate redis or the like which is essential in a load balanced scenario.

The API doesn't seem quite idiomatic either, I'd expect to create a struct containing options and a function that closes over the http.Handler interface e.g. func(l *Limiter) Limit(next http.Handler) http.Handler or a function that takes options and a next http.Handler that creates a struct implementing http.Handler.

I suspect flex-time will be coming sooner than expected. flexbox is amazing!

I guess it depends on how averse you are to risk and how long you can go without getting paid.

Never forget that a contract is meant to be negotiated - a contract's first draft typically contains a bunch of unreasonable or vague requests and wishes from the party that created the contract. Don't sign a contract until the vagueness has been clarified or defined.

It's up to you to negotiate the contract in your favor. To put it plain and simple; unless you negotiate a contract in your favor, you're going to have a bad time. Like the video said; if you have no contract, you're left with the sympathy card and that rarely works.

Another bit of advice: Keep track of all communications and have all word-of-mouth agreements put on paper (before you commit to anything, like signing the contract). I keep a projects folder per client containing communications, documents received etc.

Hourly billing only works when you keep a detailed log of what was done. It's definitely a lot easier to get paid for work if you provide a breakdown on what was decided and done. The descriptions should prove as motivations of why the work was necessary.

Good to know :)