danenania

Being one of the people on this list... yes I would personally say it's mainly about agency and determination, and being obsessive/perfectionist about details. I think YC selects for these traits much more than domain expertise or raw intelligence.

Now that I'm working at a large org (before this my career was purely in startups), I see the importance of this all the time. When you work on a significant project in a bigger org, you get blocked by all kinds of things. Most have very reasonable explanations, but you are blocked nonetheless. Many people just accept this and allow things to proceed pretty slowly, or they accept tradeoffs that make the product worse because it's the path of least resistance. If you want to go faster and not compromise on details, you often have to be persistent and willing to follow up on things to the point of being annoying, which feels similar to being a founder.

publicly reported numbers

Anyone can google it /shrug

I’d also point out that LLM inference revenue already totals more than 100B annually based on publicly reported numbers. Almost none of that is replacing knowledge workers. Almost all is increasing their productivity. So empirically what you describe is already happening to a nontrivial degree.

Cool, good to hear. I think it’s often the case even within an individual file or change that it’s 90% routine and 10% critical to review. That’s a big part of the problem in my mind.

Interested to try this! Have you thought about separating the parts of a PR that are routine/uninteresting from the parts that are load-bearing and need more careful review?

I mean it’s quite literally a command line interface to their tool… what else should it be called that differentiates it from a pure browser flow?

What you are describing sounds more like “TUI” than “CLI” imo. A CLI is an interface—it’s about the input step. It makes no promise about what happens after that.

You can’t get every detail right up front, but you can build a robust foundation from the beginning.

The argument seems to be that AI is causing managers to demand faster results, and so everything has to be a one-shotted mess of slop that just barely works. My point is that it doesn’t take much longer to build something solid instead. Implementation time and quality/robustness are not tightly coupled in the way they used to be.

You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.

Getting the model to do it is the skill.

Line by line is no longer what I need to think about. I think about types/schemas, architectural division, contracts between services and components, how to test thoroughly, scaling properties, security properties, and these kinds of things.

It takes very little time to polish now.

That sounds pretty much the same as it’s always been? It used to be: “Does the happy path work? Then ship it! There’s no time to make it robust or clean up tech debt.”

Now there actually is time to make things robust if you learn how to do it.

thinking, abstracting, deciding how to apply your knowledge and experience, searching for information

None of this requires coding by hand. I can do those things better and faster with agents helping me. That incudes unfamiliar areas where I am effectively a junior.

That’s also true without AI. Engineers want more time to polish and businesses want to ship the 80/20 solution that’s good enough to sell. There's always going to be a tension there regardless of tools.

This is a great point. We’re very much in a transitional phase on this, but I personally do see signs in my own work with agents that we are heading toward the main deliverable being a readme/docs.

The code is still important, but I could see it becoming something that humans rarely engage with.

If it’s broken and the dev can’t debug it, the business won’t have much of a choice.

If a junior builds something with agents that turns into a mess they can’t debug, that will teach them something. If they care about getting better, they will learn to understand why that happened and how to avoid it next time.

It’s not all that different than writing code directly and having it turn into a mess they can’t debug—something we all did when we were learning to program.

It is in many ways far easier to write robust, modular, and secure software with agents than by hand, because it’s now so easy to refactor and write extensive tests. There is nothing magical about coding by hand that makes it the only way to learn the principles of software design. You can learn through working with agents too.

It seems like that could change the math quite a bit, since you’d presumably be losing a lot of capacity to failures. I’d assume you would have a much higher failure rate in space, and component failure is already pretty common on earth.

What about maintenance? I’d naively assume that’s the killer.

I thought we might finally have a high profile prompt injection attack against a name-brand company we could point people to.

These folks have found a bunch: https://www.promptarmor.com/resources

But I guess you mean one that has been exploited in the wild?

tmux makes it easy for terminal based agents to talk to each other, while also letting you see output and jump into the conversation on either side. It’s a natural fit.

Gemini 1.5 Pro actually has 2M!

No other model from a major lab has matched it since afaik.

Edit: err, I see in the comment below mine that Grok has 2M as well. Had no idea!

I built a tool at work that allows claude code and codex to communicate with each other through tmux, using skills. It works quite well.

The correct answer is “Postgres would handle it, but if it needed to scale even higher, I’d…”

The point of a system design interview is to have a discussion that examines possibilities and tradeoffs.

I have a similar process and have thought about committing all the planning files, but I've found that they tend to end up in an outdated state by the time the implementation is done.

Better imo is to produce a README or dev-facing doc at the end that distills all the planning and implementation into a final authoritative overview. This is easier for both humans and agents to digest than bunch of meandering planning files.

Very cool! A noob question about how models handle video: do you do everything via sending frames as images to the model at some framerate? Are there tricks to avoid what it seems like would be massive token use from this approach?

I’m very pro AI coding and use it all day long, but I also wouldn’t say “the code it writes is correct”. It will produce all kinds of bugs, vulnerabilities, performance problems, memory leaks, etc unless carefully guided.

There are different kinds of tribal knowledge. Some is company-specific, some is role-specific or domain-specific.

The date is just a useful fiction to:

- Create urgency

- Keep scope creep under control

- Prioritize whatever is most valuable and/or can stand on its own

If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.

I don’t think “ready to merge” necessarily means the agent actually merges. Just that it’s gone as far as it can automatically. It’s up to you whether to review at that point or merge, depending on the project and the stakes.

If there are CI failures or obvious issues that another AI can identify, why not have the agent keep going until those are resolved? This tool just makes that process more token efficient. Seems pretty useful to me.