Markus Östberg

Content Recommendation on GitHub Pages with TF-IDF

Tue, 07 Apr 2026 12:00:00 +0000

In a previous post I added client-side search to this blog using a pre-built search index and TF-IDF scoring. The same index turns out to be all you need to build a related posts feature too, with no changes to the Jekyll build.

What is TF-IDF?

TF-IDF stands for Term Frequency–Inverse Document Frequency. It weights how important a word is to a document in a collection. A word that appears often in a post but rarely across the blog gets a high weight; a word that appears everywhere (like “the”) gets a weight near zero.

For a term $t$ in document $d$ across a collection of $N$ documents:

\[TF(t, d) = \frac{\text{count of } t \text{ in } d}{\text{total terms in } d}\] \[IDF(t) = \log\left(\frac{N}{df(t)}\right)\] \[\text{TF-IDF}(t, d) = TF(t, d) \times IDF(t)\]

where $df(t)$ is the number of documents containing term $t$. The resulting weights give you a vector that describes what a post is about in terms the rest of the collection does not share.

From Search to Recommendation

The search implementation scores a query against each document. Recommendation is the same idea, but instead of a query you use another document. Once each post is a TF-IDF vector, you can compare any two of them using cosine similarity:

\[\text{sim}(A, B) = \frac{A \centerdot B}{\|A\| \|B\|}\]

Posts that share rare vocabulary score close to 1. Posts with nothing in common score close to 0. Because IDF already down-weights common terms, shared boilerplate does not inflate the score.

Reusing the Search Index

The search index built at Jekyll compile time already has everything we need. Each entry contains raw term counts in a keywords object:

{
    "title": "Build your own Search Engine 101",
    "date": "Jan 31, 2015",
    "tags": ["Dev", "Search"],
    "keywords": {
        "search": 26,
        "engine": 6,
        "document": 24,
        "frequency": 7
    },
    "url": "/projects/2015/01/31/build-your-own-search-engine-101.html",
    "excerpt": "For many of us, there is something magical with a search engine..."
}

We can compute TF-IDF vectors from those counts entirely client-side.

Implementation

The post layout includes a hidden HTML shell that JavaScript populates after the page loads:

_includes/related-posts.html

{% if page.url %}
<section class="related-posts" id="related-posts" style="display:none"
  data-url="{{ page.url | relative_url }}"
  data-baseurl="{{ site.baseurl }}">
  <h3 class="related-posts-title">Related Posts</h3>
  <ul class="related-posts-list"></ul>
</section>
{% endif %}

The script fetches the search index, computes IDF across all posts, builds TF-IDF vectors, and ranks every other post by cosine similarity against the current one. If there are results, it fills in the list and shows the section.

assets/js/related-posts.js

(function () {
  const section = document.getElementById('related-posts');
  if (!section) return;

  const currentUrl = section.dataset.url;
  const baseUrl = section.dataset.baseurl;
  const MAX_RESULTS = 3;

  fetch(baseUrl + '/search_index.json')
    .then(r => r.json())
    .then(index => {
      const N = index.length;

      // Document frequency: number of posts each term appears in
      const df = {};
      for (const post of index) {
        for (const term of Object.keys(post.keywords)) {
          df[term] = (df[term] || 0) + 1;
        }
      }

      // Inverse document frequency: terms in many posts get low weight
      const idf = {};
      for (const term of Object.keys(df)) {
        idf[term] = Math.log(N / df[term]);
      }

      // Build a TF-IDF vector from a post's keyword counts.
      // Term frequency is normalised by document length so that
      // short and long posts are comparable.
      function toVector(post) {
        const vec = {};
        const total = Object.values(post.keywords).reduce((s, n) => s + n, 0);
        if (total === 0) return vec;
        for (const [term, count] of Object.entries(post.keywords)) {
          vec[term] = (count / total) * (idf[term] || 0);
        }
        return vec;
      }

      // Cosine similarity between two sparse vectors.
      // Only iterates over non-zero entries, so cost is proportional
      // to vocabulary overlap rather than total vocabulary size.
      function cosine(a, b) {
        let dot = 0, magA = 0, magB = 0;
        for (const [t, w] of Object.entries(a)) {
          dot += w * (b[t] || 0);
          magA += w * w;
        }
        for (const w of Object.values(b)) {
          magB += w * w;
        }
        return (magA && magB) ? dot / (Math.sqrt(magA) * Math.sqrt(magB)) : 0;
      }

      const currentPost = index.find(p => p.url === currentUrl);
      if (!currentPost) return;

      const currentVec = toVector(currentPost);

      // Score every other post against the current one, then take the
      // top results. Date is used as a tiebreaker: newer posts first.
      const related = index
        .filter(p => p.url !== currentUrl)
        .map(p => ({
          post: p,
          score: cosine(currentVec, toVector(p)),
          date: new Date(p.date)
        }))
        .filter(c => c.score > 0)
        .sort((a, b) => b.score !== a.score ? b.score - a.score : b.date - a.date)
        .slice(0, MAX_RESULTS);

      if (related.length === 0) return;

      // Render results as cards and show the section
      const list = section.querySelector('.related-posts-list');
      // ... DOM rendering omitted for brevity
      section.style.display = '';
    })
    .catch(e => console.error('Related posts error:', e));
})();

The full file including the DOM rendering code that builds each card is on GitHub. The rendering just creates list items with the same structure as the search results page so they share the same card styling.

The script is loaded with defer in the site <head> so it does not block page rendering.

Tradeoffs

The algorithm works from post content alone, so it does not need manual categorization or tagging to produce results. If a post has nothing in common with the rest of the blog, its scores will all be low and the section simply will not appear.

IDF is computed at runtime across the whole collection, so the weights stay calibrated as the blog grows. A term that is rare today might become common after ten more posts on the same topic, and the recommendations will shift the next time the search index is rebuilt.

The main limitation is the search index itself. It tokenizes content with Liquid at build time, so there is no stemming. “search” and “searching” are treated as different terms. For a personal blog this has not been a problem in practice.

Conclusion

The search index already has enough information per post to power a content-based recommendation system. Adding related posts was mostly a matter of writing a cosine similarity function and wiring it into the post layout.

Piaule Catskill: A Midweek Escape to the Mountains

Sat, 04 Apr 2026 19:00:00 +0000

We’d been eyeing Piaule Catskill for a while. Friends had recommended it, the reviews were glowing, and the photos of those minimalist cabins nestled into the hillside had been living rent-free in our heads. When we finally found a window for a midweek getaway, we decided to splurge on two nights, Wednesday to Friday, and it was absolutely worth it.

The Cabins

Piaule bills itself as a “landscape hotel,” and once you arrive it’s clear why. The property sits on a west-facing hill overlooking the Catskill Escarpment, with 24 individual cabins scattered along footpaths through the woods. The design draws from Japanese and Scandinavian influences: clean lines, untreated cedar, warm white oak. The whole thing feels like it belongs in the landscape rather than being imposed on it.

The standout feature of each cabin is the massive sliding glass wall facing west, essentially a 10-by-13-foot window that opens up completely. We had light rain on and off during our stay, and honestly it only made the cabin experience better. Lying in bed listening to the rain tap against the cedar while looking out at the misty mountains was the kind of reset we needed.

The Spa

A short walk downhill from the cabins takes you to the spa, tucked beneath a green roof and almost hidden in the hillside. The facilities are laid out as a progressive circuit: hot pool, mineral plunge, cedar sauna, and a bluestone steam room. We used it multiple times during our stay, and for the most part we were the only ones there. Midweek perks.

The main jet pool has an uninterrupted view out toward the escarpment. We spent one afternoon just sitting there watching rain clouds drift across the valley, slowly dissolving and reforming over the ridgeline. One of those moments where you stop thinking about everything else. The spa is only open to overnight guests, which keeps it peaceful and unhurried.

Dinner at Piaule

Our first evening, we had dinner at the on-site restaurant. The dining room is oak and glass, with the entire western wall open to the view. We worked through a three-course prix fixe menu by Chef Ryan Tate, who previously earned a Michelin star at Le Restaurant in Tribeca. The menu changes with the seasons and leans heavily on local farms. Everything we had was thoughtfully prepared, inventive without being fussy.

What made it feel truly special was the intimacy. There were only one other couple dining with us that night, which gave the whole experience a sense of calm and exclusivity. It almost felt like we had the hotel to ourselves.

Lil’ Deb’s Oasis

The second night we drove down to Hudson for a completely different vibe. Lil’ Deb’s Oasis is a James Beard-nominated spot on Columbia Street that describes its food as “tropical comfort food,” blending South Asian and Latin American flavors with local Hudson Valley ingredients. The place is vibrant in every sense: coral and turquoise exterior, neon signage, and a buzzing energy that couldn’t be more different from where we’d just come from.

We can wholeheartedly recommend the whole fried fish, crispy and flaky with a bright citrusy sauce, paired with the Plato Tropical: beans, herbed rice, and garlicky greens. Really, everything we tried was great. After two days of quiet contemplation, the lively restaurant was a welcome jolt of energy and a nice reminder of how much the Hudson Valley has to offer.

Final Thoughts

If you’re looking for a genuinely restorative getaway, Piaule is hard to beat. Go midweek if you can. The quiet makes a huge difference, and a little rain doesn’t hurt either. And leave one evening for dinner in Hudson. The shift from Piaule’s stillness to the lively dining scene there makes the whole trip feel that much richer.

Rebuilding the Kublet with Claude Code

Fri, 27 Mar 2026 22:00:00 +0000

Last year I wrote about my disappointment with the Kublet Kickstarter, a $150,000 campaign that shipped nice hardware with software that never lived up to its promise. My three Kublets had been sitting in a drawer ever since. This past week, I pulled them out and, with the help of Claude Code and the new Opus 4.6 model, turned them into the devices I originally backed.

From paperweight to project

The Kublet hardware is fine. It’s a compact ESP32 with a 240x240 LCD, WiFi, and a single button. The software is what let it down. The official app store had almost nothing in it, the companion app didn’t do much, and the developer tools barely worked.

I forked Kublet’s community repo, stripped out the broken tooling, and started building. The original repo shipped with four bare-bones example apps. Over the course of a week, Claude Code helped me build 20+ new ones on top of that. It was supposed to be a weekend project but I kept going because it was fun.

The tooling problem (and fix)

The original Kublet developer experience relied on krate, a proprietary CLI that barely worked and is no longer maintained. The official docs point to dead links. Before I could build any apps, I needed a way to actually compile and deploy code to the device.

Claude Code helped me build a replacement dev tool in Python that handles the full lifecycle. It does initial USB flashing with WiFi credentials baked into NVS, PlatformIO builds with the correct TFT_eSPI pin configuration, and wireless OTA deployment so I don’t have to keep plugging in cables.

./tools/dev init              # One-time USB flash + WiFi setup
./tools/dev build <app>       # Compile an app
./tools/dev deploy <app>      # Build and OTA deploy
./tools/dev logs              # Stream serial logs

Getting the display configuration right was one of those things that would have taken me hours of digging through forums. The Kublet uses an ST7789 display on specific SPI pins with a 40 MHz clock, and none of this was documented. Claude Code helped me trace through the original firmware, figure out the pin mapping, and wire it into the PlatformIO build so it “just works” for every app.

The apps

Each app is a self-contained PlatformIO project that compiles to a firmware image deployed over WiFi. Here are some of them (the full list is in the repo):

Stock Ticker

Weather

Hacker News

Clock

Music

Notifications

Aquarium

Matrix

DVD Screensaver

Snake

Astro

Badgers

Stock Ticker – Tracks 10 symbols (VOO, AAPL, NVDA, BTC-USD, etc.) with intraday sparkline charts, refreshing every 5 minutes. This is what I originally backed the Kublet for.

Weather – Current conditions plus a 3-day forecast with animated weather icons. Uses the Open-Meteo API so no API key needed. Cycles through three saved locations.

Hacker News – Displays the top 10 stories with scores and comment counts, auto-cycling every 30 seconds.

Clock – Analog clock, NTP-synced, with smooth sweeping hands and proper hour markers.

Music – Shows what’s currently playing in Apple Music with album artwork rendered as a 240x240 JPEG, track name, artist, and elapsed time. A small Python server on my Mac polls Music.app via AppleScript and serves the data over the local network.

Notifications – Mirrors macOS notifications from iMessage, Slack, Discord, Mail, and Calendar to the Kublet in real time. This one alone justified pulling the devices out of the drawer.

Aquarium – An animated underwater scene with fish, jellyfish, a crab, seahorse, seaweed, and rising bubbles. Three color themes.

Matrix – Digital rain with 40 falling character columns and glowing trails. Five color themes toggled with the button.

DVD Screensaver – The bouncing DVD logo. It counts corner hits and flashes white when it finally gets one.

Snake – An “AI”-controlled snake game using A* pathfinding with flood-fill safety checks. It plays itself endlessly.

Astro – Pulls NASA’s Astronomy Picture of the Day and cycles through a 30-day archive.

Badgers – My first Kublet app, written a few months ago with much more limited AI help. It plays the Badgers meme. I couldn’t get the GIF rendering smooth until I came back to it with Claude Code.

Working with Claude Code

I used Claude Code with Opus 4.6 for the whole project. I expected it to struggle with ESP32 development, given the constrained environment (320 KB of RAM, no filesystem, no standard library networking), but it consistently produced code that compiled and ran on first deploy. It understood the TFT_eSPI API, ArduinoJson patterns, and the quirks of WiFi on ESP32 without much hand-holding.

The iteration cycle worked well. Describe an app concept, get a working first version, deploy over WiFi, see it on the screen, refine. Most apps went from idea to running on hardware in under an hour. The maze app with its multiple generation and solving algorithms was the most complex and that took maybe two hours.

The music and notification apps were interesting because they required a Python server running on my Mac to bridge between macOS APIs and the ESP32 over HTTP. Claude Code wrote both sides, the AppleScript integration and the server endpoints on the Mac side, and the embedded C++ client code on the ESP32 side.

The graphics work impressed me the most. Apps like the aquarium and matrix rain involve real rendering math that all runs at full frame rate on a tiny microcontroller. The first versions worked out of the box, but it took several iterations to get things like the aquarium to actually look alive. Tuning fish movement, bubble timing, color palettes. Claude Code was good at taking vague feedback like “the fish look robotic” and turning it into better animation code.

How far things have moved

A little over a year ago I wrote about exploring AI coding tools, comparing GitHub Copilot and a local Llama model on a single-file Python problem. My takeaway at the time was that these tools were useful for basic tasks but fell apart when complexity increased, especially across multiple files. I ended that post saying I’d keep writing most of my own code.

This project was nothing like that. Claude Code handled embedded C++ on an ESP32, Python servers bridging macOS APIs, display driver configuration, OTA deployment, and rendering math for animations, all in the same session. It kept context across files and knew when changes in one place needed updates in another. The gap between what AI coding tools could do in early 2025 and what they can do now is significant.

What’s next

The repo is public. If you have a Kublet gathering dust, clone it and try the dev tool. Each app is self-contained and deploys over WiFi in about 30 seconds. I have three Kublets on my desk now: one showing stocks, one showing the weather, and one showing my recent notifications. They’re finally doing what I paid for.

The Kublet is still a cautionary tale about Kickstarter promises, but it’s also proof that good hardware outlasts bad software.

MongoDB Community Edition: Vector Search for Everyone

Sun, 12 Oct 2025 23:00:00 +0000

I’ve been itching to try MongoDB’s vector search ever since I saw it demoed at MongoDB.local NYC back in September. But here’s the thing: until recently, it was Atlas-only. If you wanted to build a RAG application or experiment with semantic search, you either paid for Atlas or jury-rigged something with Pinecone or Weaviate alongside your MongoDB instance. It works, but it always felt like a duct taped solution.

Then MongoDB 8.2 Community Edition dropped with vector search in public preview, and I immediately spun up a demo project. This isn’t just a nice-to-have feature. It fundamentally changes what you can build locally. No more “well, I’d love to test this, but I need to sign up for their cloud service first.”

What Actually Changed

Here’s what MongoDB added to the free, self-managed Community Edition:

$vectorSearch - Semantic similarity search right in your aggregation pipelines
$search - Full-text keyword search with fuzzy matching
$searchMeta - Metadata and faceting for search results
mongot - A separate search binary that handles the indexing (runs alongside mongod)

The key part is functional parity with Atlas. Same APIs, same aggregation operators, same everything. You’re not getting a watered-down version. This is the real deal, just running on your own hardware.

Setup

I built a Wikipedia search demo to test this out properly. The stack is pretty straightforward:

MongoDB 8.2 and mongot running in Docker
LM Studio for generating embeddings locally (using Nomic Embed)
A Python app to ingest Wikipedia articles and run searches

The interesting bit is that you need both mongod and mongot running. Mongot is the search server. It handles the indexing and similarity calculations while mongod stores the actual data. They talk to each other behind the scenes.

One gotcha: MongoDB needs to run as a replica set, even if it’s just a single node. The search features require this. Not a huge deal, but it means your docker-compose setup needs a few extra lines to initialize the replica set.

Here’s the basic docker-compose structure:

services:
  mongod:
    image: mongodb/mongodb-community-server:8.2.0-ubi9
    command: mongod --replSet rs0
    ports:
      - 27017:27017

  mongot:
    image: mongodb/mongodb-community-search:0.53.1
    ports:
      - 27028:27028
    depends_on:
      - mongod

That’s it. No Atlas credentials, no external services. Everything runs locally.

For more details, check out the official MongoDB quick start guide: MongoDB Vector Search Quick Start.

Setting Up the Indexes

The first thing you need to do is create search indexes. MongoDB needs these to know how to handle your searches. Kind of like telling it “hey, these vectors should be searchable by similarity” or “these text fields should support keyword matching.”

Vector Search Index

For vector search, you create an index that knows how to handle high-dimensional embeddings. In my case, I’m using 768-dimensional vectors from the Nomic Embed model:

from pymongo.operations import SearchIndexModel

definition = {
    "fields": [
        {
            "type": "vector",
            "path": "embedding",
            "numDimensions": 768,
            "similarity": "cosine"
        }
    ]
}

model = SearchIndexModel(
    definition=definition,
    name="vector_index",
    type="vectorSearch"
)

collection.create_search_indexes([model])

The numDimensions has to match your embedding model. I’m using 768 because that’s what Nomic Embed outputs. The similarity metric is usually cosine for text embeddings. It’s what works best for semantic similarity.

Text Search Index

For full-text keyword search, it’s even simpler. You can just use dynamic mapping and MongoDB will index all your string fields:

definition = {
    "mappings": {
        "dynamic": True
    }
}

model = SearchIndexModel(
    definition=definition,
    name="text_search_index",
    type="search"
)

collection.create_search_indexes([model])

That’s it. MongoDB handles the rest.

The Data Structure

I split Wikipedia articles into two collections: one for article metadata and one for searchable chunks. The chunks collection is where the magic happens:

{
    "page_id": 12345,
    "title": "Machine Learning",
    "chunk_index": 0,
    "section": "Introduction",
    "text": "Machine learning is a method of data analysis...",
    "embedding": [0.123, -0.456, 0.789, ...],  # 768-dim vector
    "token_count": 256
}

Each chunk is about 512 tokens of text (roughly a few paragraphs), and each one gets its own embedding vector. This chunking strategy is important. You can’t just embed entire Wikipedia articles. They’re too long, and you lose granularity. By chunking, you can find the specific section that’s relevant to a query.

I’m using LM Studio to generate the embeddings locally. The Python code uses the lmstudio package to interface with the embedding model:

import lmstudio as lms

# Load the embedding model
model = lms.embedding_model("text-embedding-nomic-embed-text-v1.5@q8_0")

# Generate embedding
embedding = model.embed("Your text here")

The embeddings go right into MongoDB as arrays. No special format needed, just a list of floats in the embedding field.

Vector Search: Semantic Similarity in Action

This is where things get interesting. Vector search is all about semantic similarity. Finding documents that mean the same thing, not just documents that contain the same words.

The query is an aggregation pipeline with the new $vectorSearch stage:

pipeline = [
    {
        "$vectorSearch": {
            "index": "vector_index",
            "path": "embedding",
            "queryVector": query_embedding,
            "numCandidates": 100,
            "limit": 10
        }
    },
    {
        "$project": {
            "title": 1,
            "text": 1,
            "score": {"$meta": "vectorSearchScore"}
        }
    }
]

results = list(collection.aggregate(pipeline))

You embed your query text (same way you embedded the documents), then pass that vector to $vectorSearch. It finds the closest matches using cosine similarity.

The results are genuinely impressive. I can ask “Greek hero with weak heel?” and it pulls up relevant chunks about Achilles and the Trojan War, even though I never mentioned his name. That’s the semantic part working. Conveniently, Achilles is one of the first articles loaded from the Wikipedia dataset, which makes it a perfect quick test to validate everything is working correctly.

One thing to note: numCandidates is how many documents it considers before narrowing down to your limit. Higher numbers give better results but are slower. I experimented a bit and set it to 10x the limit as a starting point.

Text Search: Good Old Keyword Matching

Sometimes you just want to find documents that contain specific words. That’s what $search is for: traditional full-text search with all the bells and whistles.

pipeline = [
    {
        "$search": {
            "index": "text_search_index",
            "text": {
                "query": "Albert Einstein relativity",
                "path": ["text", "title"],
                "fuzzy": {"maxEdits": 2}
            }
        }
    },
    {"$limit": 10},
    {
        "$project": {
            "title": 1,
            "text": 1,
            "score": {"$meta": "searchScore"}
        }
    }
]

results = list(collection.aggregate(pipeline))

The fuzzy matching is nice. It’ll catch typos and close variations. If someone searches for “Einstien” instead of “Einstein,” it still works.

Text search is faster than vector search and more predictable. If you know the exact term you’re looking for (like a person’s name or a technical term), text search is usually the better choice. But it doesn’t understand semantics. It’s just matching words.

Hybrid Search: The Best of Both Worlds

The really cool part is combining both approaches. You run a vector search and a text search, then merge the results using something called Reciprocal Rank Fusion (RRF). It’s a way of saying “if a document shows up high in both result sets, it’s probably really relevant.”

Here’s the basic idea:

# Run both searches
vector_results = vector_search(query, limit=20)
text_results = text_search(query, limit=20)

# Calculate RRF scores
rrf_scores = {}
for rank, result in enumerate(vector_results, 1):
    rrf_scores[result.id] = 1.0 / (60 + rank)

for rank, result in enumerate(text_results, 1):
    if result.id in rrf_scores:
        rrf_scores[result.id] += 1.0 / (60 + rank)
    else:
        rrf_scores[result.id] = 1.0 / (60 + rank)

# Sort by combined score
final_results = sorted(rrf_scores.items(), key=lambda x: x[1], reverse=True)

This gives you the best of both worlds. Documents that match semantically and contain the right keywords get boosted to the top. It’s surprisingly robust. I’ve found it works well without much tuning.

You can also do weighted combinations if you want more control (e.g., 70% vector, 30% text), but RRF is usually good enough.

What This Enables

The real win here is RAG (Retrieval-Augmented Generation). You can now build a complete RAG pipeline without leaving MongoDB:

User asks a question
You embed the question and do a vector search
You retrieve the top 3-5 relevant chunks
You feed those chunks as context to an LLM
The LLM generates an answer grounded in your data

This is the “memory” concept from the MongoDB.local keynote. Giving AI agents access to your data in a way that’s fast, relevant, and doesn’t require syncing between multiple databases.

And because it’s all in MongoDB, you get:

Transactional consistency - No sync lag between your main DB and your vector store
Simple architecture - One database, one query language, one connection string
Metadata filtering - Combine vector search with traditional filters (e.g., “find similar articles, but only in the ‘Science’ category”)

Performance

The search performance itself is solid. Vector search typically returns results in under 100ms for 10 results. Text search is even faster at around 20-30ms. Hybrid search is just the sum of both plus some merging logic.

The bottleneck is embedding generation. Processing 10,000 Wikipedia articles for ingestion into MongoDB takes hours on consumer hardware, and parsing and embedding the entire Wikipedia dump would take days. That’s not a MongoDB problem though. That’s just how long it takes to run text through an embedding model locally. Once your data is indexed, queries are fast.

Wrapping Up

Vector search in MongoDB Community Edition changes the local development game. Before this, building a RAG application meant juggling multiple databases: MongoDB for your data, Pinecone or Weaviate for vectors, and some sync mechanism to keep them aligned. Now it’s just MongoDB. One connection string, one query language, one place where everything lives.

The fact that this is in the free Community Edition matters. No monthly bills, no vendor lock-in. You can prototype locally, understand exactly how it works, and decide later whether you want to move to Atlas or keep running it yourself. That’s the kind of flexibility that makes experimenting with new features actually happen instead of staying on the “maybe someday” list.

I’ve put the complete demo project on GitHub at markusos/mongo-search-demo. It includes the Docker Compose setup, Wikipedia ingestion pipeline, LM Studio integration, and an interactive CLI for testing all three search modes. Clone it, run docker compose up, and a few additional setup steps, and you’ll have a working vector search system running locally in minutes. No cloud accounts required.

Snowflake World Tour NYC: Beyond the Warehouse and into AI

Thu, 02 Oct 2025 23:00:00 +0000

Is it just me, or is every data conference at the Javits Center this year the exact same conference? A couple of weeks ago it was MongoDB’s turn, and today I just got back from the Snowflake World Tour. It felt like deja vu. The lights are different, the logos are different, but the theme being blasted from the keynote stage is identical: AI is here, and we’re the platform you need for it.

Snowflake’s version of this story is called Cortex Agents. This was the star of the show, where they pitched a future of building and deploying AI that lives and runs right on top of your data. The vision is compelling, for sure. They even tried a live demo, which promptly ran into some real-world chaos in the form of bright red “Internal server error” messages. It was a good reminder that this stuff is still on the bleeding edge, even for the folks building it.

One session that stood out from the main AI theme was on Snowflake Postgres. It was an interesting deviation, and after their acquisition of Crunchy Data, it’s a clear indicator of where they’re heading. They’re making a run at developers building transactional apps, trying to pull OLTP workloads onto their platform and stop being just the final destination for data.

Of course, you can’t unleash AI agents on corporate data without locking them down, which is where the session on the Horizon Catalog provided a necessary dose of reality at the end of the day. They covered the governance and security guardrails, which is the stuff that actually matters if you want to use any of this in a real company.

So, walking out of the Javits Center again, the deja vu was real. The industry is shouting one thing right now: AI. Every platform wants to be the center of this new world. Last time it was MongoDB pitching itself as the “memory” for agents. Today, Snowflake laid out its grand vision to be the entire “central nervous system”. It feels like the definition of a data platform is changing in real-time. For engineers, this brings our mission into sharp focus. Our job remains what it has always been: to cut through the marketing metaphors and separate the architectural signal from the aspirational noise.

MongoDB.local NYC: Embracing the AI Era with New Tools

Wed, 17 Sep 2025 23:00:00 +0000

Just got back from MongoDB.local NYC, and my head is still buzzing a bit. It was a long day, but a good one. The theme was pretty much blasted from the stage all day: data infrastructure for the AI era. They kept framing MongoDB as the “memory” for AI agents: the thing that provides context and state so the agents aren’t just stateless parrots.

For me, the biggest announcement was the public preview of Vector Search for the Community and Enterprise editions. This is a huge deal, honestly. It means I can actually build and test RAG applications locally without being tied to a cloud service just to get vector search working. It really lowers the barrier to just trying things out. Along with that, they announced their new Voyage AI models to improve retrieval accuracy and an Application Modernization Platform, which seems geared more toward large enterprise projects.

But the highlight for me was a hands-on session on giving AI agents persistent memory. They walked us through the new MongoDB Store for LangGraph, and it finally clicked how this “memory” concept works in practice. We saw how an agent could use MongoDB to store different types of memory (like episodic or semantic) across multiple conversations, using its JSON structure and vector search to pull relevant context. It’s a really practical solution to a tricky problem.

So, walking away from it, my main takeaway is that MongoDB is making a serious play to be more than just a database in the AI stack. Making vector search accessible to everyone in the Community Edition is the smartest thing they could have done. It feels like they’re shifting from being just a place to store data to being an active part of an AI’s brain. Time to go download the latest version and see what I can build with it.

MCP Server for Data Access: The Future of Analytics?

Sun, 29 Jun 2025 23:00:00 +0000

After spending some time with Anthropic’s Model Context Protocol (MCP), I’m cautiously optimistic about what might be a fundamental shift in how we interact with data. MCP promises to be the “USB-C port for AI applications”: a standardized way for LLMs to access external data and tools. While the protocol itself may seem like yet another abstraction layer, the bigger question is whether we’re witnessing the early stages of LLMs becoming the primary interface for data exploration.

To test this in practice, I built an NYC 311 Data MCP Server that exposes 3.5 million New York City service requests from 2024, enabling LLMs to interact with the data. The server lets AI assistants run read-only SQL queries against the full dataset: complaint types, geographic patterns, temporal trends. It’s built on DuckDB for performance and includes some security guardrails to prevent dangerous operations.

The bottom line: It works surprisingly well for basic exploratory data analysis, and raises interesting questions about whether traditional dashboards and BI tools might eventually give way to conversational analytics.

MCP Architecture

MCP uses a client-server architecture where the host (Claude Desktop, LM Studio, VS Code, etc) coordinates everything and enforces security, while clients maintain isolated sessions with servers that expose data through standardized primitives.

The good news is that servers are isolated from each other, ensuring they cannot access the full conversation history. Capability negotiation occurs upfront, allowing you to understand what features are supported before proceeding. While this adds complexity compared to a simple REST endpoint, MCP offers a lightweight and practical standard for tool interoperability. However, as MCP is still in its early stages and evolving rapidly, its long-term adoption remains uncertain.

NYC 311 Data MCP Server

To test this concept, I built an MCP server using the FastMCP framework with a DuckDB backend optimized for analytics requests. The server provides access to the full 2024 NYC 311 service requests dataset, comprising 3.5 million records with detailed location data (borough, ZIP, latitude/longitude), request specifics, and temporal information.

The core functionality centers around a query_data tool that executes read-only SELECT queries, plus a schema resource that provides table structure information. Security guardrails block SQL operations altering data (DROP, DELETE, UPDATE, INSERT, ALTER, CREATE, TRUNCATE, EXEC) and enforce LIMIT clauses for SELECT * queries. This allows the LLM to safely explore the dataset without risking accidental data corruption or excessive resource usage.

Testing with Real Data: Natural Language to SQL

The complete code to test this out is available in the markusos/llm_duck repository.

Setting this up requires Python 3.9+, the uv package manager, and an MCP-compatible client. LM Studio 0.3.17+ supports MCP by editing ~/.lmstudio/mcp.json, and tool calls show confirmation dialogs for security by default.

mcp.json:

{
  "mcpServers": {
    "311_data": {
      "command": "uv",
      "args": [
        "--directory",
        "/ABSOLUTE/PATH/TO/llm_duck",
        "run",
        "run_mcp_server.py"
      ]
    }
  }
}

After setting up the MCP configuration and loading Google’s gemma-3-27b LLM model into LM Studio, the model automatically discovered my MCP server. When prompting, the LLM began exploring the NYC 311 dataset. Without the need for manual SQL writing, it generated queries to uncover patterns across the 3.5 million records. DuckDB’s columnar storage handled the analytical workload efficiently, while the MCP layer added minimal overhead.

The assistant successfully analyzed complaint patterns, handled missing data gracefully, and even generated simple aggregations on demand. While these capabilities—basic text-to-SQL conversion and query execution—are impressive, MCP provides a crucial advantage: it establishes a standardized framework for LLMs to interact seamlessly with multiple tools, diverse data sources, and complex workflows.

During testing of the MCP server with LM Studio and the google/gemma-3-27b model, the AI assistant successfully generated SQL to aggregate data, such as identifying the Zip codes with the most service requests in Brooklyn. When encountering invalid column names, the LLM utilized the schema resource to understand the correct structure and re-queried the data. This highlights how LLMs can leverage structured metadata and iterative refinement to enhance query accuracy, representing a significant advancement beyond basic text-to-SQL conversion.

SELECT 
    incident_zip, 
    COUNT(*) AS count 
FROM service_requests 
WHERE borough = 'Brooklyn' 
GROUP BY incident_zip 
ORDER BY count DESC 
LIMIT 10

What’s particularly impressive is how the LLM can enrich raw query results with contextual information not stored in the database. For example, it translates ZIP codes into recognizable neighborhood names, making the data more meaningful to users.

ZIP Code	Neighborhood Name	Service Request Count
11213	Sunset Park	849
11203	Williamsburg	765
11216	Bushwick	746
11206	Bed-Stuy (Bedford–Stuyvesant)	738
11211	Greenpoint	735
11209	Crown Heights	724
11217	Kensington	687
11221	Fort Greene/Clinton Hill	653
11205	Park Slope	649
11233	Flatbush	648

The system works well for natural language to insights without manual SQL writing. While someone fluent in SQL could write these queries more accurately and efficiently, LLMs with MCP enables individuals without SQL expertise to access and interact with data in ways that were previously inaccessible, opening up new possibilities for data exploration.

LLMs as the New Dashboard?

This MCP server builds on my previous work categorizing NYC 311 requests using local LLMs, but represents a fundamental shift toward conversational analytics. Where traditional BI tools require pre-built charts and fixed queries, LLM-powered analytics enables dynamic exploration through natural language.

The implications are profound. Instead of building dozens of dashboard widgets to answer specific questions, we might soon have AI assistants that augment dashboard capabilities to instantly generate insights from natural language queries. Want to see “noise complaints by neighborhood during summer weekends”? No need to pre-define that visualization. The LLM constructs the query, executes it, and explains the results.

Rather than clicking through dashboard filters and pivot tables, analysts could simply describe what they want to understand and let the AI handle the technical translation. This represents a fundamental shift from static, pre-built visualizations to dynamic, conversation-driven data exploration.

What’s particularly interesting is how this complements my earlier batch processing work. Where I previously used LLMs to transform and categorize data at scale, this MCP server demonstrates LLMs as interactive query engines. We’re seeing the emergence of a complete LLM-powered analytics stack: batch processing for data preparation and real-time conversations for data consumption.

Challenges and Opportunities Ahead

While this experiment demonstrates the potential for LLM-powered analytics, several challenges remain before conversational data analysis becomes mainstream.

LLM reliability issues surfaced during testing that highlight the technology’s current limitations. The AI assistant sometimes failed to generate correct tool calls, occasionally made up tool responses instead of using the actual MCP server, and would ignore parts of the tool output while generating responses. These aren’t just minor bugs. They represent fundamental challenges with LLM reliability that could undermine user trust in production environments.

Technical standardization is still evolving. MCP provides one approach, but the ecosystem is fragmented. Today you might build an MCP server, tomorrow it could be a different protocol entirely. The good news is that the underlying capability (LLMs generating and executing SQL) works regardless of the transport mechanism.

Security and governance require careful consideration. Unlike traditional dashboards with fixed queries, LLM analytics can generate arbitrary SQL. This flexibility is powerful but demands robust guardrails, especially with sensitive enterprise data. My implementation blocks some dangerous operations, but determined users could still extract large datasets through their prompts.

Data complexity scales quickly beyond simple schemas. My single-table NYC 311 dataset works relatively well, but enterprise scenarios with hundreds of tables, complex joins, and business logic require sophisticated semantic layers. The LLM needs to understand not just what data exists, but what it means and how metrics should be computed.

User expectations will need to evolve too. Traditional dashboards set clear expectations about what questions can be answered. Conversational analytics promises infinite flexibility, but users will need to learn how to ask good questions and interpret probabilistic responses from LLMs that might misunderstand context or hallucinate results.

Despite these challenges, the trend toward LLM-powered analytics feels inevitable. As models become more capable and data infrastructure adapts, the friction of asking questions will continue to decrease. The question isn’t whether this will happen, but how quickly organizations can adapt their data practices to support it and how fast foundational LLM models keep improving.

Observations and Future Potential

My trial with the NYC 311 Data MCP Server demonstrates both the promise and practical challenges of LLM-powered analytics. Similar to my initial impressions of AI coding assistants, there’s an immediate sense that we’re witnessing the early stages of a fundamental shift in how humans interact with data.

The system excels at translating natural language questions into SQL queries and providing immediate insights without manual coding. The standardized interface could theoretically work across different AI assistants, creating a unified way to access organizational data. Most importantly, it hints at a future where business users can explore data directly through conversation rather than relying on pre-built dashboards or technical teams.

However, significant challenges remain. The infrastructure feels heavyweight for simple use cases, and real-world adoption patterns are still unclear. More critically, scaling beyond simple schemas requires sophisticated semantic layers that most organizations haven’t built yet.

The honest assessment is that we’re still in the early experimental phase, but the direction seems clear. As LLMs become more capable and data infrastructure evolves to support them, conversational analytics will likely become the norm rather than the exception. Traditional dashboards may not disappear entirely, but they’ll increasingly serve as fallbacks rather than primary interfaces.

For now, MCP represents one approach to standardizing this future, but the more important trend is the underlying shift toward AI-powered data exploration. Whether through MCP, enhanced REST APIs, or entirely different protocols, the age of conversational analytics is beginning.

Decoding the City's Pulse: Analyzing NYC 311 Data with LLMs

Sat, 14 Jun 2025 21:00:00 +0000

NYC’s 311 system generated ~3.5 million service requests in 2024, a perfect dataset for testing whether local LLMs can handle large-scale text analysis without API costs or rate limits. In this post, I’ll walk through how I used a local LLM to categorize and analyze these requests, revealing insights into the city’s pulse.

Instead of processing each request individually, I reduced the dataset to ~1,200 unique combinations of agency, complaint type, and descriptor fields, then used a local LLM to categorize these patterns. This approach works well for pre-computing categories to later use for analysis, such as identifying hotspots or trends.

Visualizing the Baseline Data

Before diving into LLM categorization, let’s examine the spatial and temporal patterns in the raw data:

The heatmap shows expected patterns, high density correlates with population density. More interesting is the per-capita analysis:

Some hotspots with anomalously high request rates (highest month per zipcode):

Zip Code	Neighborhood	Month	Requests per 1000 Residents
10466	Wakefield	Dec 2024	275
10004	Financial District	Oct 2024	241
11239	East New York	Dec 2024	166
11366	Fresh Meadows	Jun 2024	158
10006	Financial District	Jul 2024	109
11101	Long Island City	Sep 2024	101
10018	Garment District	Oct 2024	95
10007	Tribeca	Sep 2024	92
10464	City Island	Jun 2024	86
10036	Hell’s Kitchen	Oct 2024	81

The Financial District’s high rates likely reflect commercial density rather than residential issues, while areas like Wakefield and East New York suggest genuine challenges.

LLM-Powered Categorization

To extract insights from this massive dataset, I integrated a local LLM directly into DuckDB using a custom User Defined Function (UDF). This approach combines SQL’s analytical power with modern language models, processing and categorizing data at scale within a single query.

DuckDB + LLM Integration

I created a Python UDF that connects DuckDB to a local install of LM Studio, serving the gemma-3-27b-it model via OpenAI-compatible API.

Here’s the core implementation:

# This file contains the UDF for calling the local LLM API.
# Register the Python function as a scalar UDF
# con.create_function("prompt", prompt, [str, str, str, float], str)

import json

import requests

MODEL = "gemma-3-27b-it"
MODEL_TEMP = 0.4
MODEL_MAX_TOKENS = -1


# Define the UDF
def prompt(
    prompt_text: str,
    system_message: str | None = None,
    json_schema: str | None = None,
    temperature: float | None = None,
) -> str:
    """
    Calls the local LLM API and returns the response.
    """
    url = "http://localhost:1234/v1/chat/completions"
    headers = {"Content-Type": "application/json"}
    payload = {
        "model": MODEL,
        "messages": [
            {"role": "user", "content": prompt_text},
        ],
        "temperature": MODEL_TEMP,
        "max_tokens": MODEL_MAX_TOKENS,
        "stream": False,
    }

    # Set system message if provided
    if system_message is not None:
        payload["messages"].insert(0, {"role": "system", "content": system_message})

    # Set temperature if provided
    if temperature is not None:
        payload["temperature"] = temperature

    if json_schema:
        payload["response_format"] = {
            "type": "json_schema",
            "json_schema": json.loads(json_schema),
        }

    try:
        response = requests.post(url, headers=headers, data=json.dumps(payload))
        response.raise_for_status()  # Raise an error for HTTP codes 4xx/5xx

        return (
            response.json()
            .get("choices", [{}])[0]
            .get("message", {})
            .get("content", "No response")
        )
    except requests.exceptions.RequestException as e:
        # Raise an exception to ensure the query fails
        raise RuntimeError(f"API request failed: {str(e)}") from e
    except Exception as e:
        # Handle any other exceptions
        raise RuntimeError(f"An error occurred: {str(e)}") from e

This UDF handles the API communication, error handling, and JSON schema enforcement. The open_prompt DuckDB extension provides similar functionality, but I opted for a custom UDF to ensure I had full control over the model usage and response formatting.

SQL-Powered Categorization

The following python code snippet demonstrates how to use the UDF within a DuckDB query to categorize service requests based on agency, complaint type, and description. The LLM processes each unique combination, returning a JSON object with the assigned category and subcategory.

Load the UDF and other necessary libraries, then define the system prompt and JSON schema for the LLM:

import json

import duckdb
from jinja2 import Template

from src.duckdb_prompt_udf import prompt

# Connect to DuckDB
con = duckdb.connect(database=":memory:", read_only=False)

# Register the Python function as a scalar UDF
con.create_function("prompt", prompt, [str, str, str, float], str)

Define the system prompt and JSON schema for the LLM. The system prompt instructs the model to categorize service requests based on predefined categories and subcategories, while the JSON schema ensures valid responses:

system_prompt = (
    "You are a government auditor reviewing New York's 311 service request system.\n\n"
    "Your task:\n"
    "1. Review the given service request details (agency, complaint type, and description)\n"
    "2. Choose the most appropriate category and subcategory from the provided CATEGORIES json structure\n"
    "3. The sample data in CATEGORIES json serves as guidance for classification\n\n"
    "Important rules:\n"
    "- Only use CATEGORIES and SUBCATEGORIES that exist in the provided CATEGORIES json block\n"
    "- Do NOT use the sample labels as categories or subcategories\n"
    "- Do NOT create new categories\n\n"
    "Response format:\n"
    "```json\n"
    '{"category": "STRING", "subcategory": "STRING"}\n'
    "```\n"
    "Note: Your response must contain ONLY the JSON object, nothing else."
)

#  Define the JSON schema for the response
json_schema = json.dumps(
    {
        "name": "category_response",
        "type": "object",
        "strict": "true",
        "schema": {
            "type": "object",
            "properties": {
                "category": {
                    "type": "string",
                },
                "subcategory": {
                    "type": "string",
                },
            },
        },
        "required": ["category", "subcategory"],
    }
)

Finally, we define the SQL query that uses the UDF to categorize service requests. The query processes the dataset, calling the LLM for each unique combination of agency, complaint type, and descriptor. The prompt function formats the request, while the JSON schema ensures valid responses.

# Define the SQL query template
query_template = """
COPY (
    WITH llm_categorization AS (
        SELECT
            regexp_replace(
                prompt(
                    '# CATEGORIES:\n'
                    || '```json\n'
                    ||categories::VARCHAR || '\n'
                    || '```\n'
                    ||'# SERVICE REQUEST:\n'
                    ||'AGENCY: ' || IFNULL(agency, 'N/A') || '\n'
                    ||'COMPLAINT TYPE: ' || IFNULL(complaint_type, 'N/A')  || '\n'
                    ||'DESCRIPTION: ' || IFNULL(descriptor, 'N/A') || '\n',
                    ''::VARCHAR,
                    ''::VARCHAR,
                    ::FLOAT
                ),
                '```json|```',
                '',
                'g'
            )::VARCHAR AS raw_llm_response,
            json_extract_string(raw_llm_response, '$.category')::VARCHAR AS category,
            json_extract_string(raw_llm_response, '$.subcategory')::VARCHAR AS subcategory,
            agency,
            complaint_type,
            descriptor,
            request_count,
        FROM (
            SELECT 
                agency,
                complaint_type,
                descriptor,
                count(*) AS request_count
            FROM "" 
                group by 1,2,3
                order by 4 desc
                limit 
        ) CROSS JOIN read_json('./data/categories.json')
    )

    SELECT
        agency,
        complaint_type,
        descriptor,
        category,
        subcategory,
        raw_llm_response,
        request_count
    FROM llm_categorization 
) TO '';
"""

# # Render the template with variables
template = Template(query_template)
query = template.render(
    system_prompt=system_prompt,
    json_schema=json_schema,
    temperature=0.2,
    data_file="./data/cityofnewyork/service_requests_2024.parquet",
    output_file="./output/llm_categorize_output_2024.csv",
    limit=1200,
)

# Execute the query
print("Executing query...")

result = con.execute(query).fetchall()
print(result)

The input dataset is a Parquet file containing NYC 311 service requests for 2024, which is read into DuckDB. The query deduplicates the dataset to focus on unique combinations of agency, complaint type, and descriptor, significantly reducing the number of LLM calls required.

The categories.json file contains the predefined categories and subcategories, which the LLM uses to classify requests. The query deduplicates the dataset, reducing it from 3.5 million records to just ~1,200 unique combinations.

The resulting categorized data is saved to a CSV file, which can be used for further analysis, by loading it back into DuckDB or any other data analysis tool.

Processing Results

Processing this SQL query with the LLM integration took about 60 minutes on a MacBook Pro. Each LLM call took 2-4 seconds, with the bottleneck being model inference rather than data processing.

The model achieved high categorization accuracy. I manually reviewed a random sample of 200 requests and found ~196 correctly assigned. This 98% figure should be taken as indicative rather than rigorous.

Breaking down the data

Now that we have the data categorized, we can start to break it down by category and subcategory to identify trends.

The top 10 request categories/subcategories for 2024 are:

Category	Subcategory	Request Count
Public Safety & Order	Parking	796,805
Public Safety & Order	Noise & Disturbances	752,910
Housing & Infrastructure	Building & Utilities	715,222
Environmental Health & Sanitation	Waste Management & Sanitation	247,084
Housing & Infrastructure	Street & Sidewalk Conditions	234,890
Environmental Health & Sanitation	Animals & Pests	129,931
Hazardous Conditions	Water Quality & Leaks	113,746
Government & Community Services	Parks & Community	104,311
Public Safety & Order	Non-Emergency Police Matters	95,088
Consumer & Business Services	Consumer Complaints	64,080

These results align well with the primary functions of NYC’s 311 system, showing that our LLM-powered categorization has successfully identified the most common types of citizen requests across the city.

Conclusion

This analysis demonstrates how LLMs can automatically categorize large-scale government datasets at zero marginal cost. By integrating a local LLM into DuckDB through a custom UDF, we processed 3.5 million NYC 311 requests with 98% accuracy in 60 minutes on consumer hardware.

The key technical insight—deduplication before processing—reduced computational requirements by 99.97% while maintaining analytical value. This approach proves that sophisticated text analysis can be performed cost-effectively without relying on expensive cloud APIs.

Performance characteristics:

Input: 3.5M records → 1,200 unique combinations
Processing: 60 minutes on M4 Max MacBook Pro with 36GB RAM
Accuracy: 98% on manual validation sample
Cost: $0

The complete methodology could be applied to any large-scale text classification task where deduplication is possible, or sufficiently unique combinations exist. This opens up new possibilities for real-time categorization of citizen requests, customer feedback, and other large text datasets.

What’s Next?

Having established a working methodology for LLM-powered categorization of NYC 311 data, several analytical directions could provide deeper insights:

Seasonal Patterns: Analyze how complaint categories vary throughout the year—do heating complaints surge in winter while noise complaints peak in summer?

Neighborhood Clustering: Combine our categorized data with the geographic hotspots to identify which neighborhoods consistently report specific types of issues.

Response Time Analysis: Use LLMs to extract urgency indicators from complaint text and correlate with actual resolution times across different categories.

Predictive Modeling: Train machine learning models on the categorized data to predict future complaint trends based on historical patterns.

The complete code is available in the markusos/llm_duck repository.

5 days with Jules: Evaluating Google's AI coding assistant

Sat, 24 May 2025 12:00:00 +0000

For many in software engineering, the idea of an AI coding assistant feels a bit like magic. You give it a task, and it dives into the codebase to help out. Pretty exciting, right? So, when Google recently opened up access to Jules, their new Gemini-powered AI coding agent, I was keen to see how it worked in practice. After trying it out for five days, here’s a look at what I found.

Getting Started: The Initial “Wow”

First off, let’s be clear: the concept is super cool. Imagine an AI that can clone your repository, understand your instructions, and then try to write code, fix bugs, or even update dependencies. When I first set it up and gave Jules its initial tasks, it definitely felt like I was looking at a new way of working.

During this trial period, Google offers five free tasks per day, which provided ample opportunity to experiment without cost concerns.

What Happens When Jules Gets to Work?

So, what was it like once I got past the initial setup? It quickly became clear that Jules is still very much a work in progress, which is expected for a new tool in a trial phase.

One of the first things I noticed was that the service seemed to be under heavy load quite often. This meant that sometimes starting a task or getting consistent results was a bit tricky.

And how long did tasks take? Well, agent tasks could often take hours to complete. I also saw that the tool usage for Jules would frequently time out. This made for an experience that wasn’t always smooth and made it hard to depend on for anything urgent.

Environment Awareness Gaps: One particularly interesting observation was Jules’ interaction with its work environment. The agent didn’t always seem aware of the status of the Virtual Machines (VMs) it was using. This led to frustrating loops where Jules would repeatedly attempt failing commands without recognizing that the underlying VM might be the issue.

At one point, I was trying to convince Jules to validate the VM status by running a simple command instead of repeatedly trying to run the pytest that was timing out. After some back and forth, it finally agreed to check the VM status using ls. This kind of interaction highlighted how much more efficient the process could be if Jules had better environmental awareness and could automatically provision a new VM when the existing one failed.

Communicating with Jules: Interface and Code Quality

Feedback Mechanisms: Currently, communication with Jules happens primarily through a chat interface. While this works for general feedback, it lacks the ability to comment on specific lines of code that Jules suggests. Adding inline code commenting would significantly improve the feedback refinement process.

Project Context: I experimented with providing Jules repository-specific context. While we all have project-specific guidelines, there’s currently no dedicated mechanism to share this information with Jules (unlike GitHub’s copilot-instructions.md approach). I tried adding context to the main README.md file, but Jules’ adoption of this information seemed inconsistent.

Code Quality Assessment: Now, for the big question: what about the code quality? Jules could generate code snippets and suggestions pretty quickly. But the usefulness varied a lot. Some suggestions were genuinely spot on and helpful. Other times, however, I found Jules struggling with fixing even basic Python linter errors, like E501 Line too long. Sometimes, its attempts to fix these small things would actually break something else, and it would get stuck trying to fix the new problems it created. So, some of the code was great, while other parts weren’t quite usable without a lot of changes.

Verdict on Jules for Now

After spending a week with Jules, my overall impression is that it’s a genuinely powerful tool with a lot of exciting potential. The thought of handing off certain coding tasks to an AI is very appealing.

However, it’s also clear that Jules, in its current state, isn’t about to replace human developers. Think of it more as a helpful assistant that works alongside us, rather than a replacement. It might be great for taking a first pass at a new feature, helping with boilerplate, or suggesting solutions for simpler bugs. But the complex problem-solving, the architectural decisions, and the deep understanding of a project? That’s still our job.

The world of AI in software development is evolving rapidly. My time with Jules showed me both the incredible promise and the current learning curve. As the technology gets better, deals with performance hiccups, and improves how it understands our projects and code, tools like Jules are set to become even more valuable. I’ll definitely be watching to see how it grows!

Escape the City Buzz: A Cozy Catskills Getaway

Sat, 05 Apr 2025 19:00:00 +0000

Feeling the relentless pace of city life? That craving for fresh air, quiet woods, and a sky full of stars, perhaps without sacrificing a comfy bed and modern conveniences, is something we know well. We recently chased that feeling with a weekend escape to Postcard Cabins Eastern Catskills, and it turned out to be the perfect antidote to the urban grind.

Day One: Trading Concrete Jungles for Woodland Whispers

Leaving the familiar chaos of New York City behind, we pointed our car north towards the Catskills. The roughly 2.5-hour drive to Catskill felt like shedding layers of city stress with every mile. Its proximity makes it an incredibly accessible retreat for a quick nature fix. Before fully settling into our woodland haven, a quick 7-minute zip to the nearby Hannaford had our groceries sorted for the weekend.

With supplies gathered, our first evening unfolded exactly as hoped: simple, peaceful, and outdoors. We fired up the grill over the cabin’s fire pit, the scent of woodsmoke replacing traffic fumes, enjoying dinner under the vast, darkening sky. It was an instant decompression.

Day Two: Cabin Calm and Cascading Falls

Day two was all about embracing the stillness we came for. We let the morning unfurl slowly within our cozy cabin, a space genuinely designed for recharging. Sunlight streamed through the large window, offering front-row seats to the local wildlife theatre. We watched birds flit between branches and squirrels scamper playfully, a simple, grounding connection to nature enjoyed over morning coffee, right from our bed.

Later, adventure beckoned. A scenic 28-minute drive brought us to the legendary Kaaterskill Falls. Setting off from Laurel House Road, we tackled the 1.7-mile out-and-back trail. It’s generally considered moderately challenging; while well-maintained steps have been added recently, expect some steep and rocky sections (good footwear is recommended!). The payoff? Absolutely breathtaking views of the 260-foot Kaaterskill Falls, New York’s highest cascading waterfall. The sheer scale and the roar of the water were invigorating.

For dinner, we ventured to Casa Susanna in nearby Leeds (part of Camptown lodging), drawn by its reputation for modern Mexican cuisine inspired by family history and the incredible bounty of the Hudson Valley. Their commitment to local farmers, ranchers, and fishermen felt perfectly aligned with the region’s natural spirit, and the meal was fantastic. Back at the cabin, the day wound down with a quintessential campfire activity: melting marshmallows for gooey, delicious s’mores by the fire pit.

Departure Day: Hudson Charm and Lingering Calm

Our final morning involved packing up, a straightforward process thanks to the cabin’s minimalist, “everything you need, nothing you don’t” approach. We weren’t quite ready to dive back into city life, so we made a detour to the delightful town of Hudson, NY.

For brunch, Le Perche on bustling Warren Street proved to be an excellent choice. We can personally vouch for the incredible Croque Madame and the perfectly zesty Spicy Chicken Sandwich. While they might be known for baked goods, their savory options are definitely worth the stop! Afterwards, a leisurely stroll down Warren Street, popping into unique boutiques and galleries, offered a final, perfect taste of Hudson Valley charm before the drive back to Brooklyn.

Overall Reflections: The Glamping Experience

Our stay at Postcard Cabins Eastern Catskills delivered a solid dose of “modern glamping.” It strikes a great balance, offering comforts like an en-suite bathroom (a huge plus!) and reliable AC/Heat, alongside outdoor essentials like the cozy fire pit. It’s ideal if you want a nature immersion without fully “roughing it.” The cabins are smartly designed, cozy, and make for a comfortable base camp.

A Few Things to Keep in Mind:

While we thoroughly enjoyed our stay, here are a few practical points based on our experience and general feedback:

Community Vibe: While nestled in woodlands, the cabins are situated relatively near each other. Expect to see and possibly hear your neighbors – it’s more of a shared nature retreat than total seclusion.
Hot Water Schedule: The hot water system provides about five minutes of shower time before needing roughly 30 minutes to regenerate. Just something to plan around, especially if multiple people are staying.
Connectivity: As expected in a more remote spot, cell service can be patchy (perhaps a welcome nudge to disconnect!). However, the Wi-Fi worked reliably when we needed it.
Priced Provisions: While convenient, some items stocked in the cabin (like tea bags, coffee and firewood) come at an extra cost, operating like a hotel minibar. To give you an idea, a single tea bag was priced at $2.50, so factor that in if you plan to use these extras.

Final Thoughts

Ultimately, our weekend at Postcard Cabins was precisely the recharge we craved. It offered a seamless blend of quiet nature, comfortable lodging, and easy access to stunning local attractions like Kaaterskill Falls and the vibrant town of Hudson. It was a welcome reminder that a truly refreshing escape doesn’t have to be far-flung or complicated. We left with lungs full of fresh Catskills air, feeling reconnected and ready to face the city again, until the next escape calls!