01 / Developer experience#
CDK deployment tool
WHAT I DIDI built a tool that finds changed CDK apps and deploys them in dependency order.
~60 → 15 minMeasured deployment time
Reduced deployment time by roughly 75%, from about an hour to 15 minutes.
AWS CDKGitDeployment tooling
Details+
Deploying every CDK app in a repository took about an hour. I built a tool that maps Git changes to apps, checks dependencies, and deploys only what needs to change.
- Added change-only deployment and diff commands.
- Replaced repeated Bash scripts with shared tooling and failure reports.
02 / Data & cost engineering#
WHAT I DIDI built a tool to assign S3 objects to projects, analysed old object versions, and tested tagging reliability.
~99% allocatedOne ~803 TiB dataset
Assigned roughly 99% of one 803 TiB dataset to projects. Separate analysis identified about $60k/year in potential storage savings.
S3 InventoryAthenaLambdaS3 Batch Operations
Details+
Project attribution
Storage ownership was unclear. I used S3 Inventory, Athena, Batch Operations, and Lambda to tag objects with their project. Objects without enough evidence stayed unallocated.
The process used version-aware manifests, dry runs, backups, and reconciliation. Existing unrelated tags were preserved.
Old object versions
Inventory analysis found about 1.56 million noncurrent versions using roughly 210 TiB. This identified an estimated $60k in annual storage savings, subject to archive or deletion decisions. It is an estimate, not confirmed savings.
Tagging reliability
Higher Lambda concurrency caused more processing failures in testing. Lowering it improved reliability. I also explored ECS workers for more control over request rates and retries; moving runtimes alone would not remove pressure on S3.
03 / Delivery & reliability#
WHAT I DIDI worked on a separate test environment, container releases, and database recovery across AWS accounts.
UAT → productionWork in progress
Tested database restores and documented the steps. Release changes and recovery targets are still in progress.
GitLab CI/CDOIDCContainersAmazon RDS
Details+
Database recovery
I worked on RDS restore tests across AWS accounts, using an isolated recovery environment, and documented the recovery steps. Recovery time and data-loss targets are still being defined.
Related deployment work
I also worked on shared deployment patterns: application repositories handle releases, while the platform manages infrastructure, permissions, and approval stages. The aim is to reduce manual steps and conflicting configuration changes.
04 / AI & developer tooling#
AI reviewer platform
WHAT I DIDI manage the infrastructure for an AI code reviewer, including credentials, CI configuration, and GitLab webhooks.
Service infrastructureOngoing work
Working on error handling, usage tracking, and setup instructions for more teams.
GitLabAI toolingService identity
Details+
The reviewer already had working GitLab hooks. My part is the service infrastructure: service accounts, API credentials, CI settings, webhook failures, and usage costs. Another engineer handles the model and review quality.
I kept the reviewer’s read-only restrictions and used dry runs when testing on real merge requests. Documentation and onboarding for additional projects are ongoing.
05 / Security automation#
Security ticket automation
WHAT I DIDI built an AI workflow that reads Wiz findings, checks the affected code, and drafts a ticket for review.
Approval before writesImplemented
Checks for duplicates and creates a Notion ticket after approval. Leaves Wiz and GitLab unchanged.
WizGitLabNotionAI agents
Details+
Investigating a Wiz alert meant finding the affected repository, checking ownership, and writing a ticket by hand. I connected Wiz, GitLab, and Notion to prepare that work.
- Read the finding and locate the affected repository or dependency.
- Check Git history for likely ownership and Notion for duplicate tickets.
- Draft a ticket with evidence and remediation steps.
- Create one Notion ticket only after human approval.