Ben Weiner

founder in sf. orbital, unboxed, dailymile. did you see the runner’s hair?

[Ben Weiner @bweiner]

ever wondered whether most software never seems to get better because writing code takes time or because most teams don't know what good looks like or what's worth building? now that code basically writes itself, i think we have our answer...

[Jason Fried @jasonfried]

The speed at which a product is developed doesn't inherently make the product better or worse. The number of commits doesn't make the product better or worse. The number of people or agents working on it doesn't make it better or worse. The number of hours you’re pouring into it doesn’t make it better or worse. Working on a weekend, or late into the evening, doesn’t make it better or worse. Talking about these things sounds like it’s talking about the product, but it’s not talking about the product.

Those are all development metrics and styles of work. They don't speak to the product itself. They're all back of the house. Important to those making the work, but not inherently important to the people using the work.

Development metrics and style say nothing about fit. They say nothing about quality. They say nothing about clarity. They say nothing about usability. They say nothing about utility. They say nothing about performance. They say nothing about how customers feel when they use your product.

It's like reviewing a restaurant by talking about how many cooks were in the kitchen, how long the shift lasted, how many orders they fired, or how late they stayed cleaning up. None of that tells you about the meal, the product, the customer’s experience.

Mistaking making for the thing you've made is like confusing the kitchen for the meal or the blueprint for the building. They're connected, but they're not the same thing. One of them matters a whole lot more than the other.

[Ben Weiner @bweiner]

@P_Bonnet @turbopuffer @Sirupsen very bullish on turbopuffer. did you access the calls via AlphaSense?

[Ben Weiner @bweiner]

@KentonVarda this is true but also an IC and EM are responsible in different ways for shipped code

[Ben Weiner @bweiner]

@brandur yeah, same. i find ai can do a very thorough job reviewing from a correctness lens, but i find it lacking on some of the other lenses you bring to a code review. i guess ymmv depending on how much effort you’ve spent trying to solve for all that.

[Ben Weiner @bweiner]

@stevekrouse A codebase is legible if...

[Ben Weiner @bweiner]

pointbreak looks really interesting. in the scenario of one agent using context from pointbreak to review another agent's work, does that context not overly bias it? ie, with human review, it's nice to have fresh set of eyes from someone who didn't get into the weeds on the particular solution (of many) to review work. and it's so much easier to get an llm to overindex on something in its context than a human.

[Ben Weiner @bweiner]

@breckyunits @stevekrouse can't both claims be true? when i read "writing is thinking" i think that writing is one way in which we form and change our thoughts and that seems clearly valuable

[Ben Weiner @bweiner]

@eliebakouch yes, this is super impressive, but a lot of people reacting to this are missing that the model just did what it was prompted to do

[Ben Weiner @bweiner]

this was always the bar for product eng. what's changing is the speed of delivery, which puts downward pressure on product decisions toward the IC. (also, PMs are converging from the other side, they can build now too!)

[Drew Breunig @dbreunig]

“taste” isn't enough…

The three tiers of agent powered developers:

1️⃣ Can implement products: Can use agents to build code, with great tests.
2️⃣ Can implement products, 𝘄𝗶𝘁𝗵 𝗴𝗿𝗲𝗮𝘁 𝘁𝗮𝘀𝘁𝗲: Your feedback, which can keep up with the pace of code creation, lets you ship *good* products.
3️⃣ Has a deep empathy for their market and user and tons of surface area with them to stay up to date: Taste isn't enough! You need user empathy.

Everyone keeps saying “taste”, to define a company's value when code is cheap. But “taste” is incomplete.

User understanding, subject matter expertise, etc. These things are no longer the domain of just Product people, they need to be internalized by all and orgs should be designed to max out this surface area.

I've said the difference between a good data scientist and a great data scientist is domain expertise:

“When you have an idea how the business works, you can make more complex assumptions and develop hypotheses further out from the baseline. Bigger leaps, adequately tested, help you move faster and find unique information.”

This now applies to software engineers.

[Ben Weiner @bweiner]

@steipete are we back to workflows now?

[Ben Weiner @bweiner]

@nabeelqu found it. will read this and give the ep a listen. thanks!

[Ben Weiner @bweiner]

@RhysSullivan this is the right approach almost always. long ago would handroll generating sdks and typed frontend clients for react from an api, but nowadays there is so much tooling to support that generation, and every web framework will have some way to generate the openapi specs too.

[Ben Weiner @bweiner]

@nabeelqu oops, s/reader/listener, not used to using this phrase in this context apparently :)

[Ben Weiner @bweiner]

@nabeelqu do they spend time a lot of time on this premise or is it left up to the reader? not immediately obvious to me why this would be true

[Ben Weiner @bweiner]

@_lopopolo @AdamDNewell @tombombadeel this is really the only way because even for a given individual, those 6 skills you want will change based on the specific task or modality that you’re operating in.

[Ben Weiner @bweiner]

@alvinsng this is great. the takeaway for providers is that as models evolve and along with the needs of AX vs DX, exposing multiple layers is really the way to go.

[Ben Weiner @bweiner]

@GeoffreyHuntley i mean, that's certainly where things are headed. good luck time traveler 🫡

[Ben Weiner @bweiner]

@GeoffreyHuntley lol, you win :)