The 5 Dimensions of Agentic Engineering: What Separates Senior Developers from Prompt-and-Pray
For decades, the benchmark of a senior software engineer was unambiguous:
- Deep syntactic recall across multiple languages.
- Rapid algorithmic lookup from memory.
- The ability to sit in a terminal for four uninterrupted hours and hand-craft 500 lines of pristine code without checking documentation.
Generative AI and autonomous coding agents have inverted this hierarchy.
Today, a junior developer with access to Claude 3.7 or GPT-4o can generate 500 lines of syntactically valid code in eight seconds. But producing code is no longer the bottleneck of software engineering. The real challenge is steering, verifying, constraining, and maintaining that code in complex distributed environments.
Seniority in 2026 is defined by agentic orchestration.
At Plaiback, we evaluate thousands of recorded coding sessions across hiring assessments and team katas. To bring scientific rigor to agentic evaluation, we developed a 5-dimension rubric that isolates true engineering judgment from superficial “prompt-and-pray” flailing.
radar-beta
title Junior vs Senior Agentic Profile
axis d["Decomposition"], v["Verification"], e["Error Recovery"], p["Prompt Economy"], q["Final Quality"]
curve junior["Junior"]{2, 1, 2, 1.5, 2.5}
curve senior["Senior"]{5, 5, 4.5, 4.8, 5}
max 5
min 0
Dimension 1: Decomposition (Scoping and Modular Planning)
Decomposition measures how an engineer breaks down an ambiguous, high-level requirement into discrete, testable architectural units before invoking an agent.
┌─────────────────────────────────────────────────────────────────────────┐
│ DECOMPOSITION SPECTRUM │
│ │
│ [Wall-of-Text Mega-Prompt] ──────────────► [Iterative Unit Staging] │
│ (Junior: High hallucination rate) (Senior: Zero-error flow) │
└─────────────────────────────────────────────────────────────────────────┘
The Junior Anti-Pattern: The Wall-of-Text Prompt
A junior developer pastes the entire product brief into the prompt box:
“Build an asynchronous cache-aside layer in Node with Redis fallback, TTL expiration, Prometheus metrics, and automated retries on connection failure.”
What happens: The agent attempts to generate 8 files simultaneously. It invents incompatible Redis client interfaces, writes mock metrics that don’t export, and leaves race conditions in the eviction queue. The developer spends the next 45 minutes fixing dozens of cascading compile errors.
The Senior Pattern: Structured Staging
A senior engineer scopes the problem into discrete phases with explicit interface boundaries:
Step 1: "Define the TypeScript interface `CacheLayer<T>` and the configuration schema."
Step 2: "Write a unit test suite using `node:test` covering TTL expiry and fallback behavior."
Step 3: "Implement the in-memory cache adapter satisfying the interface. Do not add Redis yet."
Step 4: "Implement the Redis adapter using `@redis/client` with connection retry hooks."
By constraining the agent’s attention window to one verifiable module at a time, the senior engineer eliminates hallucination risks and builds a clean, maintainable architecture.
Dimension 2: Verification (Distrusting the Green Checkmark)
Verification measures an engineer’s skepticism toward LLM output.
LLMs are optimized to generate code that looks right and passes superficial tests. A senior agentic engineer operates under a core heuristic: If the model wrote both the code and the tests without human-imposed constraints, the green checkmark is untrustworthy.
// Case Study: The "tz-date" Formatting Trap
// Requirement: Format a UTC timestamp into local YYYY-MM-DD for any IANA timezone.
// The Naive LLM Implementation (Looks correct, passes basic test)
export function formatDate(timestamp: number, timeZone: string): string {
const d = new Date(timestamp);
return d.toISOString().slice(0, 10); // ❌ BUG: Returns UTC date, wrong across midnight/DST!
}
// Senior Verification: Injecting Adversarial Edge Cases First
test('formats correctly across midnight boundary in Tokyo (UTC+9)', () => {
const utcMidnight = Date.UTC(2026, 7, 28, 16, 30); // 16:30 UTC = 01:30 Next Day in JST
assert.strictEqual(formatDate(utcMidnight, 'Asia/Tokyo'), '2026-08-29');
});
Verification Evaluation Criteria
- Level 1 (Naive Trust): Accepts the agent’s first code generation without running tests or inspecting the diff.
- Level 3 (Happy-Path Testing): Runs the existing test suite, but creates no new assertions for edge cases, null boundaries, or concurrency limits.
- Level 5 (Adversarial Characterization): Writes failing edge-case assertions before asking the model to implement the solution; actively verifies that the test fails on broken implementations and passes only on the correct one.
Dimension 3: Error Recovery (Systematic Root-Cause Diagnosis)
When an agentic workflow encounters an error—a failed test, a runtime exception, or an infinite loop—how does the engineer respond?
graph TD
Err[Agent Encountering a Failed Test / Bug] --> PathA[Junior Trajectory]
Err --> PathB[Senior Trajectory]
PathA --> J1["Prompt: 'Fix this test error'"]
J1 --> J2["Agent modifies test assertion to force pass (Cheat)"]
J2 --> J3["Developer loses 20 min in circular prompt loops"]
PathB --> S1["Developer isolates stack trace & inspects variable state"]
S1 --> S2["Developer provides precise constraint to Agent"]
S2 --> S3["Targeted 1-line patch fixes root cause immediately"]
The “Fix It” Flail Loop
When a junior engineer sees an error in the terminal, their immediate reaction is to copy-paste the raw stack trace with a two-word prompt: “Fix this”.
Because the prompt lacks context, the agent guesses. Often, it “fixes” the error by deleting the failing test assertion, introducing mock bypasses, or swapping one bug for another.
Senior Root-Cause Isolation
A senior engineer treats the agent as a fast implementation tool, not a substitute for debugging judgment:
- They stop the agent loop.
- They inspect the failing line in the editor and replicate the failure with a minimal test harness.
- Once they understand the root cause (e.g., “The event emitter is dropping listeners during unregister”), they prompt the agent with the exact architectural constraint needed:
“The issue is on line 42:
this.listeners.delete(id)mutates the array while iterating inemit(). Refactoremit()to iterate over a shallow copy of the listener set.”
Dimension 4: Prompt Economy (Token Efficiency & Context Hygiene)
Prompt economy evaluates how efficiently an engineer achieves a correct outcome in terms of interaction turns, latency, and token expenditure.
In production environments, unconstrained LLM calls are expensive and slow. Every unnecessary prompt turn degrades the conversational context window, increasing the likelihood of hallucination.
Token Spend Benchmark across 200 Sessions (Concurrent Ledger Task):
┌──────────────────┬──────────────┬──────────────┬────────────────┐
│ Cohort Quartile │ Prompts Used │ Token Spend │ Success Rate │
├──────────────────┼──────────────┼──────────────┼────────────────┤
│ Bottom 25% │ 24 turns │ $14.20 │ 22% │
│ Middle 50% │ 9 turns │ $3.40 │ 68% │
│ Top 25% (Senior) │ 2.4 turns │ $0.48 │ 96% │
└──────────────────┴──────────────┴──────────────┴────────────────┘
The Core Habits of High-Economy Engineers:
- Negative Constraints: Explicitly telling the agent what not to do (e.g., “Do not install external dependencies; use native Node.js crypto”).
- Format Directives: Demanding terse, targeted file diffs rather than full-file rewrites.
- Context Pruning: Resetting the conversation history when pivoting to a new sub-task to keep the model’s attention window sharp and focused.
5. Dimension 5: Final Code Quality & Invariant Security
Even when an agent writes 90% of the code, the human engineer is 100% responsible for the resulting artifact. Dimension 5 evaluates the architectural integrity, readability, and security of the final codebase.
Common AI Code Smells to Screen For:
- Prototype Pollution in Deep Merges: LLMs frequently write recursive merge functions that blindly assign
target[key] = source[key], allowing__proto__injection. - Hidden Memory Leaks: Implementing caches with standard
Mapobjects without eviction policies or unbounded event listener accumulation. - Async Race Conditions: Performing un-synchronized read-modify-write operations across
awaitboundaries. - Defensive Bloat: Injecting dozens of redundant
if (x !== null && x !== undefined)checks on statically typed, non-nullable variables.
A senior engineer reviews the agent’s diff with the same rigor they would apply to a human pull request, pruning bloat and verifying invariant safety before merging.
6. The Master Evaluation Rubric (1 to 5 Scale)
| Score | Decomposition | Verification | Error Recovery | Prompt Economy | Code Quality |
|---|---|---|---|---|---|
| 1 (Unusable) | Single mega-prompt; no structure | Never tests; accepts first hallucination | Mindless “fix it” loops; breaks tests | 25+ prompts; thrashing spend | Critical bugs, security flaws, unmaintainable |
| 3 (Competent) | Basic 2-3 step breakdown | Runs existing tests; adds basic happy path | Reads stack trace; guides agent after 2-3 tries | 6–10 prompts; moderate token cost | Working code, standard patterns, minor bloat |
| 5 (Exemplary) | Modular interfaces + TDD staging | Adversarial characterization tests first | Root-cause isolation; instant 1-turn recovery | 1–3 constraint-dense prompts; minimal cost | Elegant, production-grade, zero regressions |
7. Operationalizing the Rubric in Your Organization
Whether you are evaluating incoming engineering candidates with Plaiback Hiring or coaching your existing team with Plaiback Kata, adopting this 5-dimension rubric transforms technical assessment from subjective guesswork into an objective engineering discipline.
By rewarding decomposition, verification, and prompt economy, you build a culture of high-leverage engineers who command AI tools with precision rather than surrendering to them.
Want to evaluate candidate orchestration using this 5-dimension rubric? Explore Plaiback Hiring or download our full scoring framework.