Give context first
"We're in the payment processing module. Goal: cut latency without breaking PCI compliance. Current architecture is X. Constraints are Y." Not "optimize this function." The kitchen counter, not the bathroom counter.
Slide 01
My daughter Lily is nearly five. I told her "put the plate on the counter." She walked to the bathroom counter — she'd washed her hands there before breakfast. In her context, that was "the counter." That's your LLM. All of human knowledge. And it walked to the bathroom counter.
Slide 02
"We're in the payment processing module. Goal: cut latency without breaking PCI compliance. Current architecture is X. Constraints are Y." Not "optimize this function." The kitchen counter, not the bathroom counter.
"Walk me through your approach before you write anything." Like asking Lily: "Tell me the steps you're going to take to put that plate on the kitchen counter." If her plan involves climbing on the counter and swinging from the light fixture, you catch that before she starts.
"Caching works, but adjust for data freshness requirements." Concrete feedback against a known plan. Not vague "that's not quite right." Save what works as your standard approach — it becomes organizational knowledge.
Slide 03
These were valuable because code generation was the bottleneck. The 10x engineer was the one who could produce correct code faster than everyone else. That constraint is gone.
The engineers who struggle are the ones who skip the context step. The engineers producing the most value are the ones who've made specification writing a discipline — not an afterthought.
Slide 04
Slide 05
This is a process investment, not a tooling investment. The tool is fine. The gap is in how your team prepares context, reviews plans, and iterates with specificity.
Teams that make this investment see first-pass success rates increase, cycle time decrease, and senior engineer time shift from cleanup to architecture — which is what you wanted all along.