FIELD NOTE / INSTAGRAM
Generated apps still need four engineering models.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved Instagram edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
Generated apps still need four engineering models.
Video caption
Generated apps still need four engineering models.
One repository rarely contains the whole answer.
The candidate can reason through a test without building it.
Sessions expire; causal models stay useful.
#EricFieldNotes
Full written post / accessibility read
A polished AI-built screen can conceal uncertainty in four places: data contracts, state transitions, trust boundaries and operations. You need an engineer who can trace each layer when a feature crosses services. The question is not whether the agent writes code; it is who knows what that code means in production.
For data, ask which old events can reappear. For state, ask what retry or partial failure does. For trust, ask which identity may act. For operations, ask how a bad release is detected and rolled back. These are ordinary fundamentals; their importance rises when plausible patches arrive faster.
Show a fictional producer diff and a lagging consumer. Ask what an older queued event should produce and which changed field would make an independent replay probe turn red. Listen for the expected business outcome, not merely another green producer assertion. The employer owns the fixture; the interview tests the engineer's model.
Keep architecture, data-flow and failure reasoning in the hiring bar. Do this because the person who can explain the system can ask the agent for a better patch, identify a broken assumption and preserve the reasoning for the next owner. A glossy result without that understanding is hard to maintain.
#EricFieldNotes
Four-beat scene transcript
1. Generated apps still need four engineering models.
A polished AI-built screen can conceal uncertainty in four places: data contracts, state transitions, trust boundaries and operations. You need an engineer who can trace each layer when a feature crosses services. The question is not whether the agent writes code; it is who knows what that code means in production.
Visual: Surface polish is a weak acceptance test.
2. Name the contract at each layer.
For data, ask which old events can reappear. For state, ask what retry or partial failure does. For trust, ask which identity may act. For operations, ask how a bad release is detected and rolled back. These are ordinary fundamentals; their importance rises when plausible patches arrive faster.
Visual: One repository rarely contains the whole answer.
3. Ask where the generated feature crosses a boundary.
Show a fictional producer diff and a lagging consumer. Ask what an older queued event should produce and which changed field would make an independent replay probe turn red. Listen for the expected business outcome, not merely another green producer assertion. The employer owns the fixture; the interview tests the engineer's model.
Visual: The candidate can reason through a test without building it.
4. Fundamentals are the repair manual.
Keep architecture, data-flow and failure reasoning in the hiring bar. Do this because the person who can explain the system can ask the agent for a better patch, identify a broken assumption and preserve the reasoning for the next owner. A glossy result without that understanding is hard to maintain.
Visual: Sessions expire; causal models stay useful.
Research and claim limits
- U.S. OPM: Work Samples and Simulations (S151)
- Google Research, Towards AI as a Collaborative Partner (S155)
The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.