Self-healing APIs, metric mapping, and asset allocation 💡
Monday Ideas — Edition #169
1) 🔒 Secure your AI-generated code
This idea is brought to you by today’s sponsor, Snyk!
AI coding tools boost productivity, but they also introduce new security risks. Join Snyk's new webinar to learn how to protect your AI-powered development 👇
Securing Vibe Coding: Addressing Security Challenges of AI-Generated Code
Thursday, August 28 at 11:00 AM ET
— with Snyk Staff Developer Advocate Sonya Moisset
You’ll discover how vibe coding is changing software delivery, the security pitfalls to watch out for, and practical strategies to secure AI-generated code at scale.
2) 🩹 Design self-healing APIs
We are still in the early days of having AI using our tools and APIs, but it’s already enough to see how different things behave vs traditional systems.
When regular software hits an error, it just fails. When AI hits an error, things get interesting.
AI can, proactively:
Retry with creatively modified parameters
Switch to alternative endpoints that might work
Infer the problem from error messages and self-correct
This adaptability is chaotic but potentially powerful, and our API design can take advantage of it.
Recent work by Pol Avec on AI agent error handling shows how descriptive error messages drive faster agent recovery than minimal machine-formatted responses. And Stytch found that APIs optimized for AI agents often work better for human developers too.
Traditional error response:
{"error": "Invalid date format", "code": 400}
AI-optimized error response:
{
"error": "Invalid date format",
"code": 400,
"hint": "Use ISO-8601 format: YYYY-MM-DD",
"example": "2024-03-15",
"alternativeEndpoint": "/v2/orders?date_format=flexible"
}
The difference? The AI can actually act on this information. It might retry with the correct format, try the alternative endpoint, or explain the issue to the user. So this is not just reporting errors — it is enabling recovery.
We explored how API design changes with AI in this recent piece 👇
3) 📊 Map metrics into actionable data
Many teams struggle at using engineering metrics because they seem too high-level. You can get from a big-picture diagnostic metric to an actionable improvement metric through a process called metric mapping:
Start with your high-level metric — for example, Change Failure Rate.
Think about the boundaries of this metric — what is the big idea of what the metric is trying to capture? What are the starting and ending points of any processes it measures, and does it include any sub-processes? What areas of your system would need to improve in order to influence this metric? What do developers think about it?
Define smaller measurements — the answers to these questions will give you smaller, more actionable measurements that are easier for teams to reason about, and more likely to be within the team’s control.
Let’s use Change Failure Rate as an example:
What is the big idea the metric is trying to capture? Software quality
What are the starting and ending points of any processes it measures, and does it include any sub-processes? CFR is the result of a few different processes: local testing workflows, CI/CD, QA (if any), and is influenced by batch size, build speed, test flakiness, etc.
What areas of your system would need to improve in order to influence this metric? E.g. we know that our CI processes are slow and unreliable, we also work on really big changes most of the time, and we know that bigger changes are riskier to deliver.
What do developers think about the big idea? We can measure satisfaction with software quality to see if we’re heading in the right direction with all of these other interventions.
The hypothesis? If this team reduces batch size, improves CI flakiness, and increases satisfaction with quality practices, then Change Failure Rate will decrease. The improvement metrics give teams a clearer picture of where to focus.
We explored how to make metrics actionable with Laura Tacho in this recent article 👇
4) 🏦 Asset allocation for engineers
Surprisingly enough, one of the most popular Refactoring articles of all time is about… personal finance.
Nicola is one of the most knowledgeable people I know about this topic, and last year wrote a fantastic guest article on it.
Here is how he allocates his assets, and a bit of the thinking process behind it. Quoting him in first person:
⛑️ Emergency fund — 12 months of living expenses (with a family, I prefer to err on the side of caution).
🏦 High-yield savings account — 30% of my assets, currently earning a 4% interest rate.
🏖️ Retirement account — currently, I don't have one due to limited tax advantages in Italy.
📜 Bonds — 20% of my portfolio, offering returns comparable to high-yield savings accounts at present.
🌐 ETFs — 40% of my investments, diversified across various ETFs.
📊 Individual stocks — 5% of my portfolio, primarily in tech stocks like NVDA and AMZN.
🎉 Fun money — 5% allocated for high-risk investments like crypto and options trading.
The first thing I built was my emergency fund. While it's usually suggested to allocate money for 3-6 months of expenses, considering my personal situation (43, with two kids and living in an expensive area), I opted to accumulate liquidity for 12 months. This is deposited in a high-yield account, separate from my main one, currently giving me 4% yearly interest.
I keep 30% of my liquidity in a high-yield savings account where I can withdraw freely.
As I'm currently living in Italy, I decided not to have a retirement account. While you can save some taxes, the benefits are limited, and your money is locked up for a long time. This could vary based on your home country, so it's crucial to inform yourself about local retirement savings options.
Another 20% of my assets is in government bonds. I use these for planned expenses that I anticipate in the next 2 to 5 years (which is how I decided their expiry dates).
My risk tolerance is high enough that I'm prepared to see 50% of my assets potentially lose 40% of their value in a few days or months. That's why I decided to put them in ETFs, stocks, and also have some "fun money" for higher-risk activities like trading and cryptos. For ETFs in particular, I've automated the process, allocating a portion of my income every month to selected ETFs, which I rebalance periodically.
Remember, this allocation reflects my personal risk tolerance and financial goals. Your ideal portfolio might look different based on your age, career stage, and financial objectives. The key is to find a balance that allows you to sleep well at night while still working towards your financial goals.
You can find the full article below 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca
interesting stuff, @Luca Rossi