Interesting articles and resources that resonate with my work.
The article is structured in four parts: (1) how to trust the outcome, (2) knowing what not to build, factoring in cost-per-token among others, (3) accountability of agents and the code they generate, and (4) philosophizing about the future of agentic engineering.
“If you don’t learn how to use AI, you’re going to be left behind.” So leave me behind.
If you’ve ever built a web application, you’ve almost certainly had to generate unique IDs. Maybe you needed primary keys for your database rows, or unique identifiers for API resources, or trace IDs for your logging pipeline. The two most popular choices today are UUIDs and nanoid, and both get the job done. But both come with tradeoffs that have bugged me for a while. Let me explain.
And slowing the fuck down and suffering some friction is what allows you to learn and grow. You can sleep well knowing that you still have an idea what the fuck is going on, and that you have agency. Your understanding allows you to fix the recall problem of agentic search, leading to better clanker outputs that need less massaging. All of this requires discipline and agency. All of this requires humans.
MCP servers do not scale efficiently. As the number of tools increases, all tool schemas are injected into the LLM’s context window before processing the user request. The traditional execution model worsens this inefficiency: each tool call requires a round-trip, with intermediate results repeatedly flowing through the context window, increasing token usage and reasoning overhead. The code mode pattern addresses both problems.
But code is the only interface that scales with AI. If you want to leverage the acceleration of LLMs, your stack must be defined in code.
Un fenĂłmeno como siempre. Cortito y al pie.
Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don’t save us time learning. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.
- Solid historical recap. - Thoughtful technical reasoning that weighs the pros and cons. - No strong bias.
Training a kid's ear before it's too late without being a native speaker
If you want to solve you self-service analytics problem, you need a data catalog. Now you have a data catalog problem and you forgot about the self-service analytics
Many ask themselves, "Why would I use a semantic layer? What is it anyway?" In this hands-on guide, we’ll build the simplest possible semantic layer using just a YAML file and a Python script—not as the goal itself, but as a way to understand the value of semantic layers. We’ll then query 20 million NYC taxi records with consistent business metrics executed using DuckDB and Ibis. By the end, you’ll know exactly when a semantic layer solves real problems and when it’s overkill.
The old data stack was built for hindsight. This one is built for foresight, action, and even autonomy. Welcome to the Postmodern Data Stack.
The article advocates for embracing AI in the data industry to drastically improve delivery speed, efficiency, and project success rates. It challenges outdated practices and resistance to change, highlighting how AI can accelerate tasks like data modeling, coding, and stakeholder alignment.
As data engineers, we spend countless hours combing through logs - tracking pipeline states, monitoring Spark cluster performance, reviewing SQL queries, investigating errors, and validating data quality. These logs are the lifeblood of our data platforms, but parsing and analyzing them efficiently remains a persistent challenge. This comprehensive guide explores why data stacks are fundamentally built on logs and why skilled log analysis is critical for the data engineer's success.
This paper provides an overview of the weaknesses of Eric Raymond's paper The Cathedral and the Bazaar as well as the more coherent demonstration of the fact that the bazaar metaphor is internally contradictive.
The founder of dbt is trying to establish the foundation for a general framework for a mature analytics workflow.