Between the 27th-30th August 2026, my wife and I schlepped down to Soltau in Niedersachsen to attend SoCraTes 2026, which was my first time attending a self-organised open space style event. I was honestly quite nervous about going, I cannot remember the last time I went to a tech event with lots of people that I did not know that wasn't also organised by the place that I work at. Maybe some now-ancient edition of Berlin Buzzwords.
Admittedly, this event had higher emotional stakes for me than other events I had been to in the past. Not only did I want to go participate in interesting discussions with interesting people, but I desperately wanted to recapture something that I had lost towards this field for a while now - enthusiasm, or hope, or something along those lines. It was probably unfair to hope that the event would cure my world-historical levels of uncertainty and alienation, but it did do a little bit. I wanted to write this both to gather my notes on some of the (many) discussions I participated in.
These are not all the sessions I attended, just the ones where I felt like the notes I took during them would be useful to make more concrete.
Day One (28th August 2026)
Pairing & Ensemble In The Age Of LLMs
This was a really interesting discussion and I was glad that it kicked off the conference for me, as something along these lines had been on my mind for a while. My software development environment for the last few years had been a lonely one. The realities of cross-timezone teams, remote working and work streams that tend to make people silo meant that I was quite used to, in some way, working by myself. I miss the dynamic when I started as a junior developer of pairing with seniors on things, it felt like a very social mode of development that falls by the wayside when you work as a senior in a team of seniors (and above), capable of defining and directing yourselves.
Couple that with agentic engineering, which at present feels a very anti-social mode of working. I don't mean this as a value judgement (I do, I am lying to you), but more that the capabilities of LLMs when coupled with good codebases and decent knowledge graphs means there's less inclination to reach out to peers. I was really curious to see what experiments people had run with pairing and ensemble programming with LLMs and whether they were successful or not, and whether this mode of development can be made more social.
The anecdotes I heard in the session were mixed - it does seem like the current way of working with these tools (like with an agentic harness) feels weird and full of friction when you try and include them in a pair programming context. This could be a tooling issue, but I'm not sure how to address it in a way that doesn't mean 2 or more developers on a zoom call, or sat round a keyboard, waiting for a coding harness to return a result.
I shared some experience I had with working on Flink Improvement Proposals (a kind of detailed feature plan) with others in a sort of pair-like process. This feels like it works better. The planning and ideation stage feels more organic to collaborate on, and while an LLM can still be used here, it feels more natural to use it as an underlying tool to validate design assumptions in the background while you and collaborators also plan. That a Flink Improvement Proposal has to be a document made for public consumption and voting helps a lot too.
I heard the proposers of the session were running workshops with people where everyone tried to figure out ways of doing pairing/ensemble with LLMs. I didn't attend any of these, but I hope they had some success!
Stop Guessing & Start Knowing: LLMs & Knowledge Graphs
This was a fun and interesting session, and I was glad to see that I was validated in an opinion I had come to while working on building a wine tasting app and using data from Wikidata for myself in that: SPARQL is not very fun to use, and LLMs are great at writing SPARQL queries lol
This session was really nice to see as a demonstration that deterministic data beats out probabilistic prose, and combining the former with the latter via knowledge graphs genuinely does produce useful results (and probably lets you get away with using smaller models to do so). I especially liked how the presenter modelled knowledge gaps as explicit points in the KG, and the LLM used these marked graphs to answer "I don't know" to a query (can you imagine!).
It was also interesting to hear about results people had gotten combining RAG and knowledge graphs. One downside of knowledge graphs is that its hard to direct the model where to start in the graph for a search - using the semantic closeness of RAG to identify potentially good entry point nodes in the knowledge graph, and then traversing the knowledge graph for 'factual' closeness seemed like it would be useful. Also heard about work being done on https://neowiki.ai from a session participant, which seemed interesting too.
In some ways this made me think that the semantic web guys finally got their revenge.
Join The Event Sourcing Cult
As an already-existing member of the event streaming cult, it was nice to don my robes and sacrificial knife and go to this one. Ted's talk was very fun (I'm sad I didn't find the time to play his TDD game) and using an event stream as a source of truth upon which you build your different views (tables, DBs, etc) felt pretty natural, especially when it came to how you define transaction boundaries, restore backups (you dont need to, just replay the stream). A nice demo of the connection (i'm never quite sure if i'd call it a morphism) between tables and streams.
Made me start sketching out a personal tool to make called saga, which treats shell history as a stream and uses iroh to synchronise different history streams between machines to produce a kind of machine/session/command aware global history across my laptop, pc, raspberry pi, etc. Currently peacefully tapping away at it, no LLMs involved. Just rawtyping rust and sql like my grandmother used to
Day Two (29th August 2026)
How To Fail Fast with Architectural Decisions
This was a nice pull session on how to not overcommit to architectural decisions when adding a new feature/service to an existing infrastructure. It was nice to hear how much of the conversation was about the social problems of architectural decisions, not just the technical ones. This often feels underestimated, but adoption, changing how people interact with the things you build, ownership and organisational debt feel like they often make or break these decisions more than the actual technical side often does.
The emphasis on developing prototypes with a known, expected duration over which you can monitor things like adoption rates also made a lot of sense, especially since prototypes are quite easy to make these days. Failing informatively when the prototype doesn't meet the goals was also important, as well as being able to play the game of justifications and assumptions when you try and slot the architectural decisions into whatever requirements have percolated down to you.
fzf is actually an interactive terminal toolkit
Okay this talk absolutely blew my tiny tiny mind. I've used a lot of fzf in my life over the last few years but I had no idea how powerful it was, or how expressive it was with the ability to select, show and filter on different bits of whatever you're fzfing over. It really does feel like the fzf developers accidentally stumbled upon a really good abstraction for a terminal interface and then just built a ton of features on top of it. ncurses is dead, long live fzf
Daniel's slides (built in fzf, of course) are really worth taking a look at. This session was so fun!
NixOS @ Work
Hell yeah. Was very happy to hear anecdotes about successful NixOS integration at an actual workplace, even if it was a manageable amount of people. After having experienced Enterprise Managed Ubuntu, I often thought that NixOS & home-manager would make a great pairing in a work context (but I would say that). It was also interesting to hear it being used for server definitions as well, and it felt nice to be able to share something about my experience of using nix with a low resource server (mostly using github's ubuntu-24.04-arm runners to build my rpi images, pushing to cachix and then just pulling on the rpi).
It was also nice to whine a bit about the community side of things too (the nixpkgs team had just blown up a short period ago).
Peer2peer Sustainable Code Hosting w/Radicle
This was a very interesting session, and unfortunately, maybe the one that made me doom the most. I'd heard of radicle in the past but had never played with it before, but Yorgos' demo was very cool. I especially liked the way they handled patches with the special refs/patches ref through git-remote-rad.
The session started with a discussion around the painpoints we currently have around Github and also code forges in general. Somewhat serendipitously, Konstantin from kernel.org published an article on the same day on how git.kernel.org is now burning more CPU cycles rendering HTML views of commits (!!!) for LLM scrapers than all their git operations combined. It seems like running any kind of code hosting, a forge or anything, was a thankless task before. When you couple the traffic from scrapers with metrics like Github posted after their incident also showing the sheer increase in git operations (now obviously driven by LLMs), the enterprise seems absurd:
It makes me wonder, what exactly is the point in public source code on code forges anymore? It's increasingly hard to run your own for your own or a community's purposes, because as soon as it's public facing you get hammered. Even Github seems to be unable to handle it. Do we just have to have a Dark Forest approach to code forges? Keep them private and hidden, because if you make a sound you'll be smothered under training traffic?
Hm.
Parting Thoughts
So spending a weekend in Soltau didn't cure my anxiety disorder. That's fine. It was nice to see some stuff people are doing with LLMs that didn't feel terrible. The main takeaway from the event, I think, was that I didn't realise how lonely tech had gotten for me over the last few years. It was really nice to be in a setting surrounded by enthusiastic, curious people. It was nice to see people like me at a tech event (I genuinely can't recall the last time I felt that).
It was my first experience of an unconference/open space and, though I enjoyed it, I did feel some friction with the setting sometimes. As a pretty naturally quiet person, it did feel quite hard to participate in the kind of open discussions that the format brought. It was also quite chaotic, both in a good and bad way! I think to fully engage with an event like this takes more social skill than I really brought with me.
Speaking of social, the event made me feel more energised to try and get involved in more pro-social tech stuff back in Berlin, if such things still exist.
I will try and go back again next year. I had a lovely time, even if I stayed on the margins of most of the events.
And i'll bring some coffee for the overly-complicated-coffee-corner next time.