Alcides Fonseca

Introduction to AI Engineering

Alcides Fonseca — Sat, 30 May 2026 00:05:30 +0000

Luca Cavallin wrote a wonderful guide to AI Engineering for Developers. It covers patterns, infrastructure and introduces several concepts one ought to know (RAG, Agents, Prefix Caching, ReAct, LangGraph).

I see this as a starting point for any new graduate whose degree did not cover all of this stuff. Spoiler alert: the one I teach in does not. And it won’t any time soon. I’ll link to the post I am writing explaining why.

LLM April Inflection Point

Alcides Fonseca — Thu, 28 May 2026 22:40:20 +0000

I’ve called November 2025 the November inflection point because that was when GPT-5.1 and Opus 4.5, combined with their respective coding agent harnesses, got good—good enough that we’ve spent the last six months adapting to agent systems that can reliably get useful work done.
I think April 2026 is a new inflection point where the revenue implications of this have started to land, to the benefit of the frontier AI labs and with material impacts on the budgets of large companies.
We’ll know for sure how real this moment is when the S-1 documents for the upcoming Anthropic and OpenAI IPOs give us some real, audited numbers to get our teeth into.

— Simon Willison in I think Anthropic and OpenAI have found product-market fit

What if AI is more expensive than junior developers? Everything stays the same, but AI companies go bankrupt and the AI bubble bursts much earlier than expected.

Is this scenario so crazy? Simon spends ~2000$ per month, which is a reasonable cost of a junior developer in Portugal or another near-shore country. Now I’m sure he is more productive with those tokens than he would with a junior developer. In fact, he would be less productive given the cost of training. But developers can leave anytime, and it is a good idea to train new productive developers.

Of course LLM providers do not want the AI bubble to burst. To avoid it, they can just reduce infrastructure and training costs. No CEO will do that at the risk of losing the monopoly race to their competitors. So it’s a race to the bottom, aiming to become the last survivor. I wonder if this has happened in the past, and what was the role of nationalization in the process….

UK's NHS just got called to the principal's office

Alcides Fonseca — Sun, 17 May 2026 19:30:48 +0000

Private repositories can create a false sense of security.

Making code private is not an appropriate mitigation for lack of ownership, patching capability, or operational assurance, so systems that cannot be safely maintained should be remediated or retired.

Moving code from public to private as a substitute for investment in secure-by-design delivery, ownership and remediation is a warning sign because it reduces sharing and scrutiny, can slow coordinated improvement across government and suppliers, and does not remove the underlying weaknesses in a running service.

— Government Digital Service

It looks to me like a small group within NHS England have received a report showing some potential vulnerabilities discovered by Mythos. Rather than following their own internal guidance, they’ve over-reacted and slapped a blanket ban on coding in the open.
I fervently hope that this new guidance will encourage DHSC to bring NHS England into line with best practice. If not, perhaps GDS ought to reassert itself as the technical authority with power to veto a department’s incomprehensible decisions?

— Terrence Eden (ex-GDS) in GDS weighs in on the NHS’s decision to retreat from Open Source

I just love the role GDS has had in the UK digital infrastructure. Nowadays, government digital services are a critical infrastructure. Protecting it is a national responsibility and should be done with the proper resources.

In Portugal, I do not see a push towards open-source. There are a few exceptions but, in general, Portugal is lacking in developing in the open. I would love to spend time fixing bugs in the software I have to use.

We need this to come from the top. And proper resources to be spent in our infrastructure, which means paying competitive wages and hiring top talent to spread good practices to the rest of the government, like GDS did in the UK.

ArXiv introduces penalties on slop

Alcides Fonseca — Sun, 17 May 2026 09:47:34 +0000

If generative AI tools generate inappropriate language, plagiarized content, biased content, errors, mistakes, incorrect references, or misleading content, and that output is included in scientific works, it is the responsibility of the author(s). We have recently clarified our penalties for this. If a submission contains incontrovertible evidence that the authors did not check the results of LLM generation, this means we can’t trust anything in the paper. The penalty is a 1-year ban from arXiv followed by the requirement that subsequent arXiv submissions must first be accepted at a reputable peer-reviewed venue. Examples of incontrovertible evidence: hallucinated references, meta-comments from the LLM (“here is a 200 word summary; would you like me to make any changes?”; “the data in this table is illustrative, fill it in with the real numbers from your experiments”)

— Thomas G. Dietterich

Just like Github, arXiv is where anyone can upload their scientific outputs. There’s a minimal verification to prevent Spam, but arXiv was never about gatekeeping content. Until now.

As I mentioned before, reputation is more important than ever in an age where text (and voice) is being produced cheaply, financed by monopoly-inducing LLM factories at a loss.

If the goal of arXiv is to provide an open alternative to the gatekeeping of journals, what is the open alternative to the gatekeeping of arXiv?

Typography of the Future

Alcides Fonseca — Wed, 13 May 2026 09:47:08 +0000

We’ve already seen how Eurostile Bold Extended is spectacularly effective at establishing a movie’s timeframe. But if Eurostile isn’t enough, there’s more you can do to clarify your movie’s timeframe. I’d like to introduce you to six easy rules that are pretty much guaranteed to position your text firmly in the FUTURE.

— Dave Addey, in HOW TO MAKE YOUR TEXT LOOK FUTURISTIC

Wonderful description of how to take your typography 50 years into the future. But maybe it only works for 80is and 90ies kids like me.

LLM and Competency Impersonation

Alcides Fonseca — Thu, 07 May 2026 07:29:39 +0000

I have a colleague, a careful and intelligent person in a role that is not engineering, who spent two months earlier this year building a system that should have been designed by someone with formal training in data architecture. He used the tools well, by the standards by which use of the tools is currently measured. He produced a great deal of code, a great deal of documentation, a great deal of what looked, to anyone who did not know what to look for, like progress. He could not, when asked, explain how any of it actually worked. The work was wrong from the first day. The schemas, and more importantly the objectives, were wrong in a way that would have been obvious to anyone with two years in the field. Several of us did know. When opinions were voiced even as high as a V.P., he fought back. The room had been arranged in such a way that saying so was not a contribution; his managers were too invested in the appearance of momentum to want the appearance disturbed. The work will continue, in all probability, until it is shown to a stakeholder, and they decide not to invest.
This is the part of the phenomenon I find hardest to write about. The tool did not make him a worse colleague. It made him able to impersonate, for months, a discipline he had never trained in, and the impersonation was good enough that the institutional incentives all bent toward letting him continue. Perhaps it’s a failure of management, but I have been finding management to be so eager to embrace AI that they’re willing to accept the risk.

— No One’s Happy, in Appearing Productive in The Workplace

Why TUIs are back

Alcides Fonseca — Sun, 03 May 2026 22:31:35 +0000

Terminal User Interfaces (TUIs) are making a comeback. DHH’s Omarchy is made of three types of user interfaces: TUIs, for immediate feedback and bonus geek points, webapps because 37signals (his company) sells SAAS web applications and the unavoidable gnome-style native applications that really do not fit well in the style of the distro.

The same pattern occurred around 10 years ago in code editors. We came from the native editors of BBEdit, Textmate (also promoted by DHH), Notedpad++ and Sublime to Electro-powered apps like Atom, VSCode and all its forks. The hardcore, moved to vim or emacs, trading immediate feedback and higher usability for the steepest learning curve I’ve seen.

Windows

The lesson is clear: Native applications are losing. Windows is doing the GUI library standard joke. Because one API does not have success, they make up another one, just for that one to fail within the sea of alternatives that exist.

MFC (1992) wrapped Win32 in C++. If Win32 was inelegant, MFC was Win32 wearing a tuxedo made of other tuxedos. Then came OLE. COM. ActiveX. None of these were really GUI frameworks – they were component architectures – but they infected every corner of Windows development and introduced a level of cognitive complexity that makes Kierkegaard read like Hemingway.

— Jeffrey Snover, in Microsoft hasn’t had a coherent GUI strategy since Petzold

Since then, Microsoft has gone through Winforms, WPF, Silverlight, WinUIs, MAUI without success. Many enterprise and personal desktop application still rely on Electron Apps, and the last memory of coherent visual integration of the whole OS I have is of Windows 98 or 2000.

It turns out that it’s a lot of work to recreate one’s OS and UI APIs every few years. Coupled with the intermittent attempts at sandboxing and deprecating “too powerful” functionality, the result is that each new layer has gaps, where you can’t do certain things which were possible in the previous framework.

— Domenic Denicola, in Windows Native App Development Is a Mess

Linux

The UI inconsistency in Linux was created by design. Different teams wanted different outcomes and they had the freedom to do it. GTK and Qt became the two reigning frameworks. While Qt is most known for it, both aimed to support cross-platform native development (once upon a time, I successfully compiled gedit on Windows, learning a lot about C compilation, make files and environment variables in the process) but are only widely used in Linux land. Luckily, applications made in the different toolkits can look okay-ish next to each other, something that the different frameworks on Windows fail to achieve. How many engineer-hours does it take to redo the windows Control Panel?

Given the difficulty in testing the million different combinations of distros, desktop environments and hardware in general, most companies do not bother with a native Linux application — they either address it using electron (minting the lock-down), or they let the open-source community solve it self (when they have open APIs).

macOS

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface. Fast forward a few decades, and Apple is doing the ~~best~~ worst it can to break all the guidelines and consistency it was known for.

Now, Apple has been ignoring Fitts’ law, making resizing windows near-impossible (even after trying to fix it) and adding icons to every single menu. MacOS is no longer the safe heaven where designers can work peacefully.

Electron

Everyone knows that the user experience of electron apps sucks. The most popular claim is the memory consumption, which to be fair has been decreasing over the last decade, but my main complaint (as I usually drive a 64GB RAM MacBook Pro) is the lack of visual consistency and lack of keyboard-driven workflows. Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all.

Let us take the example of Cursor (but would be true for VSCode as well). If you are in the agent panel, requesting your next feature, can you move to the agent list on the side panel with just the keyboard? Can you archive it? These are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus. And over the last decade, developers have been forgetting to add menus to do the same things that are available in their application (mostly because the application is HTML within its sandbox). For the record, Slack does this better than the others, but it’s not perfect.

Restarting from scratch

Together with Dart, Google wanted to design a new operating system, without all the legacy of Android, for new devices. It wanted a fresh UI toolkit (Flutter UI) but Google gave up on the project before a real product was launched. It’s one of those situations where having a monopoly (or a large enough slice of the market) is required to succeed.

Meanwhile, Zed did the same thing in Rust: they designed their own GPU-renderer library (GPUI) which is cross-platform. Despite the high-speed, it lacks integration with the host OS on itself, requiring the developers to add the right bindings. Personally, I would rather have a slow renderer that integrated with my OS than the extra speed.

TUIs

TUIs are fast, easy to automate (RIP Automator) and work reasonably well in different operating systems. You can even run them remotely without any headache-inducing X forwarding. When the native UI toolkits fail, we go back to basics. Claude and Codex have been very successful on the command-line: you focus on the interaction and forget about the operating system around you. You can even drive code and apps on cloud machines, or remote into your GPU-powered machine from your iPad. TUIs are filling the void left by Apple and Microsoft in the post-apocalyptic world where every application looks different. Which is good if you are doing art (including computer games), but not if your goal is to get out of the way of letting the user do their job.

What’s next

A checkbox is also part of an interface. You’re using it to interact with a system by inputting data. Interfaces are better the less thinking they require: whether the interface is a steering wheel or an online form, if you have to spend any amount of time figuring out how to use it, that’s bad. As you interact with many things, you want homogeneous interfaces that give you consistent experiences. If you learn that Command + C is the keyboard shortcut for copy, you want that to work everywhere. You don’t want to have to remember to use CTRL + Shift + C in certain circumstances or right-click → copy in others, that’d be annoying.

— John Loeber in Bring Back Idiomatic Design

We need to go back to the basics. Every developer should learn the theory of what makes a good User Interface (software or not!), like Nielsen, Norman or Johnson, and stop treating User Design as a soft skill that does not matter in the Software Engineering Curriculum. In any course, if the UI does not make any sense, the project should be failed. And in the HCI course, we should aim for perfect UIs. It takes work, but that work is mostly about understanding what we need. The programming is already being automated.

Operating systems and Toolkits authors should drive this investment. They should focus on making accessible toolkits that developers want to use, and lower the barrier to entry, making those platforms last as long as possible. I do not necessarily argue for cross-platform support, but having one such solution would help reduce the electron and TUI dependency.

Hanna Fry on (OpenClaw) Agents

Alcides Fonseca — Sat, 02 May 2026 09:04:05 +0000

A good explanation for the lay man or woman.

You probably don't need git worktrees

Alcides Fonseca — Thu, 30 Apr 2026 10:44:29 +0000

I have been trying to debug why Claude (and Cursor) often skips running “git pre-commit hooks”, despite being in the Claude.md. I have to remind it every prompt, and even then it fails to run them. They only show up in CI, failing immediately (without running the test-suite). Now, this is also happening to the Dragonboat team and I know it’s not a me-problem.

One of the things that I changed during this debugging was to make each agent clone their own repo — our repos are quite small — and I’ve kept up with this practice, as there is no real advantage for me in keeping a centralized local repo. In fact, this way I am sure they don’t change the centralized database, potentially interfering with each other. In fact, I had some issues where agents would reuse branches, mixing different PRs together.

But worktrees have some significant limitations. Not least of which is that their dependence on hardcoded fully-qualified paths written into configuration files not only makes worktrees non-portable, but also makes them DOA for any kind of containerized development environment. The worktree.useRelativePaths option helps here, but as of this writing it’s still relatively brand-new (Git v2.48 released Q1 2025), and not available in the version of git you probably have installed on your host machine or any of your container images. On top of that, VSCode’s support for relative worktrees with devcontainers is experimental, totally undocumented, and (as of this writing) unreliable at best.

— Avdi Grimm in You probably don’t need git worktrees

I wasn’t aware of all of those disadvantages, but it is so easy and fast to clone a new version. And even if you want to work offline, you can just clone from another local repo, like I did in 2007 when there was no wifi on campus.

Now if you have a multi-gigabyte repo, you might think twice about skipping worktrees. But then you have bigger problems to worry about.

The impact of LLMs on the Software Economy

Alcides Fonseca — Thu, 09 Apr 2026 10:43:55 +0000

There are a few people I recommend following to understand what is going on with software development:

Martin Fowler is probably my best reference in software engineering, both from the low-level Design Patterns point of view (where he made his fame), to more processes oriented and the more recent AI impact on the development processes. Even academics would agree with me on this one.
James Governor (Redmonk) do a more industry-wide macro view of the software development trends. They advise big companies on what route to take, and they estimate the money involved in these new trends. I would hire them if I was running a SaaS or devtools-focused VC. I met James last year at LisbonAI, and there is a large contrast between his wacky style and the sobriety of his writing.
Simon Willisson has been the new person in terms of AI development. I follow Simon since before Django had a 1.0 release, and he has become the reference in terms of AI development. He even has a paid newsletter with less content. Simon focus more on the exploratory side, and less on the engineering side, although he has started to document agents design patterns.

The fourth spot on my Mount Rushmore is up for debate. Tim Bray would blog a lot about the organizational side of things, but has now retired from that. I used to love the writing of Steve Yegge, but I think he has drank too much of his own cool aid.

The new kid on the block for me is Mitchell Hashimoto. He has the technical background — Vagrant, Terraform and Ghostty — and he does not mind sharing his path.

Specifically, I think two of his recent blog posts were what every developer needs to read:

Historically, the effort required to understand a codebase, implement a change, and submit that change for review was high enough that it naturally filtered out many low quality contributions from unqualified people. For over 20 years of my life, this was enough for my projects as well as enough for most others.

Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change.

— Vouch, an open source tool to explicitly keep track of trust in open source repos.

Agents will more readily pick open and free software over closed and commercial. At the time of writing this article, this is an objective truth. Independent research labs running experiments on popular models have found repeatedly that under diverse circumstances, models pick open and free alternatives over commercial. So far.

— The Building Block Economy, which gives you a new perspective on the impact of LLMs on the software development economy and tooling.