Not as an experiment, but as my production workflow.
An autonomy policy in three tiers
I ran agents under a written autonomy policy with three tiers. Tier one runs unattended: edits, tests, builds, read-only git. Tier two stops and asks: pushes, rebases, branch deletion, file removal, container lifecycle, deployment commands. Tier three never runs at all: recursive deletes, sudo, permission resets, hard resets, force pushes. A PreToolUse hook intercepts every shell command before it executes, so the boundary is enforced by the harness — not by my attention at two in the afternoon.
Containment at the OS level
Agents ran inside ai-jail, an OS-level sandbox: Linux namespaces (PID, UTS, IPC, mount), Landlock LSM for filesystem rules, seccomp-bpf blocking around thirty syscalls, resource limits, and a lockdown mode that unshares the network. On Windows, that means running under WSL 2.
The cost, stated plainly: inside the jail, .env files reached the agent blank. When a task needed environment variables, I stepped out of the sandbox for that task.
Worktrees, and the teardown nobody warns you about
Worktrees separate tasks; subagents parallelize inside one task. Different axes — I used both.
I wrote a skill that, from the main repository, creates a directory and a git worktree for each feature, fix or chore, with the branch already named. Each Claude Code session runs inside its own worktree, and that is what keeps sessions from colliding. The same skill handles teardown: before a worktree directory is removed, a script compares its .env against the main one and propagates anything added or changed back. The sync was a precondition of removal, not a background watcher.
Why that detail earns its place: .env is gitignored, a fresh worktree starts without it, and a variable created inside one dies with the directory. It is the kind of problem that only surfaces once you are actually running several fronts at a time.
Reconciliation happened by pull request. Conflicts happened too — two fronts touching the same file — and were resolved the way any developer resolves a git conflict. A worktree doesn't eliminate conflict; it turns it into an ordinary merge.
What the role became
The machine allowed four sessions. I preferred two — three at most, and only when the task didn't need much of my judgment in the chat — because past that the bottleneck stopped being the tooling and became my own capacity to decide and to review.
What changed was where the work happens, not how fast it goes. My time moved from writing most of the lines to specifying, deciding architecture, reviewing and testing. That only holds up because the guarantees are layered rather than personal: TDD, quality gates, pre-commit and pre-push hooks, CI checks after the push, and review by another developer. My own pass was exercising the feature through the interface and reading the code at the macro level.
I don't have a measured before-and-after to offer, and I would rather say so than quote a number I can't defend.
Something was lost, and it's worth naming: the craft of it — the making with my own hands — is mostly gone.
What all of it rests on: spec-driven development
Every task starts as a document: one .md describing what the task needs and how it behaves for the user. From there it fans out, each piece in its own file — ADR, schema, tests, edge cases, likely failure modes, implementation plan, decisions taken. It lives in a local folder that never enters the repository, which also means a new session can pick the thread back up without losing context. Nothing gets built until I've read all of it back.
Underneath: MCPs for persistent memory and documentation, language servers, code review and security skills, plus third-party skill collections. Useful, and replaceable. The policy, the sandbox and the worktree isolation are what made the rest safe to run.
This site's specs sit in a local _internal/ folder that the repository ignores; the repository itself is public, and the commit history is there to be read — every commit in it carries a co-author trailer.
GCB Hub — client onboarding
I built GCB Hub from scratch — Hexagonal Architecture, DDD, TDD — and grew it into a firm-wide system serving ~100 users across the Wealth, Private, and Retail teams, with 99.8% backend unit test coverage.
Onboarding is the piece that best shows how I work. The process was manual and tracked outside any single system. Together with compliance and business leadership, I consolidated it into a single tracked workflow inside the Hub: a multi-stage workflow engine with granular RBAC, digital contract signing through D4Sign webhooks, document generation via Amazon S3 pre-signed URLs, and client data pre-filled from Amazon Redshift. Onboarding went from days to hours.
Consolidating the process into one system is what made the next thing possible: a management dashboard with onboarding KPIs and stage-level metrics that the business had asked for.
About
Full-stack software engineer specializing in TypeScript (Node.js/NestJS, React), with AWS and infrastructure-as-code experience.
~4 yearsbuilding fintech platforms across wealth management, credit, and capital markets
99.8%backend unit test coverage on GCB Hub
~100 usersacross the Wealth, Private, and Retail teams
~60%reduction in customer credit approval wait time
Experience
Software Engineer — GCB Investimentos
São Paulo, Brazil –
Built GCB Hub from scratch applying Hexagonal Architecture, DDD, and TDD, scaling it into a firm-wide system serving ~100 users across the Wealth, Private, and Retail teams with 99.8% backend unit test coverage; also evolved the Administrative platform and extended the Financial one at this Brazilian credit and wealth management firm.
Built an investment redemption workflow integrated with Pipefy via OAuth 2.0, with full audit trail and back-office approval handoff.
Expanded the Administrative platform from a back-office tool into a cross-department system for HR, Finance, and managers, with decision-support dashboards and client onboarding metrics that hadn't existed before.
Planned the architecture for modernizing the Debt Capital Markets (DCM) operations portal — integrations via Microsoft Graph/SharePoint and AWS Lambda — and delivered its foundation: initial backend, Docker, and CI/CD pipelines with quality gates; contributed to infrastructure as code (Terraform/Terragrunt).
Co-architected (two-person team) the customer credit approval flow migration from a Django Admin monolith to a Node.js service with asynchronous queue-based processing, leading the frontend; customer wait time fell from 5+ minutes to under 2 minutes — a ~60% reduction.
Led the company's rebrand by building a new customer-facing frontend from scratch (React, Vite, TypeScript, Chakra UI) with full backend integration.
Designed backend features with Node.js, Prisma, and Redis, including secure authentication and authorization for RESTful APIs; migrated production data to a new PostgreSQL structure with RabbitMQ messaging.
Implemented Azure Storage for secure file management, set up CI/CD pipelines with GitHub Actions, and mentored junior developers.
Delivered features and optimized solutions for an investment management platform across backend (Kotlin/Spring Boot, C#/.NET) and frontend (Angular) systems on Azure.
Built BI dashboards and a queue-based processing service for end-of-day portfolio reconciliation integrated with the BTG brokerage.
Stack: Kotlin, Spring Boot, C#, .NET, Angular, MySQL, Azure
Software Engineer Intern — Pragma Patrimônio
São Paulo, Brazil –
Built ETL/ELT pipelines and API integrations and resolved production issues for a wealth management firm using .NET/C#, React, Node.js, Next.js, Python, and SQL Server in an Agile environment.
Eliminated redundant external API calls by caching a once-daily dataset via a scheduled cron job aligned to the source's refresh cycle.
Stack: C#, .NET, React, Node.js, Next.js, TypeScript, Python, SQL Server