❤️ Pulse
A living snapshot of what I'm building, using, and working on. Updated monthly. Last updated: May 2026.
Now
What's actually occupying my time and attention this month. Not highlights. Not the reel. The real.
Building
Power of Smol is becoming something different from what I originally planned. Started as an AI literacy content brand. Now it's shaping into a consultancy — still rooted in AI literacy, still for people who didn't ask to become AI experts but have to figure it out anyway. The pivot feels right. I'm mapping what that actually looks like as a service before I say more publicly.
Project Chipmunk is underway. Can't say much yet, but it's connected to citizen science and community. If that phrasing means something to you, it might be worth watching this space.
Decoding Photosynthesis is my quiet obsession right now. I started pulling on a thread about quantum biology — specifically how plants might be using quantum coherence to achieve near-perfect energy transfer during photosynthesis — and I couldn't stop. So I turned it into a structured research project.
Living on GitHub: github.com/berniepng/decoding-photosynthesis. Updated as I go.
Learning
AIAP24 is in progress. The AI Singapore Apprenticeship Programme. Round two. I wrote about what AIAP23's rejection clarified for me — here. This time I'm in it. The work is harder. That's fine.
Completing the NTU Advanced Professional Certificate in Data Science and AI, finishing June 2026. The final stretch.
Quantum computing is on the reading list now too. Started because of the photosynthesis research, stayed because it keeps cracking things open.
Thinking about
What it means to build a consultancy when you're one person with too many interests and not enough hours. Whether that's a weakness or just an unusual kind of leverage. Still working that out.
The gap between what AI can do and what most organisations actually let it do. It's not a technical gap. It's a trust and translation gap. That's the space I want to work in.
Currently not doing
Taking on new freelance projects. Heads down on AIAP24, the NTU cert, and the consultancy foundations until the picture is clearer.
Find me on Bluesky or LinkedIn if something here resonates.
Uses
The tools, gear, and software behind my daily working environment. Honest opinions, no sponsorships.
Hardware
Apple MacBook Pro M4, 24GB RAM Primary machine for everything: pipelines, code, content, writing. The 24GB matters once you're running Docker stacks with Kafka, Spark, and multiple services simultaneously.
DJI Osmo Action 4 + DJI Mic Mini Camera and wireless mic for all video content. Most creators underinvest in audio. The Mic Mini fixed that at a price that made sense.
Nintendo Switch Lite (currently broken) Mostly for Animal Crossing. Someday.
Dev Environment
Google Antigravity — Agent-first IDE by Google, still in preview. The Manager view for running multiple coding agents in parallel is genuinely new territory.
VSCode — For when I want more direct control than an agentic environment gives me.
Anaconda — Python environment and package management. Keeps Jupyter notebooks and project dependencies from colliding.
GitHub — Version control and public portfolio.
Docker — Containerises my full data stack. Non-negotiable once you have multiple services running together.
Cloud and Data
Google Cloud / BigQuery — Primary cloud data warehouse. Serverless queries on tens of millions of rows without managing compute.
AWS Lightsail — Hosts my web projects. Chose it over EC2 deliberately: simpler, cheaper, does exactly what I need.
Meltano + dbt + Dagster — Full ELT pipeline stack. Ingestion, transformation, orchestration. Covers the lifecycle with proper lineage, testing, and dependency tracking.
AI Tools
Claude — Primary reasoning partner. Pipeline debugging, code review, writing, strategy. Most of my builds have Claude somewhere in the workflow.
Gemini / Antigravity — Secondary model and agentic IDE. Cross-checking, multimodal tasks, and parallel coding workflows.
Writing and PKM
Obsidian — Everything I'm learning, building, and thinking about lives here first. Organised by project and skill, queried with Dataview and Bases.
WriteFreely — Powers this blog. Plain Markdown, no algorithmic feed, no metrics. Exactly what a personal blog should be.
Content
DaVinci Resolve — Video editing. Cut and Edit pages only. No subscription required.
Notion — Content management for Power of Smol. Four linked databases: calendar, ideas, drafts, published.
Curious about a specific tool or a decision I made? Ask me on Bluesky.
Work
Deep dives into selected projects. Not just what I made, but the decisions behind it, what worked, what didn't, and what it proved.
Ollama File Renamer
Type: CLI Tool / AI Tooling · Solo project · Year: 2026 Year: 2026
The problem: Asking a frontier model to rename files is like hiring a senior consultant to move boxes. The capability is there, but the cost-to-task ratio makes no sense. And remembering bash syntax or regex just to clean up a folder is friction most people don't need.
What I built: A local CLI tool that takes plain English instructions and renames files using a locally running LLM via Ollama. You describe what you want — “replace all spaces and dashes with underscores” — and the tool sends your file list plus that instruction to whichever model you have running. It returns a rename plan, shows you a preview table, asks for confirmation, and executes. No cloud. No API costs. No data leaving your machine. One line in the config to swap models.
Decisions worth noting: The confirmation step before every execution is deliberate and non-negotiable. LLM output is non-deterministic — the preview table is the actual safety net, not the system prompt. The script also only ever calls os.rename(). There is no delete or destructive operation anywhere in the code, so even a badly worded instruction can't cause irreversible damage.
What it proved: That the right use of a frontier model is often to build the tool once, then hand execution off to something local and free. Claude wrote the code. Gemma runs every rename job after that. That's the division of labour that actually makes sense.
Stack: Python · Ollama · Rich · requests
EverySong: Music Discography Explorer
Type: Full-Stack Web / Data Engineering · Solo project · Year: 2026 Year: 2026
The problem: Music discographies are scattered across Wikipedia, fan wikis, and Discogs. No single place lets you browse a complete catalogue — album tracks, B-sides, solo work, collaborations, bonus discs, and soundtracks — in one filterable, searchable view. Streaming platforms don't solve this: they're optimised for discovery, not completeness.
What I built: A self-hosted discography explorer with a full data pipeline behind it. Discography data is researched from authoritative sources (Wikipedia song lists, Discogs, official fan wikis) and compiled into version-controlled CSVs. Custom Node.js seed scripts parse and load the data into SQLite, fetch album art from the iTunes Search API at runtime, and cache URLs in the database. The Express server renders artist gallery pages with filterable views by year, album, and performer, plus a search that spans song names, albums, and highlight notes. Currently catalogues BTS (386 songs, 2013–2026) and Pet Shop Boys (350 songs, 1984–2025) — including material most databases miss: hidden CD-only tracks, mixtape tracks, demo recordings from Further Listening reissue series, soundtrack scores, and fan club singles.
Decisions worth noting: Used Node's built-in node:sqlite module rather than better-sqlite3 to eliminate native module compilation on the server — a deliberate tradeoff that makes deployment simpler without sacrificing anything meaningful at this data scale. Server-side rendering via EJS instead of a JS framework keeps the stack lean and the first-paint fast with no hydration overhead. GitHub Actions CI validates CSV integrity and DB seeding on every push.
What it proved: That the data engineering skills from the DSAI4 coursework transfer directly to personal projects — schema design, seed scripting, query optimisation, CI pipeline configuration — outside the structured environment of a capstone. And that building in public, with a proper README and documented data sources, is a different discipline from just shipping something that works.
Stack: Node.js · Express · SQLite (node:sqlite) · EJS · iTunes Search API · nginx · PM2 · AWS Lightsail · GitHub Actions
CityCycle London: Bike Rebalancing Intelligence Pipeline
Type: Data Engineering / Machine Learning · Team: DSAI4 Module 2, Team 2 · Year: 2026
The problem: London's CityCycle network runs 795 docking stations. The core operational headache is rebalancing: stations run empty during morning commutes or overflow when everyone rides the same direction. Lost rentals, frustrated riders, expensive manual crew runs.
What we built: A full production-grade ELT pipeline, from raw data to operational dashboard, with every layer properly tested and orchestrated.
The pipeline ingests 32 million real rides from BigQuery via Meltano, transforms them through a 7-model dbt star schema with 56 schema tests, runs Great Expectations quality gates (30 pass, 4 warn, 0 fail), trains an XGBoost demand forecasting model (RMSE 2.4), and surfaces everything through a 5-page Streamlit operations dashboard and a Looker Studio executive report. Orchestrated with Dagster and GitHub Actions CI across 5 jobs.
Key finding: Three stations are in critical territory. New North Road Hoxton drains 90% of days with a net flow of 7 bikes per day. Without a pre-AM crew run, that station starts every morning short. K-Means clustering found three rider segments — Leisure 53%, Casual 32%, Commuter 15% — each draining stations in different directions at different times. One rebalancing schedule doesn't work across the network.
What I'd do differently: Add weather and event data as features from the start. The biggest gap in the XGBoost model is exogenous signals. A cold rainy Tuesday and a sunny bank holiday look identical to the current feature set.
What it proved: That a solo contributor can architect and ship a full production-grade data engineering pipeline, not just a notebook. Real stack. Real data. A tool an operations crew could use on a Monday morning.
Stack: Meltano · dbt · BigQuery · Great Expectations · Dagster · XGBoost · Streamlit · Looker Studio · Python · GitHub Actions
More case studies coming. Under The Hood and the Global Air Quality Pipeline will be documented here once the air quality pipeline is ready for public view.
If you're building in data engineering or AI and want to compare notes, find me on LinkedIn or Bluesky.