105 karma · joined February 4, 2026
1/ it took me a while to understand this is a social network. I thought it was about giving me more visibility into my sessions/token usage
2/ Unless I am missing something it should be pretty easy to game the system.
3/ I think that landing the user on a global feed of all users will help
It's very hard to rank models' solutions on such problems, which is why they rarely appear in benchmarks (I'd be glad to stand corrected).
Even Opus 4.5 coding a C compiler from scratch - jaw-dropping as it is - doesn't tell the whole story. Most of my tasks are not that well spec'd.
I'd be glad to stand corrected but AFAICT this is the only sentence that describes the change. All other say "nothing is changing in [some area]".
Trying to downplay something to that extent immediately raises suspicious that this something (the change) is much more profound that what is stated.
In short: the tension described in "systems thinking" is the same one as the one between "spec driven" vs. "iterative prompting"
My second reaction: still incredible, but noting that a C compiler is one of the most rigorously specified pieces of software out there. The spec is precise, the expected behavior is well-defined, and test cases are unambiguous.
I'm curious how well this translates to the kind of work most of us do day-to-day where requirements are fuzzy, many edge cases are discovered on the go, and what we want to build is a moving target.
Installation instructions: https://code.claude.com/docs/en/overview#get-started-in-30-s...
yet - given an existing codebase (even not huge) they often won't suggest "we need to restructure this part differently to solve this bug". Instead they tend to push forward.
> GPT‑5.3‑Codex is our first model that was instrumental in creating itself. The Codex team used early versions to debug its own training
I'm happy to see the Codex team moving to this kind of dogfooding. I think this was critical for Claude Code to achieve its momentum.
Take critical thinking — genuinely questioning your own assumptions, noticing when a framing is wrong, deciding that the obvious approach to a problem is a dead end. Or creativity — not recombination of known patterns, but the kind of leap where you redefine the problem space itself. These feel like they involve something beyond "predict the next token really well, with a reasoning trace."
I'm not saying LLMs will never get there. But I wonder if getting there requires architectural or methodological changes we haven't seen yet, not just scaling what we have.
Yet despite this head start, the Turing machine formalism became the dominant framework for CS theory—complexity classes, computability, formal verification. Whether that's path dependence, historical accident, or something deeper about how humans reason about computation, I'm not sure.
But it does make me wonder: if the imperative, state-based model proved more tractable even for theorists, maybe FP's learning curve isn't purely about unfamiliarity. There might be something genuinely harder about reasoning in terms of pure functions and recursion vs. "do X, then Y, update Z."
Fully acknowledge this is handwavy—curious if others have thoughts.
(1) Business model: hosted software you pay monthly for (vs self-hosted/one-time purchase)
(2) "Glue" products: tools like Monday.com that primarily provide synergy between data sources and workflows
The article is really about (2) - and yes, those are vulnerable to vibe-coding. If your product's core value is "we connect X to Y and show you a dashboard," that's now a weekend project.
But there's a huge category of SaaS where the value is in the product itself, not the integration layer. Take Excalidraw - fits the SaaS model, but try vibe-coding a collaborative whiteboard with real-time sync, proper data persistence, conflict resolution, export formats, etc. The hard problems aren't "connect API A to API B."
Or PostHog - sure you could vibe-code some analytics tracking, but building reliable event ingestion at scale, session replay, feature flags with proper rollout controls? That's years of engineering.
The "vibecodeable" SaaS products were always somewhat commoditized - AI just accelerated the timeline. The ones solving genuinely hard technical problems seem a lot safer to me.
When Google announced free turn-by-turn navigation in 2009, Garmin dropped 16% and TomTom dropped 21% — in a single day[1]. Investors weren't irrational; they recognized Google was giving away for free what others charged $150+ for.
Same dynamic here. Haiku/Sonnet/Opus are the hardware, Cowork is the operating system, and those markdown files are the apps. Together they deliver real utility that previously required paid SaaS or billable hours — at near-zero marginal cost. The market's read may have been hasty, but the underlying concern is real.
[1] https://www.theverge.com/2015/10/29/9634146/google-MAPS-kill...
One point: the pricing model wasn't immediately clear. I was a bit perplexed by "own this brand for $49" — I get why this is the business model, and it makes sense. But getting a hint about it earlier in the process would have helped set expectations.
One thing: my immediate gut reaction was "will they steal my idea?" On reflection, I think that's actually a super common concern among your target users. Early-stage founders are often paranoid about idea theft - even if it's usually irrational (execution >> ideas), the anxiety is real. This could be a conversion killer if not addressed.
Might be worth adding something visible about data privacy/handling right on the landing page.
The HTML→React evolution is a good parallel. Writing long-term maintainable markup without loops, reuse, and parameterization became untenable at scale. React (and similar) emerged precisely because "data" (HTML) needed to become "code." Not everyone loves frameworks, but clearly many developers found the abstraction ceiling of pure markup too low.
That said, declarativity has real advantages — mostly around security and sandboxing. CloudFormation is instructive: CDK eventually outputs CloudFormation YAML. AWS could let you run arbitrary code inside CloudFormation, but they don't — because if you can send code there, you can also make it mine bitcoin. The declarative layer is the trust boundary.
So maybe the sweet spot is code-that-emits-data. You get loops, abstraction, and type safety at authoring time, but the execution environment only sees the constrained, analyzable output. CDK got this right. The problem is when systems skip the "emit data" step and try to grow a DSL organically inside YAML.
Suddenly friction points that were negligible (opening a browser tab, waiting for CI, context-switching to check logs) become proportionally more significant. Tools like this start making a lot more sense when the coding itself is no longer the slowest step.
But a screen recording would really help, since some of the descriptions are too vague to understand the actual workflow. For example, what does "You don't even have to open the file to jot down your notes" mean in practice?
Case in point is Moltbook: it went from being an idea to going viral in a matter of days, and now it could either become the ecosystem that powers the next wave of innovation or the textbook example of the risks of vibe coding.
One thing I'd love to see: what does "actually works" mean in measurable terms? The engineering is sophisticated, but I'm curious about user-facing impact - did memory injection improve task completion or satisfaction? How often do users invoke /memory forget? What's the false positive rate on extraction?
These systems are hard to evaluate because failure modes are subtle - the AI "knows" something but uses it awkwardly, or surfaces context that feels intrusive. Would be great to hear what metrics you're tracking to validate the complexity is paying off.
Curious if a web interface is coming—some of the value prop seems like a better fit there, since it wouldn't require the recipient to install an app.
> "While there is often a component of logic involved [in applying discoveries, patterns, and abstractions from the past] the balance frequently shifts away from pure science and toward something closer to art"
I'd argue that software has a unique structural property here: it's recursive. You write a function that uses other functions, which use other functions. You're always simultaneously using an abstraction and creating one.
Contrast this with physical structures like buildings: floors contain flats, flats contain rooms—each level is fundamentally different. A flat cannot contain a flat. The skills for designing each level are distinct.
In software, that divide is much smaller. The same patterns of thought apply whether you're writing a utility function or architecting a system. Maybe this is why the "art vs. science" tension feels different in our field.
Anyhow, I feel these entire chats are a gentle game of what to tell, when, and how much. Too little guidance and it won't understand the goal. Too much and it'll drown in details and lose focus. The gestures (which I do try to keep as short as possible) are micro-steerings I apply along the way.
LLMs are trained to complete threads based on data collected from the internet. Conversations where people say "thank you," "not quite," "we're getting close but..." have different continuation patterns than ones where people are terse or dismissive. These gestures are in the training data, so they will influence how the model continues your thread.
In anything longer than a very short exchange, your tone and feedback signals genuinely help steer the agent in the right direction.