I work on two things that turn out to be the same thing: field ecology, where I design the sampling and run the analysis, and the systems small businesses run on — inventory, point of sale, invoicing, field tooling. In both, the job is to measure something properly and then decide what to do about it.
I came to software from biology. That is where I learned that a number needs a defence.
Two kinds of repository.
Decision records for systems whose source code is private, because it belongs to the business that paid for it. What is documented is the reasoning: what I decided, what I rejected, and what each decision cost.
| Repository | What it is |
|---|---|
| specialty-retail-erp | A retail ERP in production: modules, domain model, and a consolidation refactor over live financial data |
| geospatial-survey-toolkit | Field tooling for a surveying practice: delivering software to non-technical users |
| geospatial-data-processing | Work in progress: where I'm learning Google Earth Engine, GIS, LiDAR and photogrammetry with AI assistants, including the Earth Engine work for my papers |
| ecological-data-analysis | Methods behind the manuscripts: Bayesian inference, prior sensitivity, simulated bias |
Reproducibility packages for my own research: data, analysis scripts and the figures each manuscript reports, so the analysis can be re-run. They are kept private until each paper is accepted — the journal uses double-anonymous review — and will be released with a DOI and the final citation, as the data accessibility statement of each paper requires. Four of them are ready: Bayesian capture-mark-recapture with its own MCMC sampler, microhabitat use, morphometrics, and population dynamics.
I build with AI assistants, and I say so. I define the problem, the data model and the architecture; I review, test and reject what does not hold up. The retail system is still in production at the business, which I am no longer part of. Some of the decision records exist precisely because a plausible AI suggestion was wrong for the domain, and the record says why. If the tools stopped being available tomorrow, the code is versioned, documented and tested, and I would go back to working the way I did before they existed.
I bind documentation to the code instead of promising to keep it updated. A post-commit hook flags documentation that has gone stale. A checker verifies that every citation from code to manuscript still resolves. A manuscript reads its numbers from generated JSON, so the text and the tables come from the same place. Three different projects, the same conclusion: anything maintained by good intentions drifts.
I meter what the models cost. Every LLM call in production logs tokens, latency and cost, priced from a maintained table, so cost per feature is a query instead of a surprise at the end of the month.
I plan for a dependency being gone. Optional integrations degrade instead of failing. One third-party integration has been broken in production for months, by design, with no user-visible failure.
I write down what a decision cost. Every record has a section for its downsides. A document that only lists benefits reads like marketing and makes the rest less believable.
I know where automation should stop. In the surveying tools the software flags anomalies and refuses to correct them: a field measurement is evidence, and the surveyor is the one qualified to judge it.
Validating against data held out of fitting. Propagating measurement error into anything derived from it. Separating precision from accuracy. Not reporting a figure without its uncertainty.
These are ordinary obligations in field ecology, where a population estimate without a confidence interval does not get published. They are less ordinary in commercial software, and carrying them over required no new technical knowledge — only the habit of asking, of any number: compared to what, and how sure are we?
I'm a PhD candidate in Natural Sciences at UNLP, aiming to submit in 2027, on the ecology and conservation of a Patagonian amphibian. I teach Zoology at the same faculty, and I am a certified ISO 9001 internal auditor. Those are not a parallel career; they are why the software looks the way it does.
Based in La Plata, Argentina. Open to on-site work in Buenos Aires and to remote roles, in training, field operations and data, and to research collaboration.
CV → · English and Spanish, PDF included · LinkedIn · Google Scholar · ORCID · t3.com.ar



