You Can't Coordinate What You Don't Understand
AI doesn't lower the knowledge bar for the person directing it. It raises it. The case for continual learning in an age that keeps insisting you'll never need to learn anything again.
I did not build Simple Durable Jobs and a unified LLM SDK because I was bored, or because I enjoy reinventing wheels, or to pad a portfolio. I built them because I walked into specific walls and needed a way through.
That distinction matters more than it used to, because we are now surrounded by a quiet suggestion that knowing things is becoming optional. The model knows the framework. The model has read the docs. Why keep the landscape in your own head when you can summon it on demand? I think this is backwards for anyone whose job is to direct the work rather than do all of it by hand. The more of the typing you delegate, the more the value of what remains concentrates in judgment, and judgment is made of the same knowledge people are being told they can outsource.
You can’t ask for what you can’t name
The quality of what an agent produces is bounded by the quality of what you ask for. And you cannot ask for what you cannot name.
If you do not know that a Postgres-backed queue like River exists, or how it differs from a message bus like NATS, or what Temporal actually buys you and what it costs, then “build me a durable job system” is the most specific instruction you can give. You will get something. It will look plausible. You will have no basis to tell whether it is the right shape, because you do not hold the space of alternatives it should have been chosen from. The agent will happily fill that vacuum with the most statistically common answer, which is not the same as the right one for your constraints.
When I know the landscape, the instruction gets sharper: durable, but no separate cluster to operate; checkpoint each step so a crash resumes at step four instead of step one; back it with the database I already run. That is not a vaguer prompt with more words. It is a request that could only come from someone who has felt the weight of the heavier options and decided against them on purpose. The knowledge is what turns a wish into a specification.
Pushing back is a knowledge operation
The most important thing I do with agents is not ask. It is push back.
An agent will produce a confident, well-structured solution that is subtly wrong: an abstraction built around the wrong axis, a concurrency pattern that leaks under cancellation, a “fix” that moves the bug rather than removing it. Catching that is not a matter of running the tests. It is a matter of seeing it, and you only see what you have the vocabulary for. Every time I have meaningfully redirected an agent away from a bad path, it was because I had hit that specific failure mode myself, somewhere, in code I owned, and felt the consequences.
This is the redirect I make most often. Hand an agent a single sprawling repository and a large context window and the instinct is to celebrate, because it can see everything at once. In practice it runs wild. It writes code that duplicates something three directories away, leaves dead paths that nothing calls, and quietly breaks links and imports across a surface too large for anyone, human or model, to hold honestly in one head. The fix is an old idea from long before any of this: boundaries. Distributing the work across services along logical areas of concern, with shared models at the seams, steers an agentic session far more deliberately and accurately than turning it loose in one giant tree. Agentic coding compounds the same way ordinary development always has, broken into bounded services and stackable primitives rather than poured into one undifferentiated context. The big context window is the seductive wrong answer. The architecture is the right one. I could only make that call because I had already felt, in plain human projects, what a monolith costs and what clean seams buy. The model will not volunteer that lesson, because the easy thing and the thing it was asked for both point the other way.
This is why building primitives and learning continuously are the same activity for me, not competing ones. The act of building the LLM SDK, putting eighteen providers behind one interface, getting streaming and tool-loops and cancellation right, is what gave me the standing to tell an agent, with specifics, when its take on a provider integration is wrong. You cannot fake that standing, and you cannot borrow it from the model. It is the residue of having done the work.
The real tension only shows up when you understand both sides
The “just use the framework” advice always skips a step: you cannot feel the real tension of adopting something until you understand it well enough to have built the alternative.
Simple Durable Jobs exists because I genuinely understood the heavy options. Temporal and Cadence are excellent. They are also a whole runtime to operate, a separate thing to deploy and reason about and page someone over at 3 a.m., and they ask you to write your logic as deterministic, replayable workflow code, a programming model in its own right rather than just a heavier way to run the same steps. NATS is a beautiful piece of infrastructure that was solving a problem one size larger than the one I had. River is lovely and close to what I wanted. For most of those, the tension was not “is this good software,” since all of it is, but “is the operational and conceptual cost worth it for this job.” I could only weigh that because I had carried each of those tools far enough to know its real shape, not its README.
And I won’t pretend building my own was free. Every library I made instead of adopted is now mine to maintain, with a bus factor of one. That is a real tax, and I paid it deliberately, because for this particular job it was smaller than the tax I was avoiding. Understanding both sides is also what lets you price that trade honestly, instead of reaching for “build it ourselves” as reflexively as the people who reach for the framework.
The same was true for the LLM work. The observability gap that led me to build a Go SDK for Langfuse was not visible from the outside. It only became a wall once I was deep enough in production LLM plumbing to need tracing that the existing options did not give me in Go. You do not discover the right thing to build by reading comparison tables. You discover it by understanding the existing options well enough to know where they stop fitting.
Someone who reaches for a framework without that understanding is not making a decision. They are accepting a default and calling it a choice. Sometimes the default is right! But you will not know, and neither will the agent you delegated the choice to.
Building a thing is how you, and the agent, come to understand it
There is a second-order effect I did not expect. An agentic assistant works well with a library to the exact degree that it can reason about that library: its shape, its invariants, the assumptions baked into its API. And one of the most reliable ways to make a codebase legible to an agent is to have built it, with the agent, under your guidance.
When I write a primitive collaboratively, me supplying the judgment about what it should be and the agent supplying a lot of the mechanism, both of us come out the other side fluent in it. I understand it because I shaped every real decision. The agent works well with it because the design is coherent and the reasons are legible, not bolted on. Familiarity is not something you have or lack. It is something you build, and building the thing is the most direct way to build the familiarity. A bespoke primitive you co-authored is legible to both of you in a way an internal dependency you imported and never opened is not.
The map is the asset
I have written before about how the comprehension and judgment at the end of a project are the part that stays human. This is the upstream version of that argument. The judgment at the end is only as good as the knowledge you brought to the beginning.
Continual learning, in this light, is not nostalgia for a craft that automation is retiring. It is the maintenance of the one asset that makes me a credible coordinator: a rich, current, first-hand map of how this stuff actually works, what exists, what it costs, where it breaks. The agents can render any individual square of that map on demand. They cannot hold the whole thing for me, and they cannot tell me which square to look at. That is the job now. It is a better job than the one it replaced, and it asks more of what I know, not less.
So I keep learning the hard things. Not out of duty, and not because I distrust the tools. I do it because the tools only help as much as the person aiming them knows where to aim.