Ruby Argentina met on July 23 at La Maquinita Innovation Lab in Buenos Aires. The night brought together two questions that tend to surface once an application (or a development workflow) gets serious: what does a convenient default cost us later, and what should we refuse to delegate?
The cost of being unique
Santiago Merlo from Rootstrap opened with “El costo de ser único” (“The cost of being unique”), a close look at what choosing a UUID as a PostgreSQL primary key actually changes.
UUIDs are useful when an identifier must be generated independently or when sequential IDs should not be exposed. But they are not free. Compared with a bigint, they take more space in tables and indexes; random UUIDv4 values also make B-tree indexes less dense and more fragmented. That affects writes, reads, joins, cache use, and the everyday work of inspecting data and logs.
Santiago benchmarked several approaches: integer keys, UUIDv4, UUIDv7, text IDs, and a hybrid model. UUIDv7 improved the insertion and fragmentation story substantially over v4, but it still carries the size cost. His practical preference was the hybrid approach: retain a numeric primary key for internal relations and use a separate UUID—or an encoded public ID—where an opaque identifier is needed. Hiding a sequential ID is useful, but it is not authorization.
The discussion also covered a less obvious Rails consequence: UUIDs do not preserve creation order. Code or tests that quietly rely on ORDER BY id can become intermittent and surprisingly difficult to debug.
Ay! Ahí hay AI!
After the break, SINAPTIA’s Patricio Mac Adden gave “Ay! Ahí hay AI!”, prompted by a client decision that landed close to home: reduce a development team and spend the budget on tokens instead.
Patricio used that moment to separate a few practices that are often lumped together. Autocomplete and chat assistants can help in small ways; coding agents can use tools and act on a repository; vibe coding can quickly produce a prototype, but its gaps are filled by a non-deterministic model. Generating code has become cheaper. Discovering that the generated code solves the wrong problem has not.
The alternative he explored was spec-driven development. First, make the intent and constraints explicit; then agree on a plan; then implement in manageable pieces; finally, verify the result. The artifacts can be simple Markdown files, as in the OpenSpec workflow Patricio has been trying. The point is not the framework, but reviewing the decisions before an agent turns them into code.
He also made the case for keeping an agent’s harness deliberately small. Claude Code and OpenCode are capable tools, but Pi starts with a much smaller set of tools and initial context; developers can add what a project actually needs instead of carrying every capability by default. Patricio also gave a special mention to Detritus, SINAPTIA’s deliberately small Ruby coding agent. We wrote about building and open-sourcing it in AI agents in Ruby: Why is it so easy?. The approach means less context to pay for and inspect, fewer assumptions made on our behalf, and a clearer answer to the question of what we actually need from the tool.
Thanks to Howdy for hosting, to Rootstrap, OmbuLabs, and SINAPTIA for supporting the meetup, and to everyone who joined the conversation. Keep an eye on Ruby Argentina for the next one.
