Building a system does not a habit make

The job market is difficult at the moment, which is well enough established that I don't think I need to argue the point, and it has been particularly difficult for me. I graduated with a degree in games design and found fairly promptly that there was nobody hiring for 3D modelling roles, and that the handful which did surface would have paid me at the level of a diploma holder. That was not something I was willing to accept for work of that intensity, because 3D is exacting and slow in a way that is difficult to appreciate from outside it, a single asset can absorb a week of your life before anyone else lays eyes on it, and being compensated as though the degree had never happened made the whole proposition rather hard to justify. In a better market I suspect the technical knowhow would have been given a chance to find its feet through experience. This is not that market, and in it the field of your study matters considerably more than your capacity to learn, so the degree that was supposed to open a door turned out mostly to describe one that was shut.

Marketing became the answer, or at least the pragmatic version of one. It had solid overlap with what I had already done, visual work, brand thinking, the technical side of getting things in front of people, and it was a field that would actually hire. But there was a clear issue waiting on the other side of that decision, which is that there are simply too many bloody jobs. Hundreds of them, from whatever which company, a great many disreputable or compensated poorly, and running underneath all of it the constant irritating barrage of internship listings when what I wanted was a position I could actually make a living from. Build a career with.

Automation, naturally, became my answer. If the problem was volume then the solution was filtering, so I pooled the job boards together and built something to do it. A web-hosted dashboard that ran a nightly pull of every currently available role into a local cache, filtered and rated the lot of them, and served the results to me as an email with recommendations attached. It ran on my own server, it ran while I slept, and it did precisely what I had asked it to do.

What I found quite quickly, however, was that building a system does not a habit make.

What it had actually created was a pile of applications of unclear veracity or value. Some of the roles it surfaced were rather weird, and a lot of them simply didn't feel suitable despite carrying high ratings, which is a specific and maddening kind of failure, the machine was confident and I was not, and there was no way to interrogate the gap between us. This was all solveable in principle by running it through an LLM. The trouble was the web interface itself, which gave me rather limited ability to modify or adjust the steering day to day. I had, quite literally, built my own version of LinkedIn, and it was serving me the same ineffectually sourced roles that were just noise.

That is the part worth dwelling on, because I think it generalises. The problem was never that the system wasn't clever enough, it was that the thing wasn't steerable, and a system you cannot steer is one you stop trusting, and a system you stop trusting is one you stop opening. The dashboard never failed loudly or threw errors at me, it just quietly became another tab I didn't click on.

So the question I actually needed to answer was how you create a habit, rather than how you create a pipeline, and my answer was to consolidate the whole thing into a workflow and a skill inside Claude Code. This solved for two separate vectors, the first being that by making it LLM-driven it required me to actually interact with the thing, which sounds rather like a downside and is in fact the entire point, since the interaction is where my judgement gets applied. More importantly, it could be considerably more deliberate about its ranking and about what it chose to put in front of me, because I could adjust that reasoning in conversation rather than in a config file I'd have to redeploy.

The mechanics run in two tiers, the first of which grabs all the roles and filters them down to a top twenty on title alone, which is cheap and gets rid of the obvious noise. The second pass pulls the full job description for each of those twenty and ranks them properly against two documents: a search brief, which holds the general goals and the direction I want to push the search in, and a master resume carrying my full work history. Ranking against both matters, because they answer different questions, the brief says what I would actually want and the master resume says what I would plausibly get, and a role needs to score on both to be worth an evening.

From those twenty it narrows down to five, and for each of them it optimises a basis resume built in JSON, which gets rendered through Reactive Resume, an open source resume renderer I use because it gives me the most flexibility when building new variants. That basis is then enriched with whichever parts of my full work experience are most relevant to the role in question. What lands in front of me at the end is five applications, already shaped, that I can read properly and adjust per role.

Five is not an impressive number and that is more or less the point of the exercise. Two hundred open roles is not two hundred opportunities, it is two hundred unresolved decisions sitting in your head, and they compound until a Sunday spent reading job descriptions produces nothing at all by Monday, whereas five is a number I can actually be deliberate about.

There is a principle underneath all of this that I have ended up relying on well beyond the job search. The data held inside a model is unreliable, not simply wrong now and then but unreliable in the more awkward sense that you cannot tell from the output whether it is recalling something true, something out of date, or something it has assembled to resemble the first two, and they all arrive sounding equally confident. So rather than asking the model to know things, I have got into the habit of supplying the things it needs and then constraining what it is permitted to do with them, and nearly every tool I have built in the past six months sits on one side or the other of that line. The brief and the master resume are supplied context, while the go/no-go scoring that happens before any tailoring work begins is a constraint, as is the rule that the click which actually submits an application stays human permanently, because that is the one thing here that cannot be taken back.

It is not finished, and I'd rather say so than pretend otherwise. Greenhouse, Lever and Ashby are straightforward to query, but the larger multinationals and the local banks sit on Workday and SuccessFactors, and both are a problem, the Workday adapter caps out at forty results with no location facet available, which makes filtering a global board down to Singapore a guess dressed up as a query, and there is no SuccessFactors adapter at all. Those companies are effectively invisible to the sweep and I check them by hand, inconsistently, which is exactly the behaviour the whole thing was built to get rid of, and I don't have a fix for it yet.

Which brings me round to why I am writing this down at all. I am looking for work, and the sort of work I am after is the sort of thing described above, building AI automation and low-code tooling, ideally somewhere with enough room to automate parts of the job itself. I am not a software engineer and I am not pretending to be one, though building working things without writing much code is hardly new territory for me, since games development runs heavily on visual scripting, Blueprints in Unreal and node graphs for materials, where you assemble logic out of boxes and wires rather than syntax. Going from wiring nodes together to orchestrating models turned out to be a much shorter step than it sounds. What I can do is understand AI and enough of how code works to build real tools through it, work out what actually moves the needle, and then automate the tedious parts away to buy back the time. This system is the clearest example I have of that, mostly because I built it for myself, and there is nowhere to hide when you are the only user.

Nathan Wong is in Singapore, building AI automation and low-code tooling, most of it self-hosted on an Unraid server called Obelisk. Portfolio