itay-maman

First impression(s):

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

The inherent problem with evaluating coding performance of models remains: most day-to-day coding tasks are open-ended/partially-spec'd, and as such there is huge uncertainty on how the "right" solution looks.

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.

Thank you! That's the one. Amazing sleuthing.

It took me several reads to distill their post to this one sentence: "Enterprise Account contracts will no longer be offered to new customers"

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.

Wow that's a good piece. It propelled me into writing this: https://dev.to/itay-maman/the-elephant-in-the-room-systems-t...

In short: the tension described in "systems thinking" is the same one as the one between "spec driven" vs. "iterative prompting"

My first reaction: wow, incredible.

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.

Important: I didn't see opus 4.6 in claude code. I have native install (which is the recommended instllation). So, I re-run the installation command and, voila, I have it now (v 2.1.32)

Installation instructions: https://code.claude.com/docs/en/overview#get-started-in-30-s...

agree on that and the speed is fantastic with them, and also that the dynamics of questioning the current session's assumptions has gotten way better.

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.

Something that caught my eye from the announcement:

> 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.

Impressive results, but I keep coming back to a question: are there modes of thinking that fundamentally require something other than what current LLM architectures do?

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.

There's an interesting historical angle here: Church's lambda calculus actually predates Turing machines by a few months (both 1936), and they're provably equivalent in computational power. Church even proved undecidability of the Entscheidungsproblem first, using lambda calculus.

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.

The term "B2B SaaS" is doing a lot of heavy lifting here and I think conflates two different things:

(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.

My policy as a CTO is to always prefer things which are capped, so I'd go with 50 hours/month.

This looks really promising. I understand the rationale behind BYOS, but I think there's a segment of builders who'd prefer a managed service over provisioning/securing their own machine.

There's another angle here: in the LLM era, markdown files in a public repo actually are apps.

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...

This is brilliant. I'm pretty sure I'll use it when the need arises.

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.

I really like this direction - I think it certainly clicks with your audience and solves a real problem.

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.

Two thoughts this sparked, somewhat in tension with each other:

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.

I am not sure how this use case is prevelant on your system but in my sessions with chatgpt, claude web, claude code, I often find myself in a situation where I enjoy the fact that it is stateless. I can give a fresh context of who I am and get a suitable reply.

Hey, nice SDK! Heads up that the docs link at the bottom (https://api.meter.sh/docs) returns a 404

This touches on something I've been noticing: agent-based coding is reshaping where the bottlenecks live. Writing code used to be the constraint - now it's often the fastest part of the loop.

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.

This is appealing to me on several fronts—I like the focus on simplicity and local-first markdown files. Quick thought capture feels essential for staying productive these days.

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?

I think everything is absurdly chaotic at the moment, and a major question is whether it will ever calm down or perhaps this level of chaos is the new norm.

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.

Interesting writeup. The tiered retrieval approach and privacy model for group chats are well thought out.

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.

The Screenshot-Proof mechanism is clever: showing just one line at a time, never displaying the author name alongside the text. It might be the only serious approach to actually achieving the premise.

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.

One point in the post resonates strongly with me:

> "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.

Agreed that it is weird. FWIW, when I feel my chat with the LLM has landed (I got a final answer I'm satisfied with), I usually just close the tab or exit the agent session without the ceremony of "thanks, that was helpful."

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.

There's all this discourse about "you don't need to say thank you to AI" (Sam Altman said it costs a fortune). I agree with the economic perspective, but there's something deeper.

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.