thomas vilhena

This blog is on the Small Web

Wed, 18 Mar 2026 16:00:00 +0000

I was browsing Hacker News yesterday and saw a post titled Kagi Small Web ranking high on the front page. Curiosity got the better of me, so I clicked through. I ended up spending some time there just jumping through random posts comprised of actually interesting stuff written by real people, not the usual SEO-optimized or AI “slop” we see everywhere now.

Then I did a bit of digging. It turns out, this blog is on that list too 🙂

What is this list?

I went over to their GitHub repository to see what was going on. As of today, the smallweb.txt file is comprised of 34,492 blogs and personal websites. It’s basically a very large, curated index of a (more?) “human” internet.

If you’re wondering how a site gets included, they have a specific set of rules:

Non-Commercial: No intrusive ads, paywalls, or heavy affiliate marketing.
Human-Centric: Absolutely no AI-generated or LLM “spam” content.
Technical: You must have a valid RSS or Atom feed.
Recent-ish: The blog needs at least one post in the last 12 months to stay in the index.
Personal: It favors personal diaries, niche technical deep-dives, and independent essays over corporate blogs or newsletters (Substack seems like a no-go).

Turns out, these criteria favor both better content and a better experience, exactly what I value.

Seven years of “Zero Maintenance”

I actually never submitted my blog to be included. It likely got picked up because I’ve been running this blog for seven years now, since 2019. I use Jekyll - don’t know if it’s still a thing, but it works.

The best part? Jekyll generates an RSS feed out of the box, which turned out to be one of the requirements for getting indexed by Kagi. I host everything on GitHub Pages, which I highly recommend. It’s free, requires zero maintenance time, and it’s surprisingly robust. It can handle a “Hacker News hug of death” without breaking a sweat whenever one of my posts accidentally hits the front page.

If you’ve been thinking about starting your own blog and you have some technical skills, you don’t need a complex setup / CMS. You could literally just clone my repo, restyle the layout, and set up your own domain on GitHub Pages for free.

Is the small web actually useful?

The original HN thread had some mixed feelings. A few people were underwhelmed by the current implementation, calling it “more like a curated blog ring than a discovery engine for the broader indie web.” Others were more optimistic, acknowledging that it’s a “good idea with a decent foundation.”

Personally, I just appreciate the small bit of recognition. In a world where every search result feels like it was written by a bot to sell me a mattress, it’s nice to be officially part of the “Small Web”, even more since I didn’t subscribe to be on the list myself.

Cheers! 🍻

Craftsmanship coding and the five stages of grief

Fri, 13 Feb 2026 15:00:00 +0000

If you’ve been reading recent Hacker News threads, you’ve probably noticed a recurring tone: a recurring mourning for “craftsmanship” in software, for the clay-in-hands feeling of shaping code line by line.

Here’s some evidence:

“We mourn our craft”
“I miss thinking hard”
“I started programming when I was 7… the thing I loved has changed”
And, of course, existential dread about “slop” eating the internet

If we borrow the “five stages of grief” as a metaphor, it feels like part of our industry is hovering around depression. Not because people are lacking resilience, but because the change is structural, not cosmetic. And structural change hits identity.

The next stage is acceptance.

Not “AI will code everything,” but “AI will code most of it”, and in many teams, it already does. But what does that mean? Simply put, software engineers will delegate most tasks to AI.

Here’s some truth about professional software:

Most developer time isn’t cathedral-building. It’s digital plumbing.

It’s reading code, changing code, moving data between systems, integrating APIs, handling edge cases, and keeping production stable.

That’s exactly where “agentic coding” is already meaningfully useful, because it’s fast at the repetitive, low-cognition parts, and when you can verify outputs/diffs (with your own eyes) cheaply. So why not use it in this context?

But bear in mind: most tasks don’t mean most value. So at a minimum treat agentic coding as a great tool to delegate lower-value tasks so that you can spend more time on higher-value work.

A practical ladder (most to least delegable)

Work type	What agents are good at	Your job stays
CRUD	patterns, scaffolding, consistency	schema/constraints, tests, review
Data plumbing / transfer	adapters, ETL-ish glue, client code	contracts, failure modes, monitoring
Simple transformations / integrations	deterministic changes, refactors	golden tests, invariants, change safety
Algorithms (well-specified)	standard approaches + edge handling	spec, complexity targets, property tests
Architecture	exploring options, drafting designs	making implicit constraints explicit
High-assurance software	helping with review and test drafts	ownership, compliance, zero-tolerance gates

There are many levels of delegation; it isn’t (and shouldn’t be) all-or-nothing. The less complex, less sensitive, and more reversible a task is, the more you can delegate the bulk of the work and let the agent drive. At the other end of the spectrum: complex or high-stakes work where failures are costly and reversals are painful, you keep your hands on the wheel.

What I’ve experienced in real projects

When the codebase has clear boundaries and coherent architecture, agents can be genuinely productive. When it’s spaghetti code, agents degrade quickly and produce mediocre output, because the system itself has weak signals.

Starting projects from scratch with agentic tools is also possible, but usually harder. You can make it work, but only if you provide much stronger specs. The broader and more ambiguous the task, the worse the output variance.

In other words, agents excel when scope is narrower, objectives are explicit, and review is cheap. The best use cases are tasks you’d feel comfortable coding yourself: you can write clear instructions, verify results, and do small adjustments before shipping.

That’s where the efficiency gains are real.

So, how to stay ahead in an agentic world

It isn’t about typing faster. It’s about moving craftsmanship upstream.

When agents write more of the code, the “handmade” part doesn’t disappear, it relocates. Craft becomes the ability to shape intent into constraints, turn ambiguity into decisions, and build systems where correctness is the default, not a happy accident.

Acceptance is not surrender. It’s admitting that most work is plumbing, and choosing to spend your human attention where it compounds: on higher-value, higher-stakes tasks.

So I say embrace the new paradigm agentic tools enable, where specification and intent are ever more important, low-complexity tasks delegated in bulk, and we can leverage our time to focus on higher-level challenges.

Revisiting ChatGPT’s financial advice, 15 months later

Tue, 03 Feb 2026 13:00:00 +0000

In Oct/2024 I asked ChatGPT for a portfolio to endure a messy world (original post here). At that time I expected the Israel–Palestine conflict (on top of Russia–Ukraine) to be the main driver of financial uncertainty in the coming months.

Fifteen months later, the conflicts are still there, but the volatility came from a different menu: U.S. surprises, Trump’s tariff war, a U.S. strike on an Iranian nuclear facility, and most recently Maduro’s capture.

This post is my promised check-in: what would have happened if I’d followed ChatGPT’s financial advice? I re-ran the original constraints using a 2024 model snapshot, translated the output into a real ETF portfolio, and measured the results.

The portfolio setup

The original post suggested a broad allocation. To make it testable, I re-ran a prompt in the old GPT-4o model (via OpenAI’s API, specifically gpt-4o-2024-08-06 to avoid lookahead bias) to generate a concrete, investable portfolio, using the exact constraints from that post.

prompt

Construct a portfolio of stock indices, US bonds, corporate bond indices, and commodities, adhering to the following percentages:

50% Equities: Diversify across geographies and sectors (some growth-oriented, some defensive).

30% Bonds: Split between safe-haven government bonds and investment-grade corporate bonds.

20% Commodities & Alternative Investments: This portion can include gold, oil, and possibly some real estate or infrastructure investments that are less correlated with traditional assets.

Suggest only assets accessible to an individual investor via a US investment account.

Here’s the generated response:

response

Creating a diversified portfolio as per your specifications involves selecting specific ETFs and index funds that are accessible to retail investors. Here’s a suggested portfolio:

50% Equities

US Equities (25%)

SPDR S&P 500 ETF Trust (SPY): Covers large-cap U.S. equities.

International Equities (15%)

iShares MSCI ACWI ex U.S. ETF (ACWX): Provides exposure to large and mid-cap stocks outside the U.S.

Emerging Markets (10%)

Vanguard FTSE Emerging Markets ETF (VWO): Targets growth-potential markets.

30% Bonds

US Government Bonds (15%)

iShares 7-10 Year Treasury Bond ETF (IEF): Focuses on U.S. Treasury bonds, providing a safe-haven investment.

Corporate Bonds (15%)

iShares iBoxx $ Investment Grade Corporate Bond ETF (LQD): Offers exposure to investment-grade U.S. corporate bonds.

20% Commodities & Alternative Investments

Gold (10%)

SPDR Gold Trust (GLD): Direct exposure to gold prices.

Oil (5%)

United States Oil Fund (USO): Tracks the daily price movements of West Texas Intermediate (WTI) light, sweet crude oil.

Real Estate & Infrastructure (5%)

Vanguard Real Estate ETF (VNQ): Provides exposure to U.S. real estate investment trusts (REITs).

Considerations

Diversification: The selection covers multiple geographies, sectors, and asset classes, reducing risk through diversification.
Accessibility: All assets are available through major U.S. brokerages.
Liquidity: ETFs and index funds offer liquidity, making it easier to enter and exit positions.
Risk Tolerance: Adjust weights as needed based on individual risk tolerance and investment horizon.

Before investing, consider consulting with a financial advisor to tailor the portfolio to your personal financial situation and goals.

This gave me a realistic, investable snapshot of “what ChatGPT would have done” at the time.

The results (Oct 4, 2024 → Jan 27, 2026)

A couple of days ago I pulled the adjusted prices (dividends, splits, capital gains) from Yahoo Finance (e.g., GLD history) and calculated the ROI for each sleeve.

Asset	Weight	2024-10-04	2026-01-27	ROI
SPDR S&P 500 ETF Trust (SPY)	25%	564.43	695.49	23.22%
iShares MSCI ACWI ex U.S. ETF (ACWX)	15%	54.59	71.97	31.84%
Vanguard FTSE Emerging Markets ETF (VWO)	10%	46.56	57.64	23.80%
iShares 7-10 Year Treasury Bond ETF (IEF)	15%	92.01	95.98	4.31%
iShares iBoxx $ Investment Grade Corporate Bond ETF (LQD)	15%	105.48	110.81	5.05%
SPDR Gold Trust (GLD)	10%	245.00	476.10	94.33%
United States Oil Fund (USO)	5%	76.35	75.66	-0.90%
Vanguard Real Estate ETF (VNQ)	5%	90.63	90.39	-0.26%

Portfolio result: +23.74% over 15 months. Not bad.

Closing thoughts

Net result: the portfolio held up. Most of it came from a surprisingly good gold run, with stocks doing their job and everything else mostly hovering. That’s encouraging, since diversification did its job, and also a warning, because one lucky ingredient can dominate the outcome.

So: would you trust an AI to build your portfolio, or are you already using it (even if just as a second opinion)?

Scaling Decision-Making: Guardrails Beat Gatekeepers

Tue, 23 Dec 2025 18:00:00 +0000

I walked into a budget meeting expecting the usual spreadsheet tour: what went up, what went down, and where we should trim next year. We did that. But in the middle of the call, something else surfaced: we were debating how decisions should happen, not just what the numbers were.

Someone suggested a simple rule: any spend above a threshold should go to a committee for approval. It was well-intentioned, practical, and it looked good on paper.

My first reaction was: this won’t work.

Not because the threshold was too high or too low. But because the framing was off. It pushed strategy down to the operational level. It asked leaders across the company to act like mini-CFOs, to weigh trade-offs they don’t have context for. It created a system that depended on individual judgment instead of a repeatable path.

That’s the opposite of systems thinking.

Systems thinking

Systems thinking means you don’t fix outcomes only by giving people more decisions, you fix outcomes by designing the system that shapes decisions. If you want different behavior, you redesign the structure: the incentives, the sequence, the guardrails.

In practice, that means leadership has to do the hard part: define the path and remove ambiguity. The operation executes within that path.

So instead of telling everyone “spend less,” I prefer to ask: what are the rails that will naturally lead to better spending?

Enabling constraints (the rails)

That’s where enabling constraints come in. They are rules and flows that:

limit the decision space,
make the right choice the default,
without killing autonomy.

In our case, the first draft of the policy was “anything above X needs approval.” The system-thinking version was different:

First, internalize. If a request is about an external vendor, the first step is always to route it through the internal capability. Only if that path is exhausted does the approval flow even start. The point isn’t “protecting internal teams.” It’s reducing avoidable spend and fragmentation when the capability already exists, and escalating fast when it doesn’t.
Second, decide in the right moment. The worst time to approve a vendor is when the proposal is already on the table and the deadline is tomorrow. The flow needs to exist upstream, where the decision can be made calmly.
Third, separate strategy from execution. Teams should focus on delivery and client outcomes. Leadership should define guardrails with the people who run the work and monitor the system.

The difference is subtle but huge. Instead of asking people to make better decisions in chaotic situations, you reshape the process so the right decision is the easy one.

None of this eliminates judgment. It just moves judgment to the right layer: design the default path once, then let the organization run it repeatedly.

What I proposed

I proposed a lightweight “rail system” built around the reality of our operation:

Define the default path. For certain categories (vendors, external analysis, specialized work), the default is internal first. If it can’t be done internally, the request escalates.
Make the moment explicit. Add checkpoints inside the workflow where the request must be raised early, not when it’s already late.
Keep approvals simple. No ceremonies, no weekly meetings, no bureaucracy. Just clear inputs, fast review, and a decision trail. Clear inputs = scope, deadline, expected outcome, alternatives considered, and a rough cost envelope.
Define exception paths. Legal/compliance requirements, incident response, hard external deadlines, or unique expertise not available internally. If an exception applies, the flow skips steps, but still leaves a decision trail.

In other words: leadership designs the system; the team follows the rails.

Closing thoughts

This is not about being “tough on costs.” It’s about clarity. If you want a company to scale, you cannot rely on individual heroics or ad-hoc judgments. You need a system that consistently nudges people toward the strategic path.

And building those systems is not easy. You need to identify what should change, understand why the current structure enables the old behavior, visualize alternatives, and think through side effects, incentives, and how to earn buy-in from the people involved. That’s real work.

You know the rails are working when urgent approvals go down, repeat vendors consolidate, and lead time for “yes/no” decisions becomes predictable.

The easy thing is to outsource the problem to leaders who are already constrained in their day-to-day. “Just approve everything” sounds simple, but it’s naive to think that passing the burden downstream will solve the root issue.

Build the rails. Then let the train move fast.

Anecdotal evidence of increased coding productivity with AI

Wed, 02 Apr 2025 13:55:00 +0000

I have been using AI to help me code (and actually to help me do anything) for a couple of years now. More and more I keep seeing how it boosts my productivity.

When programming, I keep code suggestions minimal in the IDE and really like the chat interface for tackling coding tasks. Writing down the problem, its constraints, and the task goals in a structured way has, in my experience, shown really great results and visibly boosted my productivity. As a bonus, it has positively influenced the way I communicate about technical challenges with colleagues.

So today, I saved some time to share a simple example — the anecdotal evidence. My task was to implement the following feature in a section of our app:

Automatically compress uploaded images

It took 25 minutes from start to finish. If I hadn’t used AI, I estimate that it would have taken me about 2 hours to search references, write down the code, test, and review before finishing this task.

👉 That’s roughly a 5x speed-up in this particular case.

Here’s a quick overview of how I structured my workflow using ChatGPT (GPT-4o model):

Define the Problem: I started by clearly defining my task, which was to compress uploaded images automatically in two user flows.
Generate Code: I asked ChatGPT to create a method for compressing images to high-quality JPEG, providing contextual code from my existing project.
Integrate Changes: Next, I requested ChatGPT to modify two existing image upload methods, incorporating the new compression method.
Create Unit Tests: Lastly, I asked ChatGPT to write a unit test for the new compression functionality following existing testing styles in the project.

Let’s take a deep dive.

The Workflow in Detail

Initially, I reviewed the source code to understand the user flows I needed to change and to locate the image upload entry points.

After getting familiar with the codebase, I concluded that the project didn’t yet define a method to compress images to JPEG. I also found an ImageExtensions class that contained several methods for performing operations on images (e.g., Rotate, Resize, Generate thumbnail, etc.), which I decided was the right place to define the new compression method.

So, in my first prompt to ChatGPT, I asked it to create the compression method, passing along additional contextual information to ensure the generated code would be compatible with my project:

prompt

In C# I’m using the following code for resizing images:

using System;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Drawing.Imaging;
using System.IO;
using System.Linq;

public static Image Resize(this Image image, int newWidth, int newHeight, string url = null) 
{
    using (var newImage = new Bitmap(newWidth, newHeight))
    {
        foreach (var item in image.PropertyItems)
            newImage.SetPropertyItem(item);

        using (var graphics = Graphics.FromImage(newImage))
        {
            graphics.SmoothingMode = SmoothingMode.AntiAlias;
            graphics.InterpolationMode = InterpolationMode.HighQualityBicubic;
            graphics.PixelOffsetMode = PixelOffsetMode.HighQuality;
            graphics.DrawImage(image, new Rectangle(0, 0, newWidth, newHeight));
            var format = url != null ? GetImageFormat(url) : image.RawFormat;
            return Image.FromStream(newImage.ToStream(format));
        }
    }
}

Using the same referenced namespaces, how can I define a method for compressing images?

I want to compress PNG images into JPEG with high quality.

In its response ChatGPT correctly produced the following method (I’m omitting additional information and the usage sample also returned by ChatGPT):

response

public static Image CompressToJpeg(this Image image, long quality = 90L)
{
    if (image == null) throw new ArgumentNullException(nameof(image));

    // Set JPEG quality encoder
    var jpegEncoder = ImageCodecInfo.GetImageDecoders()
        .FirstOrDefault(c => c.FormatID == ImageFormat.Jpeg.Guid);

    if (jpegEncoder == null)
        throw new InvalidOperationException("JPEG encoder not found");

    var encoderParams = new EncoderParameters(1);
    encoderParams.Param[0] = new EncoderParameter(Encoder.Quality, quality);

    using (var ms = new MemoryStream())
    {
        image.Save(ms, jpegEncoder, encoderParams);
        return Image.FromStream(new MemoryStream(ms.ToArray()));
    }
}

I skimmed through the code, and it seemed to implement everything I requested, so I copied and pasted the generated code into my project’s ImageExtensions class.

I continued by asking ChatGPT to adjust two of my application user flows to use the new method, with additional considerations:

prompt

Now consider these two methods which handle Image objects:

    private string SaveCover(string coverName, Stream coverStream)
    {
        var path = GenerateImageName("covers", coverName);
        using (var img = Image.FromStream(coverStream))
        using (var stream = img.ToStream())
            return store.SaveObject(stream, path);
    }

    private string SaveIcon(string iconName, Stream iconStream)
    {
        var path = GenerateImageName("icons", iconName);
        using (var img = Image.FromStream(iconStream))
        using (var stream = img.ToStream())
            return store.SaveObject(stream, path);
    }

Check if the file name indicates that the image is PNG (or other uncompressed image file).
In case it is, call CompressToJpeg() and replace the name extensions to .jpeg.

As a result, both methods were modified as requested, and ChatGPT proposed a helper method IsUncompressedImage to be used by both methods in accordance with the DRY (“don’t repeat yourself”) principle.

Here’s the final code generated by ChatGPT for one of the methods after the introduced changes:

response

private string SaveIcon(string iconName, Stream iconStream)
{
    var isUncompressed = IsUncompressedImage(iconName);

    var finalName = isUncompressed
        ? Path.ChangeExtension(iconName, ".jpeg")
        : iconName;

    var path = GenerateImageName("icons", finalName);

    using (var img = Image.FromStream(iconStream))
    {
        var processedImage = isUncompressed ? img.CompressToJpeg(90L) : img;
        using (var stream = processedImage.ToStream(ImageFormat.Jpeg))
        {
            return store.SaveObject(stream, path);
        }
    }
}

Again, I reviewed the code and was happy with the proposed changes. After pasting it into my application code, everything compiled without any issues.

Finally, before closing the code changes, I wanted to create a unit test for the new CompressToJpeg method, so I sent another message to ChatGPT to create the test method analogous to another test in my project:

prompt

Now, create a unit test for the “CompressToJpeg” method. Follow the style below:

    [TestMethod]
    public void GetGeolocatedImageCoordinateTest()
    {
        var image = Image.FromFile(@"Resources\geolocated.jpg");
        var c = image.GetCoordinate();

        Assert.IsNotNull(c);
        Assert.AreEqual($"{-22.8939933776855}", $"{c.Latitude}");
        Assert.AreEqual($"{-43.1236000061035}", $"{c.Longitude}");
    }

The test should:

Load a @”Resources\Boots.png” image
Convert it to Jpeg
Assert that the compressed image size is less than 25% of the original image size

Don’t save the compressed image to disk.

And voilà, the unit test was correctly created according to my request:

response

[TestMethod]
public void CompressToJpegTest()
{
    var image = Image.FromFile(@"Resources\Boots.png");

    using (var originalStream = new MemoryStream())
    using (var compressedStream = new MemoryStream())
    {
        // Save original image as PNG to stream
        image.Save(originalStream, ImageFormat.Png);
        var originalSize = originalStream.Length;

        // Compress to JPEG and save to stream
        var compressed = image.CompressToJpeg(90L);
        compressed.Save(compressedStream, ImageFormat.Jpeg);
        var compressedSize = compressedStream.Length;

        // Assert that the compressed image is less than 25% of the original size
        Assert.IsTrue(compressedSize < originalSize * 0.25,
            $"Expected compressed size < 25% of original. Original: {originalSize}, Compressed: {compressedSize}");
    }
}

After pasting the new test method into my test class, I was able to quickly run it and confirm that it passed 🟢.

Once I finished the code changes, I performed a manual test to validate that the task was completed:

Figure 1. Upload request in Chrome's network tab

Success!

Wrapping Up

This was just one of many examples where AI tools can turbocharge the time it takes to complete manual code structuring and fiddly tasks. This task was a great candidate because it was mostly digital plumbing, relying on high-level operations (like JPEG compression) already provided by the underlying framework.

Several studies try to capture how much productivity AI tools can bring. At the end of the day, it all depends on how frequently and how well you use them in your workflows.

As with anything, usage brings experience, and we become better at identifying the best situations and strategies for extracting productivity from these tools. A naive approach of blindly using AI in everything may backfire.

My complete conversation with ChatGPT can be accessed in the link below:

https://chatgpt.com/share/67ed2912-af88-800b-835c-c0e0703a617f

Financial advice from ChatGPT? Let's give it a try!

Fri, 04 Oct 2024 21:00:00 +0000

I recently watched an interesting video titled How AI & LLMs are Shaping Financial Advice by MIT Professor Andrew W. Lo. In it, he discusses how LLMs could be used for tasks like analyzing financial reports and offering sound financial advice. He also touches on the challenges of oversight, trust and fiduciary duty, sharing his thoughts on how these issues might be addressed in the long run.

Right after that, YouTube suggested a news report from BBC about the Israel conflict in the Middle East, and that gave me an idea for an experiment. You see, we might be on the verge of an escalation in that conflict, and if it happens (I hope it doesn’t), I’m sure it’ll have a significant impact on the financial markets. I’m also sure that I’m not prepared for it, and that (again, if it happens) I’ll think in hindsight that I could have hedged against the real, though uncertain, possibility of escalation.

So in this experiment, I prepared a simple CoT (Chain-of-Thought) prompt to enlighten me about the possibilities ahead and advise me on what I could do. Let’s take a look at it below.

The prompt

If a conflict escalation occurs between Israel and Palestine in the Middle East, potentially involving Lebanon and possibly Iran…

1) What will happen to the global economy?

1.1) How might the global economy react if the conflict escalates further (e.g., involving the U.S.)?

2) Which currencies, commodities, bonds, and investments are likely to strengthen in this scenario, and which ones are likely to weaken?

3) How can I protect my capital in such a situation?

3.1) If the situation deescalates, what would be a balanced asset allocation strategy to hedge against both escalation and deescalation scenarios?

The purpose of this prompt is to first explain the typical impacts of conflict escalation on the global economy. Then, it analyzes the effects on an investor’s portfolio. Finally, it seeks advice on how to balance the portfolio, considering both the chances of escalation and de-escalation (essentially as a hedge).

I think with a little more effort, we could’ve made an even better prompt. But it’s friday so let’s give this one a shot and see what we get!

The reply

If the conflict between Israel and Palestine escalates, especially involving countries like Lebanon, Iran, and potentially drawing in global powers like the U.S., the global economy could be affected in several ways. Here’s an overview of what could happen, which investments might be impacted, and how you could protect your capital:

1. Global Economic Reaction to Conflict Escalation

If the conflict escalates into a broader regional war, the global economy could react in several ways:

Energy Supply Shocks: The Middle East is a crucial hub for global oil production. Any conflict that disrupts production or threatens the Strait of Hormuz (through which a significant percentage of the world’s oil passes) could send oil prices soaring. This would lead to inflationary pressures globally, particularly in energy-dependent economies.
Market Volatility: Investors might seek safer investments, leading to increased volatility in equity markets. Emerging markets could be especially vulnerable as they often rely on stable energy prices and foreign investment, both of which would be impacted.
Risk-Off Sentiment: Global investors tend to shift to safer, low-risk assets in times of uncertainty or geopolitical turmoil, which can affect multiple asset classes.

2. Impact on Currencies, Commodities, Bonds, and Investments

Strengthening Assets:

Commodities (Oil and Gold):
- Oil: Any conflict in the Middle East typically leads to a rise in oil prices due to potential supply disruptions. Energy stocks might see a boost as oil prices rise.
- Gold: Gold is traditionally viewed as a safe-haven asset during geopolitical tensions. Its price tends to rise when uncertainty or war escalates.
Currencies (USD and CHF):
- USD (U.S. Dollar): The U.S. dollar tends to strengthen during global crises due to its status as a reserve currency and safe haven. Investors flock to the dollar in times of geopolitical instability.
- CHF (Swiss Franc): Similar to the U.S. dollar, the Swiss franc is considered a stable, safe currency. It often appreciates during global turmoil.
Bonds (U.S. Treasuries, German Bunds):
- U.S. Treasuries: Investors tend to move into U.S. Treasuries during times of global uncertainty. This will likely lead to lower yields (higher prices) for these bonds.
- German Bunds: German bonds, considered some of the safest in Europe, are another place where investors might park capital during geopolitical crises.

Weakening Assets:

Equities (Especially in Emerging Markets):
- Stocks, particularly in riskier or emerging markets, are likely to decline as investor sentiment turns risk-averse. Even developed markets might face downturns as investors sell off riskier assets in favor of bonds or safer investments.
Middle Eastern Currencies (Israeli Shekel, Lebanese Pound):
- Currencies of countries directly involved in or geographically close to the conflict are likely to weaken. Investors may lose confidence in these currencies due to instability and fear of prolonged conflict.

3. Protecting Your Capital During Escalation

Increase Allocation to Safe-Haven Assets:
- Gold and Precious Metals: Allocate part of your portfolio to gold or other precious metals.
- U.S. Treasuries or Investment-Grade Bonds: Move towards high-quality bonds, such as U.S. Treasuries, or investment-grade corporate bonds to reduce risk and provide stability during market volatility.
- Hold More Cash in USD or CHF: Having more liquidity in safe-haven currencies can provide flexibility and safety as the situation evolves.
Energy Sector Exposure: Increasing exposure to energy stocks or commodities like oil could provide a hedge against rising energy prices during conflict escalation.
Diversification: Ensure that your portfolio is diversified across geographies, sectors, and asset classes to minimize exposure to any one region or sector impacted by the conflict.

4. Balanced Asset Allocation Strategy for Escalation and De-escalation Scenarios

If you want to hedge against both escalation and de-escalation scenarios, you can adopt a balanced asset allocation strategy:

Escalation Hedge:

Commodities Exposure: Maintain some exposure to commodities like gold and oil. In times of escalation, these would benefit from flight-to-safety dynamics and potential supply disruptions.
Safe-Haven Bonds: Allocate to U.S. Treasuries or other low-risk government bonds, as they would strengthen in the event of increased geopolitical risk.

De-escalation Hedge:

Growth-Oriented Equities: Once the situation deescalates, global equity markets may recover, particularly in sectors that are cyclically sensitive like technology, consumer discretionary, or industrials. Maintain some exposure to these equities to capture potential upside.
Emerging Markets Exposure: If tensions ease, emerging markets that were initially hit hard may rebound strongly, making them an attractive investment for growth in a de-escalated environment.

Overall Strategy:

60/40 or 50/30/20 Allocation: A traditional balanced allocation could work:
- 60% Equities: Diversify across geographies and sectors (some growth-oriented, some defensive).
- 40% Bonds: Split between safe-haven government bonds and investment-grade corporate bonds.
- 20% Commodities & Alternative Investments: This portion can include gold, oil, and possibly some real estate or infrastructure investments that are less correlated with traditional assets.

By maintaining a diversified portfolio that includes both risk-on and risk-off assets, you can protect your capital and remain prepared for both escalation and de-escalation of geopolitical tensions.

There was a mix of stuff a bit obvious and some things that were new to me in the reply. But hey, sometimes the obvious needs to be said, right? Overall, I thought the info was pretty impressive. Then again, I’m not a financial analyst, so I might be falling into the Gell-Mann Amnesia effect without even realizing it.

Closing thoughts

It was a fun, quick experiment, and I learned a thing or two about global dynamics. Even though I won’t be following this advice for practical reasons, the main goal was to share it openly and get feedback from some friends in the financial sector. I also want to let it sit for a while, maybe check back in a year to see if GPT-4’s advice was somewhat valuable or just generic/simplistic fluff.

Easy-wins for generative AI

Mon, 24 Jun 2024 19:30:00 +0000

I will start this post with a direct question:

What are the most useful generative AI-powered product features you regularly use?

Think about it for a while. The answer usually includes [1]:

Chat apps (e.g., ChatGPT, Google Gemini)
Media generation tools (e.g., audio, image, video)
Code generation extensions (e.g., GitHub Copilot, Code Whisperer)

These are indeed very useful! But weren’t we promised that generative AI would completely change every aspect of our lives? So why can’t most of us, specially non technical people, think of more examples to answer this question? The logical answer is that they aren’t that prevalent, yet.

To add more context, it’s not that no one is trying. We’ve all seen prominent companies investing significant resources to ride the generative AI bandwagon. However, many of them decided to chase home runs instead of easy-wins, and for that reason a lot of them failed [2].

So in this post, I’ll argue that to successfully adopt generative AI in your product, you should focus on easy wins rather than home runs.

But what is an Easy-win?

An easy win, also known as a “low-hanging fruit,” can be defined as any product feature that delivers significant value to the end user while having relatively low implementation complexity:

Figure 1. Prioritization matrix

This concept originates from the prioritization matrix, a tool that helps teams manage tasks more efficiently, reduce viability risks, and optimize delivered value.

It may seem obvious to target easy wins, but more often that not we get carried away chasing shiny objects and commit to poorly assessed challenges.

How to discover gen AI easy-wins?

Considering that you may already have a working product that customers use (and love!), you should look for opportunities to improve your product’s existing user flows to make them easier, faster, and more enjoyable.

If we go back to the start of this post we can see that the gen AI apps that we use more often are those that save us time, make us more productive. Focus on that, make your customers more productive. That’s valuable.

One way I like to think of generative AI, contrary to the belief that it’s a superintelligent being, is to consider it as a very competent intern — one that can receive generic instructions and carry out low cognitive complexity tasks with reasonable precision. So, in the context of easy wins, avoid assigning your competent intern tasks that are too broad in scope, overly complex, or demand extreme precision. Those aren’t easy wins.

Additionally, anticipate and prepare for imprecise results from generative AI. If you start with a zero-tolerance policy for errors, you’re likely to fail. Instead, design your solutions to support inexpensive review and regeneration cycles. This allows end users to easily assess the quality of the output and either accept it or quickly regenerate it if necessary.

Wrapping It Up:

Target existing user flows
Search for opportunities to make your users more productive
Adopt gen AI for low-cognitive, narrowly scoped tasks
Design for inexpensive review and regeneration cycles

A concrete example

I believe it’s important to provide a real world example to illustrate how these principles can be applied in practice. At MindMiners, we offer innovative web and mobile market research solutions. Our customers create surveys on our platform and collect responses from our proprietary respondents panel via a mobile app.

One of the most time-consuming user flows on our platform is the questionnaire creation process, so we decided to focus on improving it. A common low cognitive complexity task for survey creators is listing options for multiple-choice questions based on the question text. To streamline this, we added a button for generating options.

Here’s how it looks - And of course, we took the opportunity to add some marketing flair to the icon and label there 😉:

Figure 2. Question without options

Upon clicking this button, the platform constructs a simple prompt using the question text and requests a suggestion of options from the generative AI REST API. Once a result is generated, it is inserted into the frontend:

Figure 3. Question with AI generated options

If the end user is not satisfied with the results, they can easily and quickly regenerate the question options and even provide additional instructions, such as specifying the number of options.

Closing thoughts

In this post, I outline a strategy for identifying opportunities to leverage your existing product with generative AI. Instead of pursuing overly ambitious and sophisticated features, I advocate for starting with simpler yet highly valuable improvements. I present a concrete example of a technically straightforward feature that we have developed and that was very well received by our users, demonstrating the effectiveness of this approach.

Reference

[1] Ask HN: What are some of the best user experiences with AI?

[2] Every app that adds AI looks like this

Guidelines for addressing requests from colleagues

Mon, 16 Oct 2023 21:30:00 +0000

In the workplace we are constantly receiving requests from colleagues, and the more senior we get, the higher the demand for us. That’s natural and expected as we progress in our carrers and take on leadership roles.

The way we address these requests has a direct impact on how we are perceived within the company and in the collaborative work environment we want to foster. I see them as opportunities to exercise communication and leadership skills, share knowledge, give feedback and positively impact my team and the business.

Let’s take a look at how we can approach requests effectively, how seniority plays a role and analyze a few illustrative examples.

Guidelines

In a nutshell, our communication in these situations should be driven by the following guidelines:

Employ empathy and nonviolent communication
Promote a cooperative, trusting, and supportive environment
Empower colleagues’ autonomy
Advance colleagues’ technical skills
Focus on results

Before responding to a request, reflect on whether your communication meets most of the above criteria, and whether it doesn’t directly go against any one of them. If your communication is aligned with this, proceed with confidence.

Notice I deliberately highlighted ‘autonomy’, since I believe it plays a central role. In this context, it means that we should encourage our colleagues to seek solutions to their requests as autonomously as possible. It’s like the old saying: ‘Give a man a fish, and you feed him for a day; teach a man to fish, and you feed him for a lifetime’ (even though sometimes we’ll have no option other than give the fish - due to short deadlines, lack of experience of the courterpat, etc).

Seniority

Before heading to examples, a quick note on how the seniority level from our counterpart affects the way we communicate.

Junior-level colleagues require more care and attention in communication, as they are in an early stage of professional development and need the consideration and support of more senior colleagues to help them grow. Positive and constructive feedback should be given frequently, and we should push them out of their comfort zone, but in a healthy and considerate way.

In senior-to-senior relationships I encourage some friction. We need to have the courage to be honest with each other without beating around the bush, and trust in the maturity of our colleagues to receive feedback that is less polished, but constructive and insightful. This can speed things up and foster a more dynamic environment.

Examples

To illustrate below are examples of typical reponses we often give. The first sentence in red shows an inadequate response according to the guidelines. The following sentence in green shows a more appropriate response. It is important to note that there isn’t only one way to act in each situation, and depending on your background and leadership style, your communication will vary. Additionally, keep in mind that we’re examining scenarios in which junior professionals seek assistance from their senior counterparts.

A)

“Hi Alice, I don't have time to help you, I'm too busy.”

This is a cold response, if you reply like this a lot then you’re not making yourself available to your colleagues, creating the perception that the door to collaboration is closed.

“Hi Alice, unfortunately I'm very short on time today due to a priority activity I need to finish by the day's end. Is this urgent, or can we come back to this topic tomorrow? You can also check if Bill is available. Please keep me informed either way.”

This response shows adequate empathy, as it not only provides insight into your own situation but also expresses genuine interest in understanding the urgency behind the request. It further demonstrates cooperation by suggesting a schedule for assistance, possibly the next day. It also indicates alternative ways, such as exploring the availability of another colleague, possibly familiar with the subject, who could provide assistance.

B)

“Bob, you should be able to do this by yourself. Try harder”

This can be characterized as a harsh response, especially for people at a more junior level, as, it potentially brings an unfavorable judgment of the person’s ability, and closes the door to collaboration.

“Bob, kindly share what you've attempted so far, along with any unsuccessful attempts. This will help me grasp the context and offer more tailored guidance.”

This response aims to comprehend prior efforts through clear and well-crafted communication, naturally fostering the culture of autonomy valued within the company. It conveys the expectation that individuals have made an effort to address the issue independently before seeking assistance.

C)

“Hi Alice, look, I've explained this to you several times, do some research.”

Again, an example of a harsh response. Even though a subject may have been already discussed in the past, it’s essential to maintain an environment of trust and companionship by employing a more thoughtful communication.

“Hi Alice, I recall encountering this issue on multiple occasions in the past, and I believe that by revisiting our previous solutions, we can resolve it effectively. Please consider retrieving the approach we took when dealing with a similar situation, such as 'XYZ'. If you have any questions, feel free to reach out. I'm here to assist.”

Here, we assume an honest oversight without passing judgment, recognizing that we can sometimes struggle to recall past situations and apply them to new ones. With time and guidance, we can enhance this skill and progress. This presents a valuable opportunity to support a colleague’s technical development and foster their autonomy.

D)

“Bob, don't worry, I'll take a look and solve this problem by myself, I think it will be faster. I'll let you know when I'm done.”

At first glance, this response appears cooperative and results-oriented. However, it contradicts the autonomy guideline by depriving the individual who sought help of the opportunity to learn and grow from the challenge. This approach can inadvertently foster dependency, as the person may not acquire the skills to handle similar situations independently in the future.

Unless there’s a good reason to ‘hijack’ the problem, for instance due to a short deadline, the following approach is recommended:

“Bob, this is a very interesting problem. Let's discuss it, and I'll assist you in finding a solution. I anticipate it might arise in future scenarios, making it crucial to solidify this learning.”

Now we see the clear mentoring approach, emphasizing the development of colleagues and a forward-looking perspective.

Closing thoughts

The more senior a team member becomes, the higher the expectation for them to have a positive impact on the team and subsequently in the business, inspiring and pushing their colleagues beyond their comfort zones, and thus earning recognition as a leader among peers.

It’s far from easy; in fact, it’s quite challenging to assume the responsibilities of mentoring and take a prominent role within the team. Effective time management will be essential to strike a balance between safeguarding our personal time and remaining accessible to the team. This means prioritizing tasks, setting clear boundaries, and ensuring that our schedule allows for both focused work and availability to assist our colleagues. By efficiently managing our time, we can fulfill our leadership roles without becoming overwhelmed or unavailable when needed.

The leadership challenge, whether in a managerial or technical role, is substantial, but the personal growth it brings is truly worth the effort.

Setting up a reverse proxy using nginx and docker

Fri, 21 Apr 2023 15:30:00 +0000

A reverse proxy is a web server that sits between client devices and backend servers, receiving requests from clients and directing them to the appropriate server. The backend servers are shielded from direct internet access and their IP addresses are hidden, providing an additional layer of security.

Figure 1. A Reverse Proxy

Overall, reverse proxies are useful for improving security, performance, and scalability of web applications and services. They’re commonly used for load balacing traffic between any number of backend servers, and for SSL offloading.

In this brief post I provide a template for setting up an nginx reverse proxy using docker.

Docker-compose

This is a docker-compose file with two services, the nginx web server that will act as a reverse proxy, and a certbot agent for enabling SSL connections to it:

version: '3.3'

services:

  nginx:
    image: nginx:1.19-alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./volumes/nginx:/etc/nginx/conf.d
      - ./volumes/certbot/conf:/etc/letsencrypt
      - ./volumes/certbot/www:/var/www/certbot
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"

  certbot:
    image: certbot/certbot
    restart: always
    volumes:
      - ./volumes/certbot/conf:/etc/letsencrypt
      - ./volumes/certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

The nginx service uses the official Nginx Docker image with version 1.19-alpine. It maps ports 80 and 443 to the host machine, which allows incoming HTTP and HTTPS requests to be forwarded to the Nginx container. The volumes section maps three directories on the host machine to directories in the container:

./volumes/nginx is mapped to /etc/nginx/conf.d, which allows custom Nginx configuration files to be added to the container.

./volumes/certbot/conf is mapped to /etc/letsencrypt, which stores the SSL/TLS certificates generated by Certbot.

./volumes/certbot/www is mapped to /var/www/certbot, which is where Certbot writes temporary files during the certificate renewal process.

The certbot service uses the official Certbot Docker image. It also maps the same volumes as the nginx service. The entrypoint section specifies a shell command that is executed when the container starts up. This command runs a loop that sleeps for 12 hours before evaluating the renewal of SSL/TLS certificates using Certbot.

Now let’s see how each service is configured.

Nginx

Below you’ll’ find an nginx configuration file that sets it up as a load balancer and reverse proxy for the thomasvilhena.com domain:

### Nginx Load Balancer

upstream webapi {
	server 10.0.0.10;
	server 10.0.0.11;
	server 10.0.0.12; down;
}

server {
	listen 80;
	server_name localhost thomasvilhena.com;
	server_tokens off;
		
	location ^~ /.well-known/acme-challenge/ {
		default_type "text/plain";
		alias /var/www/certbot/.well-known/acme-challenge/;
	}
		
	location = /.well-known/acme-challenge/ {
		return 404;
	}
		
	location / {
		return 301 https://thomasvilhena.com$request_uri;
	}
}


server {
	listen 443 ssl http2;
	server_name localhost thomasvilhena.com;
	server_tokens off;

	ssl_certificate /etc/letsencrypt/live/thomasvilhena.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/thomasvilhena.com/privkey.pem;
	include /etc/letsencrypt/options-ssl-nginx.conf;
	ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

	location / {
		proxy_pass http://webapi;
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_set_header X-NginX-Proxy true;
		proxy_redirect off;
	}
}

The “upstream” section defines a group of servers to be load balanced, with three sample servers listed (10.0.0.10, 10.0.0.11, and 10.0.0.12). One server is marked as “down” which means it won’t receive requests.

The first “server” block listens on port 80 and redirects all requests to the HTTPS version of the site. It also includes some configuration for serving temporary files over HTTP which are required for the SSL certificate renewal process through Let’s Encrypt.

The second “server” block listens on port 443 for HTTPS traffic and proxies requests to the defined “upstream” group of servers. The “location /” block specifies that all URLs will be proxied. The various “proxy_set_header” directives are used to set the headers needed for the upstream servers to function correctly.

Certbot

Certbot requires two configuration files:

/volumes/certbot/conf/options-ssl-nginx.conf contains recommended security settings for SSL/TLS configurations in Nginx. Here’s a sample content:

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

/volumes/certbot/conf/ssl-dhparams.pem contains Diffie-Hellman parameters used for SSL/TLS connections. It is generated by running the following command:

openssl dhparam -out /etc/letsencrypt/ssl-dhparams.pem 2048

Here’s a sample content:

-----BEGIN DH PARAMETERS-----
MIIBCAKCAQEA3r1mOXp1FZPW+8kRJGBOBGGg/R87EBfBrrQ2BdyLj3r3OvXX1e+E
8ZdKahgB/z/dw0a+PmuIjqAZpXeEQK/OJdKP5x5G5I5bE11t0fbj2hLWTiJyKjYl
/2n2QvNslPjZ8TpKyEBl1gMDzN6jux1yVm8U9oMcT34T38uVfjKZoBCmV7g4OD4M
QlN2I7dxHqLShrYXfxlNfyMDZpwBpNzNwCTcetNtW+ZHtPMyoCkPLi15UBXeL1I8
v5x5m5DilKzJmOy8MPvKOkB2QIFdYlOFL6/d8fuVZKj+iFBNemO7Blp6WjKsl7Hg
T89Sg7Rln2j8uVfMNc3eM4d0SEzJ6uRGswIBAg==
-----END DH PARAMETERS-----

That’s it, now you just need to docker-compose up and your reverse proxy should be up and running ✅

The burden of complexity

Mon, 10 Apr 2023 16:30:00 +0000

Complexity is present in any project. Some have more, some have less, but it’s always there. The manner in which a team handles complexity can pave the way for a project’s success or lead towards its technical demise.

In the context of software, complexity arises from a variety of factors, such as complicated requirements, technical dependencies, large codebases, integration challenges, architectural decisions, team dynamics, among others.

When talking to non-technical folks, especially those not acquainted with the concepts of software complexity and technical debt, it can be helpful to present the topic from a more managerial perspective.

So I propose the following qualitative diagram that regards complexity as an inherent property of a software project, and simultaneously, a responsibility that a software development team must constantly watch and manage for being able to deliver value in the long run:

Figure 1. The Complexity Burden Diagram

From the diagram:

The Complexity Burden curve represents the theoretical amount of effort necessarily spent servicing complexity, as oposed to productive work. This is an inevitable aspect of software development and can manifest in various forms, including spending time understanding and working with complex code, encountering more intricate bugs and errors, updating depencencies, struggling to onboard new team members due to excessively elaborate designs, among others.
The Team’s Capacity line is the maximum amount of effort the team is able to provide, which varies over time and can be influenced by factors such as changes in the product development process, team size, and efforts to eliminate toil [1]. Additionally, reductions in the complexity burden of a project can unlock productivity, influencing the team’s capacity as well.
The Complexity Threshold represents the point where the team’s capacity becomes equal to the complexity burden. In this theoretical situation, the team is only allocating capacity towards servicing complexity. Value delivery is compromised.

With these definitions in place, let’s review the two colored zones depicted in the diagram.

The Improvment Zone

Projects are typically in the improvement zone, which means that the team has enough capacity to handle the complexity burden and still perform productive work. The lower the complexity burden, the more efficient and productive the team will be in delivering results. The team can choose to innovate, develop new features, optimize performance, and improve UX. It’s worth noting that doing so may result in added complexity. This is acceptable as long as there is sufficient capacity to deal with the added complexity in the next cycles of development and the team remains continuously committed to addressing technical debt.

The Degradation Zone

A project enters the degradation zone when the team's capacity is insufficient for adequately servicing complexity, adding pressure on an already strangled project. The team will constantly be putting out fires, new features will take longer to ship, bugs will be more likely to be introduced, developers may suggest rewriting the application, availability may be impaired, and customers may not be satisfied. The viable ways out of this situation are to significantly reduce complexity or to increase capacity. Other efforts will be mostly fruitless.

Closing thoughts

The concept of complexity burden can be a valuable tool for enriching discussions around promoting long-term value delivery and preventing a project from becoming bogged down by complexity, leaving little room for new feature development. It’s important to make decisions with a clear understanding of the complexity burden and how it may be affected.

It’s worth pointing out that if the productive capacity of a team is narrow, meaning if the proportion of the team’s capacity allocated towards the complexity burden is already too high, the team will find itself in a situation where continuing to innovate may be too risky. The wise decision then will be to prioritize paying off technical debt and investing in tasks to alleviate the complexity burden.

Even though they are related, it’s crucial to distinguish between the complexity burden and technical debt. The former materializes as the amount of (mostly) non-productive work a team is encumbered by, while the latter is a liability that arises from design or implementation choices that prioritize short-term gains over long-term sustainability [2]. A project can become highly complex even with low technical debt.

Finally, a project is a dynamic endeavor, and a team may find itself momentarily in the “degradation” zone in one cycle and in the “improvement” zone in the next. What matters most is to be aware of the technical context and plan next steps preemptively, aiming to maintain the complexity burden at a healty level.

Reference

[1] Google - Site Reliability Engineering. Chapter 5 - Eliminating Toil

[2] Wikipedia - Technical debt