How I Use Agents Without Stopping My Own Growth

Jared Currie · article · 2026-05-27 source ↗ Reader 🖥️

Agent Planning Artifacts Agentic Engineering Cognitive Surrender Desirable Difficulty & Productive Struggle Pull Requests & Async Code Review

Agentic coding tools are safe to lean on only if the developer deliberately keeps exercising the judgment they would otherwise outsource — by planning before delegating and reviewing generated code as if reconstructing its reasoning themselves — because the tools amplify whichever posture the developer brings to them.

practical · expository — First-person practitioner reflection arguing for specific habits (plan-first, slow-review) to preserve engineering judgment while delegating execution to agents. No data, no citations — a personal-practice essay, not an empirical or theoretical argument.

Structure

Part	Role
Opening: agents can inspect, plan, implement, and iterate — a step beyond autocomplete or Q&A.	context
The reframe: the workflow's most important variable is not agent capability but the developer's intentional engagement.	thesis statement
The danger named: agents make it easy to outsource thinking, producing shallow system understanding, because generated plans and code look reasonable at first glance.	problem statement / motivation
What judgment consists of: system design intuition, recognizing over-complex abstractions, weighing trade-offs, critical code review — capacities an agent cannot replace.	definition of the stakes
Practice 1: sketch a personal plan (outline, file list, assumptions) before asking the agent, then compare the agent's proposal against it.	evidence / practice
Payoff of practice 1: comparing plans exposes gaps in the author's own thinking or shows the agent optimizing for the wrong thing / missing codebase context — forcing architectural thinking rather than accepting the generated plan as the answer.	evidence / practice outcome
Practice 2: slow down when reviewing generated code rather than checking only compilation/tests; trace specific consequences (queries run, network/failure behavior, performance under real use) depending on what the change touches.	evidence / practice
Claim that agents are not automatically faster: sometimes they speed up repetitive work, sometimes they slow the author down via heavy-review code, missing context, or off-pattern paths.	qualifying evidence
Closing payoff: over time this posture has visibly built better engineering instincts (faster at unfamiliar code, better at edge cases, more aware of failure modes/performance costs, growing review checklist) — reframed as the actual goal: becoming a stronger engineer, not dependency.	conclusion

Key terms

outsource thinking
Accepting an agent's plan or code without independently verifying or comparing it against one's own reasoning, so the agent's output becomes the extent of one's understanding of the system.
planning muscle
The habit of independently sketching an approach (outline, files to touch, assumptions to validate) before an agent proposes one, exercised deliberately so it doesn't atrophy.
understand at a surface level
Approving code because it compiles and passes tests without tracing what it actually does to data access, network behavior, or performance under real use.

Propositions

explicitThe most important variable in an agentic coding workflow is not how much the agent can do, but how intentionally the developer stays engaged while it works.conf: high
explicitcorroboratedAgents make it easy to outsource thinking because they generate plans quickly, summarize unfamiliar files, and produce code that looks reasonable at first glance — creating a risk of shallow system understanding if accepted blindly.conf: high
supports ←No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p14 — That source diagnoses outsourced thinking as an emergent risk of agent use; this talk independently names the same risk as its central prescriptive warning ('do not outsource the thinking').
explicitSketching a personal plan before asking an agent to implement, then comparing the agent's proposal against it, surfaces gaps in the author's own thinking or reveals the agent optimizing for the wrong thing or missing codebase context.conf: high
supportsDet skal være vanskelig · p6 — Currie's plan-first habit is a deliberately reintroduced 'desirable difficulty' — voluntarily doing work an agent would remove, in order to preserve the learning that effort produces.
explicitAgents are not automatically faster: they sometimes speed up repetitive work but other times slow the developer down by producing code that needs heavy review, misses context, or breaks project patterns.conf: high
explicitReviewing agent-generated code by tracing its concrete consequences (what queries run, how services communicate and fail, how a shared path performs under real use) rather than checking only that it compiles and passes tests is what keeps understanding from degrading to a surface level.conf: high
extendsAgentic Code Review · p8 — Currie's practice of tracing queries/network behavior/performance rather than trusting compile+test is a concrete individual response to the problem this proposition names: with agent-written code, review must reconstruct reasoning that never existed in anyone's head.
explicitSustaining this deliberate-review posture over time measurably builds better engineering instincts — faster comprehension of unfamiliar code, better edge-case spotting, more awareness of failure modes and performance costs, and a growing personal review checklist.conf: medium
supportsAI coding creates two kinds of debt. You're only measuring one · p7 — Currie's self-reported instinct-building from sustained deep review is an individual-level anecdote matching the Infobip finding that cognitive posture (asking follow-up questions, demanding explanations) — not raw AI usage — is what predicts skill growth.
implicitWhether an agent strengthens or replaces a developer's judgment is not a property of the tool but of the posture the developer brings to using it.conf: high
supportsCognitive Surrender · p7 — Currie's whole essay is a first-person practitioner instance of exactly this claim: the same agent tool sharpens or hollows out judgment depending on the developer's posture, not the tool's capability.
implicitSystem design intuition, recognizing over-complex abstractions, weighing trade-offs, and critical code review are judgment capacities that cannot be acquired by observing an agent's output — they require the developer's own active exercise.conf: medium

Arguments

Developers using coding agents should deliberately sketch their own plan before delegating implementation, and should review generated code by tracing its real consequences rather than trusting that it compiles and passes tests. strength: medium

Explicit premises:

Agents make it easy to outsource thinking by generating plausible-looking plans and code.
Blindly accepting agent output risks shallow understanding of the system.
Software development requires judgment (system design intuition, trade-off assessment, critical review) that an agent cannot supply.

Implicit premises:

Judgment is a skill that atrophies without practice and can only be maintained by continuing to exercise it, even when a faster alternative (accepting the agent's output) is available.
A developer can reliably tell, in the moment, whether they are engaging critically or merely rubber-stamping — i.e., surface-level acceptance is a detectable and avoidable failure mode, not something that can happen unnoticed.

Inferences:

If judgment atrophies without practice, then any workflow optimization that removes the friction of planning or deep review (even a well-intentioned one) trades short-term speed for long-term skill loss — a cost the essay never puts a number on.
The prescription implies a personal, individual-level defense (habits one developer chooses to keep) rather than a team- or organization-level one (metrics, gates, review policy) — the essay's remedy operates entirely at the level of individual discipline.

Questions addressed

✅ How can a developer use agentic coding tools heavily without letting their own engineering judgment atrophy?
By deliberately continuing to plan independently before delegating, and by reviewing generated code deeply enough to trace its actual consequences rather than trusting surface signals (compiles, tests pass).
⭕ Is the discipline the author describes something innate to how they personally work, or a practice that generalizes — could a less disciplined or more time-pressured developer sustain it, and would it survive at team scale rather than as an individual habit?

Gaps

incompleteThe essay offers no account of how a developer would notice they had slipped from the described disciplined posture into surface-level acceptance — no signal, checkpoint, or external check is described, only self-monitoring. This is exactly the failure mode the piece warns against, and the corpus's more empirical treatments of the same problem (cognitive-surrender, det-skal-vaere-vanskelig) identify this absence of a detectable signal as the central danger: surrender happens gradually and confidence rises even when the AI is wrong, so relying on the practitioner's own sense that they are 'staying engaged' is precisely the mechanism that fails.
Read next: extract-cognitive-surrender (external, measured account of the same posture-dependent outcome, including why self-monitoring is unreliable) and extract-ai-coding-two-kinds-debt (organizational-scale version of the same problem, including why individual-level self-report can't surface it)
incompleteThe essay is written entirely from an individual-contributor, single-developer vantage point with no discussion of team or organizational context — code review by others, shared coding standards, pairing, or whether colleagues can tell from the outside whether a given PR reflects genuine understanding or the described discipline having quietly lapsed on a busy day.
Read next: extract-agentic-code-review (on how review itself has to change when agent-written code has no human intent behind it to reconstruct) and extract-ai-coding-two-kinds-debt (on cognitive debt as a team-level property invisible to individual self-report)
incompleteNo engagement with why this discipline is effortful or costly — the essay treats 'staying engaged' as simply a choice the author makes, without acknowledging that agents are explicitly designed to remove exactly this kind of friction, or that sustaining it under deadline pressure, fatigue, or high agent-output volume (many PRs, many agents running in parallel) may be much harder than the calm, first-person account suggests.
Read next: extract-det-skal-vaere-vanskelig (Bjork's desirable difficulties — the effort is the mechanism, not a flaw, and AI is close to a machine purpose-built for removing it) and extract-agentic-code-review (on review volume outpacing human capacity to sustain deep engagement at scale)