On August 26th, Mark Raasveldt and Hannes Mühleisen published a very short note on the DuckDB blog: DuckLabs, the company behind DuckDB, is becoming a subsidiary of Amazon Web Services. The deal closes in early September.

I read it more carefully than usual because at CARTO we’ve been using DuckDB for a relatively short time, and I’ve written here about file formats and performance and about the httpfs proxy mess. When you adopt a piece of software in production and months later a hyperscaler buys it, the least you can do is sit down and read the fine print.

In April 2021 I made my first commit to the monorepo behind CARTO’s cloud-native platform. It was PR number 9, a docker-compose. Five years later I’ve looked back with some calm and found around 450 commits, around 447 pull requests, and a presence in virtually every service in the repository.

The numbers aren’t the interesting part. What’s interesting is that, going through that history, a thread shows up that I hadn’t fully identified myself: I’ve spent half a decade connecting the platform to other people’s data warehouses. Six different providers — BigQuery, Snowflake, Redshift, Databricks, Oracle and PostgreSQL — each with its own credential model, its pooling, its timeouts and its error messages.

I’ve been writing about Go on this blog since 2015. Back in that “What I like about Go” article I talked about simplicity, fast compilation, and how good it feels to use a language that doesn’t force you to memorize twenty ways of doing the same thing. Then Go 1.18 arrived with generics in 2022, and with them an asymmetry that has bothered a lot of people for years: you could write generic types and generic functions, but not generic methods.

pontecesures.net is a personal project I’ve been running for years: the news portal of Pontecesures, my home town, a Galician municipality of about 3,000 people. The idea has always been a simple one — keeping the information about what happens there alive. Twenty-one years of archive, from 2005 to 2026, 29,559 entries.

The problem is that most of them are uncategorised or categorised inconsistently. When you’ve been publishing for two decades, taxonomies decay on their own: I ended up with 56 categories that no longer meant anything. An archive like that stops being browsable, and at that point much of its value is lost. It’s exactly the kind of task you keep putting off, and one I had wanted to tackle for a long time.

If you’ve been using Claude Code with Auto Memory enabled for a while, you’ve probably noticed that after several sessions, Claude’s notes about your project start accumulating contradictions. Entries saying “yesterday we decided to use Redis” without specifying which day “yesterday” was. Debugging notes referencing files that no longer exist. Three different entries about the same build quirk. What started as a useful notebook becomes noise.

Anthropic has just released Auto Dream, a feature that does exactly what its name suggests: it consolidates Claude Code’s memory the way the human brain consolidates memories during REM sleep.

I have been using Claude Code daily for months, and there is one configuration that has completely changed how it works with my code. It is not a new plugin, a more powerful model, or a magic prompt. It is something that has existed since 2016 and that most developers use without knowing it every time they open VS Code: the Language Server Protocol (LSP).

Karan Bansal published an excellent article explaining in detail how to enable LSP in Claude Code and why it matters. After trying it, I can confirm the difference is real and significant.

Every month, 2.2 million job postings in the United States result in zero hires. Four in ten companies admit their listings are fake. Seven in ten call it morally acceptable. 85 percent still bring candidates in for interviews.

These are not figures from a conspiracy blog. They come from the Bureau of Labor Statistics, from surveys of 650 hiring managers published by ResumeBuilder, and from Revelio Labs analytics. The ghost job economy is a documented, quantified phenomenon, and apparently a perfectly tolerated one.

The problem: httpfs ignores your environment variables

If you work with DuckDB and the httpfs extension to read remote Parquet files, CSVs from S3, or any HTTP resource, you probably assume that the HTTP_PROXY and HTTPS_PROXY environment variables work just like every other tool. Curl respects them. wget respects them. Python requests respects them. Node.js respects them.

DuckDB does not.

I ran into this while working in a corporate environment with a mandatory proxy. I had a script reading Parquet files from Google Cloud Storage using httpfs, and it simply would not work. No clear error, no descriptive timeout, just silence. Meanwhile, a curl to the same resource with the same environment variables returned data without issue.

Every query starts with a plan. Every slow query probably starts with a bad one. And more often than not, the statistics are to blame. But how does it really work?

PostgreSQL doesn’t run the query to find out — it estimates the cost. It reads pre-computed data from pg_class and pg_statistic and does the maths to figure out the cheapest path to your data.

In the ideal scenario, the numbers read are accurate, and you get the plan you expect. But when they’re stale, the situation gets out of control. The planner estimates 500 rows, plans a nested loop, and hits 25,000. What seemed like an optimal plan turns into a cascading failure.

I recently came across an exceptionally dense technical analysis about container security that’s worth sharing. The author started with a simple hypothesis: container filesystem isolation should be sufficient for multi-tenant workloads without virtual machines, if you sufficiently understand what’s happening at the syscall level.

After thorough investigation, the conclusion is more uncomfortable than expected: the defaults protect you well, but the moment you reach for “advanced” features like bidirectional mount propagation or SELinux relabeling, you’re one misconfiguration away from handing an attacker the keys to your host.

Greg Brockman, President and Co-Founder of OpenAI, recently published a thread that perfectly describes the moment we’re living in software development. According to him, we’re witnessing a genuine renaissance in software development, driven by AI tools that have improved exponentially since December.

The qualitative leap

The most striking part of Brockman’s thread is how they describe the internal change at OpenAI: engineers who previously used Codex for unit tests now see the tool writing practically all code and handling a large portion of operations and debugging. This isn’t an incremental improvement, it’s a paradigm shift.

A few days ago I was reading a fascinating essay by David Bessis that made me think deeply about something we all take for granted: intelligence. Bessis, a mathematician and author of Mathematica: A Secret World of Intuition and Curiosity, presents a thesis that challenges many of our deeply held beliefs about the origin of cognitive differences between people.

What’s most interesting about his approach is not so much the conclusion -which I’ll get to- but the path he traces to get there, a path that mixes mathematics, neuroscience, and a good dose of personal experience.