Ppl on Daffa Abhipraya

PPL: AI at Different Cognitive Distances [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks where AI was the primary productivity multiplier across very different task shapes. Week 1 leaned on iterative CI debugging (ten MRs of “run pipeline, read failure, ask AI, apply fix”) and integration-test infrastructure design. Week 2 leaned on bulk test generation (400+ mutation-killing assertions), bash-with-tricky-primitives design (a flock-based slot allocator), and cross-agent documentation research. The common thread across all six patterns: AI is best when the task is a known pattern applied to new context, and weakest when the task is about how primitives interact in a specific environment.

PPL: Code Review at Two Altitudes [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks of code review on teammate MRs. Week 1 (2-8 Apr) covered three substantial MRs: hl’s CSV import modal (!155), hl’s settings management system (!128), and qenthm’s ML risk scoring engine (!166) — 44 review points including 7 P0s. Week 2 (9-15 Apr) covered fadhliraihan’s AR Staff read-only client access (!171) and fernanda.nadhiftya’s communication history UI (!177) — 6 review points including 2 P0s caught through manual testing that static reading missed. Fifty review points total, nine P0s, reviews posted as threaded discussions on every MR.

PPL: Mutation Testing, From Setup to Score [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks on mutation testing across the SIRA codebase. The first week wired mutmut (Python) and Stryker (TypeScript) into the pipeline and uncovered the uncomfortable truth: 91% line coverage on the services layer translated to a mutation score just above zero in places. The second week closed that gap by writing 400+ targeted tests across two rounds, driving the API mutation score from ~66% to 80.3%. This blog tells the full arc.

PPL: Quality as a Feedback Loop [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks of quality infrastructure: wiring in the tools that measure test quality (week 1), then shortening the feedback loop so that signal actually influences the code being written (week 2). Starting state: 91% line coverage, no mutation testing, integration test coverage missing from SonarQube. Ending state: combined unit + integration coverage in SonarQube, mutmut + Stryker running per-MR with results in the CI comment, API mutation score 80.3%.

PPL: Security, From App Code to Supply Chain [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks of security work that span the whole stack. Week 1 (2-8 Apr) closed two OWASP A01 (Broken Access Control) gaps — one in our own code, one caught during a teammate’s code review — and added Sentry observability to Celery tasks so background job failures stop disappearing silently. Week 2 (9-15 Apr) patched a high-severity axios SSRF (GHSA-3p68-rc4w-qgx5) that pnpm audit caught in a routine MR pipeline. The pattern across the two weeks: fix boundaries in our own code, and keep dependencies patched via automated audit.

PPL: Separation of Concerns, Feature Code to Infra [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks of work that ended up demonstrating the same principle at two very different scales. In the application code: isolating invoice number generation as a pure function (SIRA-123, MR !130) and composing authentication onto GET endpoints via FastAPI dependency injection (SIRA-82, MR !154). In the infrastructure: designing scripts/ci-supabase-slot.sh (SIRA-274, MR !197) — a 110-line bash script that claims one of three parallel Supabase stacks and hands back an isolated environment to the caller. Different problem domains, same discipline: give each unit of code one reason to change.

PPL: Two Weeks of CI/Testing Discipline [Sprint 2, Week 3]

Wed, 15 Apr 2026 00:00:00 +0700

What I Worked On

Two weeks (2 April through 15 April) produced 25 merged MRs and roughly 40 commits, overwhelmingly CI and testing infrastructure with a handful of features and a security upgrade layered in. The work forms one continuous arc: wire mutation testing into CI → make it work on MR pipelines → write tests that actually pass the quality bar → shard the Supabase stack so CI runs three jobs in parallel. Every MR was mergeable on its own and every walk-back is visible in the commit log, not hidden with force-pushes.

PPL: Self-Hosted Error Monitoring with Custom Instrumentation

Sat, 11 Apr 2026 00:00:00 +0700

Error monitoring is one of those things that feels optional until the first production bug slips through unnoticed. A user reports “the page is broken,” you check the server, everything looks fine, and three hours later you discover a background task has been silently failing since the last deploy. This blog covers how we built monitoring that catches those failures before users do.

Note: Our project is hosted on an internal GitLab instance, so we use the term MR (Merge Request) throughout this blog. If you’re coming from GitHub, MRs are the equivalent of Pull Requests (PRs).

PPL: Communication and Knowledge Sharing [Sprint 2, Week 2]

Thu, 09 Apr 2026 00:00:00 +0700

Overview

Sprint 2 Week 2 (April 3 to 9) communication work centered on three substantial code reviews posted as GitLab discussion threads, merge coordination for 13+ teammate MRs, and Linear ticket management. The reviews caught several critical bugs that would have reached production, including a broken SQL join and an auth bypass.

1. Threaded MR Reviews with Severity Grading

Three MRs were reviewed this week, all following the same structured approach: positive callouts first, then issues grouped by severity (P0 blockers through P3 nitpicks), with code fix suggestions for every issue.

PPL: New Learnings Applied to SIRA [Sprint 2, Week 2]

Thu, 09 Apr 2026 00:00:00 +0700

Overview

Sprint 2 Week 2 (April 3 to 9) was dominated by a mutation testing sprint: setting up mutmut and Stryker in CI, building integration test infrastructure from scratch, and writing mutation-killing tests. The week also delivered three application features and a meta-level improvement to AI workflow. Each area required learning at least one technology or concept not covered in standard Fasilkom coursework.

1. Mutation Testing with mutmut (Python)

Mutation testing is a technique where a tool injects small faults (“mutants”) into your source code (flipping operators, changing constants, removing lines) and checks whether your test suite catches each fault. If a test fails, the mutant is “killed.” If no test fails, the mutant “survives,” meaning your tests have a blind spot.

PPL: Quality Gates That Actually Block Bad Code

Thu, 09 Apr 2026 00:00:00 +0700

Quality tools are useless if they are not enforced. Our project had SonarQube analyzing every commit, schema fuzzing running against our API, and load tests measuring latency, but every single one of them was set to allow_failure: true. Violations were silently ignored, real bugs slipped through, and nobody noticed because the pipeline was always green. This blog covers how we turned those advisory checks into blocking gates, built automated CI reporting so reviewers could actually see the results, and watched the tools catch a JWT vulnerability, a production crash, and 31 code quality violations that had been accumulating for weeks.

PPL: SOLID Principles in a FastAPI Invoice System

Thu, 09 Apr 2026 00:00:00 +0700

SIRA (Smart Invoice Reminder AI) is a system that automates invoice collection reminders. It monitors payment status, scores client risk using a weighted formula, and sends personalized reminders by email or messaging. The backend is built with FastAPI, Supabase (Postgres via REST), Celery for background jobs, and Redis as the message broker.

This blog walks through how SOLID principles shaped the architecture at three levels: the overall layer structure, service-level design patterns, and individual function design. The goal is not to explain what SOLID stands for (there are plenty of articles for that), but to show what it looks like in production code and why certain design choices were made over simpler alternatives.

PPL: When 91% Test Coverage Means Nothing

Thu, 09 Apr 2026 00:00:00 +0700

We had 91% line coverage and felt good about it. Then we ran mutation testing and scored 0%. Every line of our service layer was executed by tests, but almost nothing was actually verified. This is the story of how we discovered the gap between “code was run” and “code was checked,” and what we changed to close it.

Note: Our project is hosted on an internal GitLab instance, so we use the term MR (Merge Request) throughout this blog. If you’re coming from GitHub, MRs are the equivalent of Pull Requests (PRs).

PPL: Work Ethic and Commitment [Sprint 2, Week 2]

Thu, 09 Apr 2026 00:00:00 +0700

Overview

Sprint 2, Week 2 (April 3 to 9) output summary:

Metric	Count
MRs authored and merged	19
MRs reviewed (in-depth, threaded)	3 (44 review points)
MRs merged as maintainer	13+ (from teammates)
Commits	50+
Domains covered	5 (CI/CD, testing infrastructure, API features, documentation, infra)