How well agents can do this is mostly proportional to how well they can understand and navigate your codebase broadly.
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.
The FDA (or equivalent in the relevant country) regulates whether an approved drug requires a prescription based on the safety profile. To be approved for OTC, there is a much higher bar in terms of ease of misuse, side effects, and so on.
My experience raising in Vancouver is that there are two angel communities.
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!
Thanks Grey – other than the presenting-at-an-event flow I do really did like the Figma Slides experience, so this is great to hear. The world is better off with a strong Figma.
I mentioned Ruby and Python in this vein, but PHP with Laravel would count in my book too. That said, PHP may be nearing the stage Java has gotten to, where it’s well-understood but is perceived as outdated enough that it causes hiring and retention friction.
While this can be done in principle (it's not a foolproof enough method to, for example, ensure an LLM doesn't leak secrets) it is much harder to fool the supervisor than the generator because:
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
Yeah this is an interesting point. Other threads make the point about the "bitter lesson", and how expert-trained ML has historically not scaled, and human-generated LLM training data may just be repeating that dead end. Maybe so.
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.
I think this is a valid criticism. I weighed a few different titles that would fit in my (arbitrary) title length limit, but on reflection the one I chose was too glib.
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.
> Also "generate some better examples" sounds like fudging data to fit the expected outcome.
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.
> be sure to do it strongly in one direction or the other, so that you set the direction of exploration, too.
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.
I too find this frustrating, but I’m curious about the claim that Chrome is the most common browser on Mac. I sometimes see this claim, but I struggle to find any data to back it up.
The US government web analytics (https://analytics.usa.gov/data/), which seems like a reasonable source for general usage in the US, show Safari substantially ahead of Chrome on Mac.
Have you seen any sources that show Chrome ahead of Safari on Mac for a general audience?
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!