There are various contributing factors to this, but they include clear docs, notes and refactors that clear up parts the agent commonly gets confused by, choosing boring technology (your dependencies are well understood) and access to command-line tools that let it lint + typecheck + test the code. A lot of the scaffolding and wiring necessary are built into Cursor and Claude Code themselves now. Hope that helps!

In this case, I had made an overlarge squashed merge that included both the Intercom integration (a suspiciously likely cause of slowness) and the feedback button that added the heart – so I needed to go deeper to figure out the true cause. (Noto Emoji was in the app from before, but wasn't triggered in the dashboard until we added an emoji there.)

While in this case we’d included the emoji font for displaying user content in another part of the app, the hazard of letting a “simple” approach expand and get out of hand is part of what I wanted to convey in writing this.

There is an easier to find Vancouver-centric investor group that behaves as a you describe. Many of these investors didn’t come up as tech founders. I was advised not to waste time with them, so I don't know if there are some gems in the rough there or not.

Then there is a quieter group that got their capital from building serious tech businesses. This group spends more time connecting outside Vancouver – Bay Area mostly, but also Toronto and globally. These folks do write early-stage cheques and can be very helpful advisors, but they're not full-time angels who are spending time on deal flow. They're mostly focused on building their next thing, so it’s more difficult to earn their attention.

So yes there are questionable actors, but there are also very legit folks doing great work, and it’s possible to go to an event or dinner party that only really has one or the other. Hope that’s helpful to any other founders building in Vancouver!

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

Points: 2

# Comments: 0

  gpt-4o: speed 3/5
  gpt-4.5-preview: speed 3/5
  gpt-3.5-turbo: speed 2/5

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

Points: 3

# Comments: 0

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

Points: 3

# Comments: 0

1. You can't get output from the supervisor, other than the binary enforcement action of shutting you down (it can't leak its instructions)

2. The supervisor can judge the conversation on the merits of the most recent turns, since it doesn't need to produce a response that respects the full history (you can't lead the supervisor step by step into the wilderness)

3. LLMs, like humans, are generally better at judging good output than generating good output

Something that is new this time around, AFAIK, is that we haven’t previously had general ML systems that businesses and consumers are paying billions of dollars a year to use. So if, say, 10% of revenue goes back in to making better data sets every year, I can imagine continued improvement on certain economically valuable use cases – though likely with diminishing returns.

My core point is that the “Trained On the Internet” mental model is becoming less true over time, which makes it a poor model for predicting the long term performance of models. These titles would be better:

1. LLMs Aren’t Just “Trained On the Internet” Anymore

2. LLMs Aren’t Simply Being “Trained On the Internet”

3. Future LLMs Won’t Just Be “Trained On the Internet”

I’ve swapped in the first one. Thanks for the feedback.

LLMs are tools. As a tool author, you have certain desired outcomes for certain use cases. If the current data you’re training on isn’t giving you those outcomes, it is absolutely reasonable to "fudge" the data. This might mean reducing bias, or adding bias, or any number of nudges. Training an LLM is not a scientific study, it’s a product development effort.

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

Points: 69

# Comments: 155

This reminds me of a game design technique Blizzard learned to use back in the day when balancing their RTS games. Sometimes they'd make a small change – say increasing damage by 4% – and playtest the result. It seemed, maybe better? So they'd ship it. Some time later, they'd realize they had way undershot, and the ideal increase would have been 25%. They sometimes found themselves buffing or nerfing the same thing over and over, trying to get it right.

The approach that worked better for them was to err on the side of first overcorrecting – say, try increasing damage by 40%. This way, in playtesting they could clearly see the effects of having gone too far, then back off the change as appropriate.

I’ve been writing monthly for 10 years, and otherwise for 20. Topics have ranged from product development to leadership to breakfast cereal selection techniques.