Interesting articles and resources that resonate with my work.
Marcelo Cavazzoli explores how AI and 'steering intelligence' are transforming software creation, turning everyday users into makers, driving an explosion of custom and disposable software, and shifting value toward user distribution.
Martin Fowler reflects on his mixed feelings about AI and large language models, explaining that despite their practical utility, he dislikes interacting with them due to their uncanny conversational tone, confident hallucinations, and reflection of Silicon Valley culture.
So what then is left for us humans to do in the data work context? Many are defaulting to adding or curating context, ergo the rise of a context layer. I see even more talks about added Ontologies. Maybe you ask yourself, what is that even? Do we need all of it? This article is a primer about the context layer, the difference between a classical semantic layer contained in every BI tool, and an external semantic layer.
The last 12 months have been a bit of an odyssey learning how to build large production systems productively and effectively. This has required a lot of trial-and-error with development process, prompt and harness tuning, and custom tool development. We are biased towards human-operator-centric workflow that is intended to minimize the amount of code slop that lands in our repos. This requires each of us to remain engaged with the design process, architecture, and details of what we are doing, never delegating critical work to an autonomous coding loop.
But the hard part is not only technical. Every new integration improves the platform, while also increasing its operational and security complexity. That is why strong alignment across data, infrastructure, and security becomes essential. In the end, what makes this architecture valuable is not any individual service, but the fact that the whole system works together to turn raw data into something governed, understandable, and genuinely useful for the business.
CI cross-project no es “el mismo CI pero más grande”. Son dos responsabilidades distintas que en el monolito estaban fundidas y que Mesh te obliga a separar. La del consumidor: validar tu proyecto contra las interfaces de las que dependes. Y la del productor: no romper la interfaz pública de la que dependen otros. Gobernar el mesh es, básicamente, hacer que esa frontera entre proyectos sea exigible.
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.