100% this! This is why I explicitly mentioned in my CLAUDE files to generously use Python for any calculations using the virtualenv. It was also my first time using Claude for tax related calculations so I did cross-check it against an online ACB calculator https://www.adjustedcostbase.ca
> I use structured JSON documents precisely for this reason, because with a well-defined schema the LLM can write TypeScript functions that must compile.
The intention of this is to reduce hallucination on information extraction, right?
Also, how do you convert your docs / information into JSON documents?
As a counter argument to the kubectl example made in the article, I found the k8s MCP (https://github.com/containers/kubernetes-mcp-server) to be particularly usefuly in trying to restrict LLM access to certain tools such as exec and delete tools, something which is not doable out of box if you use the kubectl CLI (unless you use the --as or --as-group flags and don't tell the LLM what user/usergroup those are).
I have used the kk8s MCP directly inside Github Copilot Chat in VSCode and restricted the write tools in the Configure Tools prompt. With a pseudo protocol established via this MCP and the IDE integration, I find it much safer to prompt the LLM into debugging a live K8s cluster vs. without having any such primitives.
Orchestera (https://orchestera.com/) - Fully managed Apache Spark clusters in your own AWS account with no additonal compute markups, unlike EMR and Databricks.
Currently implemented the following:
- Automated scale in / scale out of nodes for Spark executors and drivers via Karpenter
- Jupyter notebook integration that works as a Spark driver for quick iteration and prototyping
- A simple JSON based IAM permissions managementent via AWS Parameter Store
Work-in-progress this month:
- Jupyterhub based Spark notebook provisioning
- Spark History Server
- Spark History Server MCP support with chat interface to support Spark pipeline debugging and diagnostics
Spent my 2025 building https://orchestera.com as a side project. The premise is simple - to give Data Engineers and Data Scientists the opportunity to spin up Apache Spark clusters on Amazon EKS without them needing to know all the infrastructure details, how Spark works on Kubernetes, auto-scaling etc.
The platform I am building allows users to launch Spark on Kubernetes in their own AWS account without adding any markup costs to the CPU/Memory on EC2 instances. For example, AWS EMR offering adds a 25% markup cost on top of the EC2 instance pricing. Databricks markup is even higher ranging anywhere from 30% to 100% markup.
I second that. Home Assistant "just works". I have had it running on this cheap used HP EliteDesk 705 G3 Mini Desktop for more than 4 years now without a hiccup and barely any maintenance or hygeing work on it. Just sitting in my tv stand and doing it's work.
Does anyone else find the irony in this statement from a company that is pushing for a Virtual Reality social world since almost the beginning?
> Our early analysis of performance data suggests that engineers who either joined Meta in-person and then transferred to remote or remained in-person performed better on average than people who joined remotely. This analysis also shows that engineers earlier in their career perform better on average when they work in-person with teammates at least three days a week. This requires further study, but our hypothesis is that it is still easier to build trust in person and that those relationships help us work more effectively.
> As part of our Year of Efficiency, we’re focusing on understanding this further and finding ways to make sure people build the necessary connections to work effectively. In the meantime, I encourage all of you to find more opportunities to work with your colleagues in person.