Dietmar Kühl

This evening's work for Claude, on Patches: 1) Thinking over a couple of API decisions I recorded yesterday, I realised there were cleaner approaches available to one particular aspect, piggy-backing on previous changes. I proposed those approaches to the LLM, talked them through, considered objections, settled on a new approach; the LLM wrote up the revised ADR (which I read, checking that it captured my intention clearly) 2) The method that compares a new patch graph to the existing one and builds an updated execution plan is huge, nested and complex. I would never have written it that way myself, but it works as it stands. Nevertheless, I have future changes targeting that area, and it's risky to have something that's both syntactically convoluted and hard to read and test, especially in such a central piece of logic. It badly needs some attention. I asked the LLM to propose a breakdown of the method into smaller, testable pieces. Its proposal was ok, but missed an opportunity to separate cleanly the "deciding what to do" phase from the "acting on the decision" phase, leaving graph analysis and new module instantiation somewhat tangled up with each other. I suggested some further re-organisation to disentangle things, and asked the LLM to remark on the impact this would have on testing; it confirmed that it would make the testable surface of each of the distinct pieces smaller and more easy to control. Once we had a scheme that looked sound to me, I asked it to write up an epic and a sequence of tickets for it. Then I asked it to start working through the changes. Now it's chugging through the first ticket, while I write this. It will go on doing so while I pop downstairs and do the washing-up. I'm comfortable with the fact that the first draft of the code it's now tidying up was unsatisfactory from a testability and maintainability point of view: it grew organically and expediently in the course of pulling together something that worked well enough for me to start playing with it. Now it's a glaring area of technical risk, so I'm cheaply and quickly addressing it. A capable human developer would have kept much better discipline throughout the drafting process, but might not have seen that the decide/action split was natural and desirable until about this point in the game - I didn't until I stopped to think about it. What's absent from this process, for me, is anxiety that the LLM will just heap up piles of intractable slop. It will typically do the expedient thing at each step along the way, but that's fine if you're working in short iterations provided you're also periodically stopping to review where cruft and friction are accumulating. What it lacks in foresight, you somewhat have to make up for in hindsight. But the latter is famously somewhat clearer than the former anyway.

2

We have little choice but to anthropomorphise LLMs, as we have no more precise language with which to describe their high-level behaviours. For example, earlier today I was describing m6r.ai to someone, and saying that the way it bootstrapped prompts by first defining a structured language, then specifying desired behaviour in that language, seemed to produce more focussed “attention” from the model. Now there are some very handwavey intuitions behind why this seems to work - I’ve often found that it pays to go “meta” with LLMs, to introduce the theme of reflecting on the implicit rules of the language game you’re playing. Of course “reflecting” is no more a thing it is actually doing than “paying attention”. But it tends to avoid stereotypical blather a bit better if the context is set up to include additional layers of recursion (talk about talk, second-guessing youself). Saying why this might be so in operational terms appropriate to what an LLM chatbot actually is and does remains challenging though. I’m reminded of the philosopher Wilfred Sellars’s distinction between the “manifest image” we have of human cognition, which rests on social and psychological categories, and the “scientific image” which tells us that we have physical brains with neurons in them, and so on. We are going to need a new language, with new metaphors, to get a stronger grasp of LLM behaviour. Already I find myself mixing descriptive registers - talking about “attention” one minute, and “low-energy states” the next. This kind of hybrid language is a sign that something hasn’t yet found a settled place in our mental map of the world: we still have an unstable sense of what *kind* of thing it is.

6

1 Comment

Consistency in distributed systems isn’t binary. It’s a business trade-off. Immediate consistency feels comforting, every read reflects the latest write. But at scale, this comes with trade-offs like latency and tight coupling. Eventual consistency embraces reality: writes propagate asynchronously, systems stay available under failure, and resilience improves. But it comes with trade-offs like potentially stale data. The real question for architects isn’t “Which is better?” It’s: - What’s the business tolerance for staleness? - Where do we need strong guarantees (e.g. balances)? - Where can we accept lag (e.g. recommendations, analytics)? - Modern systems blend both. It’s not a purity contest, it’s a design choice tied to business risk. What’s the toughest consistency trade-off you’ve had to make in a real system? #EventualConsistency #SystemDesign #ArchitectureDecisions #DistributedSystems #EDA #DDD

22

1 Comment

ORMs are a great Day 1 tool. The problem is they often end up living in a Day 2 system. The ORM scaffolds early development, the product ships, and then sprint priorities move on. The engineers who set it up carry a mental model that rarely makes it into the wiki. Team members rotate. New engineers learn just enough to be productive. And by the time something goes seriously wrong with the database, the ORM is effectively a museum piece. What follows is usually a performance incident that monitoring tools can triage but can't explain — because the diagnosis requires a mental model of the schema that the team may no longer have. I wrote about what this looks like in practice, why it's a model maintenance problem more than an ORM problem, and what the teams that navigate it well tend to do differently. Read more: https://lnkd.in/gyFirbWf

1

A few weeks ago, I was stuck at the airport waiting to fly home. That same week, Gary Lobermier showed off his Mythic C2 agent Fawkes — fully built via Claude. This made me want to see what can happen from the other side. So, I started building. What came out is an open-source detection engineering lab where Claude Code acts as an autonomous blue team agent — writing, validating, tuning, and deploying security detections across Elastic and Splunk, all mapped to MITRE ATT&CK. AI Detection Engineering Lab — an open-source template that turns Claude Code into an autonomous blue team agent. One command (./setup[.]sh) spins up a full SIEM lab (Elasticsearch, Splunk, Cribl Stream) with simulated attack telemetry from a real C2 framework (Fawkes/Mythic). Five AI agents then run the entire detection engineering lifecycle — ingesting threat intel, generating attack scenarios, authoring Sigma rules, deploying to both SIEMs, and monitoring detection health — all mapped to MITRE ATT&CK. What makes it different: - Claude reasons locally via CLI (claude -p) using your Pro sub — no API keys, no cost beyond what you already pay - Every change goes through a PR workflow with an AI security gate — the agent proposes, humans approve - Agents learn from past runs via a cross-agent journal system — mistakes get recorded, patterns get reused, and the quality agent reads all journals for fleet-wide insight - Built-in budget tracking with daily token caps and per-model cost weights — light mode automatically kicks in when usage hits thresholds, so it won't burn through your Pro subscription - Dual-mode: full Claude reasoning locally, deterministic fallback in CI — nothing breaks if credentials aren't available Currently 9 detections across 2 SIEMs covering 43% of the target threat model, with a prioritized backlog to keep building ^^^^ That was basically entirely AI typed but honestly this is super cool (to me). It's not entirely correct all the time, obviously, but it really gives me a starting point of how and where these AI tools can be used in an Enterprise setting. It made cool names for itself like five times, and I finally just let it do its thing. It doesn't just pick out Fawks methods as I just updated it to include an Intel agent that checks the internet for new intel and when run locally it utilized Claude CLI to make more informed decisions. Updates will continue to be applied to this repo as I juggle the Claude Pro credits (I'm not paying $200 a month for Max and API access) Give it a look! Fork it, and see what you learn: https://lnkd.in/gCjafhdc

74

10 Comments

I’ve seen a load of JSON vs TOON posts circulating on LinkedIn over the last couple of weeks, and it’s certainly piqued my interest. At a high level, the dynamic feels a bit like this: JSON: Trustworthy, well-structured, universally supported - the format that’s been holding our systems together for years. TOON: New, efficient, trims the syntax, and suddenly everyone’s talking about token savings and cost reductions. In reality, it’s not a battle so much as a reminder to choose the right tool for the right job. If your data is deeply nested or irregular, JSON is still the safer, clearer option. If your LLM workflows rely on clean, uniform, structured data, TOON can offer meaningful token reductions and that can translate directly into lower costs. It’s been interesting watching this conversation evolve, and I’m curious to see how tooling, adoption, and real-world benchmarks shape the next phase.

10

1 Comment

When is a comment actually helpful, and when is it just noise? We're taught to comment our code, but the *type* of comment matters. Clean code aims to be self-explanatory, meaning the code itself tells you "what" it's doing. Comments, then, should focus on "why." Why did we choose this particular algorithm? Why is this specific workaround necessary? Think of comments as a brief historical note or a warning label, not a play-by-play description. If you find yourself explaining *what* a line of code does, chances are your code isn't clear enough. Instead, refactor for clarity. If you found this helpful, please like and share! What's the most impactful "why" comment you've ever come across in someone's code? #CodeComments #SelfDocumentingCode #ProgrammingBestPractices #DeveloperLife #TechTalk

3

1 Comment

Playwright v1.57.0 has landed! Here’s what’s new 👇 💡 Speedboard See exactly which tests slow down your pipeline. No more guessing! 🌐 Chrome for Testing = default Better alignment with real Chrome. Same speed, new look. ⚙️ Smarter server waits Playwright can now wait for a regex log line before running tests. Developers with “server ready” console logs — this one’s for you! 🧩 Extra goodies ✨ Tag entire test runs ✨ Worker console event support ✨ Improved locator descriptions ✨ Better Service Worker network visibility ❗ Heads up: Page#accessibility is gone — use Axe for a11y checks. 📌 Browser bumps: Chromium 143 • Firefox 142 • WebKit 26 Another solid release — loving the direction Playwright is going! 🚀

10

I am old enough to remember when Lehman Brothers collapsed. It was a “canary in the coal mine” and it became the inflection point that crystallized the systemic fragility underlying the 2008 financial crisis. The firm filed for Chapter 11 bankruptcy protection on September 15, 2008, triggering a severe liquidity freeze and amplifying counterparty risk across the global financial system. In contrast, this situation involves a private credit fund. The structure, leverage profile, and interconnectedness are materially different, and it is not yet clear whether it poses the same level of systemic contagion risk that we saw in 2008. I had just started my MBA that year, and I still remember a professor sharing that a close family member worked at Lehman. It brought home the human dimension behind it. #FinancialCrisis #LehmanBrothers #MarketHistory

Fantastic breakdown of what development workflows are starting to look like in this AI-assisted era we live in. I’ve also been experimenting with sub agents, skills, custom slash commands, hooks and MCP servers in Claude Code for my own home set up. Great thing is - it doesn’t have to be just for development - any creative process that you can break down into steps and describe well can be automated this way. You just have to understand the process well, which requires a lot of introspection, observation and transcription - you’re essentially *encoding* your way of doing something so the system you set up can do it for you, just the way you like it. This section of Nick’s post sums up the human aspects beautifully: “Another challenge I see is the continuous improvement aspect. For engineers who like writing code and building systems, it could be a big change in mindset. Now, a key part of the job is to automate software development and identify mistakes or improvement opportunities so that AI produces better code and architecture. Rather than writing code, I think it might be more that we need to think about “how can we improve the workflow and context so that we don’t need to manually write this line of code”. Software engineering might be more workflow + context engineering.” Yup, the role of a software engineer is indeed is changing!

18