Like other tech disrupted crafts before this, think furniture making or farming, that's how it goes. From hand-made craft, to mass production factories (last couple of decades) to fully automated production.
The craft was dying long before LLMs. Started in dotcom, ZIRP added some beatings, then LLMs are finishing the job.
This is fine, because like in furniture making, the true craftsmen will be even more valuable (overseeing farm automation, high end handmade furniture, small organic farms), and the factory worker masses (ZIRP enabled tech workers) will move on to more fulfulling work.
Where do people find this optimism? I reckon when the software jobs fall everything else will follow shortly too. That's just the first target because it's what we know and the manual stuff is a little harder for now. The "good news" is everyone might be in the same boat so the system will have to adapt,
There is however no reason to believe that the system will adapt in ways that are beneficial to you. Those in power don't tend to like giving it up and now they don't even need other humans to help them oppress those that would stand up to them.
Software, and most STEM based jobs, have a lot of determinism and verifiability + some way to reduce the cost of failure so brute force iteration can cover up the remaining. There is often "a correct answer". They've also yet to be truly disrupted until now which makes them particularly vulnerable than any other job.
Most jobs don't have the same level of verification and/or repeatability. Some factors include:
* Physical constraints: Even the jobs that have productive output if they are physical it will take a long time for AI and more importantly energy density to catch up. Robots have a while to go as well - in the end human hands and your metabolism/energy density will be worth more than your brain/intelligence.
* Cost of failure/can't repeat: For things like building the cost of failure is high (e.g. disposal, cleanup, more resources, etc) -> even 70% of a "building bench" benchmark would be completely inadequate without low cost to repeat. Many jobs are also already largely automated but scaled (e.g. mining, manufacturing, etc) - they've already gone through the wave.
* Human need for its own sake: Other jobs cater not just for productive output, but for some human need where it hasn't been made more efficient ever (e.g. care jobs). There are jobs that a human is more effective in the medium term because the receiver needs it from a human.
No -> this just affects white collar STEM based roles. Thinking we are in it together is just another form of "cope" sadly. There's a rational reason why others have optimism while we SWE's are now full of anxiety and dread.
For the people who it doesn't affect given their current place in many societies (nurses, builders, etc etc) there will be little sympathy.
That’s not how it goes for the worker. If you are a capitalist then it doesn’t matter, you own the means of production. The laborer, however, has to learn new skills, which take time and money. If your profession no longer exists, unless you have enough capital to retool/be a capitalist, then you will personally get poorer.
I'm not sure comparing artisanal software to woodworking or organic farming is possible.
With woodworking and farming you get as a result some physical goods. Some John Smith that buys furniture can touch nice cherry paneling, appreciate the joinery and grain. With farming you he can taste delicious organic tomatoes and cucumbers, make food with it.
Would this John Smith care at all about how some software is written as long as it does what he wants and it works reliably? I'm not sure.
CedarDB focuses on being a high-performance HTAP database whereas Spice's was built from day 1 to enable high-peformance data and search for data-intensive applications and AI.
So Spice natively has data acceleration, federation, hybrid-search (vector + BM25 full-text-search), and LLM inference in the core runtime so you can zero-copy data across them, which you would not normally see in a database like CedarDB.
Like most things, all measures fail point in time and on short time horizons, but law of big numbers and trends can be useful. I.e. compare yourself (on almost any measure) to yourself in your most productive period.
We reviewed our metrics for period-on-period comparisons at 1, 2, 3, 4 years and the numbers are surprisingly consistent for each person, and across similar productive engineers.
Like in the article, if you can apply a semantic score across years of data, it gives you a pretty good idea.
Periodic objectives x customer results then GPT-5 scoring pull requests, etc. against them roughly aligned to that period. I.e. it scores higher if code is used by and produces value for customers.
Hi HN, we’re Luke and Philip, founders of Spice AI. Today, we’re announcing Spice.ai OSS 1.0-Stable, a portable, single-node data query and LLM-inference engine built in Rust.
We introduced the very first POC of Spice.ai OSS on ShowHN in Sep 2021 as a runtime for building AI-driven applications using time-series data!! [Insert, it’s been 87-years meme].
One of the hard lessons we learned was that before we organizations could use AI effectively, they needed a much higher level of data readiness. Our customers told us they wanted to adopt AI and technologies like Arrow, Iceberg, Delta Lake, and DuckDB but simply didn’t have the time or resources (and were struggling to keep up), so we focused on making it super easy and simple to use them. We rebuilt Spice from the ground up in Rust on Apache DataFusion, and launched on ShowHN in Mar 2024 as a unified SQL query interface to locally materialize, accelerate, and query datasets sourced from any data source.
It’s designed for developers who want to build fast, reliable data-intensive and AI apps without getting stuck managing ETL pipelines or complex infrastructure.
That release was just the data foundation and today, we’re announcing Spice.ai OSS 1.0-Stable that includes federated data query, acceleration, retrieval, and AI inference into a single engine—now ready for production deployments across cloud, BYOC, edge, or on-prem.
Spice supports accelerating federated queries across databases (MySQL, PostgreSQL, etc.), data warehouses (Snowflake, Databricks, etc.), and data lakes (S3, MinIO, etc.). It materializes datasets locally using Arrow, DuckDB, or SQLite for sub-second query times and integrates LLM-inference and memory capabilities and a purpose-built data-grounding toolset that includes vector and hybrid search, Text-to-SQL/NSQL, and evals to ensure accurate outputs.
The Model Context server is similar to what we've built at Spice, but we've focused on databases and data systems. Overall, standards are good. Perhaps we can implement MCP as a data connector and tool.
Being such a core component, we want developers to be completely comfortable integrating and deploying the Spice runtime in their applications and services, as well as running Spice in their own infrastructure.
In addition, Spice OSS is built on other great open-source projects like DataFusion and Arrow, both Apache 2.0, and DuckDB (MIT), so being permissively licensed aligns with the fundamental technologies and communities it's built upon.
We expect to release specific enterprise control-plane services, such as our Kubernetes Operator under a license such as BSL.
Spice AI | SWE & DevRel | FT | ONSITE (Seattle, Seoul), REMOTE (Australia)
Spice AI is the creator of the Spice.ai open-source project, a query-engine and ML inferencing runtime built in Rust on DataFusion.
Hiring experienced Rust, distributed systems, data systems, and database engineers and DevRel.
ShowHN: https://news.ycombinator.com/item?id=39854584
Details: https://spice.ai/careers
The craft was dying long before LLMs. Started in dotcom, ZIRP added some beatings, then LLMs are finishing the job.
This is fine, because like in furniture making, the true craftsmen will be even more valuable (overseeing farm automation, high end handmade furniture, small organic farms), and the factory worker masses (ZIRP enabled tech workers) will move on to more fulfulling work.