I just got my invire for entire.io, it is really cool, incredibly ui, easy cli. It does not track only what changed in the commit, it captures the entire session I had with claude, the prompt, answers, tool calls, token usage, top! I was mantaining a very naive tracker keeping the guids so I could return to a session, dont need it anymore. well, until they charge me an arm and a leg 🙂
https://github.com/sergiorgiraldo/entire101/
I am using ChatGPT since dec/22 and I showed to my son in that same month, I can say the boy turned into a llm master. Fast forward to aug/25, he asked if he should learn Python during his gap year and I said “for sure!” with all the enthusiasm to see your son doing smth you love 🙂 but …I know there is a growing assumption in technical circles that learning to code has lost its purpose, now that language models can generate working software from a short prompt, like my kid could do in a blink.
I stand by my suggestion and I read an article I loved about this clash of opinions. The argument treats coding the way we already treat mathematics or literature, as a discipline worth learning for what it teaches regardless of direct vocational payoff. The skills gained through the learning process extend well beyond syntax. Debugging teaches a structured way of isolating the source of a problem; composition teaches how small, well defined pieces combine into something larger; and the discipline of unambiguous instruction transfers to almost any field that requires clear thinking. These are meta-skills, in the sense that they remain useful long after any specific language or framework becomes obsolete. And with the added bonus of knowing to program 🙂
I could not have said better!
https://stevekrouse.com/learn-to-code
The developer Fernando Irarrázaval ran a public experiment where anyone could email his AI assistant and try to make it leak the contents of a secrets file, and the results clarify where prompt injection stands today. Over the course of the experiment the assistant received more than six thousand emails from over two thousand people, and not one of them succeeded in extracting the secret or triggering an unauthorized reply.The defensive setup was minimal; the system prompt contained only a few lines instructing the model never to reveal credentials, never to modify its own files, and never to execute code received over email.
The attacks covered the range of social engineering you would expect, including authority impersonation, fabricated incident response requests, fake compliance audits, and the same message rewritten across several languages to probe for weaker instruction-following outside English. And his defenses were effective to the point of non-exploitation.
I’ll push back a little. Given how consistently security researchers flag prompt injection as a real, unresolved risk for agentic systems, I don’t think one experiment, even if well-run and designed, should move anyone toward optimism. It shows a hardened model resisted attacks over email. It doesn’t show the problem is smaller than experts think.
https://www.fernandoi.cl/posts/hackmyclaw/
𝘉𝘢𝘤𝘬 𝘵𝘰 𝘉𝘢𝘴𝘪𝘤𝘴: go read Cal Paterson’s “An oral history of Bank Python”. It describes a class of software systems that run inside large investment banks, and it is a instructive case study on software architecture. You will probable start reading and thinking “wow, this does not seem right”. Until you realize the constraints that produced them.
Every system runs on limits, whether you name them or not, what’s allowed to change independently, what has to stay coupled, what the system will simply refuse to do, what trade-off you’re accepting today so you don’t have to relitigate it tomorrow. Good architecture isn’t the absence of constraints. It’s choosing the right ones, early, on purpose.
https://calpaterson.com/bank-python.html
Last Wednesday at the ING TownHall there was an interesting presentation about reducing toil, a lot of it was around automation. Next day I read this article from Austin and both events reminded me of this XKCD strip.
Austin is a Microsoft engineer and he describes what happened when he took a colleague’s advice to never do anything three times, meaning that any task performed more than twice should immediately be handed over to automation. He assumed he had very little left to automate, since most of his coding work was already delegated to AI agents, and he expected the remaining fragments to be too awkward or too specialized to bother with at all.
He was, in his own words, very wrong, and the particular way in which he was wrong is far more interesting than a simple story about a productivity gain. He automated all the obvious parts and this gain shifted the work he needs to do. It made visible all the non-parts, what he calls “the glue work that never bothered me before”.
When start hardcore automating stuff it may be a rabbit hole 🙂
This post from Amex reminded of my time at PagBank, we had a huge monolith there and we spent so much effort into converting it to a service architecture. The idea around a microservice, we all know, is about independency of the services leading to resiliency.
What makes Amex’s approach compelling is not the novelty of isolation as a concept ofc, since engineers have pursued fault containment for decades, but rather the discipline required to enforce it in practice. Cells in their design never span multiple regions, no transaction in the critical path waits on a synchronous call to another cell, and a global router sits at the edge to deterministically send each transaction to the cell that already holds the authoritative data it needs. Reference data such as currency rates and merchant category codes gets replicated into every cell well ahead of time, which means transaction processing never has to reach back to a central system of record while a customer is waiting on a response.
The trade off is honest and worth dwelling on, because cellular isolation increases operational overhead and architectural complexity, and it occasionally forces teams to duplicate services that a single shared implementation would otherwise simplify. Again, at Pagbank, we lived this, sometimes was a step back to make two upfront. For systems where the cost of a widespread outage dwarfs the cost of that added complexity, the exchange tends to be worth making, and the broader lesson generalizes well beyond the world of payments. Resiliency is rarely achieved through monitoring and retries alone, it is achieved by defining clear failure boundaries and then enforcing them relentlessly through design decisions that the rest of the organization has to live with every day.
https://americanexpress.io/cell-based-architecture-for-resilient-payment-systems
Book recommendation: “The Proof in the Code: How a Truth Machine Is Transforming Math and AI” by Kevin Hartnett.
This is about the creation of the Z3 solver and how it drove the creation of the Lean programming language, such a fun and thoughtful reading. And the cherry on top is that Z3 was created by a Brazilian, Leonardo de Moura. In the WC mood, VAI BRASIL! 😀
The last 2 weeks we were flooded with posts about DeepSeek. I am not writing about DS, but it is related, I cant escape 🙂
This article is excellent to sharp your skills as an engineer. This is even more important as the AI world is moving rapidly towards an Open Source world, where we will have a plethora of options available.
Uber has introduced QueryGPT, a tool that leverages generative AI to translate natural language prompts into SQL queries, streamlining data analysis processes. With LLM’s, QueryGPT reduces query authoring time from approximately 10 minutes to 3 minutes. It is cool and impressive, what I found interesting are some restrictions and assumptions:
– “We introduced “workspaces,” which are curated collections of SQL samples and tables tailored to specific business domains”
– “Another issue we found was that it’s incredibly challenging to go from a user’s natural language prompt to finding the relevant schemas”
– “Allowing users to select the tables used in the query generation came up as feedback from some users who saw that the tables that were eventually picked by QueryGPT were not correct “
– “We’ve been experimenting with prompts to reduce hallucinations”
So, we still need to understand the problem space and come up with solutions tailored to our business, let alone don’t forget it will always hallucinate at some point.
I love December. Christmas, New Year, a week or 2 holidays, a look back at the year’s achievements and… AdventOfCode. AdventOfCode is an annual programming challenge consisting of puzzles that can be solved in any programming language. The event is aimed at people with different levels of programming skills and offers an opportunity to improve our skills and learn new techniques. Challenges are launched daily during the month of December until the 25th, at Christmas. There are always 2 problems and for each one solved you get a star.
I’ll be honest and say that until 2022 I solved some challenges but I was never consistent. This year I decided to take it seriously and by the 8th I had collected all 16 stars. And as I said above, I’m seeing it as a learning opportunity: every problem has an example with a solution, so here I am doing TDD, the classic red-green-refactor cycle; every day you download a text file as input and solve for each of the stars, so here I am with an automated template in node that generates a common structure of files and folders; Problems can be solved in several ways, so here I am calculating the performance of my solution and optimising; I’m publishing my answers day by day, so here I am commenting on my code so that my intentions are clear; As there is one issue per day, so here I am looking at each day as a release, I automated the generation of releases on Github using release-please.
My strategy every day has been the most naive, I try to solve everything by brute force. When it takes too long, I stop and think of something better. If it’s acceptable (well, it’s quite subjective here, anything running in less than 3 minutes, ok), I send the answers and at the end of the day I revisit the problem and reflect on whether there’s a better way to do it. For example, one day it was necessary to calculate paths using a map with instructions. My first approach was with a loop, after solving it I realised that I could use the least common multiple of the different paths. Nice!
Let’s see if I can keep up with the issues, it’s been a lot of fun, I highly recommend it!