While studying for the AWS Data Engineer cert, I did what Amazon trains into you: work backwards from the customer, not the technology.
Here’s the gap I found, and what I built to fill it…
@bcherny Your step 4 question about spending eng effort is the sharpest filter in here. I see teams running parallel agents but if someone’s still reading every diff line by line, they’re still at step 2 with more noise. What separates real trust in the loop from just more activity?
I think that’s the seat companies will keep paying for over the next few years, not the AI specialist, but the person who can sit between the domain and the architecture and see the whole shape of the problem.
One of the more interesting conversations I’ve had this year was with Netflix, about a role rebuilding their financial infrastructure — comp topping $700K.
What struck me wasn’t the number. It was why the number exists..
That combination is rare because most careers force a choice early, go deep in finance, or go deep in systems. Few people get to do both long enough to be fluent in each..
I’m learning this from both sides: building financial infrastructure in large-scale systems and deepening my AWS data engineering skills as I work toward certification.
The last year inside Amazon has looked a lot like this: a flood of AI tools, most of them redundant, short-lived, and measured by the wrong things.
We kept chasing token counts and adoption, while the real question was whether anything actually got faster, cheaper, or smarter…
like downtime, margin, and delivery speed. The next generation of product thinking is not “Where do we put AI?” It’s “What job are we automating, and what data makes that possible?” What matters isn’t how much AI you use, but whether the business is better because of it..
While studying for the AWS Data Engineer cert, I did what Amazon trains into you: work backwards from the customer, not the technology.
Here’s the gap I found, and what I built to fill it…
The build taught me more than the architecture did. Spent an hour convinced it was broken — 200 OK on every request, nothing downstream, no errors.
Turned out SQS was working exactly as designed. My test data wasn’t unique enough to prove it wasn’t a duplicate.
Lessons from Amazon: at a certain scale, bad data turns finance into archaeology. You’re not analyzing, you’re trying to infer reality from partial artifacts, mismatched systems, and janky models. That’s not an accounting problem, it’s a broken system problem & why I built Sitka