Basically every completed step is a git commit of a worklog and a commit of the updated "TODO" list.
I have a queue of tasks that have to be done, the agent reads that, does some research, updates the worklog (does not commit), does the work, crosses out the task from TODO, updates the worklog and commits.
This started out as a human-in-the-loop setup, but now it mostly just works on it's own.
The initial run is in systemd timer+service. So the whole thing mostly runs on it's own. There are multiple skills - for different tasks.
If there's a crash, pi restarts (some scripts around that), checks the worklog, sees that it's not committed and assumes that it did not finish, updates are handled the same way.
Now the TODO can be wildly different. Read my email, prepare an answer to insurance. Read my email, update my calendar. Figure out and optimize my home assistant automation. Use the ghidra MCP to rev-engineer a crackme.exe. Optimize my Openwrt wifi network (complex topology, multiple APs), rewrite my old java 6 code to modern java with tests, research birthday presents based on hobies etc...
So far I've thrown just about everything I could think of into that setup - the only time I actually need to do something is when pi needs me to do something in the physical world - say - a TRV on a radiator got air blocked and I need to bleed it. Or it did the research and I actually need to buy something.
I get a notification and a calendar entry.
I do have a similar setup at work, but since my company moves at snail pace compared to development outside, this is my way to keep "up to date".
Disagree. I've seen so many PR slop grenades -- they are essentially unreadable. I'd prefer a paragraph or two human written explanations. I suspect people are just taking the default AI text -- which is way too wordy.
> using a database engine we built on top of FoundationDB: a distributed key-value store
it would be interesting to see their experiences with using FoundationDB. this feels like a tech that is amazing if only it had more information and practical examples of how to use, leverage and manage it. the client is complicated and needs expertise to use correctly. would love it if there was more info about it all.
(McKenna tangent). I like this version of that talk. https://www.youtube.com/watch?v=hL0yfxDe6jE. It's about 12 minutes and animated with some hand-drawn whiteboard drawings. Good stuff.
> In my last performance review, my manager was actually surprised when I told him that I am now more a manager of my own work than actually doing the work.
I think this is very telling. Unless you have a good manager who is paying attention, a lot of them are clueless and just see the hype of 10x ing your developers and don't care about the nuance of (as they say) all the surrounding bits to writing code. And unfortunately, they just repeat this to the people above them, who also read the hype and just see $$ of reducing headcount. (sorry, venting a little)
Great link. I've always been drawn to sqlite3 just from a simplicity and operational point of view. And with tools like "make it easy to replcate" Litestream and "make it easy to use" sqlite-utils, it just becomes easier.
And one of the first patterns I wanted to use was this. Just a read-only event log that's replicated, that is very easy to understand and operate. Kafka is a beast to manage and run. We picked it at my last company -- and it was a mistake, when a simple DB would have sufficed.
I love the idea of SQLite, but I actually really dislike using it.
I think part of my issue is that a lot of uses of it end up having a big global lock on the database file (see: older versions of Emby/Jellyfin) so you can't use it with multiple threads or processes, but I also haven't really ever find a case to use it over other options. I've never really felt the need to do anything like a JOIN or a UNION when doing local configurations, and for anything more complicated than a local configuration, I likely have access to Postgres or something. I mean, the executable for Postgres is only ten megs or twenty on Linux, so it's not even that much bigger than SQLite for modern computers.
I've been through a Vista Equity acquisition. It was not pretty -- they slashed, consolidated and basically ran their one-size-fits-all playbook. The brought in their crew -- which is totally expected -- and then bought other companies in the same vertical. Of course, they all had different tech stacks.
(like ya said, operators is the right word. it felt icky)
At least for the first year, the acquired teams were able to run more or less the same but with new hyped-up-overly-aggressive Vista hotshot managers and then the sh*t-from-above just started raining down.
Also, they hired the worst sw architect / person I've ever had to work with. He wasted so much time and money.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.
Thanks for the reply. Summary: Here's this really cool thing we're doing! Oh, are you wrote something exotic for it? Nope, just regular Erlang goodness that's been around 20 years.
If you look at Elixir keynote for Phoenix.new -- a cool agentic coding tool -- you'll see some hints about a browser control using a API tool call. It's called "web" in the video.
reply