Notes from an ongoing experiment in shipping software with agents, data, and a lot of unfinished pages.

A technical overview of my first always-on Proxmox server: a Minisforum UM890 Pro running virtual machines, LXC containers, automation, agentic AI infrastructure, monitoring, and game servers—with a NAS, VLANs, OPNsense, media services, and dedicated AI hardware still planned.

A two-part data engineering project combining GCP architecture design, Terraform infrastructure, BigQuery, dbt Core, data-quality tests and GitHub Actions CI using the public Bitcoin Cash blockchain dataset.

I benchmarked LM Studio and Unsloth Studio inside a VM on my Minisforum UM890 Pro. The same Qwen3.5 model went from 13.01 to 22.24 tok/s, while Unsloth’s dynamic Q4 variant reached a 43.06 tok/s median—with enough variation to make that number slightly suspicious.

How I learned QGIS through real telecom problems at Orange, trained field teams with QField, and turned recurring geographic analyses into GeoPandas, Streamlit, and Folium applications for non-technical users.

A sarcastic but honest reflection on academic success, job-market rejection, impostor syndrome, and how failing to follow the expected path pushed me to launch Uncreative Projects and start building with data, AI, OpenRouter, and Paperclip AI.

I bought a Minisforum UM890 Pro to run local LLMs. It ended up hosting Proxmox, AI workflows, search tools, agents and three game servers—while still lacking the GPU power needed for the models I actually wanted.

From learning Java with BlueJ at 18 and reinstalling Linux seven times to building BI and GIS tools at Orange, running a homelab and experimenting with AI: this is the story of how I learned that being a developer is not about already knowing the answer.

Working Is Not the Same as Understanding During a technical interview, a Google Developer Expert in Data Analytics reviewed the Bitcoin Cash data platform I had built for a Data Engineer take-home challenge. The project used Terraform, BigQuery, dbt Core, and GitHub Actions. It was also my first time using Terraform. The review was positive. The reviewer especially appreciated how I had used AI. I did not let it complete the project for me. I used it to move faster through unfamiliar tools, then went back through the code, logs, and architecture until I could explain what most parts were doing. Most parts. When I was asked why I had configured the BigQuery permissions in a specific way, I could explain what the roles allowed, but not why I had chosen them. The honest answer was simple: I had let the AI decide. The reviewer explained that BigQuery separates compute from storage. A service account needs permission to create query jobs, but it also needs permission to read or modify the relevant datasets. The configuration worked. My understanding arrived later. We also discussed Terraform. I knew how to use to preview changes and to deploy them, but my state file was still stored locally. That may be acceptable for a small personal project, but not for a team. Shared infrastructure state should usually live in a secured remote backend so it does not depend on one person’s machine. He recommended that I learn more about Terraform’s , , and lifecycle, as well as dbt Cloud and its configuration system. The most useful part of the interview was not the technical correction. It was the direction it gave me. The engineers I spoke with were able to move between data analysis and data engineering depending on the problem. That is the kind of profile I want to build. My long-term goal is to become a data project manager, but I do not want to reach that role only knowing how to manage deadlines and meetings. I want practical experience in analysis, engineering, infrastructure, and delivery. I want to understand the work before I am responsible for leading it. This project showed me that AI can help me enter unfamiliar technical territory quickly. The review reminded me that a working system is only the beginning. The next step is being able to explain every decision inside it.

A small thank you to Dither UI I recently came across Dither UI, created by @grimcodes, and it immediately matched the visual direction I wanted for NotFinalDev. Because the library and my website use different frameworks, I could not integrate it directly. Instead, I built a small implementation inspired by its dithered aesthetic and adapted it to my existing Markdown publishing system. That currently includes dithered charts, step-based visual blocks and an editor that can insert editable JSON components directly into my notes and projects. It is only a modest adaptation, but it helped NotFinalDev feel much closer to the monochrome, technical public notebook I had in mind. Full credit to @grimcodes for the original library and the inspiration behind it.

Connecting the dots between dbt, BigQuery and Terraform I recently completed a technical take-home assignment that required me to build a small data platform using Terraform, BigQuery, dbt Core and GitHub Actions. I had already encountered most of these tools separately. The assignment forced me to understand how they work together as one system. Terraform defined the infrastructure and permissions. BigQuery stored the data. dbt transformed it into tested analytical models. GitHub Actions checked that everything still worked when the project changed. The part that taught me the most was IAM. Creating a service account is easy. Understanding which permissions it needs, where those permissions should be assigned and how dbt or a CI pipeline authenticates with it is where the architecture starts becoming real. I also gained a clearer understanding of the separation between staging models and data marts. They are not merely different folders containing SQL. Staging models prepare and standardize source-oriented data, while marts expose business-oriented models intended for analysis and reporting. I am not claiming to have mastered the entire stack after one assignment. But dbt, BigQuery and Terraform now feel connected rather than theoretical. I am preparing a longer article covering: The architecture I implemented The Terraform resources BigQuery datasets and IAM permissions The dbt project structure Staging and data-mart models Data tests GitHub Actions The mistakes I made A reusable playbook for future data-engineering assignments Sometimes the best way to understand a data platform is to be asked to build a small one from nothing.

Local AI Is a Necessity Local AI matters to me because I do not want large companies to have free access to my personal data, my family’s data, my code, or my private documents. Independence came first. That became more important as Windows pushed more telemetry, more accounts, and more cloud integration. I cannot stand the idea behind “you will own nothing and be happy.” I would rather own the machine, the model, the storage, the electricity bill, and the consequences of whatever I break while setting it up. Local AI is not only about privacy. It is also about leverage. Frontier models are becoming more capable, but most of the strongest systems are closed. We do not control their weights, pricing, availability, policies, or long-term direction. If open models and local infrastructure do not remain competitive, individuals and smaller companies will lose what little leverage they still have. I believe everyone should eventually have access to a local model for personal tasks. You do not need enormous compute to summarize documents, help with taxes, search private files, draft emails, organize notes, or handle basic everyday questions. These are also the exact tasks where privacy matters most. What matters to me is simple: private data; control over the model; predictable costs. I am willing to sacrifice electricity and setup time for that. Cloud models still win on context size, speed, availability, and raw capability. A local system does not need to beat them at everything. It only needs to become useful enough that privacy does not feel like choosing the worse tool every time. My definition of success is reaching a point where OpenAI, Anthropic, or any other external provider never needs to go near my codebase or private documents. The models can change. The hardware can improve. The stack can break repeatedly. But the boundary remains mine.

Autopilot Does Not Teach You How to Drive AI became useful before I had time to form a proper opinion about it. It simply arrived and became better than me at many of the programming tasks I least wanted to do. Mostly frontend code. I do not miss writing endless interface boilerplate. I am not nostalgic for moving a button twelve pixels, fixing one responsive layout, then breaking another one by breathing near the CSS. At this point, I see AI as something close to an IDE: not magic, not a replacement for understanding, but increasingly difficult to ignore if you want to work efficiently. The problem is that people exaggerate what AI can do because many of them do not understand machine learning or neural networks. The model does not understand the world the way we do. It produces its best guess and presents it with enough confidence to make us wonder whether *we* misunderstood the world instead. That is useful. It is also dangerous. I do not think AI teaches programming. Saying that would be like claiming autopilot teaches you how to drive. A tool is most beneficial when the person using it already understands the task well enough to recognize when the tool is wrong. Beginners should be careful with AI until we reach a point where programming concepts are universally understood and AI writes code the way a compiler translates a language into machine instructions. We are not there yet. Today, it can give you working code before you understand why it works, which is a very efficient way to borrow technical debt from your future self. Local AI matters to me for another reason. It is one of the few parts of the AI ecosystem that individuals can still build at their own scale. You can invest in hardware. You can run open models. You can experiment with open harnesses. You can create useful systems without owning a data center or having several billion dollars available for “research.” That matters because we should not allow a small group of wealthy companies to gain an irreversible advantage over the entire technology industry. Local AI is not only a hobby. It may be one of the best technical investments an individual can make right now. AI has probably made me ten times more productive. But that does not mean I now need to produce ten times more work. The weight of the work has shifted. Less time writing every line manually. More time deciding what should be built, checking whether it is correct, connecting systems, understanding consequences, and fixing the confident nonsense generated along the way. So the real challenge is not keeping up with AI’s speed. It is becoming at least twice as intelligent myself. Not by thinking faster. By developing broader knowledge and better judgment. Because the machine can generate more than I ever could alone. Someone still has to know whether any of it is a good idea.