Pinned Tweet
stat_pg is a StatsD-inspired native PostgreSQL metrics ingestion plugin that supports a billion metrics per second on modern hardware, and millions per second on a Raspberry Pi.
It's in alpha. It's free, open-source, and MIT licensed.
Link in first comment.
Yup, yup.
And to think, a year ago, we used to build and monitor all this the hard way.
An incremental path to a software factory:
Level 0: You notice AI is making mistakes or doing things you dislike, so you implement strong automated guardrails.
Level 1: You notice you’re repeating prompts, so you create some skills.
Level 2: You notice you’re calling skills in the same order, so you create a skill that calls the skills you use, in order.
Level 3: You notice that some skills should only be called in some circumstances, so you enhance “parent” skills to call “child” skills only when it makes sense.
Level 4: You notice you’re manually prompting the agent when the ticket is ready, so you configure your agent to monitor tickets and start automatically.
Level 5: You notice you’re manually watching your open PRs for comments, so you configure your agent to watch PRs and auto-respond.
Level 6: You notice you’re manually triggering releases, so you configure your release pipeline to release code upon merge. Features are deployed in phases for safety, so only a subset of users see the changes at first.
Level 7: You notice you’re manually watching the logs for issues after releases, so you configure your agent to open a bug and implement the corresponding bug fix when it sees an error.
Level 8: You notice the system sometimes fails, so you configure it to learn from mistakes and improve over-time.
Scaling AI to build more, safely, doesn't have to come down to trusting a bunch of AIs arguing with each other.
TL;DR - mechalinters.com
I'm building a set of reference implementations to act as a referee that AI agents have to satisfy both during development, and before code is merged. And since compute is getting cheaper by the watt everyday, I'm thinking it's time to try going as thorough in our deterministic analysis and feedback as we can go. If that sounds interesting checkout that website, and maybe mecharuby.com if you're in the Ruby community.
But as far as the idea, we can use AI to build the referee itself, but once built, then the referee (a collection of mechalinters) work for us and act as a guardrail to provide objective feedback to AI agents with the goal of making sure code changes comply with security, correctness, and performance standards.
It's (hopefully) scalable anti-slop.
One popular move right now is to throw another AI review at an AI's changes, and then another one. First of all, running a pile of AI reviews on every change gets expensive, but even if you had infinite funding what do you get at the end. You get the Spider-Man meme of AI reviews with nobody taking ownership; a bunch of opinions, but it's still up to you to figure out what to do.
So, what if you could flip that around, pour your years of experience into a referee system that enforces what's important to you, that can be constantly updated to consider new threat models, new CVEs, and the best available public research?
Or, something more humble: what if you could build a referee that simply enforced your design aesthetic at scale, deterministically?
We have more compute than we know what to do with these days, but I think we should use it to make AI better through feedback.
If this interests you, drop me a comment. Let's talk. Let's go!
kamal-watch 0.7.0 features some cleanup of unnecessary text, leaning further into the dense data design. It also raises your CPU make and model, as well as expandable per-core usage.
github.com/jefflunt/kamal-wa…
Pushed v0.7.0 of kamal-watch a few hours ago, which includes some formatting visual cleanup
Latest here: github.com/jefflunt/kamal-wa…
Curious what people think about the concept of a "mecha linter" as a reliable guardrail to AI's nondeterministic nature.
The concept is written up on this website - the concept is a first draft, it's technology/stack/domain agnostic, but there is a concrete example provided of what I mean linked from here.
mechalinters.com/
Another layer in the linter cake coming together:
github.com/jefflunt/astrotur…
Don't be so cool you can't appreciate cool stuff. Bring back some of that earnest childhood wonder, some of that pure unadulterated WOW! Retire your cynicism.
“This is the most exciting time to be into computers”
When I interviewed @dhh at our Omarchy Shenzhen meetup 2 weeks ago what stood out was his absolute enthusiasm - everyone in the room could feel it
😎
Looking forward to attending @datadoghq's Chicago summit today! Last year's summit was awesome!
Been building this out slowing, doing some reference implementations, and will share updates as I go. If you're reading this and think you'd like to participate or have ideas you want to contribute, drop me a comment, or send me a DM request.
On the theme of MechaLinters / MechaRuby, I'm working on a new gem for Rails applications, called astroturf, which you can use in combination with your favorite AI model to generate infinite synthetic data for your test suites, covering all possible values and combinations of values. It's like the 'faker' gem met a fuzzer with a cartesian product in it pocket.
astroturf will be the data generation layer of an exhaustive + fuzzing test library that will enable fearless (and flawless) refactoring by programmatically figuring out how to cover the behavior of the various entrypoints in your application such as controller actions.
The concepts will transfer to other languages as well, but I'm doing these as reference implementations.
Version 0.1.1 is out now - feedback and feature suggestiosn welcome.
rubygems.org/gems/astroturf
I've heard about REA, but haven't tried it yet. For anyone who's tried it I have a question: is there a functional difference, in your mind, between:
1. Use REA to recreate anything from blackbox testing
2. Use comprehensive golden file testing to refactor the code of a system you have access to in order to replace the one implementation with another that differs only in performance, but not computational or I/O inputs/outputs?
Of course the code itself would change. But if REA can analyze the assembly code directly and produce a clean-room implementation that does the same thing ... then other than the fact that REA operates on compiled code. what's really the difference between a complete rewrite vs. a refactor other than the scope of what it covers?
Love this.
We were taught that Earth orbits the Sun in a closed circle. In reality, Earth has never returned to the same point in space once in 4.5 billion years.
Right now, the Sun is carrying Earth and every planet around the center of the Milky Way at 230 km/s (828,000 km/h), more than 18,000 kilometers every 80 seconds.
Because the Solar System is tilted 60.2° to the galactic plane and bobs up and down through the galactic disc roughly every 30 million years, the planets trace open 3D corkscrew helices across deep space rather than flat loops.
The last time the Sun stood where it stands today, one Galactic Year (230 million years) ago, the very first dinosaurs were only beginning to appear on Earth. Since forming 4.6 billion years ago, our Sun has completed only 20 laps.
If you use kamal for deployments, I just pushed kamal-watch v0.6.0 - a web dashboard for watching your kamal clusters and all their deployed services.
Free and open source.
github.com/jefflunt/kamal-wa…
I thought I cared about the craft more than finishing and shipping projects. Then when the cost of shipping dropped dramatically, I came to realize the truth of this, at least for myself: I like finishing stuff. I love getting my creative ideas out in the world.
Voyager continues to amaze. What a forward-thinking project!
Happy November! This month Voyager 1 will become the first spacecraft to reach 1 light day from Earth. 🔭 #astro
Hm. I thought passkeys worked more like SSH keys: asymmetric public key cryptography, nothing for the user to remember, and not a low security password?
This is correct
Passkeys should be used as passwords, since they're stored in a password manager
They're "supposed" to use biometrics, but realistically they don't, you just unlock your password manager and your passkey is stored there
So passkeys are not 2FA, they're single factor authentication
Prove me wrong
I love this framing and the challenging questions it raises. The video stops short of answering the question, "So, then, what is a better metaphor?"
What do you think?
youtu.be/4Oq_gdhjYUw?is=noDz…
Hey @boardyai, I'm to curious to talk to someone in cyber security about the ideas on mechalinters.com/ and their feasibility and flaws. Got anyone in mind?











