Twenty-three months later UnitedHealth/Optum Financial acquired the company, and the modernized HRCommand architecture was sitting on the table in the due-diligence room. We never did a cutover weekend. We never had a release outage. Five engineers, two-week loop, two years.

We didn’t rewrite it. We ran the strangler fig pattern, and we ran it boring.

graph LR
    M1[Monolith] --> M2[Monolith<br/>shrinks]
    M2 --> M3[Microservices<br/>grow]
    S[New service 1] --> M2
    M3 --> S2[New service N]

Figure: the strangler-fig pattern — new grows around old as old shrinks.

Why I won’t sign up for a full rewrite

I’ve sat in the meeting at five companies now. New VP, new deck, same line: the monolith is the problem, we need a full rewrite. Four of those rewrites shipped late, shipped broken, or got killed at 60% with a half-built parallel system and a monolith nobody had improved.

A decade-old monolith is not a code problem. It’s a running business — integration contracts, regulatory commitments, a long list of undocumented behaviors that customer support has been quietly accommodating for years. The day you announce the rewrite, the old team stops shipping. The new team rediscovers undocumented behavior the hard way. Leadership rotates. The Q4 board deck reads differently than the Q1 one. None of that is exotic. It happens every time.

What we did at CYC

Thin proxy in front of HRCommand. Day one, zero new behavior. Pick the smallest bounded context with a clean data-ownership boundary — for us, that was a benefit-eligibility surface nobody wanted to touch. Build it as a Spring Boot service. Route traffic behind a per-endpoint feature flag. Watch error rates and the business KPIs that actually mattered for two weeks. If anything moved wrong, the flag flipped back in seconds. Peel the old code path out. Pick the next.

In parallel, the UI rebuilt itself the same way — React replacing the old JSP screens slice by slice, Figma-to-code components landing in a shared library that the rest of the consumer-facing product line eventually adopted.

The boring parts that decide whether it works

The pattern is simple. The discipline is the part teams skip, because it doesn’t feel like progress on the new system:

1. Anti-corruption layer at every seam. New service owns its own data model and translates in one file. When the monolith changes shape, one file changes.
2. Idempotency keys on every cross-seam write. The proxy will retry. Without idempotency you get duplicate benefits records and a very bad Monday.
3. Outbox pattern for events. State change and event write commit in the same transaction; a drainer publishes. You never lose an event, never publish one that didn’t happen.
4. Feature flags per endpoint, not per release. Thirty-second rollback instead of a war room.
5. Commit to the loop, not the order. Which context moves next falls out of where the pain is, not out of a Gantt chart drawn in March.

None of these are exotic. They’re what teams pretend they’ll add later and then don’t.

When I’d actually entertain a rewrite

One case: the monolith genuinely cannot scale and the runway is funded for a parallel build to completion. That case is rarer than people think. Most monoliths that “can’t scale” scale fine after two focused months on the three hot paths. Test that hypothesis before you spend a year of a five-person team on a parallel build that may not finish.

The pattern is just the vehicle. The thing I’m proudest of from those two years isn’t the architecture diagram — it’s that the team shipped boring, disciplined two-week increments until they compounded into an acquisition.

More soon.

That’s the bug I hate most. My fantasy baseball AI — the thing I build on weekends to tell me who to start and which trade is a fleece — kept rendering a clean, confident, empty list of waiver targets. No error. No stack trace. A recommendation engine quietly recommending nothing.

The cause was dumb, the way these always are. The pipeline was writing to two places at once: a real database and a pile of CSV files left over from an earlier design. One job stopped writing the CSVs. The waiver code still read them. Empty file, empty list, no exception thrown. A silent failure is worse than a loud one. The loud one at least tells you to come look.

So most of the week went into ripping the CSVs out.

One source of truth

The data path had thirteen spots where something read or wrote a CSV. It’s now zero. Everything goes through the database, and I added a gate to the test suite that fails the build if a CSV ever creeps back in. That part matters more than the cleanup. A one-time fix that nothing enforces is a fix with an expiration date.

The pipeline got honest about time

The nightly job that recomputes every lineup recommendation took seventy-seven minutes. This week it takes a hundred and nineteen seconds.

I’d love to tell you I found an elegant algorithm. I didn’t. The job was running the full factor-analysis pass, then running most of it again a step later on the same data. I taught the second step to reuse what the first one already wrote. The fanciest optimization is usually noticing you’re doing the work twice. That run now resolves 8,061 of 8,386 players to real projections instead of silently dropping the ones whose names don’t match cleanly.

Names are a terrible primary key

Match a player on his name and you’re one accent or nickname away from dropping him silently. So the back half of the week moved the joins that feed recommendations off player names and onto stable IDs.

Underneath that was an older sin: a past identity bug had stamped three different fantasy teams onto one team ID. The repair is self-healing now — it overwrites the corrupted values from the authoritative roster instead of politely filling in the blanks, and coverage went from around ten percent to ninety. The nightly cron also stopped false-failing on “database is locked,” which turned out to be three steps colliding with the midday stats scrape. The fix was a longer timeout. Patience, not cleverness.

The front end is finally React

For a while the UI was server-rendered HTML held together by a Python framework I’d outgrown. It’s now a real React app: twenty-eight pages covering rosters, trades, the waiver wire, draft prep, and live matchup projections, cold-loading in about a second and a half. The trade view has a proper evaluator; the roster page flags buy-low and sell-high targets off the skill-score percentiles.

I won’t pretend a side project needed React. It didn’t. But I wanted real client-side state and an honest API contract between the front and back ends, and I wanted my hands in the framework most of the people I interview with are using. Both things are true. I’ll own it.

It also writes its own column now. A morning job drafts a weekly recap of the league — who’s heating up, who you should be worried about — and the site serves it like any other page. The AI covering the league it also runs. That one makes me laugh.

The model stayed benched

A couple of weeks ago I wrote here about the model’s honest limits. This week I acted on it. There’s a machine-learning ensemble in the codebase, fully built, and it loses: a plain blend of public projections and percentile skill scores beats it on the board. So it stays benched. Shipping the ML because it’s the ML is exactly the trend-chasing I spend half my time talking other people out of, and it’s a lot harder to take that advice when you’re the one who wrote the losing model.

The boring projection that wins is the one in production.

More next week.

That’s how many JPMorgan Chase customers opted out of voice biometric authentication during the first three months. Ten million accounts in. 1,300 out. A 99.87% adoption rate on a security feature.

I’ve shipped a lot of systems in 25 years and that’s the highest voluntary adoption I’ve ever seen on anything touching account security. The headline metric is the ~$830B in fraud losses prevented across the JPMC consumer banking cohort, and that’s the one that gets quoted. The 99.87% is the one I think about, because we didn’t get there by being clever about the security model.

graph LR
    A[10M JPMC<br/>accounts] --> B[Voice fingerprint<br/>opt-in]
    B --> O1[99.87%<br/>adopted]
    B --> O2[0.13%<br/>opted out]

Figure: opt-in adoption that didn’t look like opt-in adoption.

What we were trying to solve

I was an Infrastructure Developer at JPMC’s Wilmington office from February 2018 to February 2019, embedded with the TARA Fraud Busters group. The problem was call-center fraud. Attacker calls in pretending to be the account holder. Rep authenticates with knowledge-based questions — mother’s maiden name, last four of social, last transaction amount. Every one of those answers was sitting in a breached database somewhere on the open web. Rep authenticates the attacker, fraud goes through.

Knowledge-based authentication was finished. The fraud team knew it. What nobody had was a clean replacement that customers would actually adopt.

Why we didn’t ship a passphrase

The default fix in the literature is a voice passphrase. Customer enrolls a phrase, says it on every call, system matches the voiceprint. It works as a security control. As a customer experience it’s a slow disaster — fifteen seconds on every call, a confusion vector when people forget the phrase, and an explicit opt-in moment where the customer has to choose to enroll. That moment is where security features die.

So we asked a different question: what if enrollment is the call they were already making?

What we built

Passive voice biometric fingerprinting, Python and ML on the matcher side. Customer calls about a disputed charge, a lost card, a balance question, whatever. The system captures a fingerprint silently during the natural conversation. Thirty seconds of normal call and a voiceprint accumulates in the background.

On the next call, the system matches the new voice against the enrolled one and surfaces a confidence score before the rep starts knowledge questions. High confidence — skip them, authenticate immediately. Low confidence — fall back to the old flow plus extra fraud checks. We fed all of it into the JPMC CAT tool, an Angular dashboard pulling aggregated REST APIs across the fraud surface, with a Sapiens rules engine applying policy in real time.

The customer never saw any of this. They just noticed their calls went faster.

The hard parts

Voiceprint matching itself was the easy part — mature libraries exist. The work was in the parts around it.

1. The capture pipeline. Call-center audio is not studio audio. Mid-call noise, multiple speakers, partial captures. Every fingerprint carried a quality score and the matcher gated on it.
2. The opt-out path. One sentence, on the call, no forms. “I’d rather you didn’t use voice on my account” — done, flag flipped, respected on every subsequent call. The 1,300 customers who opted out used this path.
3. The fraud-ops feedback loop. Rep flags went straight into the training set. Model got better every week.

The numbers

Three months in: 10,000,000 accounts enrolled passively, no opt-in click. 1,300 opt-outs — the number that proved the opt-out path actually worked. Twenty seconds off the average authenticated call, which at call-center scale translated to roughly 25 more customers per rep per day. The post-deployment analysis pegged the fraud-loss plateau across JPMC consumer banking at ~$830B prevented.

What I’d tell someone building the next one

Security features get treated as if customer experience is a tax you pay for safety. Frame the problem that way and you get small-percentage adoption and a postmortem.

Flip it. Build the security feature so the customer’s life gets better at the moment it engages. 99.87% is what happens when you frame the design problem correctly.

Back to work.

Training MAE: 1.765 fantasy points. Test MAE: 3.079 fantasy points.

If you’ve done any ML in production you know what that gap means. The model fits its training data tighter than it fits the world. It’s overfit. Some level of overfitting is almost always happening; the question is whether you measured it and can say out loud why it’s there.

Most of the production “AI” I’ve seen in the wild can’t.

graph LR
    T[April 1-25<br/>training] --> M[Model]
    V[April 25 - May 2<br/>test] --> M
    M --> E[Train MAE 1.765<br/>Test MAE 3.079]

Figure: the train/test split that exposed the honest gap.

What I built

A daily player-performance predictor for fantasy baseball — my side project, github.com/ethos71/fantasy-baseball-ai. XGBoost regression, Streamlit UI on top. Target is how many fantasy points a given MLB batter scores the next day, standard rotisserie scoring, about 150 batters in play on any given slate.

Training data was 2,300+ real game logs from April 2026, engineered into ten features per player-day. Rolling averages at 5, 10, and 20 games. Standard deviations across the same windows. Trend deltas. Binary flags for hot streaks and cold streaks.

Ten hand-crafted, domain-informed features. That part matters more than which gradient-boosted library you reached for.

Why XGBoost

I’m not religious about it. I picked it for boring reasons. Mixed feature types without preprocessing gymnastics. 200 trees train in seconds on a laptop. Feature importance falls out of the model for free. And when a friend in my league asks “why six points?”, I can answer in English instead of waving at gradients.

A neural network wouldn’t have helped here. 4,800 samples isn’t enough to make a deep architecture stable, and “the gradients converged” isn’t an answer that survives a Sunday-morning text thread, let alone a stakeholder room.

The validation choice

Most fantasy-sports ML projects random-split their data. Random splits look great in notebooks and lie about reality. If a model trains on May 15 data and tests on April 20 data, you’ve leaked the future into the past. The reported accuracy is fiction.

So I did temporal validation. Train on April 1–25. Test on April 25–May 2. No shuffling. The test set is strictly later than the training set, the way the model would have to operate if I deployed it. That’s the choice that produced the gap. A random split would have buried it.

What the honest number means

Train MAE 1.765 says the model learned the patterns in the April window. Test MAE 3.079 says they don’t fully generalize a week forward. The reason is in the features. Mine are all about the batter. Nothing about who he’s facing, weather, ballpark, rest, lineup spot. A hot hitter against a Triple-A call-up is a different distribution from a hot hitter against an ace, and the model has no way to tell them apart.

About 40% of predictions land within ±2 FP, useful for relative ranking. The worst errors are 15+ FP and they cluster in exactly the games my features can’t see. A slumping batter detonates against a rookie spot-starter; of course the model missed it.

80% of ML accuracy comes from the domain features. Most projects invert that ratio and wonder why the pipeline doesn’t get better in production.

What I’d ship

I wouldn’t ship this as autonomous predictions. Not yet. What I’d ship is the model as a tool an analyst uses, paired with Vegas lines, FanGraphs projections, and somebody who knows Ohtani isn’t on waivers no matter what the database says.

Next iteration adds opponent ERA/OPS-allowed, pitcher handedness, and rest days. That should close the gap and beat the FanGraphs baseline this version underperforms by about 10%. Then weekly retrains and drift monitoring against the baseline.

I’ve sat in too many rooms where someone presented a 99% accurate model that was 99% leaked. The hard part of production ML isn’t moving the metric. It’s knowing what the model doesn’t know, and being willing to put that gap on the slide.

The model doesn’t know who’s pitching tomorrow. I do. That’s the partnership.

More soon.

Most of the week went into dom, the AI cost-cutting toolkit. The premise is simple: most coding tasks don’t need a $2 Opus call. Haiku at one cent does it, and a third of the time a local Ollama model does it for free. dom routes the task to the cheapest model that can actually do it. One curl command installs it into any project; an eval policy gates every change.

Three things landed this week:

1. Polyglot smoke matrix. Three full compose stacks proving the toolkit scaffolds any combination of UI × API × DB: React+Spring+H2, React+Python+H2, and Node+C#+Oracle+Ollama. Same Karate feature runs against all three and must return the literal string hello world end-to-end. Three different language runtimes, four database vendors, and one assertion. That’s a contract.

2. Edit-everywhere, today. As of an hour ago, every stack now has a working edit button — UI fires a PUT /hello, the API tier proxies to the AI tier, the AI tier detects edit intent via a deterministic regex (no LLM for the parse — too expensive, too unreliable), and the underlying DB row gets updated. The byte-exact hello world contract still passes for any non-edit input. Five files, three languages, one consistent pattern.

3. A @dom orchestrator agent with hard rules about what it routes versus what it doesn’t touch. It’s the front door for “how do I do X in dom?” and it doesn’t write code — that’s the next agent down the chain.

dom is going to underwrite everything I build for the next year. I’d rather spend a Saturday once than $200/mo on tokens forever.

What else moved

• @job got rebuilt. Scope cut to job-hunt only, outplacement and separation docs moved out, validated-only pipeline, dashboard cleanup. The agent was carrying too much; I trimmed it to the one thing it has to do.

• smartballz, my fantasy-football XGBoost project, got a silent-failure sweep — banned a class of broad-except handlers that were masking real DB errors as “bad credentials.” Also fixed two actual model bugs (Ohtani showing on waivers when he shouldn’t, mid-tier trade values flattening out). The kind of week where you stop and notice the model is wrong before the league does.

• nyx-crm got a CI shell-injection fix and a FastMCP server with 19 verification tools — branch protection, audit logs, AI-call routing, skill search, diff, prisma studio. Boring infrastructure week. Boring infrastructure is good.

If you’re keeping score: that’s four repos with substantive commits in seven days, all while running an active job search. The fact that I can do that is the toolkit doing its job.

The other layer

I’m between roles. Anyone who’s followed along knows that. Family stuff in the mix means I’m deliberate about fit right now — and “deliberate” doesn’t mean “slow,” it means I know exactly what I’m looking for and I won’t sign for less. Senior engineering roles where the AI work is real, the team is serious, the problem is hard. Not AI-strategy-document jobs.

My kid had a great week at his Challenger sports program — the league for kids of all abilities. Every week I’m reminded that the people who run those programs are doing harder work than most engineering teams I’ve been on, with a fraction of the resources, and they show up cheerful every Saturday. I think about that a lot.

What’s next

Two threads. On the engineering side: dom gets a release tag this week and I start dogfooding it across all the side projects — already doing that, but now with versioned install instructions. On the job-search side: several real conversations in motion. Not naming names; the right ones are good shape.

If you’re here from a posting or recruiter intro — what I write here is what I think.

More next week.

graph TB
    A[Robby<br/>Vertex]
    B[Mort AI Nexus<br/>Vertex]
    C[Data Cake<br/>Vertex]
    D[Voice biometric<br/>JPMC]
    E[Strangler-fig<br/>Connect Your Care]

Figure: five systems, five domains.

1. Robby — Multi-Agent SDLC System

Where it ran: Vertex Inc., Data & Insights value stream My role: Inventor, lead engineer Year: 2024–2026

The premise was the super-chicken problem. Teams stacked with high individual performers were producing less, not more. People were spending half their day in process — Jira hygiene, status updates, sprint planning, design reviews — and the half they had left wasn’t enough to do the actual work.

Robby is a patent-pending multi-agent AI system for SDLC orchestration. The bet was that an AI layer could absorb the process work eating my team’s day and give the humans back the hours they came here for. It paid out. The afternoons that used to vanish into Jira hygiene started going back into engineering.

Tech: multi-agent AI tooling, ArgoCD, GitHub Actions, Datadog Outcome: Adopted across multiple teams; the “Raise the Boats” workshop trained ~50 engineers in the live cohort on how to extend the same approach Deeper read: Robby: I Built an AI System to Kill the Super Chicken Problem

2. Mort AI Nexus — Multi-State Economic Nexus Detection

Where it ran: Vertex Inc., Indirect Tax Intelligence My role: Inventor, principal engineer Year: 2024–2026 Status: Patent pending

The Wayfair ruling in 2018 changed sales-tax compliance for every company doing business across state lines. Each state set its own thresholds — typically $100K in revenue or 200 transactions per year — and once you crossed the line you owed sales tax in that state. The catch: most companies didn’t know they’d crossed until a state notice arrived months later, with penalties and interest stacked on top.

The existing approach was reactive. Tax teams reviewed quarterly reports and chased compliance after the fact. Financial exposure for a single missed state could run $100K–$500K.

Mort AI Nexus is a patent-pending AI system that shifts nexus discovery from reactive to predictive — so compliance teams can register and configure tax calculation ahead of crossing a state’s threshold, instead of catching up after a state notice arrives. Customers stopped finding out about exposure from state notices and started finding out from the platform, weeks before the line.

Tech: Java, Spring Boot, AWS Outcome: Customers shifted from reactive quarterly reviews to forward-looking nexus monitoring; preventable penalty exposure reduced

3. Voice Biometric Fingerprinting — JP Morgan Chase

Where it ran: JPMC TARA Fraud Busters, retail banking My role: Lead developer Year: 2018–2019

Knowledge-based authentication was a broken control. Every breached database in the prior decade had handed the answers — mother’s maiden name, last four of the social — to whoever wanted them. A rep could ask all the right questions and authenticate the wrong person.

We built a voice biometric fingerprinting service inside JPMC’s TARA Fraud Busters group. The service captured a passive voice fingerprint during the natural course of a customer call, matched it against the enrolled fingerprint for that customer, and returned a confidence score the rep saw before authenticating. The customer didn’t have to say a passphrase. They just had to talk for a few seconds, which they were going to do anyway.

The deployment numbers told the story. 10 million unique JPMC accounts opted in during the first three months. Only 1,300 customers opted out. That’s a 99.87% adoption rate. The pilot shortened the average authenticated call by 20 seconds because reps weren’t grinding through knowledge-based questions any more — which translated to 25 more customers serviced per rep per day.

The fraud-prevention number is the headline (~$830B in losses prevented across the deployment cohort). The customer-experience side was the quieter win. Security that made the customer’s day shorter instead of longer is the kind of control people don’t opt out of.

Tech: Python, ML/biometrics, REST APIs, Sapiens rules engine, Angular dashboard, JavaScript Outcome: ~10M accounts onboarded in 90 days; 20-second call reduction per authenticated call; ~$830B in fraud losses prevented across the deployment cohort

4. Data Cake — NLP Synthetic Tax Data Generation

Where it ran: Vertex Inc., AI research My role: Inventor, principal engineer Year: 2024–2026 Status: Patent pending

You can’t train tax AI on real customer transactions. The data is PII-laden, regulated, contractually restricted. You also can’t train tax AI without realistic transactional data — synthetic data that doesn’t reflect the statistical properties of real tax events produces models that fall apart in production.

Data Cake is a patent-pending system for generating realistic synthetic tax data that ML projects can train against without putting real customer transactions at risk. Synthetic outputs respect tax-law validity, so downstream models train on something that actually behaves like the production world.

What changed when we deployed it: model training stopped being a regulatory negotiation. New ML projects could spin up training data in days instead of quarters, without ever touching real customer information.

Tech: Python, NLP-driven generation Outcome: Removed the data-access bottleneck for AI model training; enabled tax ML projects that previously couldn’t be greenlit

5. Connect Your Care — Monolith to Microservices

Where it ran: Connect Your Care, HRCommand product My role: Architect & lead engineer Year: 2019–2021

Connect Your Care was a benefits-administration company sitting on a J2EE/EJB monolith built across the better part of a decade. HRCommand was the flagship product. The monolith worked. It served customers. It also blocked every strategic initiative the company wanted to ship — new product surfaces, new payer integrations, modern UX, all of it.

Standard advice for a monolith of that age is rip-and-replace. Standard outcome is a multi-year project that ships nothing while leadership rotates and the rewrite gets killed.

We didn’t do that. We picked the strangler-fig pattern. Identified the bounded contexts inside the EJB monolith that were ready to come out — usually the ones with the most volatility or the clearest data ownership boundary. Built each one as a Spring Boot microservice running alongside the legacy WebLogic/Puppet stack. Routed live traffic to the new service through a thin proxy that fell back to the monolith on failure. Validated for two weeks per service. Then peeled it off the monolith. Repeat.

Five-person team. The React rewrite of the HRCommand UI shipped on Figma-to-code component delivery, so design and engineering were never out of sync on what was being built. We never broke production. We never took the platform down for a release. We did decompose enough of the monolith — and ship enough new product surface on top of the new architecture — that the company became attractive to acquirers in a way it hadn’t been before.

UnitedHealth / Optum Financial acquired Connect Your Care in 2021. The architecture work was a direct contributor to the acquisition thesis. That’s the part of this story I’m proudest of, and the part I’d repeat if I had a stable, profitable platform that needed to be modernized without being broken.

Tech: Spring Boot, J2EE/EJB, WebLogic, Puppet, React, Figma-to-code Outcome: Modernized core product platform without downtime; contributed to UnitedHealth/Optum Financial acquisition

If you’re working on something with the same shape and want to talk it through, I’m at Dominick.do.Campbell@gmail.com, or LinkedIn.

Nine jobs, mainframe to AI. A handful of things have held true across all of them. None of them are in the architecture books.

graph LR
    M[Mainframe] --> J[J2EE]
    J --> S[Microservices]
    S --> C[Cloud]
    C --> A[AI]

Figure: every era. Same fundamentals underneath.

1. The database outlives everything

You will rewrite the application 4 times. The schema you shipped in 2008 will still be there in 2026, quietly haunting every new engineer who joins the team. I’ve watched it happen on Oracle, on DB2 over an IBM AS/400, on Postgres, on Snowflake. Different decade, same schema, different application sitting on top of it.

Design the data model like it’s permanent. It basically is.

2. Observability is a feature, not a tax

Every system I’ve seen fail catastrophically failed silently first. The tax close pipeline at Vertex processing 50M–100M transactions a day didn’t fall over loudly. It drifted for hours before anyone noticed. In every case I can think of, the dashboards came after the outage, when they should have come before the launch.

Build the dashboards before you build the features.

3. AI doesn’t change the fundamentals, it raises the stakes

I hold 4 patent-pending AI inventions now. I’ve built LLM-backed audit defense tools, a synthetic data generator, and a multi-agent SDLC system. The most important thing I’ve learned from any of it:

AI doesn’t eliminate the need for good system design. It punishes bad system design faster.

A traditional service with a weak design degrades. An AI service with a weak design starts inventing answers, and it sounds confident doing it.

4. The best engineers I’ve met are fundamentally teachers

At Vertex I built and delivered the “Raise the Boats” curriculum: 200+ engineers and analysts through the program, ~50 through the live cohort I taught myself. The engineers who treated teaching as overhead were the same ones whose systems left with them when they left the company.

5. Every great product I’ve shipped had a clear owner

HRCommand at Connect Your Care drove the Optum acquisition because one architect owned the EJB-to-Spring-Boot decomposition and one team knew who was making the calls. The voice biometric fraud system at JPMC hit 10 million accounts in three months with 1,300 opt-outs because someone took the heat for the design and stayed with it. Committees come later, after the thing already works.

Twenty-five years and the lessons keep coming from the same place: the data, the boring dashboards, the person who owns the thing. If any of this lands, find me on LinkedIn or GitHub.

More soon.

I’m a Principal Engineer with 25+ years of experience and four patent-pending AI inventions, and I’m still relearning how to do this. A few things from the first few weeks.

graph LR
    A[Apply] --> S[Recruiter screen]
    S --> H[Hiring manager]
    H --> T[Technical loop]
    T --> O[Offer]
    T -.most candidates exit here.-> X[No]

Figure: the senior-engineer funnel — and where it actually filters.

The ATS problem is worse than you think

I knew ATS (Applicant Tracking Systems) existed. I didn’t appreciate how aggressively they filter until I started testing my own resume against job descriptions.

If your resume isn’t formatted for machine parsing, a human may never read it. I rebuilt mine from scratch in LaTeX to get clean pdftotext output, and good thing. My original version had a font artifact: the small-caps rendering was mapping the letter ‘I’ in “Principal” to a lowercase glyph in the extracted text. ATS was reading “PRiNCiPAL ENGiNEER.” Nobody told me. I caught it because I checked.

Run pdftotext on your resume and read what it outputs. That’s what the system sees.

The “AI will take your job” narrative is backwards for senior engineers right now

The engineers getting squeezed by AI are the ones who were doing work that was always a bit mechanical: boilerplate CRUD apps, basic data pipelines, junior ticket work. That’s real, and I’m not dismissing it.

But for senior engineers who can architect a system, weigh the tradeoffs, and lead a team through an ambiguous problem, the demand is higher than I expected. Companies are building AI products faster than they can find people who know how to build them responsibly.

The principal and staff descriptions I’m seeing ask for multi-agent system design, LLM observability, and the reliability patterns that keep an AI transformation from blowing up in production. Narrow pool. I happen to be in it.

The conversation that’s changed

In 2022, most senior technical interviews were about system design: scale, tradeoffs, distributed systems. That’s still there. Now there’s an overlay.

How would you AI-enable this? shows up everywhere. Fine question. What’s telling is how wildly the interviewers vary in their own understanding. Some are genuinely sophisticated. Some are fishing to see whether you’ll bolt an LLM onto everything, which is the answer they’re hoping you won’t give.

So be honest about what AI is good at and where it falls down. The interviewers who matter respect that more than enthusiasm without nuance.

What I’m looking for

I want to build something real. Not a proof-of-concept, not an “AI strategy” document, but a production system that solves a hard problem for people who need it solved.

I know tax, compliance, and fintech. I’m open to any technically hard problem where the stakes are real and the team is serious.

If that’s you, find me on LinkedIn.

More soon.

So this isn’t a bubble post. It’s a post about how fast it’s actually moving, because the keynote version and the 11pm version are not the same conversation.

graph LR
    I[Inflated<br/>expectations] --> D[Disillusionment]
    D --> P[Productivity<br/>plateau]
    P --> V[Real value]

Figure: agentic AI follows the curve — the value at the end is real; the timeline isn’t.

The capability is there

The foundation models are good. GPT-4-class models reason across multi-step problems, synthesize large document sets, write production code, chain tool calls in ways that would have looked like science fiction five years ago when I was still doing AWS Solutions Architect study cards on a Sunday morning. crewAI matured. AutoGen matured. LangGraph gives you proper state management for non-trivial flows, which the early versions absolutely did not.

If you want an agent that researches a topic, drafts a report, validates sources, and formats the output — that works today. Genuinely. I’ve watched a non-engineer at Vertex build a RAG over an audit knowledge base in four hours during a workshop I taught, and that workshop is part of why ~200 employees got trained on this stuff in two years. The capability floor has fallen far enough that the bottleneck is no longer “can the model do it.” It’s “do you know what to ask it to do.”

Where the production version diverges

The keynote demos show the agent taking action — submitting filings, modifying records, moving money. In tax, finance, and healthcare, you cannot let an agent autonomously do any of those without a verification layer in front of it. The reason is the legal and operational reality of regulated domains, not a hole in what the model can do. Build for human-in-the-loop by default, not as the thing you bolt on after compliance asks.

Reliability is the second thing the demos don’t show. A single agent call has maybe a 2–3% failure rate on a complex task — hallucination, tool error, context-window weirdness. Chain five and that compounds into something nobody wants to look at on a Monday. You need retry logic, fallback paths, observable failure states. The pretty demos have none of it, which is why they don’t survive contact with a real workload.

Context windows are the third. Yes, they’re huge now. Large context is not the same as coherent context. I’ve watched 128K-window models quietly forget early constraints around the 90K-token mark, with no warning and a confidence score that looks identical to the runs that didn’t forget. Chunk and retrieve. Don’t stuff the window and hope.

The shape that holds up

Small agents with clear contracts. Not one big orchestrator trying to be everything — a pipeline of focused agents, each with one job, explicit inputs and outputs, and its own observability. Closer to microservices than monoliths. I’ve watched both shapes ship and only one of them is still running.

Prompts are code. Version them, test them, review them before they go to production. I’ve seen production incidents that traced back to a prompt edit nobody reviewed because it was “just text.” Treat them like the load-bearing strings they are.

The companies that win this cycle won’t be the ones with the most impressive demos. They’ll be the ones who figured out how to run agents reliably, observably, and safely at the scale a real business needs. That’s an engineering problem, and engineers who’ve been doing this for a few years right now have a real edge. I’d rather spend that edge building things that work than shipping a demo that hallucinates a tax filing.

More soon.

That was week two. The moment I knew the curriculum worked.

By the time we wrapped, 200+ Vertex employees across engineering, product, data science, and finance had been through the AI Curiosity Workshop — internally called “Raise the Boats.” About 50 came through the live cohort I taught. The rest worked through the curriculum around it.

graph TB
    W[Workshop<br/>graduates] --> R[Higher waterline]
    R --> T[Team operating<br/>higher]

Figure: what “raise the boats” means in practice.

Where the framing kept failing

Most of the engineers I worked with at Vertex are sharp. So I assumed the early sessions would land. They didn’t. I opened with how transformers work, with token windows, with embeddings. People nodded politely and walked out unable to picture what they would actually do with one of these things on Monday morning.

The shift came when I rewrote the opener. Instead of starting with the machinery, I started by asking what each person hated about their week. The thing they avoided. The thing that made them want to throw their laptop.

Then we built something that handled that. The analyst’s audit RAG was one of those. So was a product manager chaining three tools together to triage a support backlog she’d been staring at for months. So was the data analyst who got tired of waiting on engineering and shipped her own first prompt template by Wednesday.

The framework was never the barrier. Permission to imagine was.

What I told them worked, and what didn’t

We used crewAI and AutoGen heavily. Both are solid. The honest cut between what shipped to production and what looked great in a demo:

What works in production:

• Multi-agent pipelines for research and synthesis (summarize, validate, format)
• RAG over structured internal data — policies, audit histories, transaction logs
• Code review and doc-quality tooling

What doesn’t, yet:

• Fully autonomous decisions on anything with financial consequence
• Agents that “just handle it” with no human-in-the-loop step somewhere
• Anything where the failure mode is silent

That last one is the bit I hammered on every session. A traditional service throws a 500. An agent confidently gives you a wrong answer with excellent grammar. Those aren’t the same failure mode and they don’t get caught by the same monitoring.

The unexpected win

The best outcome wasn’t the tools people built. It was the language they started using.

Teams began having different conversations. Instead of “we need a developer to build a script for this,” it was “can we agent this?” Product managers were writing prompt templates. Finance analysts were chaining tools together. The vocabulary changed, and what felt possible to ask for changed with it.

That’s what the name actually meant. Not everyone becomes an ML engineer. The whole team operates at a higher waterline.

Back to work.