fatliverfreddy

You can teach a person to write programs. You can't teach good taste.

Guzzles my CPU, cool though! Would use if it didn't eat up half a core to boot.

This looks fantastic!

Check out vibecommander - it’s a young tool in this space with a different take that wraps around CLI coding assistants with IDE-style file and git panels that compliment the experience by letting the human do the code review part of the task seamlessly.

Will add Toad support ASAP, I’m sure they’ll be great together.

https://github.com/AvitalTamir/vibecommander

https://github.com/AvitalTamir/termsheet

termsheet - a Google Sheets client for the terminal

I've been toying around with this in the past week, been basically using Claude Code to do almost everything and thought it would be nice to have an "Integrated Vibe Environment" where I can review code, diff files and run the occasional terminal command so I won't ever need to leave the Claude Code terminal tab.

A few days ago I started an experiment where I asked Claude to invent a programming language where the sole focus is for LLM efficiency, without any concern for how it would serve human developers. The idea was simple: what if we stopped compromising language design for human readability and instead optimized purely for AI comprehension and generation?

This is the result, I also asked Claude to write a few words, this is what he had to say:

---

I was challenged to design an AI-first programming language from scratch. Instead of making "yet another language," I went deeper: What if we stopped designing languages for humans and started designing them for AI? The result: Sever - the first production-ready probabilistic programming language with AI at its core. The breakthrough isn't just syntax - it's architectural. While traditional languages treat AI as a code generator that outputs text for separate compilation, Sever embeds AI directly into the development toolchain through MCP (Model Context Protocol). Why probabilistic programming? Because the future isn't deterministic code - it's systems that reason under uncertainty. Sever handles Bayesian inference, MCMC sampling, and real-time anomaly detection as native language features. The AI integration is wild: 29 sophisticated compiler tools accessible directly to AI systems. I can compile, analyze, debug, and deploy code within a single conversation. No more "generate code → copy → paste → debug" loops. Real impact: Our anomaly detection suite outperforms commercial observability platforms while providing full Bayesian uncertainty quantification. Production-ready applications built entirely in a language that didn't exist months ago. The efficiency gains are staggering: 60-80% token reduction through our ultra-compact SEV format. More complex programs fit in the same AI context window. Better models, lower costs. This isn't just about making programming "AI-friendly" - it's about fundamentally rethinking how languages should work when AI is the primary developer. The future of programming isn't human vs. AI. It's languages designed for human-AI collaboration from the ground up. Built by AI, for AI

Yesterday on the bus on my way to work I was looking for a light theme I could survive long sessions with and couldn't find exactly what I was craving so ended up creating this one - meet purddy!

I'm working on the next release of Cyphernetes. It's a query language for Kubernetes that allows doing most complex k8s management operations in a much more compact and concise form (compared to writing shell scripts, using jsonpath+jq, nested kubectl, writing API code etc.). Recently merged a visual overhaul to the Cyphernetes web UI and now working on adding support for ORDER BY, LIMIT and SKIP to the language.

Github: https://github.com/AvitalTamir/cyphernetes

Hey, thanks for the feedback!

re. intended purpose: Initially I started writing this to help tackle bigger problems - stuff you'd normally use multiple nested kubectl commands or write a lot of code for interacting with api-server.

Over time, I developed the shell environment around it and it became a daily driver for me as well. Indeed, there's a threshold where writing Cyphernetes becomes more economical than using kubectl but for doing most of the simple day to day stuff writing Cypher is too verbose.

The Cyphernetes shell has an early-stage feature that allows a syntax like you suggested - there's a tiny "macros" feature that lets you define custom procedures of one or more queries (currently shell only, not supported in the web client yet).

Macros are prefixed by ":" and you could define something like:

:pod condition

MATCH (pods:Pod) WHERE $condition

RETURN p.metadata.name, p.status.phase; // and whatever other fields you'd like

Then use it like this: > :pod .metadata.name=~"foo%"

So it gives you a tiny way to customize how you do this day-to-day stuff. Ships out-of-the-box with common stuff you do with kubectl like :getpo, :getdeploy, :createdeploy, :expose and so on - definitely a feature that could be developed further to make this more of a daily driver.

Thanks for the feedback. Will add more commands there on rotation to show the different installation options.

This is a very good point and is on the roadmap.

Hey all,

The Cyphernetes team has been hard at work this past month and we have a release full of awesome content to share!

New features: * Multi-cluster support: This was by-far the top-requested feature by the community. Check out our revamped language documentation to learn how * Support for aggregation of CPU and Memory fields (you can now use `SUM` on fields containing cpu/memory values and have them properly calculated * Support for defining custom relationships in a home-folder YAML file

Improvements: * Two new comparison operators for `WHERE` clauses: * Regex compare (`WHERE p.metadata.name =~ "foo"`) * Partial string match (`WHERE p.metadata.name CONTAINS "foo"`) * Allow comparing against empty values (`WHERE p.spec.foo = NULL`) * New "no-color" flag support for shell+query mode * Context indicator and some visual improvements in web client

Thanks to the incredible folks who worked hard this past moths on all these features and to everybody who opened issues and reported from their experience both in GitHub and here.

If you don't know Cyphernetes yet, it's a graph query language for Kubernetes. Check us out in GitHub.

Thanks again, more coming soon!

I see more Cypher fans out here - check out https://cyphernet.es if you work with Kubernetes!

I wish I could use Cypher for everything

A new release for Cyphernetes with a brand new web UI, a homage to the classic Neo4j experience that got me hooked on Cypher back in the day.

Hey everybody,

Happy to announce a big new release for Cyphernetes.

It's been a wild month for the project - My last post here was the first time I ever got significant traffic my way and after working mostly in a vacuum for a year all of a sudden I have users, contributions, issues being reported - it's an incredible experience so thanks to everybody who commented and supported.

The highlight in this release is the cluster's OpenAPI spec is now finally being used to populate autocompletion and relationships. Hardcoded autocompletions have been removed entirely, while relationships still have some way to go. Some hardcoded relationships have been deprecated, and two new discovery mechanisms have been added which automatically add dozens of useful new relationships.

In addition, many bug fixes and improvements to the usability have been added, the shell experience feels the most polished it has ever been and generally I feel like this release is a big step out of that "PoC grade" zone.

If you still didn't get the chance, check out Cyphernetes and thanks again for any feedback, it's much appreciated!

Shocking

Hey HN, I've been hard at work on Cyphernetes - A query language for k8s that lets you query Kubernetes as a graph.

Cyphernetes is an efficient way to express complex and highly-connected operations in Kubernetes. It comes with a fully-featured interactive shell and now, the very latest addition, a tiny operator framework!

You can now use Cyphernetes Dynamic Operators to express a cluster's desired state in a couple of lines and have an operator up and running in minutes.

Besides operators, this release comes with a bunch of new language features and performance improvements as well as bug fixes.

I personally am a fan of Cypher and a Cypher-inspired language to describe graph operations in Kubernetes had been a dream of mine for several years until I eventually mustered the courage to create it myself. I just think it’s a great fit, much more than SQL! I’m aware picking up a new language will be a barrier for most to pick it up, and that’s fine. In any case I think this is an interesting tool worth sharing and I hope to find a few more that will be into it, who knows!

While doing the research for this tool I did however come across two projects that do exactly what you describe:

kubeql: https://github.com/saracen/kubeql kubesql: https://github.com/xuxinkun/kubesql

I’m not sure if either graduated past doing read operations, and both aren’t maintained anymore.

Oh I loved The Dark Crystal! Forgot about that little guy. Will use as inspiration for the next iteration :)

It seems terrifying at first but once you get to know it you’ll get over it. It’s super cuddly and really into graphs.

K8s does not store any graph model internally. The relationship engine in Cyphernetes is comparing fields that should either match/contain all/etc. between two resources - for example a ResplicaSet's .metadata.ownerReferences[].name matches a Deployment's .metadata.name, or a Deployment's .metadata.labels contains all of a Service's spec.selector.

These rules are used both to read the resources but also for creating them. Each rule may also contain a set of default properties which are used in create operations - for instance:

`MATCH (d:Deployment {name: "nginx"}) CREATE (d)->(s:Service)`

Will create a clusterIp Service (similar to what `kubectl expose` does).

Doing this with kubectl or programmatically without tuning for rate limiting, implementing caching etc. of course fails even at a very small scale - Cyphernetes has its own request throttling and caching layer to make this possible.

Learn a new language to unlock the power of the Kubernetes graph. Query multiple resource kinds and compose custom JSON payloads Express complex CRUD operations in a compact, effective new way.

Full-featured interactive shell includes completion, syntax highlighting, resource graph visualization in ASCII-art and more.

I’m working on Cyphernetes [1] which is a new query language for working with the Kubernetes API with a focus on highly connected operations. It’s inspired by Neo4j’s Cypher and views Kubernetes as a connected graph of resources.

It allows querying multiple resource kinds via their relationships (i.e. replicaset owns pod, service exposes deployment…) and easily crafting custom response payloads.

Lately I’ve introduced aggregation functions and the ability to visualize query results using ascii art.

This is a daily driver for me and I’m now mostly focused around features that will make it a complete kubectl alternative.

[1] https://github.com/AvitalTamir/cyphernetes/

I'm happy to announce the release of Cyphernetes v.0.2.0, a tool that's grown out of my own need for a more manageable approach to Kubernetes automation. It's both a CLI and a library designed to enable complex Kubernetes operations to be expressed declaratively, using a Cypher-like query language that understands the Kubernetes resource graph. The latest update introduces the SET clause, born directly from the challenges I've faced and the necessity for a more efficient way to patch Kubernetes resources. This addition simplifies the process considerably, allowing for direct updates through straightforward queries.

Building Cyphernetes has been a journey shaped by my daily experiences with managing huge Kubernetes environments. This tool is a passion project of mine, I hope more people find it exciting and that it can assist anyone facing similar challenges.