Shunya Sekiguchi @cat_programer

AI is making it cheaper than ever to generate code. But the cost of understanding that code hasn't decreased at the same rate. This creates a dangerous asymmetry: we can now produce more code than we can thoroughly reason about. Security vulnerabilities often emerge not from individual functions, but from the assumptions between them — trust boundaries, implicit permissions, shared state, and unexpected interactions. The real bottleneck in AI-assisted development isn't writing code anymore. It's maintaining a correct mental model of the system as it grows.

Behind the hype around “Vibe Coding,” I think we’re starting to realize just how important precise specification is again (SDD). As AI gets better at writing code faster, the lack of clarity in the specifications defined by humans can directly become a trigger for highly precise technical debt.

“PostgreSQL doesn’t scale, so you should move to a distributed database early.” I see this kind of advice all the time, but I came across a really interesting discussion on Reddit. One developer compared typical hardware from the 1990s with what we have today. Back then: • ~4 CPU cores • 512MB of RAM • HDDs • Dozens to around 100 random IOPS Today: • 300+ CPU cores • Terabytes of RAM • NVMe storage • Hundreds of thousands of IOPS • GB/s-level storage bandwidth In other words, workloads that once required sharding, multiple database servers, or specialized storage can sometimes be handled by a single PostgreSQL instance today. That raises an interesting question: “Is PostgreSQL actually the bottleneck?” There are plenty of cases where developers worry about sharding or distributed databases far earlier than they actually need to. With modern hardware, a single PostgreSQL instance can handle much more than people often assume. Of course, large-scale systems eventually run into different bottlenecks. But the interesting part is this: Are we still applying database design assumptions from the past to modern hardware? Hardware has improved enormously. Maybe the biggest problem today isn’t that our infrastructure is too slow. Maybe we’re making it unnecessarily complicated.

@jnoble100 true

Everyone keeps saying “SaaS is dead.” But I think the reasoning behind it is fundamentally wrong. The common argument goes: “AI makes it possible for anyone to build SaaS.” → “SaaS becomes commoditized.” → “SaaS is dead.” That logic doesn’t make much sense. Just because anyone can build a SaaS product doesn’t mean anyone can build a good one. If SaaS is still being built, SaaS itself clearly isn’t dead. If SaaS is actually going to die, I don’t think it will be because AI makes SaaS easier to build. I think it will happen when AI commoditizes software itself. And I believe MCP is going to be at the center of that. With MCP, AI can directly connect to and interact with all kinds of services and tools. That means humans increasingly won’t need to open a SaaS product and interact with its UI themselves. So rather than “SaaS is dead,” I think “UI is dead” is much closer to the truth. SaaS itself doesn’t necessarily disappear. What disappears is the need for humans to interact with software through a UI. As AI + MCP commoditizes software, the pricing, structure, and even the need for traditional SaaS products will fundamentally change. That’s what I think “SaaS is dead” will actually mean.

Honestly, when comparing X ads and Reddit ads, Reddit ads were definitely better for reaching people overseas. On the other hand, X ads were extremely effective when targeting people in Japan. The ads I ran were for NodeFlare, a developer-focused tool, so I can’t say whether the same results would apply to other apps or products.

The official X MCP had limitations when used remotely, especially when it came to posting. I also checked several community-built X MCPs, but I couldn’t find one that could handle the full workflow I wanted — like writing a post, finding a relevant video, and attaching it automatically. So I built my own and have been using it in production. It’s honestly insanely useful. If you want it, comment “MCP” and I’ll send it to you.

@pksingh1508 Signups.

@LaxanaRana Let's go!

I’ve been so busy with client work that I haven’t been able to post much lately! Starting today, I’m going to get back to posting every day consistently. NodeFlare has been going really well, and more and more companies are starting to adopt it. Let’s keep pushing! 🚀

MCP vs Skills I came across an interesting comparison on Reddit. When MCP and CLI + Skills were compared for the same use case: → CLI + Skills Faster More reliable Fewer tokens Easier to debug Meanwhile, the MCP side has been facing discussions around large tool schemas from tools/list consuming context. There was even a report of Claude Code consuming 27k tokens just from MCP tool definitions. The important point here isn't that MCP is unnecessary. MCP = standardized access to external systems Skills = on-demand knowledge and workflows In other words, the challenge with MCP may not be its capabilities, but when and which tool schemas should be exposed to the agent. How tool search and deferred loading evolve around this problem could be a very important part of the future of agent infrastructure.

@realSamHu That’s true.

Why is Jev so much faster than LLMs? I came across a reverse-engineering article about Jev, and what I found particularly interesting was its inference architecture. A normal LLM is fundamentally autoregressive: input → token₁ → token₂ → token₃ → ... → tokenₙ Even if all you need is: is_this_safe: bool route_to: one_of[agent_a, agent_b, agent_c] priority: 1..5 you're still using a model whose fundamental interface is "generate text." Jev takes a very different approach. According to the reverse-engineering analysis, the architecture may look roughly like this: ┌─ Noul → P(true) │ state encoder ───┼─ Choice → P(option₁...optionₙ) │ └─ Score → distribution / expectation The key idea is that the state can be encoded once, while multiple independent decisions can be evaluated against the same representation. So instead of: LLM → generate JSON → parse → validate → execute you can do: state → decision model → typed result → execute And because the output isn't a sequence of tokens that needs to be generated one by one, the amount of sequential decoding work can potentially be reduced significantly. This is also what allows Jev to evaluate multiple questions against the same state in a single request. What's interesting is that the optimization isn't necessarily: make the LLM smaller but rather: remove unnecessary sequential computation from the interface. LLMs are optimized for generating arbitrary sequences. Jev, on the other hand, is optimized for answering bounded questions that software can act on directly. If this architecture is close to what TypeSafe is actually doing internally, I think that's much more interesting than simply calling Jev a faster LLM.

Yeah, I measure accepts and abstains separately. Especially for agent routing, I think being able to abstain and fall back when confidence is low is more important than forcing a decision every time. The cases where a held-out state gets routed to the wrong tool are exactly what I want to catch.

What tools are essential for indie developers? I think Stripe is probably the number one, but are there any others?

@AinreekAI I’m really glad to hear you say that.

When I’m feeling down, I often listen to this song: THE BLUE HEARTS「情熱の薔薇」 youtube.com/watch?v=F0QL4B…

@AinreekAI Appreciate it! 🙏

One of my favorite UX details in NodeFlare: You can customize the order of the items in the sidebar.

@DuckyoungLee Absolutely. I really think so too.

Recently, sales have been going really well, and I can genuinely feel the team’s mood getting better. In a startup, I think the best way to improve team morale isn’t necessarily more benefits or more days off. It’s simply making the company grow.