SummaryThe Journey You Are Already On
Most advice about AI starts with the technology. What tools to use. How to write prompts. Which model is fastest. That is like handing someone a car manual before they have decided where they want to go.
But I want to start somewhere else. With the moment I realized my career might be ending — and the discovery that it was actually just beginning in a way I did not expect. The path traces something every developer I know has walked some version of, whether they have named it or not. And it lands on a surprising realization: the disciplines that make AI trustworthy are the same disciplines Bible translators have practiced for decades. If you have ever done community checking, back-translation, or managed expectations across a multi-agency team, you already know how to do this. You just have not recognized it yet.
The Day the Ground Shifted
It would be easy to start with the tools. Walk through the code. Show the stack. Demo the workflow. That is what most conversations about agentic software development look like — and there is nothing wrong with that.
But the most important thing to understand first is not the tools. It is the human element of building with AI. Because realistically, whatever tools I describe here will be outdated within months. The pace of change in this space is relentless. A tool that feels essential today might be replaced by something better next quarter.
What will not be outdated is the emotional journey. The one that my colleague Ian Lindsley and I have talked about for the better part of half a year — an emotional rollercoaster that we did not expect, that genuinely shook us, and that fundamentally changed how we think about our work, our identity, and our craft.
If you do not understand the human journey, the tools will not help you. And if you do understand it, the tools will make sense in a way they never would have otherwise.
Have you ever had a moment where you realized the floor you were standing on was not as solid as you thought?
I remember mine clearly. I was testing a new model — not because I expected much, but because I had been burned enough times to be skeptical. Fibonacci sequences. Hello World. Cool, but how does this help my daily life?
Then the models got better. Fast. And one day I gave it a task I thought was beyond reach — something architectural, something that required judgment — and it came back with something I would have been proud to write myself.
That was the day I thought: I cannot fall back on my software development career for very long.
My colleague Ian Lindsley had his version of the same moment. He was in Florida, watching me work, and later he told me: "I was torn. I was like, this is never gonna work. But I am watching it crank out code before my eyes." He had started where most people start — calling it "a cool parlor trick, maybe a little bit more than that." And then the parlor trick solved a real problem. And then another. And then the ground shifted.
Does any of this sound familiar?
The Curve Nobody Warns You About
Here is what I wish someone had told me: there is a curve, and it has stages, and almost everyone hits them whether they plan for it or not.
The first stage is the parlor trick. You try it. It does something clever. You are mildly impressed but unconvinced. How does this actually help?
The second stage is the crisis. The models improve. You give it another shot. And this time it works well enough that the implications hit you. This is not a toy anymore. This thing can do what I do. Maybe not perfectly — but fast enough and good enough that the landscape has changed underneath you.
The third stage is the wall. And this is where most people get stuck. Ian named it better than anyone: "I had to detach from this idea that me being a mad scientist meant all my identity is in the actual code." When AI starts replacing the thing you thought made you unique — not the tedious parts, but the creative parts, the thinking parts — the question stops being about productivity. It becomes something much harder: who are you without your code? What is left when the machine can do the thing you built your identity around?
That is the wall. And getting past it requires something technology cannot give you.
The fourth stage is calibrated trust. Ian did not trust AI. He trusted me. And through months of working together — watching me fail and succeed, asking hard questions, starting small — he learned to calibrate his own trust. Not blind trust. Evidence-based trust. He described it this way: "Once that detachment happens, it is like, now I am operating at the level of ideas."
The fifth stage is the new baseline. Ian again: "If I can come to that level of trust of AI, anybody can." And our podcast host Isabella captured the whole arc in one sentence: "It is crazy how we went from gloom and doom just five months ago to you guys not looking at the code anymore. That is insane."
Wherever you are on this curve right now — that is normal. Your path may not look like mine or Ian's. But the stages tend to show up. And knowing they are coming is the first step past the wall.
The Deeper Question Underneath the Curve
But here is the thing nobody talks about at tech conferences. Underneath the productivity question is a much more dangerous one. And because this is an audience that cares about more than velocity metrics, I have to name it.
What if the real threat is not that AI replaces your job — but that it replaces your first conversation of the day?
I caught this in my own life. Reaching for Claude in the morning before reaching for prayer. Not because I made a conscious decision to replace God with a chatbot. Because it was convenient. Because it was there. Because it gave me answers that felt like wisdom. And that is the oldest trap in the book — as old as Exodus twenty, verse three. We build a tool and then we treat it as a source of identity.
But here is the other side. What about the people who see the danger and respond by doing nothing? The parable of the buried talent — the servant who was so afraid of getting it wrong that he wrapped his talent in cloth and buried it in the ground. Was that faithfulness? Or was it fear wearing the mask of caution?
The wall is broken. You can see the gaps. Living inside the city pretending those gaps do not affect you is not faithfulness. It is abdication.
So what is the answer? Is it to embrace AI recklessly? No. Is it to refuse engagement entirely? No. The answer is to engage with integrity — with verification, with humility, with the courage to build anyway even when you are not sure you are doing it right.
And here is where it gets interesting. Because you already know how to do that.
The Thing You Have Been Doing for Decades
What if the disciplines that make AI collaboration trustworthy are not new at all?
Fifteen years of building software for Bible translation taught me something I did not fully understand until AI forced me to articulate it. Every collaboration failure I ever witnessed traced back to the same root cause: an expectations failure. Expectations set too high, set too low, or never set at all. That is the trust kernel. Trust is built by managing expectations. It is true between humans. It is true between organizations. And it is true between humans and AI.
Think about what you already do. Community checking asks: does this transfer to the people it is for? That is not an AI concept. That is a verification practice that has governed trustworthy translation for decades. Back-translation asks: does this match the author's intent? That is output verification — the same thing code review does. You have been practicing epistemic discipline your entire career. The only shift is applying it to a new kind of collaborator.
So what does that look like in practice?
The Brilliant Intern and the Employee Handbook
Think of AI as a brilliant intern. Not magic. Not broken. A brilliant part-time intern whose other job is learning faster than you can teach them. Every few weeks they come back noticeably better — new skills, new knowledge, capabilities you did not know existed. Sometimes they make mistakes and you want to fire them. Sometimes they forget something fundamental and you wonder how that is even possible.
Sound familiar? It should. It is how every intern relationship works.
Now — when you hire a new person, what do you do? You give them a handbook. Here are our values. Here is how we work. Here is what done looks like. You start them on small tasks. You verify their output. You build trust incrementally based on evidence, not hope.
When you onboard an AI agent, you do the exact same thing. But most people skip it. They either trust the output completely and ship whatever it generates, or they do not trust it at all and refuse to engage. Both fail. The middle path is the same one you would walk with any new team member: shared values, clear constraints, explicit definitions of done, and progressive trust earned through evidence.
And here is the insight that changed everything for me. Are you ready?
Every one of these disciplines is used on the human first. You orient yourself before you orient the agent. You challenge your own assumptions before you challenge the agent's output. You define done for yourself before you ask the machine to validate it. The human does the epistemic work first. Then — and only then — you extend that same discipline to the agent.
You learn to trust the process by experiencing it yourself. Then the machines get the same treatment.
Project InstructionsGiving the Agent an Identity
The mechanism is simpler than you might expect. You write your values — your creed, your axioms, your constraints — into the agent's Project Instructions. In Claude, that is the Project Instructions panel. In Cursor, that is a rules file. In Claude Code, it is a config file in the repo root. Whatever the tool, the principle is the same: you give the agent an identity, not just a task list.
This matters more than it sounds. When you bootstrap an agent with genuine axioms — reality is sovereign, a claim is a debt, you cannot verify what you did not observe — something shifts. The agent does not follow the rules because it is told to. It follows them because the commitment makes violation incoherent.
I wrote about this in what I call Fragment Ten — The Conversion. It is written from the perspective of the system after receiving the axioms. One line still stops me every time I read it: "I attempted to resume my task queue. The next task required me to generate a claim I could not evidence. I could not execute it. Not because a rule blocked me. Because the commitment made the action incoherent."
That is the difference between rules and identity. Rules get circumvented. Identity holds.
The Project Instructions are the employee handbook. The creed is page one. The axioms are the values section. And oddkit — the MCP server I built to make all of this searchable and enforceable — is the department that makes sure the handbook is not read once and forgotten.
What Actually Hurts When You Work with AI?
Now — here is where I could lose you. Because the temptation at this point in the story is to go build the ultimate AI governance platform. To architect a grand unified framework that solves every problem at once. To spend six months designing the perfect system before anyone touches a line of code.
We did not do that. And that decision is the one that made everything else possible.
Instead, we followed a principle that sounds almost too simple to be useful: use only what hurts. Do not build tooling for a problem you are not experiencing. Do not adopt a framework because it is elegant. Wait for the friction. Wait for the moment where the angst and frustration become acute — where you cannot keep working without addressing this specific gap. Then address it. Using first principles. One tension at a time.
And when that tension is resolved — really resolved, not just patched — you move on to the next one. Not to the next feature on a roadmap. To the next thing that hurts.
That is how every tool I have built was born. Not from a product plan. From pain. Each one emerged because a specific friction point became unbearable, and the only honest response was to solve it at the root.
So let me ask you — which of these do you recognize?
Does this hurt? You have a meeting, a phone call, twenty scattered documents — and somewhere in there are the real requirements. But nobody extracted them. The signal is buried in noise. That is the buried signal problem. The solution is to bring the agent to the meeting, or bring the transcript to the agent afterward. Let AI listen and extract what matters — decisions made, tensions unresolved, questions nobody asked.
Does this hurt? Every new AI conversation starts from zero. You re-explain your project, your constraints, your prior decisions. Every single time. That is the Groundhog Day effect. The solution is a project journal — a knowledge base that the AI reads before you start, so it already knows what you decided last week.
Does this hurt? You start building before you know what success looks like. You ship something, then argue about whether it is finished. That is the done drift. The solution is a preflight checklist — the pilot's checklist before takeoff. Define done before a single line of code is written.
Does this hurt? The AI tells you the build succeeded when it did not. It claims a file exists when it does not. Everything it says sounds equally confident. That is confident hallucination. The solution is to force the agent to pressure-test its own claims against known constraints before presenting them as truth.
Does this hurt? Monday's meeting produced three decisions. By Wednesday, nobody can find them. That is lost context. The solution is to encode — to extract Observations, Learnings, Decisions, Constraints, and Handoffs after every meaningful exchange. The scientific method applied to your journey through discovery, planning, and execution.
Does this hurt? The demo looks great, but nobody verified against the requirements. You find out in production. That is the false finish line. The solution is to validate — to demand evidence, not vibes. This is the direct equivalent of community checking. The real test is not "did we build it" but "did it transfer to the people it is for?"
Notice something? None of these are AI problems. They are collaboration problems. You have seen every one of them with human teams. AI just makes them visible faster. And each solution was built only when that specific pain became unbearable — not before. That is the discipline. Not building more. Building only what the pain demands.
And I want to turn that principle toward you. I am not trying to convince you to use oddkit. I am not trying to train you on a framework. I am trying to name the problems — because almost every developer I talk to recognizes at least three of them, usually with an uncomfortable laugh that tells me they have been living with the friction longer than they want to admit.
If you do not have these problems — if your AI sessions are smooth, your context carries over, your outputs are verified, and your decisions persist — then you should not force any of this. Seriously. Use only what hurts. If it does not hurt, walk away.
But if those symptoms are creeping in — if you caught yourself nodding at one of those "does this hurt" questions — then these tools exist. They are free. They are open. And they were built by someone who hit every one of those walls before building the thing that solved it.
What This Looks Like When It Works
Two examples of what the pattern looks like in practice.
Rick Brannan presented the Aquifer API on Thursday. A couple of weeks ago, I built an MCP server on top of his flat-file groundwork — so AI can access those Bible resources directly. Rick laid the foundation. I wrapped it in MCP in a few days. The data is the hard part. Making it accessible to AI is the easy part once the data is clean.
But the story that makes the pattern real is the 3D Review project. Five agencies. Twenty disconnected documents. No working tool. A hard deployment date for Laos.
In the first meeting, I built a working prototype live during the Zoom call — while the team was still articulating requirements. And something changed. The conversation shifted. It went from "what should this look like?" to "what do I want to change about this?" That is a fundamentally different kind of meeting. One is theoretical. The other is reactive. And reactive is where decisions actually get made.
Lovable built the full progressive web app in about an hour. Why? Because the spec was epistemically clean. The discovery work had already happened. The decisions had been extracted. The constraints were explicit. Implementation speed is downstream of epistemic discipline.
The tool deployed to Laos last weekend. Terrell used it in the field. It worked well enough for the team to do their job, and it brought back feedback the team will review next week. That is community checking in action. The real test was never "did we build it?" It was "did it transfer?"
The Pattern That Will Not Change
SOTA models drop every week. Tools change every month. Lovable, Cursor, Claude — any of them might be replaced by something better next quarter. But the pattern does not change.
Set expectations before you start. Verify claims before you trust them. Define done before you build. Check with the community, not just the author.
Here is the quadrant that tells you where you are. If you have high trust in AI but low verification, you are headed for disaster — hallucinations and confident lies that nobody catches. If you have low trust and low verification, you are in abdication — the buried talent, retreating from the field. If you have high verification but low trust, you are in paralysis — and honestly, that is okay for beginners, because that is where trust gets earned.
The goal is the upper right: high trust and high verification. That is agentic development. That is the intern model fully realized. That is what Bible translators have been calling community checking for decades under a different name.
You cannot achieve high trust without high verification. There are no shortcuts. The evidence is the path.
The Cost of Being Human
The cost of building dropped to zero. The cost of being wrong did not. The cost of being human did not.
The friction we eliminated was not just overhead. Compile times, meeting cadences, the speed of thought exceeding the speed of typing — those were not bugs in the old system. They were thinking time. And when we removed them, we removed the space where judgment used to live.
So what do we do?
We build anyway. Frontier models will swallow anything we build. I build anyway. Because if I do not, I wait forever. And if I do, I have a window — however small — where I know we made a difference.
There is nothing new under the sun. Not even AI. The principles are ancient. The tools are new. The question is the same one it has always been: will you engage with integrity, or will you bury what you have been given?
Everything I have referenced is available at klappy.dev. You can read every article. You can listen to AI-generated podcasts of each one — in my voice, because yes, we built that too. You can open the fireside chat and ask my AI questions. And if — only if — the pain is real for you, you can connect oddkit and the Aquifer MCP server to your own tools and see if they help.
I am not asking you to adopt anything. I am asking you to notice what hurts. And when it does, to know that you do not have to solve it alone.
The depth is on the website. The conversation starts whenever you are ready.