(Or: Everything Old is New Again)
This post was inspired by Cole Medin's LinkedIn post outlining five meta-skills used by the top 1% Agentic Engineers. What struck me was how familiar these patterns felt—not because they're new, but because they're old. Here's my take on why.
There's a lot of hype around "agentic engineering" and "prompt engineering" right now. But here's the thing: none of this is actually new.
The developers getting the best results from AI coding tools aren't discovering revolutionary techniques. They're applying battle-tested software engineering principles to a new context. If you've been writing software for any length of time, you already know these patterns, you just need to recognise them in a different light.
Let's break down five habits that make AI coding effective, and trace each one back to the fundamentals we've always known.
1. PRD-First Development
The agentic habit: Document before you code. Your Product Requirements Document becomes the source of truth for every AI conversation.
The traditional parallel: Requirements Engineering
This is just requirements documentation, the same thing we've been doing (or should have been doing) since the Waterfall days. The difference is who's reading it.
When you write a PRD for an AI assistant, you're doing exactly what you'd do when onboarding a new team member:
- Explain the project context
- Define acceptance criteria
- Document constraints and decisions
- Provide enough detail that they can work autonomously
The principles are identical to what IEEE 830 taught us about Software Requirements Specifications, or what agile teams do with user stories and acceptance criteria. We've always known that ambiguous requirements lead to wrong implementations. That's true whether the implementer is a junior developer, an offshore team, or an AI.
What changes with AI
The AI won't ask clarifying questions unprompted. It won't push back on unrealistic timelines. It will just... start building. So your requirements need to be more explicit than you might provide to a human who'd flag obvious gaps.
Traditional practice: "A good spec is one where an engineer can implement it without coming back with questions."
Agentic translation: The same standard, just enforced more ruthlessly.
2. Modular Rules Architecture
The agentic habit: Split your coding rules by concern. Load only what's relevant to the current task.
The traditional parallel: Separation of Concerns
This is the Single Responsibility Principle applied to documentation. It's modular design. It's the same reason we don't put all our code in one file.
We've known since the 1970s that coupling is the enemy of maintainability. David Parnas wrote about information hiding in 1972. The SOLID principles formalised it. Every architecture guide ever written says "separate concerns."
When you dump 5,000 lines of coding standards into an AI context window for a simple CSS fix, you're creating the documentation equivalent of a God Object. Everything is coupled. Nothing is focused. The signal-to-noise ratio plummets.
What changes with AI
The "cost" of loading irrelevant context isn't just cognitive load, it's literal token usage and degraded output quality. The AI will try to apply rules that don't matter, or get confused by contradictory guidance across different domains.
Traditional practice: "Load what you need, when you need it" (dependency injection, lazy loading, microservices)
Agentic translation: Same principle, applied to context and instructions.
3. Automate Repetitive Tasks
The agentic habit: If you do something more than twice, make it a command.
The traditional parallel: DRY and Scripting
This is literally just Don't Repeat Yourself, the principle Andy Hunt and Dave Thomas gave us in The Pragmatic Programmer back in 1999.
We've always automated repetitive tasks:
- Shell scripts for common operations
- Makefiles and build systems
- CI/CD pipelines
- Git hooks
- IDE snippets and templates
The only difference is the automation medium. Instead of writing a bash script, you're writing a reusable prompt. Instead of a CI pipeline, you're creating a slash command. The principle is identical: encode the process once, execute it many times.
What changes with AI
The barrier to automation is lower. You don't need to know bash scripting to create a /commit command that follows your team's conventions. Natural language becomes the automation layer.
But the discipline is the same: notice repetition, extract it, name it, reuse it.
Traditional practice: "Three strikes and you refactor" (Martin Fowler's Rule of Three)
Agentic translation: Three prompts and you make it a command.
4. The Context Reset
The agentic habit: Planning and execution are separate conversations. Clear your context and start fresh.
The traditional parallel: Stateless Design and Clean Builds
This is stateless architecture applied to conversations. It's the same reason we:
- Do clean builds instead of incremental ones when things get weird
- Restart services instead of debugging corrupted state
- Prefer stateless microservices over stateful monoliths
- Run tests in isolated environments
We've always known that accumulated state causes bugs. Every senior engineer has a story about a "works on my machine" issue that was solved by wiping derived data and rebuilding from scratch. The phrase "have you tried turning it off and on again" exists because resetting to a known good state is a legitimate debugging technique.
AI conversations accumulate state too. Early misunderstandings persist. Bad assumptions compound. The context window becomes polluted with failed approaches and outdated decisions.
What changes with AI
The fix is the same: checkpoint your progress (write it to a document), clear the state (start a new conversation), and continue from the checkpoint. It's exactly like committing your code before a risky refactor so you can reset if things go wrong.
Traditional practice: "When in doubt, rebuild from scratch" / "Prefer stateless over stateful"
Agentic translation: Capture state in documents, not in conversation history.
5. System Evolution Mindset
The agentic habit: Every bug is an opportunity to improve your AI coding system.
The traditional parallel: Continuous Improvement and Blameless Post-mortems
This is just kaizen, the continuous improvement mindset that Toyota made famous and that agile adopted as retrospectives.
When production breaks, good teams don't just fix the immediate issue. They ask:
- Why did this happen?
- How do we prevent this class of problem?
- What systemic change would catch this earlier?
This is the same thinking behind:
- Blameless post-mortems
- "Five Whys" analysis
- Adding regression tests after bugs
- Updating runbooks after incidents
- The DevOps feedback loop
The difference with AI coding is what you're improving. Instead of adding a test or updating a runbook, you might add a rule to your .agents/ directory or update your PRD template.
What changes with AI
The feedback loop is tighter. You can observe AI mistakes in real-time and immediately encode the correction. It's like having continuous deployment for your development process itself.
Traditional practice: "Every incident is a learning opportunity" / "Fix the system, not the symptom"
Agentic translation: Every AI mistake becomes a rule that prevents future mistakes.
The Bottom Line
If you've been doing software engineering for a while, you already have the mental models you need. Agentic engineering isn't a new discipline, it's the application of existing disciplines to a new tool.
| Agentic Habit | Traditional Principle | Classic Source |
|---|---|---|
| PRD-First Development | Requirements Engineering | IEEE 830, User Stories |
| Modular Rules | Separation of Concerns | Parnas (1972), SOLID |
| Automate Tasks | DRY, Scripting | Pragmatic Programmer |
| Context Reset | Stateless Design | 12-Factor App, Clean Builds |
| System Evolution | Continuous Improvement | Toyota Way, DevOps |
The engineers struggling with AI tools are often those who've forgotten (or never learned) these fundamentals. The ones thriving are those who recognise that the principles that made us good engineers still apply—they just have a new surface area.
What to do next
Audit your current approach. Which of these principles are you already applying? Which have you let slip?
Pick one to improve. Don't try to transform everything at once. Start with the habit that maps to your existing strengths.
Share what works. As a consultancy, we should be codifying these patterns across projects. What rules, templates, or commands have you created that others could use?
The best "agentic engineers" aren't learning new tricks, they're remembering old ones. Good engineering is good engineering, regardless of whether your pair programmer is human or artificial.
Top comments (0)