omarhaneef

At the heart of this article is the claim that buying equity is a form of theft.

That is an extreme claim (in the sense of surprising, remarkable, unusual, and one that needs a lot more support than ordinary claims).

It is inadequately defended here. The argument that it violates fair exchange is tautological.

There are a few dozen of these out there. That’s the first question anyone should answer.

I know you’re trying to see where the puck is headed but I think there is a lot of work between where we are and where LLMs replace 4 Junior devs.

The workflows we have are not quite right for it. Coding has always been 10% coding and 90% debugging but I think the rate at which we generate the 10% will grow exponentially.

This means that the debugging has to grow. We will generate errors at an unprecedented rate.

LLMs trained on previous errors and methods won’t catch them. They’ll be more complicated and spread out over the code.

We need new tools to visualize the code and track errors. I think what it means to be a programmer will change. More testing, thinking and less klocs.

If you found even a single job off of it, doesn’t that mean it’s great? This is its main purpose.

Perhaps it could be better, but a lot of people would pay a lot for a single good job offer. And you accepted it.

For every application of semantic search, I’d love to see what the benefit is over text search. If there a benchmark to see if it improves the search. Subjectively, did you find it surfaced new papers? Is this more useful in certain domains?

I think this is probably right but so far it seems that the areas in which an LLM is most effective do fine with the lower power models.

Example: the 4o or Claude are great for coding, summarizing and rewriting emails. So which domains require a slightly better model?

I suppose if the error rate in code or summary goes down even 10%, it might be worth $180/month.

One of the best pieces on here recently (and didn’t realize it was by Sinofsky!)

Anyway, one other insight I would add is that the issues tend to come up at the interface between the systems. Your automation has to get some input and send some output and both those are pain points. That’s why we sometimes prefer imperfect monolith software.

All these suggestions are great but I would add two more:

1. find a good text book in the field as narrowly construed as possible, and just browse the table of contents.

This will give you a quick map of the field, and a place to put all the info you gain.

2. Read the management discussion in the 10k of a public version of the company you work at and 2 leading customers, and the transcript from the earnings call.

Fastest way to get up to date on challenges.

If you read between the lines, it would seem no one was keeping the place clean.

I think the exciting part is this:

“BNT211 continues to show encouraging antitumor activity in patients with CLDN6-positive relapsed or refractory advanced solid tumors” <- interesting because they finally demo some effect in solid tumors in humans

“Follow-up of efficacy data at 1x108 CAR-T cells with or without CARVac shows an overall response rate (“ORR”) of 59% and a disease control rate (“DCR”) of 95%, with the CARVac cohort demonstrating a prolonged persistence of CAR-T cells” <- interesting because those are high response rate. Let’s hope it lasts and they can increase those rates but as a patient, you would take this.

This should not be a debate.

Take a note from the pet shop boys: they never argue.

They also never calculate the currency they spend.

Ugh. Any clue as to why?

I think question should include the size of the dev team.

Solo dev vs 50 devs might need different tools just to get out of each others way.