TD
Contact
Senior Software Engineer Minneapolis, MN

Taylor
Dumas.

I turn business needs into architecture people can actually build on.

Senior engineer at Principal Financial Group working across software architecture, cloud engineering and technical discovery. I lead complex enterprise initiatives, write the documentation teams implement from, and keep engineers, business partners and vendors moving toward the same decision.

Start a conversation See selected work
10yrs
building enterprise software, 2016 to today
40+
teams deployed on a pipeline I designed and built
3
roles, from software engineer to DevOps to senior engineer II
1
company where I've grown the whole way: Principal Financial Group
01 Approach

From a business need to a system people trust

Most of my work starts before there's a ticket. This is the path I take a project down. Select a stage to see what I do there.

Stage 3 of 5 · Architecture

Design the simplest system that fits today’s business

I design cloud applications, APIs and integrations, and I use modernization as a chance to remove legacy assumptions and manual steps.

What I do here
  • Cloud application and distributed systems design
  • API and integration design, including OAuth
  • Implementation-ready documentation
  • AWS
  • Serverless
  • APIs
  • Principle

    Question the legacy assumption

    Modernizing is a chance to simplify. I challenge inherited constraints and cut manual steps that no longer serve the business.

  • Principle

    Write it down so it ships

    Implementation-ready documentation turns a design discussion into work a team can pick up and finish.

  • Principle

    Surface risk early

    Weekly updates, focused working sessions and honest scope and timeline calls keep surprises small.

  • Principle

    Build it together

    Mentoring, pairing, mobbing, and pull request and design reviews. Better systems come from teams that understand them.

  • Principle

    Make AI part of the team

    I push for AI training, write Copilot-ready discovery tickets and introduce Model Context Protocol to teams delivering with AI assistance.

  • Principle

    Create room to decide

    I run collaborative sessions where engineers and business partners can see the trade-offs and make a clear call.

02 Selected work

Four projects that show how I operate

Enterprise work is mostly confidential, so these describe the problem, my approach and what happened, without client details.

A Platform migration2021 → now

Moving customer communications and document processing to third-party platforms

Challenge
Large-scale migrations of customer communications and document-processing capabilities, with tangled dependencies across vendors and internal organizations.
Approach
Led the migrations end to end: coordinated vendor and organizational dependencies, wrote the technical documentation, and led testing.
Outcome
Delivered, and recognized by partners for collaboration, technical documentation, testing leadership and delivery.
  • Vendor integration
  • Document technology
  • Test leadership
  • Technical writing
B Marketing technology2021 → now

Onboarding digital marketing platforms with no playbook to follow

Challenge
The business needed new digital marketing and experimentation platforms, and there was no standard path for bringing them into the enterprise.
Approach
Evaluated the platforms, then coordinated business partners and internal engineering teams to define the integration and onboarding work as we went.
Outcome
Platforms evaluated and onboarded, enabling A/B testing and digital experimentation for business partners.
  • A/B testing
  • GA4
  • Vendor onboarding
  • Stakeholder alignment
C AI-enabled engineering2021 → now

Preparing engineering teams to deliver with AI assistance

Challenge
AI coding tools are only as useful as the work they're handed. Teams needed habits and inputs that made AI assistance reliable.
Approach
Encouraged AI training, proposed Copilot-ready discovery tickets, and introduced Model Context Protocol concepts for implementing development work with AI.
Outcome
A responsible, practical starting point for AI-assisted software delivery on my teams.
  • GitHub Copilot
  • Model Context Protocol
  • Technical discovery

How I build with agents on my own projects ↓

D Developer platform2018 → 2021

A deployment pipeline more than 40 teams ship on

Challenge
Java teams needed a consistent, scalable way to build and deploy, on top of legacy SDLC tooling.
Approach
Designed and built a Java/Maven deployment pipeline, owned the RESTful services behind its automation, and administered and tuned Jenkins.
Outcome
Adopted by 40+ teams, which I kept running and improving as a DevOps engineer.
  • CI/CD
  • Java
  • Maven
  • Jenkins
  • REST APIs
03 Agentic engineering

I build software by directing AI agents, and I engineer the system they work in

I treat a coding agent like a capable new teammate. It needs context, guardrails, a way to check its own work, and someone accountable for the calls that matter. Two side projects, written almost entirely by Claude Code under my direction, are where I practise it.

NoteMost of the code in these repos was written by an agent. What's mine is the design, the decisions, and the setup that keeps the agent's work correct.

Mochi Drift

A pastel arcade dodger built as one Expo / React Native codebase that runs on the web, iOS and Android. 19 stops so far, each with a boss of its own, and three chapters finished of a planned six.

Commits
183
By Claude
179 / 183
Tests
~850
  • Claude Code
  • Expo
  • React Native
  • TypeScript
  • Vitest

Dumas Family Recipes

A family recipe site built to earn from ads: prerendered Next.js pages, recipes in Neon Postgres, staging-then-production publishing, and Google sign-in for star ratings.

Commits
274
By Claude
182 / 274
Tests
378
  • Claude Code
  • Next.js
  • Postgres
  • Drizzle
  • Jest
  • Vercel
How a change moves, in both repos
  1. 01 · MinePlan

    Design agreed in an issue; I make the open calls

    Principle 6
  2. 02Build

    A written skill is the procedure

    Principles 1 · 2 · 3
  3. 03Verify

    Tests, golden replay, playtest bot, screenshots

    Principle 4
  4. 04Review

    Read-only subagents with fresh context

    Principle 5
  5. 05Ship

    Build, publish, push, confirm CI is green

    Principle 3
  6. 06Record

    Decisions to CLAUDE.md, lessons and the issue

    Principles 6 · 1
Six principles, with the evidence
  • Principle 1

    Context is engineered, and it has a budget

    The agent reads the same instructions every session, so I write them as a record of decisions and keep them lean. Detail loads only when the task needs it.

    From the repo
    • The recipe site's CLAUDE.md had grown to 570 lines, about 8k tokens loaded into every session. I cut it to 347 by moving procedures into skills and database mechanics into a file that loads only when database code is read.
    • The import skill was split into reference files read at the step that needs them: 33 KB to 26 KB, about 1.9k fewer tokens per import.
    • Setup changes are costed, down to "about +150 tokens" of always-loaded context.
    Detail Adumas-recipes/CLAUDE.md
    This file is the record of decisions already made.
  • Principle 2

    Repeatable work becomes a skill

    When I do something twice, it becomes a written procedure the agent follows the same way every time, with the points where it must stop and ask.

    From the repo
    • Mochi Drift chains five skills from design to release: plan-step, level-design, add-stop, balance-tuning and ship.
    • The recipe site's import skill runs to about 500 lines, with hard stops. An ingredient that doesn't resolve to the site's vocabulary is never imported; it goes back to a person.
  • Principle 3

    Guardrails a machine enforces, not instructions it might skip

    Rules that matter are enforced by code: hooks, tests, permissions and the database itself. An instruction is a request; a failing check is a guarantee.

    From the repo
    • A pre-commit hook refuses any photo carrying metadata, because a phone's photo holds the house's GPS location and git history is permanent.
    • A test fails the suite if anything but the publish step marks a recipe published, and a production database refuses every recipe write except promotion from staging.
    • Read-only commands run freely; promote, migrate and restore always ask first.
    • Mochi Drift's architecture layers and banned browser APIs are checked by a test.
    Detail Bdumas-recipes/.githooks/pre-commit
    Commit refused: a staged photograph is oversized or carries embedded metadata.
  • Principle 4

    The agent can check its own work

    I give the agent ways to prove a change is right before I see it: tests it can run, measurements it can repeat, and screenshots it can look at.

    From the repo
    • A golden replay plays every stop with a fixed seed and compares the game second by second, so a refactor can't quietly change how the game plays.
    • A seeded playtest bot gives each stop a win rate, good to about ±4 points at 150 runs, against a target per stop. Difficulty is tuned to numbers.
    • Type checking runs before Jest, because Jest's SWC transform strips types without checking them, and a broken file once passed its tests.
    • Screenshots at phone, tablet and desktop sizes, and a pixel comparison of the phone renderer against the browser canvas.
  • Principle 5

    Fresh eyes come from fresh context

    The agent that wrote a change is the worst one to review it. Read-only reviewer subagents start from nothing, check the work against the rules, and must prove what they report.

    From the repo
    • change-reviewer finds bugs only, and proves each one with a throwaway probe.
    • player-reviewer walks a change as a first-time player at three screen sizes.
    • house-rules-reviewer checks a diff for what should have changed and didn't, such as the privacy policy.
    • Fixes from review usually land as their own commits.
    Detail Cmochi-drift/.claude/agents/change-reviewer.md
    Report what you measured, not what you suspect, and say plainly when a suspicion turned out fine.
  • Principle 6

    I make the calls; the agent keeps the record

    Plans live in GitHub issues, and the agent proposes before it builds anything costly. Every decision I make is written down with its reason, so no session re-argues it.

    From the repo
    • Each plan step: the agent drafts the design, asks the open choices with a recommended option, records the agreed design in the issue, then builds.
    • A "settled decisions" list in CLAUDE.md, most with the reason and when it was decided, and a lessons file from every tuning round.
    • Only the owner can verify where a recipe came from, because the person submitting it is the one making the claim.
    Detail Ddumas-recipes/CLAUDE.md
    Unasked, propose before building only where a wrong turn is costly: schema, privacy, ad slots, sign-in.
~850
tests in Mochi Drift
378
tests in Dumas Family Recipes

Tests that earn their place

Every test in these repos guards a decision I made or a bug that already happened once. A test that couldn't fail for a real reason doesn't get written.

From the repo
  • A rule I settle becomes a test in the same change: each boss throws only its own kit; no visitor column can be added without a test failing; the nightly backup never holds visitor data.
  • Bugs found along the way land in their own commit, with the test that reproduced them. A capital T once resolved to teaspoon instead of tablespoon; the fix came with tests.
  • When a tuning lever moved nothing, the cause was a mechanic that never ran: every thrown clover left the screen. The fix pinned it with a test that every clover in a fan lands on screen.
  • The bug reviewer checks that each new test can fail: windows too short, setups that never trigger, assertions on the wrong value, thresholds tuned to one seed.
  • The whole-game audit's design rules run as a test, with its list of tolerated offenders kept empty.
  • Database tests run on PGlite in-process and never skip.
Featured story · Dumas Family Recipes

The agent I designed, and decided not to build

That's a lot of machinery to replace a step the owner already does well.

GitHub issue #40

The recipe site's first plan let family members upload a recipe and have a server-side agent import it to the live site, with no deploy. I designed that agent in full. It ran on the Claude API's Tool Runner rather than the Agent SDK, since it needed ten custom tools and no filesystem or shell. Its only route to the network was one fetch tool with an SSRF guard, a size cap and a timeout. A human-in-the-loop tool paused it for questions only the owner could answer, and the existing import skill compiled into its prompt, so one rulebook drove both harnesses.

Partway through, I weighed the cost: family accounts, an upload UI, a review queue and its own API spend, to replace a step I already did well. I changed the plan. Family members now submit a Google Form shaped around what the import skill needs, and I run the skill myself.

Agent architecture judgement (runtime choice, least-privilege tools, human gates), and the discipline not to build it.

Featured story · Mochi Drift

Four reviewers, one game

…so the remaining stops can be built nearly autonomously.

GitHub issue #22

Before building the rest of Mochi Drift, I had four player-reviewer agents audit everything built so far. Each took one slice: the first-time experience and the screens around play, chapter 1, chapter 2, and the trail as a whole. They played from screenshots as newcomers and ranked what was misleading, confusing, slow or dull. Findings raised by more than one reviewer counted most. Three flagged the same thing: the lit gap that is the only answer to a curtain attack was faint on pale skies.

I made the call on each recommendation. The fixes shipped, and the design rules became a test and a novelty budget in the level-design skill. Seaside, the next chapter, was then built stop by stop, with reviewer agents checking every stop before the chapter shipped.

Several subagents with scoped briefs, synthesis by agreement across reviewers, and findings turned into rules a machine enforces.

At work: AI-enabled engineering at Principal ↑

04 Changelog

Career, release by release

Every role at Principal Financial Group widened the scope: from building features, to the platform other teams build on, to the architecture and decisions behind whole initiatives.

v3.02021 → nowCurrent

Senior Software Engineer II

Principal Financial Group · Architecture, discovery and technical leadership across a range of initiatives

  • Lead large-scale migrations of customer communications and document-processing capabilities to third-party platforms.
  • Drive alignment across business partners, engineering teams and vendors with weekly updates, working sessions, early risk calls and practical scope and timeline management.
  • Simplify modernized enterprise architectures by challenging legacy assumptions and removing unnecessary manual processes.
  • Evaluate and onboard digital marketing platforms where no standard onboarding path exists.
  • Advance AI-enabled engineering through AI training, Copilot-ready discovery tickets and Model Context Protocol.
  • Introduce and share cloud and developer-platform practices: AWS AppConfig, GitHub Actions and publishing NPM packages to Artifactory.
v2.02018 → 2021

DevOps Engineer

Principal Financial Group

  • Designed, built and maintained a scalable Java/Maven deployment pipeline used by 40+ teams.
  • Administered and optimized legacy SDLC tooling such as Jenkins.
  • Owned and maintained RESTful services supporting deployment automation and engineering workflows.
v1.02016 → 2018

Software Engineer

Principal Financial Group

  • Developed scalable web APIs and transactional applications with full unit, integration and automated acceptance test coverage.
  • Coordinated across technical teams to deliver high-quality software on schedule.
  • Mentored new team members and shared on-call responsibilities.
v0.12016

Initial commit: B.S. Computer Science

Drake University · Minor in Data Analytics

05 Toolkit

What I bring to a team

Architecture & engineering

  • Cloud application architecture
  • AWS and serverless services
  • Distributed systems design
  • API and integration design

Delivery & platforms

  • Technical discovery and requirements
  • A/B testing and digital experimentation
  • Vendor integration and onboarding
  • CI/CD and developer enablement

Leadership & collaboration

  • Cross-functional technical leadership
  • Mentoring, pairing and mobbing
  • Pull request and system design reviews
  • Facilitation and stakeholder alignment
Technologies, tools & practices
  • AWS
  • TypeScript
  • GitHub Actions
  • JavaScript
  • React
  • NPM
  • Java
  • Snowflake
  • APIs
  • OAuth
  • AWS AppConfig
  • GA4
  • A/B testing
  • GitHub Copilot
  • Model Context Protocol
  • Claude Code
  • CLAUDE.md
  • Subagents
  • Hooks
  • Agile / Scrum
  • Technical discovery
  • Distributed enterprise architecture
06 Contact

Have a system that needs a clear plan? Let's talk.

EmailElsewhere
LinkedIn GitHub

Based in Minneapolis, MN