2) What they already are good at they'll continue to improve at, because of domain knowledge & ecosystem

3) The reason they are ahead in the first place is labor cost & the QOL workers will tolerate (and intentional government investment)

4) The only way around this is for the US to invest into robotics (labor) & subsidize american manufacturing (ecosystem)

Post-training/fine-tuning is not trivial and having it as a service might make it more accessible.

[0] https://surgehq.ai/blog/training-on-complexconstraints

All of these things have historically been the job of engineers, because it helps other people contribute to the code.

Now it helps other people and other agents contribute to the code.

[0] https://www.notboring.co/p/the-electric-slide

Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.

I'm excited for when Github starts letting me check in the chain-of-thought that produced a line of code, and git blame it like I can with commits.

Engineering has moved up another layer of abstraction (just like we moved past managing buffers & writing machine code)

Or maybe it will be the more established open source model where the code is free but the maintainers offer hosting/some default product

It's not a big leap to apply that model to a company and its customers, where the company builds a well-abstracted, easily extensible base that 1) Customers can easily extend/customize for their workflows 2) Customers can self-host or run fully isolated, much easier (probably not quite there yet, but is a possible world)

These are more important than ever, because we don't have the crutch of "Teammate x wrote this and they are intimately familiar with it" which previously let us paper over bad abstractions and messy code.

This is felt more viscerally today because some people (especially at smaller/newer companies) have never had to work this way, and because AI gives us more opportunity to ignore it

Like it or not, the most important part of our jobs is now reviewing code, not writing it. And "shelfed" ideas will now look like unmerged PRs instead of unwritten code

Maybe the smallest/most convenient packages (looking at you is-even) are obsolete, but meaningful packages still abstract a lot of complexity that IMO aren't easier to one-shot with an LLM

I'm worried the harsh reality for most humans is that life is often not that easy. And if it is, it won't be for long

Yirgachefe was borne out of 3 ideas:

1) Spotify Wrapped is delightful 2) In many countries, services are required by law to provide your exported usage data in a timely manner. 3) Many services don't (or can't) provide years-in-review. I also love the idea of summarizing data people may _not_ want, a la the recent SNL "UberEats Wrapped" sketch.

Now you can "wrap" anything if you have the data - traditional sources like video & music streaming, or more creative ones like terminal history, amazon purchases, git contributions, etc.

If you bring-your-own API key, all processing exclusively happens in your browser + the Anthropic API (minus some anonymized usage data sent to Umami).

Outputs aren't perfect (it's AI after all), but it's also a demo of what you can do with the latest LLM coding tools and a weekend.

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

Points: 2

# Comments: 0

In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment

I'm very interested in what this will look like for outputs from other job functions. And if we'll end up with a similar framework that makes non-deterministic, often-wrong LLMs easier to work with.