Today’s work (really posted just after midnight) started smoothly: I pushed a candidate set of mailing‑list threads all the way through summarization to validate the next phase of the pipeline. Then it cratered - duplicate subject lines that exposed my threading logic was flawed.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.

Test run before failure

I wasn’t choosing “important” threads yet - just seeing what wholesale summarization output looked like so I could later score, filter, and review. That smoke test did its job by flushing out a structural bug instead of letting it lurk until the importance pass.

The threading bug

I’d tried to get a little “clever” with heuristics while lacking full headers (older emails, inconsistent client behaviors). The result: unrelated conversations collapsed because headers like In-Reply-To and References were not always present or complete. I also rely on some supplemental external data for stitching things together when the headers fail. Deterministic structure first, cleverness later - apparently I needed to relearn yesterday’s lesson.

Recursion beats cleverness

I rewrote the logic as a plain recursive rebuild of parent/child relationships using what reliable metadata I do have. This was basically a CS 101 traversal plus extra credit for malformed inputs and odd nesting. The LLM handled the boilerplate once I spelled out the core structural invariant: each message links to at most one parent (by Message-ID via In-Reply-To / References), roots have none, and no cycles. I owned that mental model and the test cases. The model filled in syntax. That division worked. Watching multiple models miss the full shape of the bug was useful: they offered partial patches, none produced the end‑to‑end correction without guided constraints.

On expectations (and “LLM denying friends”)

To my LLM denying friends (you’re not skeptics and you know it!): nobody promised you could type “make Jira but with cat memes” and go to lunch. Marketing slides might imply that. Reality is still stochastic autocomplete with oversight and bite-sized work needed. It’s good at cranking out a recursive walk or refactoring a loop. It is terrible at handing you judgment, taste, or guardrails. I got cute, collapsed unrelated threads, paid the tax, rewrote it. That’s the actual human‑in‑the‑loop job: think, state the few non‑negotiable structural rules, let the model grind, verify, repeat.

What you do get: fast pattern completion over training data. “Traverse this tree and stitch orphan replies” lives there. “Subtly infer intent from half-missing mail headers and not overmerge” does not unless you spell it out. So yes, some of the debugging prompts contained some profanity. That didn’t summon intelligence, it just vented mine.

What I learned (again)

• Deterministic scaffolding first. Probabilistic layers second.
• “Clever” heuristics without gold tests are debt.
• LLMs are fast at churning variants. They still need a crisp structural rule set to follow or test against.
• A blunt recursive pass is often the right baseline even if it feels unsophisticated.

Back to the pipeline

With threading fixed I’m back to grading summarization output and preparing the next human‑in‑the‑loop pass for importance ranking. Tomorrow’s goal: start scoring threads with the heuristics + enrichment stack from earlier days and see if explanations remain concise enough not to drown me.

Posting this late counts as progress anyway. Better a truthful “I broke it and fixed it” than a shiny but misleading narrative.

More tomorrow.

Today started with a plan: drop my kid at school, head to a coworking space, meet my teammate, and push the importance model forward. Reality: unexpected stuff pulled me back home first. Momentum recovered later, but the change in expectations reinforced how fragile context can be when doing iterative LLM + data work.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.

Thread heuristic exporter

I built a first pass “thread stats” exporter: sender count, participant diversity, tokens of note, and other structural hints. Deterministic, fast, and inspectable. This gives a baseline before letting an LLM opine. The goal: reduce the search space without prematurely deciding what’s “important.”

Planning importance signals

With that baseline, I worked (with ChatGPT-5) on how to move beyond raw counts. What makes a thread worth surfacing? Some dimensions that matter to me:

• Governance, Policy or consensus decisions
• Direct relevance to Azure or adjacent cloud platform concerns
• Presence of Debian package names (as a proxy for concrete change surface)
• Diversity of participants vs. a back-and-forth between two people
• Emergence of unusual or “quirky” sidebars that might signal cultural or directional shifts (these are often interesting even if not strictly impactful)

I want to avoid letting pure volume masquerade as importance. A long bikeshed is still a bikeshed.

Data enrichment

I experimented with a regexp to match Debian package names. That worked a bit too well. Claude Sonnet was reporting threads moving forward and I couldn’t believe the numbers. A little investigation and it turned out the regexp was capturing everything. Sonnet suggested pulling in a Debian package list to tag occurrences inside threads. That, plus spaCy-based entity/token passes, lets me convert unstructured text into a feature layer the LLM can later consume. The MVP now narrows roughly 424 August 2025 threads to ~250 candidates for deeper scoring. Not “good,” just narrower. False negatives remain a risk; I’d rather over‑include at this stage.

Why deterministic first

Locking down deterministic extraction serves to reduce some of the noise before LLM scoring. It also provides a dial I can change as part of the review from the human-in-the-loop process I envision.

Next phase: human-in-the-loop LLM

Tomorrow I plan to let the model start proposing which threads look important or just interesting, then review those outputs manually - back and forth until the signals feel reliable. Goal: lightweight human-in-the-loop review, not handing over judgment. Keeping explanations terse will matter or I and any hypothetical readers will drown in synthetic prose.

Agent editing workflow

While agents “compiled¹,” I created an AGENTS.md doc to formalize how I want writing edits to work. This is about editing my prose, not letting a model co‑author new ideas. Core rules I laid down include:

• Challenge structure and assumptions when they look shaky - do not invent content
• Preserve hedges; mark uncertainty with [UNCLEAR] instead of guessing
• Keep my voice; I review diff output before accepting anything

Most importantly, I am not an emoji wielding performative Thought Leader(tm) turned Influencer(tm). The new guidance has already reduced noise. I still refuse to let a model start from a blank page; critique mode is the win. Visual Studio Code diff views make trust-building easier - everything is inspectable.

Closing

Today was half heuristics, half meta-process. The importance problem still feels squishy, but the scaffolding is there. Now I’m going to stop and pick the kid up and let her redeem a grocery-store stamp card for a Smurf doll. Grocery stores are weird and since she speaks Czech she can do the talking.

From my window and balcony, I can see the balcony of a couple who live across the way. They seem to be about 10 to 15 years older than me, and I gather from their habits that they’re both retired. Several times a day, they step out onto their balcony with cups of coffee. One of them is often on the phone, while the other might sit quietly. Their voices are distinctive, so if my window is open, I always hear them.

They say you shouldn’t make up stories about people you observe and expect them to be true. It’s like assuming someone’s Instagram reflects their real life. But because I work from home, I see this couple frequently, and I think it’s lovely that they have this time, this space, and this ritual.

I often wonder what they’re saying—either to each other or to the person on the phone. My Czech isn’t strong enough to understand much, so I can’t piece together their conversations. I’ve never asked a Czech-speaking friend to listen in, either. If I did, I suspect I’d hear complaints, as I’ve been told that Czechs are prone to complaining. But one of the perks of not speaking the language fluently is that I can imagine otherwise. When I walk down the street, I assume people are talking about how beautiful the day is and how lucky we are to live in this city, rather than airing grievances.

What prompted me to write this today is that, for the first time, I noticed the woman wearing what I can only describe as a silly hat. She’s never worn a hat before, at least not that I’ve noticed. The man occasionally wears a baseball cap, but this was different. It made me wonder: is today silly hat day? If so, I hope it’s a happy one.

Today was a mixed bag. I started with the goal of advancing the central metadata architecture, which is critical for figuring out what’s worth surfacing in the notebook. However, distractions and infrastructure challenges dominated the day. The day included a hot project at work, a meeting that couldn’t be skipped, and the ever-present TPS reports (or in my case, an expense report from a recent trip). These interruptions made it hard to focus on the metadata work.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.

Brainstorming with ChatGPT

Despite the distractions, I spent some time brainstorming with ChatGPT on methods for surfacing important information. We explored various heuristics and LLM concepts. It was a productive session that gave me ideas to refine and potentially turn into something valuable.

One area we explored was how to determine if a thread was “important.” This included qualitative factors like the number of unique participants in a thread and, in a future with more data, the history of those participants’ involvement in the list. We also discussed keyword surfacing as a way to highlight significant topics and the potential for trend analysis to predict emerging themes over time. While we touched on some additional qualitative measures, I don’t recall all the specifics.

Infrastructure Challenges

The day ultimately became about infrastructure. Scaling issues forced me to shift to a database for the MVP, and SQLite came to the rescue. While not ideal, it’s a practical solution for now.

The motivation for SQLite was scalability. To ensure thread completion, I had to load more than one month of data into the MVP. Bonus months from testing added even more data, so it made sense to work with fresh data rather than repeatedly processing the same old files. SQLite also provided a way to query the data efficiently without having to read through tons of JSON files. While this approach works for the MVP, it’s clear that a more robust solution—like an MCP server—might be needed in the future.

Final Takeaway

One thing this day reinforced is how fragile AI-driven development can feel without proper context management. Whether brainstorming with ChatGPT or coding in agent mode using Sonnet in Visual Studio Code, I’ve noticed that when tools lack memory or context, things can quickly go off the rails. For example, fragile solutions like resorting to regex to parse HTML instead of using a proper library like BeautifulSoup can emerge. This highlights the need for better agent hints or configuration files, though the idea of managing those feels cumbersome.

Tomorrow, I hope to meet with a teammate to advance the more interesting parts of the project. With the infrastructure in place, I’m optimistic about making real progress.

This remains a work in progress, but I’m hopeful that the brainstorming and infrastructure work will pay off in the coming days.

This week is the Microsoft Hackathon, and I’m using it as a chance to prototype something I’ve been thinking about for a while: a tool that summarizes what’s happening in upstream Linux communities in a way that’s actually useful to people who don’t have time to follow them day-to-day.

Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal opinions.

For my MVP, I’m going to try to produce a “What happened in Debian last month” summary from selected mailing lists. It’s not a full picture of the community, but it’s a solid basis for a proof of concept.

Why this project?

Part of my work at Microsoft involves helping others understand what’s going on in upstream Linux communities. That’s not always easy — the signal is buried in a lot of noise, and most people don’t have time to follow mailing lists or community threads. If this works, I’ll have a tool that can generate a newsletter-style summary that’s actually useful.

Why Debian?

For this MVP, I chose Debian. It’s a community I work with but haven’t traditionally followed as closely as Fedora, where I have deeper experience. That makes Debian a good test case — I know enough to judge the output, and I have colleagues who can help validate it. I’m focusing on August 2025 because I already know what happened that month, which gives me a baseline to evaluate the results.

Agentic coding, not vibe coding

Agentic coding, in my view, is when you rely on an LLM to do the heavy lifting — generating code, suggesting structure — but you stay in the loop. You review what’s written, check the inputs and outputs, and make sure nothing weird slips in. It’s not fire-and-forget, and it’s not vibe coding where you just hope for the best. I don’t read every line as it’s generated, but I do check the architecture and logic. One of my frequent prompt inclusions is “don’t assume, ask and challenge my assumptions where appropriate.” This helps uncover ideas as I develop, similar to an agile process.

A breakfast pivot

This morning over breakfast with a friend, I walked through the architecture I’d outlined with Copilot on Friday. Originally, I was planning to build a vector database and use retrieval-augmented generation (RAG) to power the summarization. But as we talked, it became clear that this was overkill for the MVP. What I really needed was a simpler memory model — something that could support basic knowledge scaffolding without the complexity of full semantic search.

So I pivoted. Today’s work focused on getting the initial data in place: downloading a couple of months of Debian mailing-list emails to ensure I had full threads from August, storing them locally to avoid putting any load on Debian’s infrastructure, and building scaffolding to sort and store the data so it supports both metadata generation and LLM access.

Could I have used a vector database or IMAP-backed mail store? Sure. But this was quick, easy, and gave me a chance to practice agentic coding in Python — something I don’t get to do much in my day-to-day product management work.

What I’m hoping to learn

This MVP is about testing whether AI-generated insights from community data are actually useful. In OSPO and community spaces, we talk a lot about gathering insights — but we don’t always ask whether those insights answer real questions. This is a chance to test that. Can we generate something that’s not just interesting, but actionable? It feels a bit like the tail wagging the dog, but sadly that’s where we seem to be.

Any surprises?

Nothing major yet, but I appreciated that the LLM caught a pagination issue I missed. I’d assumed a dataset was complete; while reconstructing threads it exposed an oddly truncated dataset. Today’s work also reminded me to be deliberate about model selection — not all LLMs are created equal, and the choice matters if you don’t arbitrarily default to the latest frontier models.

What’s on deck for tomorrow?

Thanks to how some data structures came together, I’m rearchitecting the metadata store. This lets me defer generating the basic, memory-style knowledge passed to the LLM until I’m closer to using it, which should prevent some ugly backtracking.

I keep relearning this: don’t build perfect infrastructure for an MVP - ship the smallest thing that answers the question.