A first note. Who I am, what this site is, and what software has to look like now that the language models are here.
I am Simon Rendón Arango. I write and ship software for a living, the kind that has to keep working when no one is watching. I grew up in Bogotá, studied systems and computing at Los Andes, came to London for a Master's at Imperial, and stayed. The day job is production AI. Everything else on this site got built around that.
Most portfolio sites are a CV with extra animation. I did not want one of those. I wanted a small public room, made by hand, with the work inside it and a place to talk about it that wasn't a slide deck. That is what this is.
The constellation is the centrepiece: a hand-drawn map of everything I have studied, built, and shipped, with the lines between the points meaning this led to that. Open it. CVs should look like that and don't.
The notes you are reading now are the new part. The point of them is freedom. A place I control, where I can put work in front of whoever ends up reading without asking permission, without a feed algorithm deciding the order, without a platform between me and the page. If a thing is worth writing down, it goes here. If a thing is worth showing, it goes here. The point is that I get to decide.
The constellation has the long version. The short version is three eras.
The foundations were in Bogotá. A bachelor's at Los Andes in systems and computing, and a thesis on Formula 1: race-winner prediction across seventy-plus years of grand prix history, a TensorFlow and scikit-learn pipeline that landed at roughly 93% winner accuracy by the end. The work taught me that systems engineering is a way of seeing, not a syllabus. I cannot un-learn it.
The London turn was a Master's at Imperial in software engineering, and a thesis on performance regression detection in HPC workloads on Nektar++. A dull-sounding name for a beautiful problem: when a long-running scientific simulation gets slower, can you tell which commit did it? Most of the time, no. With the right discipline of evaluation, sometimes. The discipline travelled with me.
The anchor is the current one. I'm a software engineer at Untap, building LLM-backed tooling for an investment management platform. Extraction pipelines, agentic RAG, MCP servers, the occasional fine-tune, and the full Java / React / GCP stack behind them. The work is technical; the constraint is taste, because almost any LLM-shaped thing can be made to seem to work in a demo. The job is to find the version that holds up after the demo ends.
There is also an orbit of side projects shipped in the cracks of those weeks: this site, the career graph, LFM, and a handful of smaller things. Some are quiet. The ones that are not, are not.
I work at the seam between systems and people.
The systems are concrete: retrieval, LLMs in production, evaluation harnesses, the parts of an AI product that have to keep their promises when a real user is in front of them. The people part is the harder one. What should the system do? What should it not do? How do you tell the difference? How do you ship something without losing the thread of why you started? Most of the work is in those questions. Almost none of it is typing.
When I describe the job to myself, the shape is this. Take a problem that wants an LLM. Design the pipeline that makes it tractable. Build the evaluation that proves it actually works. Harden it for the long tail of inputs that will never show up in a demo. The pipeline is the easy part. The evaluation is where the work lives.
The language models did not change how software gets built. They changed what software is for.
At the level of a single keystroke, the how is slightly different. You write less of the boring code. You read more code than you write. The cycle of try-it-out has gone from days to minutes. None of that is news.
What changed is the value of finishing. Prototyping used to be most of the work; now it is almost free. A working version of nearly any small idea can be coaxed out of a model in an afternoon. The first eighty percent has been crushed. The last twenty percent has gotten heavier. The part of software that was always the hard part, the part where the system has to keep working on a Sunday morning when nobody is watching, on inputs nobody anticipated, in the hands of users who do not read documentation, that part is now the whole job.
The model does not finish. It does not stay up to look at its own logs. It does not get paged. It does not notice that the demo is gaming the eval. It hands you something that runs once on a clean input and walks away. Whoever is left in the room when it walks away has to make the thing real.
The other shift is that taste is load-bearing now. When prototyping is free, the expensive part is choosing. What ships and what gets cut. What problem the product is even for. What the right size of the surface is. These were always engineering questions dressed up as someone else's questions. Now they are the engineering questions. The editorial muscle we used to outsource to writers and designers is, suddenly, table stakes for shipping software.
So I think the software of the next decade looks less like more code, written faster, and more like less code, decided harder. Smaller surfaces. Sharper claims. More restraint. More willingness to delete. The engineers who do well are the ones who can sit in front of something a model wrote and say, plainly, this is not good enough yet, and then know what to do next.
That is the work. That is what I am here for.
Two reasons.
One: I wanted a place I owned. I write code for a living, and one of the things code lets you do is build your own room on the open web. So I built one. No platform between me and whoever ends up reading, no algorithm picking what comes first, no permission to ask. The notes go here because here is mine.
Two: most of what I make never gets seen. The day job is the day job. Side projects scatter across other people's networks. This is the place where everything lands in one room, on my own terms, with my own typesetting and my own taste. If a thing is worth writing down, it goes here. If a thing is worth showing, it goes here.
If we end up working together one day, the notes are the early agreement. You have read what I think about software when nothing was on the line. No slide deck, no interview, no demo. The conversation starts somewhere other than zero.
Welcome.