Code Is Cheap Now. That's the Easy Part.
Drew Breunig published 10 Lessons for Agentic Coding two days ago. Front page of Hacker News. Deservedly.
His tenth lesson is the one that stuck with me: "Code is cheap, but maintenance, support, and security aren't." Agentic code is "free as in puppies." Generate it all day. The bill comes later.
But here's what Breunig's list — and most agentic coding advice — doesn't fully address. When code becomes effectively free, the bottleneck isn't writing it.
It's managing it.
Deciding what to keep. Understanding what you built. Maintaining context across sessions that get wiped every time you close the tab.
That's where the current generation of coding agents falls short. And it's why we've been building Octomind differently.
The Real Lesson: Implement to Learn, But Remember What You Learned
Breunig's first two lessons are "Implement to learn" and "Rebuild often." The logic is sound — when generating a feature takes minutes instead of hours, you can afford to throw away three implementations to find the right one.
But there's a catch. Rebuilding only teaches you something if you remember what didn't work.
Current coding agents (Claude Code, Codex, most others) run in ephemeral sessions. You start a task, the agent writes code, you close the session. The next time you open it, you're starting from scratch. The agent might read the files on disk, but it has no memory of the design decisions you rejected, the constraints you discovered, or the three failed approaches that led to the current one.
So you rebuild. And you relearn the same lessons. Again.
This is context rot by another name — not the token-limit kind, but the session-boundary kind. Your agent forgets everything that isn't explicitly written down, and most of what matters in software design isn't written down. It's in the conversation. The rejected ideas. The "what if we tried this instead" moments.
Octomind handles this with session persistence. Your agent's memory, context, and tool state survive across restarts. When you come back tomorrow, it remembers why you chose the approach you did. The failed experiments are still in context — not as file comments you'd never write, but as actual conversation history the agent can reference.
Cheap code is worthless without cheap memory. Otherwise you're just paying the learning tax on every session.
Document Intent, But Don't Stop at Comments
Breunig's fourth lesson: "Document intent." Tests capture goals, code captures methods, but neither captures the why. Your intent motivates decisions, and persisting it helps you and your agent compound those choices.
Absolutely. But I'd push this further.
Intent isn't just something you write in a README once. It shifts during implementation. You start building a caching layer because you need speed, then discover your real bottleneck is database serialization, then realize the cache is actually masking a N+1 query problem. (Ask me how I know. Last Tuesday, specifically.) The why changes three times before you ship.
If your spec is a static markdown file written before coding starts, it's already wrong by line 50. Breunig knows this — lesson five is literally "Keep your specs in sync." But updating a spec file manually while you're in flow is friction most developers skip.
What if your spec stayed current automatically?
This is where agent skills come in. In Octomind, skills aren't just static prompts — they're living context that auto-activates based on what you're working on. A Rust skill loads when it sees Cargo.toml. A testing skill loads when you mention "pytest." These skills carry domain knowledge, conventions, and intent that persist across sessions without you copying and pasting instructions every time.
More importantly, skills can capture evolved intent. When you spend three sessions refining an approach, that learning gets encoded in the skill's instructions. The next time you (or your teammate) works in that domain, the agent starts from a better baseline. Not from zero.
Intent documentation shouldn't be a chore. It should be a byproduct of working.
Find the Hard Stuff — Then Give Your Agent the Tools to Handle It
Lesson six: "Find the hard stuff." Anyone can vibe-code the boilerplate. The value is in the gnarly problems: performance, security, resilience, systemic architecture.
But here's the thing. The hard stuff usually requires more than just generating code. It requires:
- Profiling tools to find the actual bottleneck
- Security scanners to catch the vulnerability you didn't think of
- Test runners that verify behavior across edge cases
- Search tools that trace how a change propagates through the codebase
Most coding agents can generate a function. Few can investigate whether that function is correct across the whole system. The hard stuff isn't just harder to code — it's harder to validate.
This is why Octomind is built around a tool-first architecture. MCP servers give your agent real capabilities: semantic code search, test execution, security scanning, dependency analysis. When your agent hits a performance problem, it can run a profiler. When it suspects a security issue, it can call a scanner. The agent isn't guessing — it's investigating.
Breunig is right that the hard work is where the value is. But you can't find the hard stuff with a text editor alone. You need tools that expose the system's real behavior. Otherwise your agent is just generating plausible-looking code for problems it can't actually see.
Code Is Cheap, But Context Is Expensive
Let's circle back to Breunig's closing warning: "Code is cheap, but maintenance, support, and security aren't."
He's right. But I'd add a fourth item to that list: context is expensive.
Every time you start a new agent session, you're buying back context you already had. The agent re-reads files. You re-explain the architecture. You re-discover the constraints.
It's like paying rent on knowledge you already own. Infuriating.
Current solutions to this are crude. Manual summaries. Frozen spec files. Copy-pasted prompts. They're workarounds for a fundamental architecture problem: the agent has no persistent memory.
This is why we built Octomind with adaptive compression. Not the kind that blindly truncates your conversation when it gets long, but the kind that understands what's important. Key decisions stay in full detail. Boilerplate gets summarized. The result is sessions that run for hours — or days — without losing the thread.
When I use Octomind for a complex refactoring, I don't restart every morning with a blank slate. I pick up where I left off. The agent remembers the three approaches we tried, why we rejected two of them, and what the remaining edge cases are.
That's not a feature.
That's the difference between toy scripting and serious engineering.
What You Actually Do When Code Is Cheap
Breunig's 10 lessons are a solid foundation. If you're just starting with agentic coding, read them twice.
But the deeper question — the one that matters for professional developers — is this: when generating code takes seconds, what's your actual job?
It's not typing faster. It's not writing more prompts. It's curation and verification. Deciding which generated code to keep. Understanding why it works. Maintaining the mental model of a system that grows faster than any human can read.
This is why I'm skeptical of the "vibe coding" framing. "Just describe what you want and ship it" works for prototypes. It fails for production systems where someone — you, your team, your future self — has to maintain, debug, and extend the code six months later.
The developers who thrive in this era won't be the ones who generate the most code. They'll be the ones who generate the right code, keep track of why they made each decision, and build systems their agents can actually reason about.
That's the future we're building Octomind for. Not a faster diff generator. A runtime where agents and humans share persistent context, use real tools, and make decisions that compound over time instead of evaporating when the session ends.
Code is cheap. Good engineering is still expensive. Let's keep it that way.
Read Breunig's original 10 lessons → dbreunig.com
Try Octomind for persistent agentic coding → github.com/muvon/octomind
