sort of a tangent, but quarkus also has a concept of "dev services" that are monitorable via the dev UI. It uses Testcontainers to start and autowire runtime deps (postgres, redis, keycloak, etc.). Pretty pleasant experience to get the whole stack spun up and observable alongside the dev server.

In real use-cases, it seems that by far the hardest part is figuring out the right representation for a spreadsheet workbook and the right primitives for the agent to be able to navigate it adeptly and cost-effectively; structure is incredibly variable and the data just compresses rather poorly (values, formulas, formatting, charts, pivots, etc.).

Great stuff though, think we'll see a lot of movement in the space in the coming years!

If you attend a well-known college that bigco's hire from frequently, there's a lot of knowledge floating around about interview prep, hiring schedules, which companies pay the best, etc. Clubs host "interview prep workshops" where they'd teach the subject matter of interviews, host events(hackathons, case competitions, etc.) to help you bolster your resume for applying to these bigco's. So just by attending a better/fancier school, you'd have pretty decent odds of eventually getting a job at one of these prestigious places.

If you were to attend a less prestigious school, regardless of your aptitude or capability, the information asymmetry is so bad that you'll never learn of the prerequisites for even being considered for some of these roles. Not many upperclassmen will have interned at fancy employers, so they won't be there to help you drill dynamic programming/black-scholes/lbo models, and won't tell you that you need to have your applications prepped by a certain date, and won't tell you that you should be working on side projects/clubs, etc.

I suppose that the apprenticeship model biases towards people that already have connections, so perhaps inequality was already bad, whereas now we just have an information asymmetry that's more easily solvable.

Pretty cool to see this post, I had no idea where to find more info about it!

Only issue is that some of the managed services are still pretty half-baked, and introduce insane latency into things that should not be slow. KV checks/DB queries through their services can be double-to-triple digit ms latencies depending on configs.

YC's goals are to manage risk and to make money, and new tech like this is almost certain to make someone a lot of money. All these YC companies are just different random initializations of potential ways that this new generation of AI can affect the world. It's a given that most startups of this breed will fizzle out with no impact, but I imagine that a few of them will actually change how something is done (and make a lot of money in the meantime).

It's a delicate balance, because these Gemini models sometimes feel downright lobotomized compared to claude or gpt-5.

NotebookLM: obviously useful, but I just wanna select some files and chat w/ them or have them summarized for me. It's got low info density, way too many cards/buttons/sections/icons, and it makes the core UX really difficult for me to navigate.

This post: I wanted to know what cool thoughts he had while designing it. Instead I get some weird scrolljacking, image carousels, unnecessary visual hierarchy, cards galore, etc.

Not trying to be too negative, it's slick and all but it just gets in the way for me instead of disappearing.

also, it always feels like I need a second instance at the very least for redundancy, but then we have to ensure they're stateless and that batch jobs are sharded across them (or only run on one), and again we hit an architecture explosion. Wish that I was more comfortable just dropping a single spring boot instance on a vm and calling it a day; spring boot has a lot of bells and whistles and you can get pretty far without the architecture explosion but it is almost inevitable

As soon as I switched to Anthropic models I saw a step-change in reliability. Changing tool definitions/system prompts actually has the intended effect more often than not, and it almost never goes completely off the rails in the same way.

Obviously, this is working better in some problem spaces than others; seems to mainly depend on how in-distribution the data domain is to the LLM's training set. Choices about context selection and the API surface exposed in function calls seem to have a large effect on how well these models can do useful work as well.

Kind of a lot of work compared to just dumping the text of 2 profiles into a context window along with a vague description of what I want, and having the LLM make the binary judgment.

It's not cheap and it's not fast, but it definitely works pretty well!