Have you considered moving to open source / Chinese models?
If gemini-2.5-flash-lite is good enough for your application, you will find even lower cost options with better performance outside of the Google ecosystem.
I worked in a startup whose value proposition was largely derived from using graph data and graph databases under the hood. The main benefit is, as the repo even states "Fast data processing: Links traversal is processed with O(1) complexity."
So, technically, you can do deep traversals quicker. A few notes:
1. Few use cases truly need low-latency deep traversal on realtime data (>5 hops). There are some well known ones like fraud detection in payment processing and, possibly, social media recommendation engines. But I am not even sure how latest social media engines work, and whether they still rely on graph DBs.
2. However, in practice the advantage is often marginal. With modern analytical databases, or even an optimized PostgreSQL (ltree, materialized views, pgrouting, pg_duckdb, etc), you often get more than good enough performance. In addition those traditional SQL DBs scale with hardware more easily than graph databases. So, you can always use the lever: "Throw more hardware at it."
3. Even Graph DBs don't get good traversal performance under all conditions without hand tuning. For example, there is the "super node" issue, a node with an abnormally high number of connections (edges). And if you still need hand-tuning, you might as well choose something more versatile.
4. The ecosystem of a PostgreSQL and other popular DBs is just unbeaten. With graph DBs, you often prematurely put yourself in a corner that you don't want to be in.
Hence, my recommendation. Unless you are really sure that a graph DB is the right fit for your use case, start with something else, and go the graph db way when you have established a true need.
It is unfortunate for the employees but it is necessary, and hopefully also a wake up call for other German companies and the government.
It’s time for leaner structures, smaller teams, faster decisions, and shorter development cycles. Volkswagen, like no other company, symbolizes the lethargy of the German economy and business environment.
Hopefully, the seven years with barely any economic growth will end soon.
> A small task that cost 121,000 tokens done directly cost 513,000 tokens when fanned out to two subagents, because every subagent has its own bootstrap cost, and the parent then consumes its transcript.
Is that true? My understanding is that the subagent only returns the result of the request without the main agent consuming its entire transcript.
Thanks! There is something magical about those symbolic approaches. But in practice, they seem to often fall short of expectations. Wonder whether there will be another "symbolic AI summer" one day.
I see. Cool. So did you generate the inference / reasoning rules to map those 500k events to 40 by hand or are there solutions to automatically discover those rules based on past incidences?
"Halle is in the state of Saxony-Anhalt, which has an election in September. The far-right anti-immigrant Alternative für Deutschland (AfD), which is leading the polls with about 42%, has seized on the row."
Yeah. Agree. The workload changes towards more orchestrating, editing, and reviewing rather than writing.
I see the same for slide decks. The bar has changed. Expectations are higher, but the high quality decks are still heavily edited, reviewed, and created by humans.
Based on your message, I assume you are and want to stay in software engineering.
Having worked in regulated and very sensitive industries (banking and semiconductor), I can tell you adoption is slower but AI is still everywhere. Because those industries have many constraints, they have to think hard how to adopt it. So, you will encounter AI initiatives everywhere.
If you want to be part of those adoption initiatives but just want more thoughtful and slower adoption, such industries might be a good fit. If you want to avoid AI initiatives in general, I am not sure whether software engineering is the right function.
Ilya mentioned in the video that 2012 and 2020 was the “Age of Research”, followed by the “Age of Scaling” from 2020 to 2025. Now, we are about to reenter the “Age of Research”.
Very cool. I implemented something similar for personal use before.
At that time, LLMs weren't as proficient in coding as they are today. Nowadays, the decorator approach might even go further and not just wrap LLM calls but also write Python code based on the description in the Docstring.
This would incentivize writing unambiguous DocStrings, and guarantee (if the LLMs don't hallucinate) consistency between code and documentation.
It would bring us closer to the world that Jensen Huang described, i.e., natural language becoming a programming language.
The answer almost certainly is no. While lithography is one of the largest single contributor to manufacturing costs, the contribution to overall cost is still far below 10%.
And one cannot simply substitute an optical lithography with a nano imprint machine without redesigning some part of the process (etch, metrology etc.).
Investing R&D resources for a (best case) 10% reduction in costs while still having a decent probability of failure in a big but declining node is not worth it.
- Even works well on mobile.
- Embedding images and videos also works flawlessly.