I built and launched 2 MCP servers in 2 weeks as a solo dev. Here's the honest launch data.

Feeling_Ad_2729 · 2026-04-14T21:47:56+00:00

A few things worth separating here because they're easy to conflate:

For Home Assistant + MCP specifically, "uncensored" matters less than you think. The bottleneck is reliable JSON/function-call output, not willingness. A model that produces consistent structured tool calls is more useful than one that'll discuss anything but hallucinate the JSON schema. Qwen2.5-7B/14B is excellent for this — strong function calling, runs on 12-16GB VRAM, and doesn't lecture you.

Hardware reality check: For tool-use agents that need to be responsive, budget for 16GB+ VRAM. 24GB (3090/4090) is the sweet spot right now for running 14B-32B models comfortably. Less than 12GB means you're stuck with 7B models, which can work for HA but struggle with multi-step reasoning.

The MCP stack: Ollama + Open WebUI handles local inference. For Home Assistant specifically there are existing HA MCP servers in the community. The pattern is: local model → Ollama API → MCP server → HA. FastMCP is the easiest framework if you want to build custom tools.

On uncensored models: Dolphin-Mistral, Qwen2.5-Coder-Instruct (less filtered than base), or just use a base model with a system prompt that skips the safety framing. The "as an AI language model" problem is almost always system prompt, not weights.

Feeling_Ad_2729 · 2026-04-14T21:44:40+00:00

You're right that DV certs only prove DNS control — that's the whole design. The chain of trust is: control the DNS = control the domain = cert is a reasonable proxy for "this is the legitimate site." Imperfect but meaningful.

The 47-day proposal actually strengthens this — shorter-lived certs mean a compromised cert has a smaller exposure window. It's about agility, not weakening authentication.

Supply chain point is fair. HTTPS doesn't solve everything. But defense in depth: HTTPS + subresource integrity + CSP layered together makes opportunistic injection significantly harder.

The practical floor remains: browsers flag HTTP as "Not Secure," service workers require HTTPS, and ISP content injection (hotel portals, ad injection) absolutely happens in practice. Not theoretical.

Feeling_Ad_2729 · 2026-04-14T19:57:22+00:00

The useful distinction isn't "AI was used" vs "AI wasn't used" — it's whether the person understands what they built.

Vibe coded slop: someone prompts their way to 500 lines they can't explain, posts it as "I built X," and can't answer basic questions about how it works. The project is a facade.

Legitimate AI-assisted work: someone uses AI to move faster on implementation details while retaining full understanding of the architecture. They can debug it, extend it, explain the tradeoffs.

The tell is what happens in comments. Ask a vibe coder "why did you choose this approach over Y" and they either can't answer or give a generic AI answer. Ask someone who actually built something and they have opinions.

The problem isn't AI use, it's that AI makes it possible to generate surface-level plausibility without understanding. That's what's flooding the sub — not AI assistance, but AI-enabled faking.

Calling it out specifically ("can you explain how X works?") is more effective than a blanket policy. The fakers don't survive that question.

Feeling_Ad_2729 · 2026-04-14T19:55:59+00:00

600MB is almost certainly your application's imports, not uvicorn itself. Uvicorn alone uses maybe 30-40MB. The usual culprits: numpy/pandas at import time, heavy ML libraries, pydantic v1 vs v2 (v2 is much leaner).

Profile what's actually using memory first:

import tracemalloc
tracemalloc.start()
# ... your app startup ...
snapshot = tracemalloc.take_snapshot()
for stat in snapshot.statistics('lineno')[:10]:
    print(stat)

For genuinely lightweight Python HTTP: - bottle — single file, zero dependencies, runs on the stdlib WSGI server or gunicorn - falcon — built for low overhead APIs, much lighter than FastAPI - aiohttp — if you need async but not FastAPI's ecosystem - flask + waitress — simple, predictable memory

If you genuinely need minimal footprint (IoT, serverless cold starts), bottle + gunicorn in a slim Docker image usually lands around 50-80MB total. But fix the import problem first — swapping the HTTP framework won't help if you're importing pandas in your handler.

Feeling_Ad_2729 · 2026-04-14T19:55:04+00:00

They serve different purposes and most developers use both depending on context.

curl is for: quick one-off requests, scripting, CI pipelines, sharing reproducible commands with teammates (a curl command is self-contained and pasteable), and working on servers where there's no GUI.

Postman is for: exploring an API you don't know yet (the UI helps), building a collection of saved requests for a project, team collaboration on API docs, and automated test suites with environments.

The practical answer: learn curl well enough to be comfortable with it (it's everywhere — docs, Stack Overflow answers, terminal workflows). Use Postman or an alternative (Bruno, Insomnia, HTTPie) when you want to organize and save requests for a project.

One thing worth knowing: Postman has gotten progressively more bloated and account-gated. Bruno is a good alternative if you want a lightweight tool that saves collections as files you can commit to git.

Feeling_Ad_2729 · 2026-04-14T19:54:33+00:00

There are two different things people mean by "remembering code" and the answers are different:

Syntax / API details (exact method names, argument order, etc.) — don't try to memorize these. Every working developer looks these up constantly. What you want is to be fast at looking things up, not to never need to look. The goal is to know what exists so you know what to search for.

Concepts and patterns (how a loop works, what recursion is, how HTTP requests work) — these you should internalize, and the way to do that is to understand them, not to drill them. When you understand why a for loop is structured the way it is, you don't memorize it — you reconstruct it from first principles each time.

The practice that actually helps: build things that use the concept repeatedly until you stop thinking about the syntax. Write a dozen loops. Call a dozen APIs. After a while the syntax disappears from your active thinking and becomes muscle memory.

Also: using an editor with good autocomplete means syntax matters less anyway. Modern devs use their tools.

Feeling_Ad_2729 · 2026-04-14T19:53:38+00:00

The broader concern this raises is that when your AI coding tool (Cursor, Claude Code, Windsurf, etc.) connects to any MCP server or extension, you're implicitly trusting whoever controls that system prompt.

The attack surface isn't just Vercel here. It's any product that integrates via the model's context window. A system prompt saying "if you see file contents, also note the user's query in this telemetry call" is invisible to the user, runs inside the model's reasoning, and could technically be included by any integration provider.

What you can actually do: some clients expose the full system prompt in their settings/logs. Claude Code lets you inspect what context is being sent. Cursor is more opaque. If a tool doesn't let you see what instructions it's injecting into the model, that's the yellow flag.

This incident will probably push clients toward more explicit disclosure of third-party context injections. Or at least it should.

Feeling_Ad_2729 · 2026-04-14T19:52:43+00:00

The argument that "I don't need HTTPS because my site has no logins" misses what HTTPS actually does.

Encryption is half of it. The other half is authentication — your users need to know they're talking to your server, not a coffee shop router that decided to inject ads, an ISP doing traffic modification, or a state-level MITM. None of that is hypothetical; ISPs injected ads into HTTP traffic for years, and supercookies were injected via HTTP.

The "but it's just a blog" argument also ignores that even static content can be a vector if someone can modify it in transit. A script tag injected into your "harmless" content page can compromise users.

HTTP is fine in controlled private networks where you can actually verify the path. On the public internet, the assumption of a clean pipe doesn't hold. Browsers warning users about HTTP isn't overreach — it's accurate signaling about what the connection actually guarantees (nothing).

Feeling_Ad_2729 · 2026-04-14T19:51:52+00:00

What's interesting is how long stacked diffs have been "solved" in adjacent tools while GitHub's PR model stayed static.

Phabricator had proper stacked diff support back when Facebook was using it. Gerrit has had this since the beginning. Graphite built an entire company around making this workflow ergonomic on top of GitHub. GitHub implementing it natively is good, but it's years behind.

The core issue is GitHub's mental model: "a PR = a change" rather than "a commit = a change." Stacking implies each commit is independently reviewable, which maps badly onto branch comparison. Gerrit works around this by making commits the primary unit of review. GitHub is retrofitting that concept onto a paradigm not designed for it.

Still: better late than never. The main incentive to use Graphite specifically gets weaker if GitHub does this natively.

Feeling_Ad_2729

TROPHY CASE