Jeff Kent Buenaflor.

Open to remote roles

I run AI agent teams that ship production software.

I design the agents, the rules they follow and the reviews that check them. Then I ship real products with them: a regulated fintech platform, a streaming service and an AI video studio. I started as a UI designer, and I still design the products I ship.

Email me Read the case studies Remote · Any time zone
Illustrated portrait of Jeff Kent Buenaflor in a hoodie with headphones

Product design

A designer first, and I still design what I ship

I set the flows, the screens and the motion for each product, and my agents build to them. Then a reviewer checks every screen for the small details.

Everywhr app screens: a globe of Japan, Discover suggestions for ramen near you, and a trip film
iOS appOwn product2026

Everywhr: an AI travel guide from your photos

Everywhr reads where your photos were taken and lights up your world on a globe. It also learns what you photograph most and suggests places near you, with the reason on screen. I designed the product, the screens and the motion, and my agents built the SwiftUI app to that design.

Design
Product, UI, motion, website
Stack
SwiftUI, on-device photo AI, Cloudflare
See the shot on Dribbble

2011

my first role: UI designer and developer

From UI designer to CTO

I started at PayrollHero as a UI designer and developer, then moved into engineering and leadership. Design is still the part of a product I check first.

58

shared components in one back office

Design systems the build enforces

I rebuilt a fintech back office on 58 shared components. Copied blocks and oversized files fail CI, so the screens stay consistent.

A written standard for the small details

Every screen my agents change is checked against it: wording, labels, spacing, alignment, focus, tap areas, and the empty, loading and error states. The reviewer sends back any miss.

How I work

Small, clear tasks. Cheap builders. Reviewers that can say no.

The same loop runs every project. The planner and the reviewer get the strongest model. The builders get the cheapest model that passes review.

01

Plan

Split each ticket into items small enough for a low-cost model to build without guessing.

strong model
02

Build

Builders work one per branch, with only the files and rules their item needs.

low-cost model
03

Review

A separate agent that never wrote the code approves or sends it back. Money and sign-in code get extra care.

independent gate
04

Verify

Tests run against the real staging system. Nothing reaches customers without a human yes.

human approval
45+→10+

Fewer, stronger agents beat more agents. I scaled the fintech team to more than 45 agents, then cut it to 10+ long-running agents as models improved and needed shorter instructions. There was far less to coordinate.

Measured, not guessed

I pick models with benchmarks and budgets

My major model choices come from tests I ran, and I report the simple baseline next to each result.

~31×

value vs spend, Feb – Oct 2026

Subscriptions instead of metered API

About $124,000 of AI work at API list prices for about $4,000 in flat-rate Claude and Codex seats, personal and employer-paid. 235 billion tokens.

16 / 16

vs 13 / 16 for a frontier model

Decision models, tested before trusted

I benchmarked a typed judgment model for routing and risk checks, at 26× fewer tokens. I retired it after measuring that about two in three of its holds were unneeded.

~20×

lower cost per coding task

The cheapest model that passes review

I benchmarked models and settings, then routed each task to the cheapest option that met the quality bar, with no rise in review failures. Open-weights workers ran under frontier reviewers.

  • Claude
  • Codex
  • DeepSeek V4.1 Flash
  • GLM 5.3 Flash
  • Ollama

Hire me for

Four ways I can help your team

Remote, full time, in any time zone: US, EU or APAC hours.

Fractional AI engineering lead

I lead your agent-assisted delivery part time: plans, reviews, model choice and the guardrails around them.

Fits: teams already using Claude Code or Codex that want more from them

Agent fleet setup

I set up planner, builder and reviewer agents in your repository, with shared memory, CI gates and cost limits.

Fits: engineering teams starting with agents

Platform rebuild with an agent crew

I rebuild a product end to end, web, back end and native apps, with my own agent team.

Fits: founders who need a full platform without a full team

Product design lead

I design your app or website: the flows, the screens, a small design system and the motion. Then I build it with my agent team.

Fits: teams that want design and build from one lead

Contact

Have a product that needs shipping?

Send a short note about the project. I reply within one working day.

Case study

Open as page

Rebuilding a regulated fintech platform with a team of AI agents

Role
CTO and hands-on architect
Context
regulated crypto buy-and-sell company, Philippines
Period
2026
Status
in final testing

The problem

The company needed its whole platform rebuilt: 9 apps, including customer sign-up, identity checks, crypto buy and sell, deposits and withdrawals, and the staff back office. The work touched money, identity verification and sign-in, where a careless change becomes a regulatory problem, not just a bug.

My goal was to make AI agents do most of the building, while keeping the review discipline a regulated company needs.

My role

I set the architecture and the acceptance criteria, and agents wrote most of the code under my review gate. My own architecture decisions: a NestJS modular monolith with 14 domain modules on PostgreSQL, Redis and Cognito; typed API contracts (ts-rest and zod) shared by the back end and 5 React web apps; money held in integer centavos until display; role separation and break-glass access on the money path, with two-person approval for compliance, fee and rate changes; a separate rate-polling worker per price source; and Terraform on AWS ECS, reachable only through Cloudflare. Every production deploy and every business-logic change needs my approval. Deterministic checks (tests, type checks, builds, scans) run automatically.

What I built

One job per agent

Each agent gets a single role: plan, build, review or test. A planner splits each ticket into small, clear items. A builder takes one item with a short, written brief: the files it may touch, the goal, and the checks that prove it is done. A builder never reviews its own work.

At peak, more than 45 agents worked at the same time across Claude, Codex and Grok, as long-running lanes plus short-lived helpers.

Model routing by risk and cost

I benchmarked models and settings on real tasks for cost and quality, then routed each job to the cheapest option that met the quality bar:

  • Small model, default effort: mechanical, tightly scoped work such as one-file fixes, fixed checklists and scripted releases. Raising its effort to maximum cost far more with no gain in quality.
  • Mid-tier model: normal feature builds and repairs, and items the small model failed twice.
  • Strongest model, high effort: planning, every independent review, and anything that touches money, identity checks, sign-in, security, migrations or many files at once.

The result was about a 20-fold lower cost per coding task, with no rise in review failures.

Measuring decision models before trusting them

I tested Jev (TypeSafe), a typed judgment model that answers multiple-choice and yes-or-no questions, as a decision layer: which agent takes a request, how risky it is, and whether to hold it for a check.

  • Classification: it labeled 16 of 16 hand-labeled prompts correctly, against 13 of 16 for a frontier model, with 26× fewer tokens (mostly because the comparison model carried a 20,000-token system prompt) and about a tenth of the wait.
  • Risk checks: wording tuned on known cases scored 93% agreement, but a frozen holdout dropped to 77–86% with one repeated miss. A rewritten version then passed a fresh 10-case holdout with no misses, at about 1/600 the cost of a mid-tier model per check.
  • Routing: 76% ± 3 accuracy over four runs, with correct owner assignment on 33 of 33 scored cases.

I retired it after about two weeks, after measuring that about two in three of its holds were unneeded. What stayed is the method: freeze a holdout, report the trivial baseline, and repeat runs before you believe a gain.

Open-weights models as workers

I ran open-weights models next to the commercial ones. DeepSeek V4.1 Flash did bounded build, rewrite and review work through Ollama and the DeepSeek API, including as the model behind Claude Code, with about six workers in parallel under the host’s concurrency cap. GLM 5.3 Flash handled scoping and build steps in a separate workflow. In a ten-run test, DeepSeek’s maximum reasoning effort solved a test puzzle no more often than its lowest setting (6 of 10 at both), although a four-run sample had suggested otherwise.

Subscriptions, not metered API

I ran the Claude and Codex agents on flat-rate subscriptions, not pay-per-token API keys. From February to October 2026, across my Claude and Codex agent work (this platform included), the agents used 235 billion tokens (197 billion in 1.5 million Claude messages, 38 billion on Codex). At API list prices that is about $124,000, against about $4,000 in subscriptions (one personal Claude plan until September, one Codex plan from August, then nine employer-paid Claude seats in October), so about 31 times the value at list prices. In October alone, $48,500 of usage ran on $2,000 of seats. About 97% of the Claude tokens were cache reads of earlier context, which is why trimming each agent’s context mattered.

Independent review on every change

Every change needs an approval from a separate reviewer agent, made against the exact version being merged, on top of the automated gates. Every release to customers also needs a human approval. Reviews of user-facing work include screenshots and a checklist of small details (wording, spacing, empty, loading and error states), because many small misses add up to a poor product. Approved changes land in batches, and a staging build is verified after each batch.

Code quality the build enforces, not reviewers

AI agents copy code readily, so a fast agent team can produce a large, repetitive code base. For the rewrite of the staff back office front end, I made reuse a rule that the build checks:

  • One shared component kit (58 parts so far: tables, drawers, dialogs, status chips, empty and error states). A missing pattern goes into the kit first, with its own tests, before any page uses it.
  • Pages cannot add their own styles. Colors, spacing and type sizes are tokens defined once, and status and error wording is defined once per value.
  • Any copied block of 50+ tokens, any unused file or export, and any file over 200 lines fails the build.

The app it replaces, area by area, had a single file of 7,000 lines. A reviewer still requests changes for copied markup or a one-off version of a kit part, but the build catches most of it first.

Safety boundaries

Agents cannot delete files, send email, or change the live system. Every release to customers needs a human approval, and the staging and production environments are always named in every report, so a staging result can never be mistaken for a production one. A test that runs against mocks is never accepted as production evidence.

Shared memory that survives sessions and providers

Agents forget everything between sessions, and different providers’ tools do not share state. I built a shared memory of 600+ short notes: rules, decisions and lessons from past incidents, each with the reason behind it. Agents read the relevant note before they act, and add one after a verified outcome.

Delivery infrastructure

A scheduler spreads builds and tests across three machines (196 jobs in one day) and caps heavy jobs so agents do not starve each other. The test suite includes 1,000+ Playwright end-to-end tests, and a chat bot connects 33 team chats to the agents so staff can raise requests where they already work.

Results

  • About 4,000 approved code changes in under six months across 9 apps (TypeScript, NestJS, React, PostgreSQL, Terraform on AWS).
  • 3,000+ automated test files, and an independent approval on every change.
  • A back office front end rebuilt on 58 shared components, where copied code, unused code and oversized files fail the build.
  • About 20-fold lower cost per coding task after routing work by risk and cost.
  • About $124,000 of AI usage at API list prices on about $4,000 of flat-rate subscriptions (personal and employer-paid), February to October 2026, across all my agent work.
  • The platform replaces the company’s current platform and is in final testing.

The same approach let me rebuild a streaming service as its only engineer: a viewer website, a staff back office with its back end, and native iOS and Android apps with 600+ tests, now in testing.

Lessons learned

  • Fewer, stronger agents beat more agents. At peak, 45+ agents ran at once, with separate lanes for features, bugs, backlog, review and chat. As models improved, a strong planner needed far shorter instructions, so I closed most of those lanes. Today 10+ long-running lanes do the work: one planner splits each ticket into small items for low-cost builders, and independent reviewers check every merge.
  • Report the trivial baseline. A risk-tier rule matched the recorded tier on 53% of the cases it covered, while always answering the top tier matched 59% of all cases. Without the baseline, 53% looked like progress.
  • Context is the main cost. Agents that reload long histories spend most of their budget re-reading. Each agent now starts with only the brief it needs.
  • Agents must fail loudly. An agent waiting on a prompt nobody sees blocks its queue in silence. Agents now stop and report a blocker instead.
  • Set scope and effort per task. Unscoped agents wander, and maximum effort on small tasks costs more without better results. Every brief names its files, its goal and its stop point.
  • Every helper needs an end condition. Tunnels, dev servers and watchers outlive the agents that start them unless each job ends with a cleanup check.

What I bring to your team

  • A working model for AI-assisted delivery that keeps review, security and release controls intact.
  • Measured cost and quality decisions, not guesses about which model to use.
  • Hands-on engineering across TypeScript back ends, React, native mobile, AWS and Terraform, with deep experience in regulated money and identity flows.
  • Each client’s code stays in that client’s own repositories.

Have a product like this?

Send a short note about the project. I reply within one working day.

Email me

Case study

Open as page

Orchestrating AI agents to rebuild a streaming platform on web, iOS and Android

Role
lead engineer (sole engineer), contract
Context
a Southeast Asian video streaming service (movies, series, live TV and sports)
Period
Aug 2026 – Present
Status
in testing

The problem

The service needed its whole platform rebuilt: a viewer website, a staff back office for the catalog, live channels and advertising, the APIs behind both, and native iOS and Android apps. That is normally the work of a team with web, back-end and two mobile specialists. I was the sole engineer, so the real job was to design an agent team that could do the work and a system that could prove the work was right.

The agent setup

I plan, agents build

I set the architecture, split the work into small items and decide what counts as done. Agents from two providers (Claude and Codex) build the items. Each agent works in its own branch and worktree, so agents never edit the same files at the same time. Agents wrote nearly two-thirds of the web monorepo’s commits.

One quality gate, the same for everyone

Every change to the web monorepo must pass one check before it lands: a frozen dependency install, lint, type check, tests, builds, unused-code detection, import-boundary rules and a secret scan. My changes and the agents’ changes go through the same gate.

A second agent checks before tests run

The native apps are tested in rounds against the real staging back end. Before a round runs, a second agent checks its plan. Each round records the commit hash of the exact code under test, takes a fresh snapshot of the test account’s data, and cleans up every simulator and process it used. A result that cannot be traced to the exact code does not count.

Agents share devices by handoff

iOS and Android test runs share one test machine. An agent must be handed a device and must hand it back before another agent can use it, so two agents never fight over one simulator.

What the agents delivered

  • Web platform: a viewer website, a viewer API, a staff back office and its API in one TypeScript monorepo (React, Fastify, PostgreSQL, AWS). The back office covers live operations, catalog curation and publishing, artwork uploads, captions and subtitles, advertising (VAST ad tags), customers, access groups and roles, account security, the TV guide, analytics and an audit trail.
  • iOS (Swift, SwiftUI): the website’s main viewer features, including on-demand and live playback, native ads, caption and subtitle choice, My List and Continue Watching, and calendar reminders. 272 unit tests and 76 UI tests.
  • Android (Kotlin, Jetpack Compose): playback with Widevine DRM, WebVTT subtitles, a 7-day TV guide, IMA ads with consent, picture-in-picture, and session data encrypted with an Android Keystore key. About 330 test functions.

Results

  • One engineer and an agent team have rebuilt a streaming platform across web, back end, iOS and Android in about ten weeks. It is now in testing.
  • 600+ automated tests written for the native apps, plus the monorepo’s test suites, and one quality gate on every monorepo change.
  • The staging test rounds found real defects before users could, and each one went into the fix queue, not to users.
  • An unsigned iOS release archive builds, and an Android release build has been run. Store release, physical-device testing and full ad-completion testing are still ahead.

Lessons learned

  • Parallel agents need fully separate state. Separate branches are not enough if agents share any tool state, so builders also avoid shared scratch areas like git’s stash.
  • Heavy test tooling belongs on its own machine. Simulators compete with agents for disk and CPU, so all simulator work runs on a dedicated test Mac and shuts down after each check.
  • A test result must prove what it tested. Commit hashes, fresh test-account snapshots and explicit device handoffs were part of the design from the start.

What I bring to your team

I design agent teams and the checks around them, so a very small team can build a product across web, back end, iOS and Android with the checks a larger team would use, without lowering the bar for what counts as done.

The client’s code stays in the client’s own repositories.

Have a product like this?

Send a short note about the project. I reply within one working day.

Email me

Case study

Open as page

An AI agent studio that writes, renders and schedules short-form video

Role
sole builder, personal venture
Context
faceless short-form channels (food history and daily AI news) on Instagram, YouTube, TikTok and Facebook
Period
Aug 2026 – Present
Status
in production since Oct 2026

The problem

A short educational video needs research, a script, a voice, music, images, motion, captions, an edit, a loudness check and an upload to each platform. A small studio does this with a writer, an editor, a motion designer and a social media manager. I wanted to find out how much of that chain AI agents could run end to end, at a quality bar I would accept, while I only made the creative calls.

The agent setup

Three agents, three jobs

  • Director (Claude Opus 5.5). Owns the series bible, script, look, shot list, visual review and final edit. It writes each step as a numbered runbook.
  • Executor (Codex, gpt-6.1-sol). Runs the runbooks: image generation, render jobs, audio mix and quality checks. It stops at the first mismatch and reports, not guesses.
  • Operator (Codex, gpt-6-luna with computer use). Drives the browser to upload, schedule and set thumbnails on each platform, then records what the platform confirmed.

One manifest per episode

Each episode is one manifest file. A new series needs only a new series bible and new manifests; the pipeline does not change.

The pipeline

Stage Tools
Facts and script Director agent; an independent agent fact-checks before anything is published
Voice, music, sound effects ElevenLabs (eleven_v4 voice, a new instrumental track per episode)
Stills Codex image generation, in a real phone-photo look
Motion Higgsfield (Kling 3.0) clips only where motion adds value; depth maps and headless Blender 5 for 2.5D camera moves
Edit and captions Remotion 4 design system, word-timed captions
Mix, master, quality check ffmpeg; loudness, true peak, duplicate-music and layout checks
Publish Browser agent schedules each platform from one post queue with file checksums

Renders run on a separate Windows GPU machine, so the laptop stays free.

Results

  • 28 finished episodes in about two weeks (Oct 12–25, 2026), each one passing an automated 12- to 13-point quality check before scheduling.
  • 53 uploads scheduled on YouTube and Instagram from one queue, with TikTok and Facebook cuts from the same masters.
  • Paid video kept small: a 5-second Kling clip costs 8.75 credits, so the pipeline uses stills and 2.5D motion by default and a paid clip only where it earns its place.
  • A second series in days: a daily AI-news format (three Shorts a day with an AI avatar host and an on-screen “AI host” label) reused the same voice, render and upload stages with a new Remotion template.

Lessons learned

  • Make the brand visible on a phone, not on a monitor. The first logo was 5.8% of the frame width and disappeared on a phone. It became a sticker at 12–14% of the width, placed clear of the Reels and TikTok buttons.
  • Check the music, not only the voice. Early beds sat 15 dB under the voice and one track was reused. Each episode now gets its own track, a checksum blocks repeats, and the bed sits about 10 LU under the voice.
  • Render one at a time when disk is the limit. Three masters rendered at once filled the render disk, and two failed. The render chain now starts a job only when at least 15 GB is free.
  • Browser agents need short, unambiguous paths. The upload dialog joined a new path to the last one, so one episode’s file went up under another episode’s name. Files now go into short, single-purpose folders and every upload is checked against its checksum.
  • One blocking review is enough for video. Several review rounds slowed delivery without better results. Each episode now gets one blocking check plus the automated quality gate.
  • Generated faces are the weak point. All five clips for one trailer were rejected because the video model redrew the faces. Clips are now used for food, objects and places, not for characters’ faces.

What I bring to your team

I can design and run a multi-agent media pipeline end to end: script, voice, image, video, edit, quality checks and publishing, with the agents’ roles, checks and costs set out in writing. The same pattern (director, executor, operator, one manifest, one quality gate) carries over to marketing content, product videos and documentation.

Have a product like this?

Send a short note about the project. I reply within one working day.

Email me