Role: Builder and product owner · Built on: Amazon’s internal OpenClaw platform · Outcome: 80% reduction in manual processing time
Confidentiality note. Written at the level of detail already public on my resume. Repository paths, build configuration and workflow specifics are omitted; the diagram is redrawn for this portfolio.
The 30-second version. Shipping a change — SQL or Python — to the production repository meant eight mandatory steps before anyone could even look at it, and 30 to 60 minutes each time. None of that time was spent thinking. I built a skill on Amazon’s internal OpenClaw platform that performs all eight, leaving about five minutes of actual decisions. It stops at the point a reviewer picks the change up, which is the only part of the sequence where a human was ever the point.
1. Eight steps between finishing and being reviewed
The change itself might take twenty minutes. Getting it to a place where a colleague could read it took longer than writing it:
- Open the cloud desktop
- Rebase against current main
- Copy the code up from local
- Authenticate and save it
- Build in the beta environment
- Run it in beta and check the output is right
- Push the change as a new commit
- Publish the review
Then a peer reviews it, and the data engineer on the team merges it to production.
Every one of those eight is mandatory, none is difficult, and none is where the work lives. It is ceremony — the tax between having done something and being able to show it to somebody.
Two things follow from that shape:
The cost is per-change, so it taxes small changes hardest. A one-line fix and a substantial rewrite carry identical overhead. That is a quiet incentive to batch changes into larger ones — which is the opposite of what you want, because large reviews are worse reviews.
The step most likely to be skipped is step six. Building and checking in beta is the one with no immediate consequence for skipping it, and it is the one you skip at 6pm on a Friday. The steps that protect you are always the steps under the most pressure.
2. What is automated, and where it stops
The skill covers the whole span from opening the cloud desktop to publishing the review. It does not review the change, and it does not merge it.
That boundary is the design, and it is worth stating as a rule: automate up to the point where judgment starts, and stop there sharply. Not “stop where the model gets unreliable” — stop where a human being was the reason the step existed. A peer reads the change because somebody other than the author should look at it. A data engineer merges because production is their responsibility. Neither of those is overhead that happens to be manual; both are the point.
Automating toward the reviewer rather than past them also means the failure mode is contained. The worst thing the skill can do is publish a bad review — which a reviewer then reads, disagrees with, and rejects. That is the system working.
3. The five minutes that stay human
What remains is not leftover friction. It is the set of things the automation genuinely cannot infer, and naming them precisely is what made it possible to automate everything else:
- Where the file is locally. No safe default; guessing wrong pushes the wrong change.
- What configuration applies on this push. Depends on what the change is for.
- If there is a DDL change, which folder it belongs in. Schema changes are placed by convention, and convention is a judgment about what the change means, not what it contains.
Each of these is a question with a right answer that only the author holds. Everything else in the sequence was a step with exactly one correct execution, repeated identically every time — which is the definition of work worth automating.
The useful test is not “can this be automated” but “does this step have more than one correct outcome.” If it does, a person decides. If it doesn’t, nobody should be spending thirty minutes a week on it.
4. Validation stops being skippable
The skill builds the change in the beta environment, runs it, and validates the output before it pushes anything. It also handles the errors that come back rather than stopping at the first one.
This is the part I would argue is more valuable than the time saved, even though the time saved is what the number measures.
Step six — build it and check the result — was always the correct thing to do and always the first thing to go under deadline pressure. Making it automatic doesn’t just make it faster; it makes it unconditional. The check now happens on the 6pm Friday change exactly as it happens on the Tuesday morning one.
Reliability improvements that depend on people being disciplined degrade precisely when the system is under the most stress. Moving the check into the path removes the discipline requirement entirely.
5. Why the 80% understates it
Thirty to sixty minutes down to about five is the headline, and it is a per-change number.
But the second-order effect is the one worth watching. When overhead per change is high, the rational response is to batch — bundle several changes into one review so the tax is paid once. Large reviews get worse scrutiny, because reviewer attention does not scale linearly with diff size, and problems hide in volume.
Cutting per-change overhead removes the incentive to batch. Smaller, more frequent reviews are easier to read, easier to reason about, and easier to revert. None of that shows up in “80% less manual processing time,” and all of it follows from it.