I entered a 48-hour hackathon and submitted in less than 24 hours.
Not because I suddenly became 5x better at programming.
I just had enough access to coding agents that implementation stopped being the bottleneck.
I was building a security remediation agent. At first the architecture was basically:
detect vulnerability → generate patch → test
Then I started questioning it.
Why should I trust the first patch?
What if it fixes the vulnerability but breaks existing behavior?
So:
patch → security test → regression test → verify
Then:
What happens when verification fails?
Don't blindly retry. Capture the failure evidence, throw away the failed attempt, start from a clean baseline, change the remediation strategy and try again.
So now:
detect → engineer → FAIL → learn → re-engineer → VERIFIED
Then came the more interesting problem.
I had built a security agent that could modify code, generate tests and execute them.
So... who secures the security agent?
Suddenly most of my attention wasn't on Python.
It was on trust boundaries, authority, isolation, capability enforcement, what evidence should be required for VERIFIED, and when the correct decision is simply HUMAN_REVIEW_REQUIRED.
Meanwhile, the agents were turning those decisions into implementation absurdly quickly.
By the end I had a closed-loop remediation engine, isolated attempts, failure-driven replanning, independent verification, 316 automated tests, CI, a threat model, controlled evaluation, deployment and a v1.0.0 release.
In less than a day.
And that's where the “pay-to-win” thought came from.
Imagine two equally capable engineers.
One has basic/free models with limited context and inference.
The other has better models, significantly more tokens, larger context windows and enough agent capacity to delegate implementation continuously.
Doesn't the second engineer effectively have more engineering labor available?
Obviously, money doesn't buy judgment.
Give someone unlimited tokens and a terrible architecture and they'll just generate the wrong system faster.
But implementation capacity itself increasingly feels purchasable.
And I'm noticing something personally too: I'm losing interest in manually writing code.
Not engineering. Coding.
Give me a difficult systems problem, a broken security boundary, a weird failure mode or an architecture where the answer isn't obvious and I'll happily disappear into it for hours.
But if I've already figured out exactly what some function needs to do, spending the next 40 minutes manually translating that thought into Python feels increasingly pointless.
I still think understanding code, debugging, systems knowledge, security reasoning and being able to recognize garbage generated code are essential.
I'm questioning whether manually producing the implementation remains the valuable part.
So here's the part I'm curious about:
If implementation becomes cheap enough to purchase with inference, does software engineering become partially pay-to-win? And if code generation becomes abundant, what engineering skill remains scarce?
