HN user

stevekrouse

2,789 karma

Spreading the joy of programming

val.town | stevekrouse.com

Posts226
Comments142
View on HN
crawshaw.io 1d ago

The agent principal-agent problem

stevekrouse
2pts0
stevekrouse.com 16d ago

Learning to code is still worthwhile

stevekrouse
318pts312
stevekrouse.com 22d ago

Chad Fowler's "Phoenix Architecture"

stevekrouse
3pts0
blog.val.town 1mo ago

Scoped Blob Storage

stevekrouse
1pts2
blog.val.town 2mo ago

From Supabase to Clerk to Better Auth

stevekrouse
304pts240
stevekrouse.com 2mo ago

AI agents are briefly overhyped

stevekrouse
1pts0
macwright.com 4mo ago

Roots – Return Old Online Things to Your Own Site

stevekrouse
2pts0
stevekrouse.com 4mo ago

Steve-eval – getting AI to write like me

stevekrouse
2pts4
stevekrouse.com 4mo ago

Reports of code's death are greatly exaggerated

stevekrouse
611pts447
stevekrouse.com 4mo ago

What if you never had to get an API key ever again?

stevekrouse
2pts0
blog.val.town 4mo ago

Bring Your Own Agent (BYOA)

stevekrouse
3pts0
stevekrouse.val.run 4mo ago

Intelligence Buying Intelligence

stevekrouse
1pts0
stevekrouse.com 5mo ago

Delegation and management is for when you lack proper tools and abstractions

stevekrouse
1pts0
macwright.com 5mo ago

What I haven't figured out

stevekrouse
1pts0
repro.fyi 5mo ago

Show HN: Repro.fyi – info-site on submitting bug reports

stevekrouse
1pts0
repro.fyi 5mo ago

Show HN: repro.fyi – a guide on making minimal repros

stevekrouse
1pts0
stevekrouse.com 6mo ago

Advice to College Students in 2026

stevekrouse
1pts0
blog.val.town 6mo ago

Catching Stars – finding customers and hires from your GitHub stargazers

stevekrouse
1pts0
leerob.com 7mo ago

I migrated cursor.com from a CMS to raw code and Markdown

stevekrouse
8pts0
blog.val.town 7mo ago

Pickling Compute

stevekrouse
1pts0
blog.val.town 8mo ago

Val Town MCP

stevekrouse
4pts0
macwright.com 9mo ago

First-run with agent skills from Anthropic

stevekrouse
1pts0
www.raymondcamden.com 9mo ago

I Know What You Did Last Summer (With Val Town)

stevekrouse
1pts0
blog.val.town 9mo ago

In, Val, Out – I/O with a val in the middle

stevekrouse
1pts0
modal.com 9mo ago

Modal's $87M Series B

stevekrouse
3pts0
www.catherinejue.com 10mo ago

Winning = Fun

stevekrouse
1pts0
blog.val.town 10mo ago

How to keep package.json under control

stevekrouse
2pts0
blog.val.town 10mo ago

vt, the Val Town CLI

stevekrouse
2pts0
blog.val.town 10mo ago

Building a better online editor for TypeScript

stevekrouse
2pts0
blog.val.town 11mo ago

We Built an API for Clay

stevekrouse
4pts0

I think we're in agreement. My Dijkstra quote is the perfect rejoinder to your Wittgenstein:

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

— Edsger Dijkstra

That's not my argument at all! Though I can see why you took that away; my bad for not making my argument clearer.

I believe that even when we have AGI, code will still be super valuable because it'll be how we get precise abstractions into human heads, which is necessary for humans to be able to bring informed opinions to bear.

Any writer who admits that they are actively working towards having a machine write their material has lost me as a potential reader.

I partly understand this perspective. I think it gets at 'proof of work' – if you can forgive me borrowing a concept from crypto. Nobody wants to be on the receiving end of a low-effort output. That's just embarrassing.

For example, I am constantly getting fairly decent spam emails, but I literally never respond because that would be so lame. No matter how good spam emails get, I won't reply.

My investor Dan Levine says that in order to get a reply for a cold email you have to pass a mini Turing Test embedded in the email. This is increasingly hard as we approach AGI, defined as the point at which machine intelligence becomes indistinguishable from human intelligence. But I still think it's possible, but hard work and definitionally unscalable. (If you find a way to scale it, readers will learn to build up defenses against it. It's a never-ending arms race.)

But relying on human-written writing as the proof-of-work is limited in two ways:

1. When we do reach AGI, it will, definitionally, no longer be possible. CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) definitionally don't make sense in a world where you can't tell humans and machines apart. 2. It's a limited way to measure 'proof of work'.

There should be other ways to show 'proof of work'. The easiest example is money. Imagine if there was a frictionless way to pay $10 or $100 to send someone an email. Or attach $10 or $100 in cash to an email as a thank-you to the recipient for reading it. This kinda already exists in that you can buy time with famous people on various marketplaces or pay $1m to charity to get lunch with Warren Buffett. (Buffett ended up hiring one guy who did this!)

So yes, nobody wants to be a dupe, and if I mass produce a lot of writing (even if it's super high quality), I would deserve to lose readers. So I'd never do that.

Instead, if I had AI that could write in my voice as well as me, I'd use it to help me dramatically improve the quality of my writing. I'd keep my effort constant, and the quality bar would go way up. Ideally, it'd be a gift to you, my potential reader.

How does that land?

The important part of MCP (that this misses) is that it's a machine interface you can quickly iterate on. In other words, an API is too slow-moving. You can't break it; it's a promise. A UI is too annoying for an LLM to deal with. An MCP is the perfect middleground: speaks JSON, but there's inference involved, so if you change the tools, the LLM will be just fine. (Just like how you can change your UI much faster than you change your API, because there's inference at runtime, ie in the human brain.)

For example, at my startup val.town, our MCP server is way more powerful than our API, because we added a bunch of tools to it willynilly because we're not worried about having to be stuck with those tools forever. We can remove them and nobody's code will break. (Just like we could remove buttons in our UI.) But an API change needs to be thought-through.

Yeah I definitely agree. I'm specifically talking about things you're not shipping or charging money for. Just little personal apps for you and friends or you and work colleagues. Internal tools, etc.

Strong agree! For example, we at Val Town just invested very heavily in getting a good ol' fashioned language server to work in our product to power hover-overs and type information in our web editor. That'll likely be our next company blog post...

The argument is that if you intent to maintain the code you should keep the AI on a very tight leash, and at least understand the architecture of the code, if not every line.

Vibe coding is allowing everyone (including me!) to make way more apps in my personal life that are very throwaway. I think some folks are doing this in business contexts too. But this is a real game-changer for non-technical folks

Fair! I agree that we want as little code as we can get away with. We love pull requests with a lot of red (deleted lines).

Like you say about libraries, it is possible to have code that isn't your problem. It's all about how leaky the abstraction is. Right now LLMs write terrible abstractions, and it's unclear how long it'll take for them to get good at writing good code.

I am excited to invest more in tools to make the understanding of code easier, cheaper, and more fun. My friend Glen pointed one way in this direction: https://glench.github.io/fuzzyset.js/ui/

As Geoffrey Litt likes to say, LLMs can help with this by building us throwaway visualizers and debuggers to help us understand our code.

Such a great essay! Peter Naur's thesis is also the central point in my talk about vibe coding from last month: https://www.youtube.com/watch?v=1WC8dxMC4Xw

I'm spending an inordinate amount of time turning that video into an essay, but I feel like I'm being scooped already, so here's my current draft in case anyone wants to get a sneak preview: https://valdottown--89ed76076a6544019f981f7d4397d736.web.val...

Feedback appreciated :)

My top choice for this kind of thing in 2025 is GitHub, using GitHub Pages. It's free for public repositories and I haven't seen GitHub break a working URL that they have hosted in the 17+ years since they first launched.

A few years ago I'd have recommended Heroku on the basis that their free plan had stayed reliable for more than a decade, but Salesforce took that accumulated goodwill and incinerated it in 2022.

As someone building a new hosting provider with a free tier (https://val.town) it's so lovely to see folks like Simon value long-term stability. It makes it easier to make the business case to invest in it. At the end of the day, it's all about trust.