How I work
Studying in Madrid. I learn machine learning by building.
Complete projects, from raw data to a served model: reproducible pipelines, inference APIs, monitoring. So nothing stays in the notebook.
I am an artificial intelligence and machine learning student. I found out early that courses alone were not teaching me what I wanted to know, so I learn by building: if the model works in validation but I cannot serve it, retrain it or monitor it, I have not fully understood it yet.
With that idea I have built, as personal projects, a credit risk platform with calibration and cost-based thresholds, a transformer from scratch in PyTorch, RAG assistants over documents, agents that write SQL, and a suite of open-source tools for ML workflows that is published on PyPI.
Madrid is my base. Right now I contribute at Cylstat and keep studying; I am interested in anywhere I can learn from people who know more than I do.
I do not have a fixed stack: I try to choose the tool for the problem. What I do try to keep constant is the method: understand the data before modelling, evaluate without leakage, calibrate, decide by cost, monitor.
Data before the model. Problem before the data.
My first projects taught me that most of them fail before they reach the model: a poorly defined goal, insufficient data or a metric that does not measure what matters. Starting from the real problem instead of the algorithm is the difference between a project that finishes and one that does not.
I try to apply the same standard whether the project is a tabular classification model, a RAG system over documents or an inference API. The domain changes, the rigour I aim for does not.
I lean on the mathematics behind ML — linear algebra, probability, optimisation — and on the engineering that turns a notebook into something that can run twice. I try to choose what each case needs, not the most complex option.
Mathematics first. Tools second.
I study with serious technical books before high-level courses: Mathematics for Machine Learning, Elements of Statistical Learning, Pattern Recognition and Machine Learning. That foundation matters when something fails and you need to understand why, not just tune hyperparameters.
That way of studying leaves marks: I prefer to understand what the model is doing before adjusting it blindly, I look for the simplest correct explanation and I am never reluctant to discard an architecture if the data does not justify it.
Madrid and its technical community fuel a lot of that curiosity. There is quiet satisfaction in building something that holds up to scrutiny from someone who knows more than you.
Deploying, not just demos. I want the model to hold up for real.
I learned to code by looking at what code does from the inside — what the optimiser does, how the gradient propagates, why preprocessing inside the pipeline prevents leakage. Today I use FastAPI, Docker, Prometheus and Grafana in my projects because I want to learn the part that comes after the notebook, not as README decorations.
When a project pushes me further — full CI/CD, version registry, drift monitoring, LLM fine-tuning — I take it on even when it is hard, because that is where I learn the most. When it does not, I do not force it. Complexity is a decision, not a flag.
Continuous learning. Open source. My own judgement.
I contribute to open source projects — Spanish translations for HuggingFace and FastAPI, technical answers in ML community forums, and I contribute at Cylstat. It is the most direct way to learn how serious software is built and to give something back to the projects I use every day.
I also publish my own tools: a suite of command-line utilities for ML workflows — train/test leakage checks, token counting, evaluation gates, serving — with tests, CI and releases on PyPI. Maintaining them is teaching me more than many courses did.
All my code is public. I would rather anyone be able to see how I do things and tell me where I am wrong: direct feedback is the fastest way to improve that I know.
If you want to talk data or ML, give me feedback or tell me about an opportunity — drop me a line.
Frequently asked questions
Personal projects, built end to end, where data is used to make a decision. Classification and regression models for tabular data (credit risk, churn), NLP with transformers (classification, extraction, semantic search), LLM applications (RAG over documents, SQL agents), and the MLOps side of my own models: inference API, versioning, CI/CD and drift monitoring. Everything is public on GitHub, with the code, the evaluation and the parts that did not work.
Studying. I am a student of artificial intelligence and machine learning, and alongside that I contribute at Cylstat and to open source projects (Spanish translations for HuggingFace and FastAPI, answers in community forums). The portfolio is where I put what I learn into practice: if I read about calibration, I calibrate a real model; if I read about drift, I set up the monitoring myself.
Yes. I am open to internships and first junior roles in data or machine learning, in Madrid or remote. What I can show today: end-to-end projects with public code, a suite of CLI tools published on PyPI with tests and CI, open source contributions, and the willingness to learn from people who know more than I do. Write to me through the contact form and I will reply.
Python as the base. scikit-learn and PyTorch for modelling, pandas for data, FastAPI and Pydantic for serving, Docker and GitHub Actions for reproducibility, Prometheus and Grafana for monitoring. For LLM applications: embeddings, vector stores and evaluation of the pipeline itself. That said, I try not to marry the tools: the problem chooses, not the habit.
Of course. They are published on PyPI and installable with pip, MIT licensed. Each one does one small thing well: checking leakage between train and test, counting tokens and estimating LLM costs, evaluation gates for CI, serving models. If you find a bug or have an idea, open an issue or a pull request. That kind of feedback is exactly why I publish them.
All of it is on GitHub: my personal projects at github.com/delcenjo and the open-source tools at github.com/jmweb-org. Every project on this site links to its repository, and the Open Source section documents each tool. I would rather show code than adjectives: if you want to know how I work, the repositories answer better than I do.
Five phases, no mystery. 1. Data and problem — understand the data, define the target variable and a metric that measures what matters. 2. Pipeline — preprocessing inside the pipeline, leakage-free cross-validation. 3. Modelling and evaluation — model comparison, calibration, cost-based threshold, per-segment error analysis. 4. Deployment — inference API, Docker, version registry, monitoring. 5. Documentation — README with decisions and results, so the project can be rerun without me. It is the method I am teaching myself to follow on every project, precisely because it is easy to skip steps when nobody is checking.
Please do. Feedback on any project or tool is the fastest way for me to improve: an issue on GitHub, a pull request or a message through the form all work. For collaborations, I am up for joining projects where I can contribute and learn — especially anything involving evaluation, data quality or taking models out of the notebook.
Because it forces me to do things better. A private notebook forgives everything; a public repository with tests, CI and a README that says what works and what does not forgives much less. It also lets anyone check what I claim: if this site says a project has drift monitoring, the code showing it is one click away. And honestly, the feedback I get from publishing is the best teacher I have.