That’s also roughly what I find after a long English-only session with a coding agent. Our conversation covers a lot of ground... and leaves out details at every level. When I look at what got built, the misunderstandings are fractal too.

I agree it’s important to design it yourself, but UML is only one level. Lately I’ve been using a scratch Python file (or even a scratch repo) that Claude and I both edit. Never mind that I’m writing Rust. Python reads like pseudocode, and pass and ... (Ellipsis) let me skip whatever I don’t care about. At any level where I do care, I can say exactly what a method’s signature should look like, what fields a domain model should have, or how it should maintain key invariants. Everywhere else I leave an ellipsis, maybe a docstring, and let the agent decide.

It works both ways: I ask the agent to sketch the current system in Python, with some details elided and others spelled out. Then I edit the sketch and have the agent push the changes back into the much bigger Rust+Tauri app.

Time will tell whether this approach has legs, but when I want to be precise, I find it sometimes pays to just write some code.

You didn't.

I started my career and my first company during the dot-com boom, before YC even existed and the word "startup" took its current narrow shape.

Things were ugly right after the bubble burst, but the years that followed were some of the best for building I can remember.

The tools change, and not necessarily for the better, particularly if you care about the craft for its own sake. But the hard part was never the build. Even back then, before AI, anyone could copy you fast. The hard part was knowing what to build, for whom, and how to reach them.

What anyone calls a startup doesn't matter. Build the things!

> best weapon against complexity spirit demon is magic word: "no"

In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.

amusing nonsense

Comments URL: https://news.ycombinator.com/item?id=48254011

Points: 4

# Comments: 0

I get the impression that the intersection of HN posters and Copilot users is quite small in practice; that Claude Code and Codex suck up all the oxygen in this room. But it seems plausible we’ll see similar “true costs greatly exceed our current subscription pricing” from Anthropic and OpenAI someday soon…

FWIW it's not entirely clear to me who Entire's long-term customer is, but the (interesting!) CLI that shipped today is very much for developers who are busy building with agents.

https://github.com/orgs/heroku/projects/130

I found that agentic coding tools were quite good at answering my architectural questions; even when their answers were only half correct, they usually pointed me in the right direction. (I didn’t use AI to write code and I wonder if agentic tools would struggle with certain aspects of the codebase like, for instance, the Cambrian explosion of utility macros used throughout.)

See https://docs.python.org/3/whatsnew/3.13.html#an-experimental...

Comments URL: https://news.ycombinator.com/item?id=46234088

Points: 2

# Comments: 0