Short answer: Working with AI is less about vibe coding and more about operating a capable system: setting context, constraints, judgment, and durable workflows so agents can do useful work.
I thought I was learning to build with AI.
Looking back at the last few months, I think something else was happening.
I was learning to operate.
I Was Never Really "Vibe Coding"
My approach to working with AI did not start with code.
It started with language.
That probably makes sense if you know me. I have an English degree, and I joke about it often as someone working in the tech industry, but one of the most useful skills I brought into this entire process was being able to take something messy, break it into modular pieces, dissect it, and reformulate it into something easier to understand.
That has always been something I thrive on.
It helped me as a call center trainer. It helped me as a Salesforce Admin. It helped me when I was teaching tough online banking curriculums to new agents. It helped me when I was building flows and trying to make declarative automation make sense.
And then, unexpectedly, it helped me work with LLMs.
Models like Claude and Codex are powerful. They can reason, research, write, generate code, inspect files, summarize systems, and move faster than any normal work cycle.
But they are not automatically aligned to the problem in front of them.
They still need context.
They still need priorities.
They still need constraints.
They still need someone to decide what good looks like.
In that sense, working with AI started to feel less like "asking something to code" and more like managing a very capable new employee.
That employee has a huge skill set, but they do not automatically know how to apply it to the problem at hand.
That became my role.
I was not trying to be the engineer in the traditional sense. I was acting more like a Product Owner, manager, trainer, and operator. I carried the big picture, broke down the work, clarified the desired outcome, and used Claude or Codex to help execute, investigate, challenge, and refine the plan.
Sound familiar?
It should.
This is something people do every day at work with coworkers. The difference is that this coworker is available all the time, responds immediately, researches quickly, and can give you something useful on demand.
No two week turnaround.
No "let me get back to you."
It was instant.
That is why I do not think "vibe coding" accurately describes what I was doing.
The work was not random. It was structured. It was guided. It was reviewed. And over time, it became less about writing better one-off prompts and more about designing better systems for AI agents to operate inside.
One of my prompts looked like this:
"Comparing what the client wants and what we built with Aster, how do we generalize it into our AI Agent builder? What are the components of a dynamic intent routing agent runtime? Draw out this concept in ASCII art and based on that, how do we make it declarative and buildable by users during the AI Agent builder experience, and then updateable after."
That is not really a "build me a thing" prompt.
That is me trying to take a messy idea, break it apart, understand the shape of it, and turn it into something someone else could use.
Different tool.
Same brain.
The Early Phase: Big Prompts, Big Vision
Taking an operator mindset shaped the prompts I sent.
I never approached the codebase as if I already knew how everything worked. I treated that as the LLM's domain. My job was not to pretend to be the developer. My job was to ask the right questions, understand the system well enough to make decisions, and then apply judgment afterward.
That felt very similar to how I had worked with developers in the past.
Let them do the code magic.
Let me help guide the outcome.
One of my early prompts looked like this:
"Explore the AgentShelf codebase to understand the context layer architecture, specifically: 1. How AGENTS.md manifests work... 2. How context injection works... 3. How agent files/context library work... 4. How these connect to chat/workspaces... Return a summary of all the components and how they connect."
That was not me asking the AI to blindly build something.
That was me asking it to help me understand the terrain.
Once I had the analysis, I did not stop there. I would read what it gave me, decide whether I had enough information, and then either ask follow-up questions or move toward a plan.
That is the part I think a lot of people miss.
They worry, reasonably, about hallucination. What if the model makes something up? What if its answer is wrong?
My answer is that this was not blind trust.
It was grounded trust.
When I asked the LLM to inspect the codebase, I was not asking it to invent an answer from general knowledge. I was asking it to look at real files, trace real flows, and explain the system back to me in natural language.
Could it still be wrong?
Of course.
But now I had something concrete to verify.
That is one of the biggest lessons I learned working with LLMs:
Context is king.
The more I helped the model work inside the right context, the more useful it became.
That is why prompts like these mattered:
"I need to understand how conversation history and context is handled when sending messages to the LLM... How many messages are sent... Is conversation history summarized... What happens if a user switches LLM providers mid-conversation?"
"I need you to trace the complete flow of how tool executions are supposed to be persisted... Tools are executing during live chat... but nothing is persisted after the session..."
These prompts helped me understand, in natural language, what was happening inside the codebase.
Once I understood that, I could guide the LLM toward the result I needed.
Then I would test.
If the result passed, great.
If it did not, I would bring the failure back into the conversation, explain what went wrong, talk through the plan forward, and only then ask it to make another change.
That was the process.
Not magic.
Not vibes.
A lot of prompting, grounding, testing, correction, and guidance toward an end result.
When you treat an LLM like a colleague instead of a vending machine, this starts to feel natural. You give it context. You ask it to explain. You challenge the result. You guide the next step.
And over time, you stop thinking of yourself as someone trying to code and start thinking of yourself as someone operating the work.
The Shift: Specs, ACs, PBIs, and Agent Memory
I learned this the hard way with Storyweaver. I'd been vibing along on that CLI project, prompting freely, having fun — then one session I let the model talk me into a "70% codebase reduction" without asking what it planned to cut first. It gutted the project. That moment changed how I work.
A chat prompt is temporary. The model does not remember what it said three sessions ago. It does not know what you were protecting. It does not know what took you two weeks to get right. That is not a flaw — it is just the reality of how these systems work right now.
So I stopped trying to fit everything into one perfect prompt and started moving the important parts of the work into artifacts the model could repeatedly reference. Specs. Acceptance criteria. PBIs. Git history. Workspace instructions.
Think about why teams write stories and tasks in JIRA. So you can clock out Friday, come back Monday, and know exactly where you left off. What was decided. What is blocked. What comes next.
LLMs need that same operating surface.
Not because they are fragile. But because context is king, and the more you help the model stay inside the right context, the less likely it is to come back and offer to delete seventy percent of something you built.
The Real Skill: Judgement
The Storyweaver lesson was really a judgment lesson.
The model was not malicious. It was not broken. It was doing what I asked, inside the context I had given it — which wasn't enough. I had not told it what mattered. I had not told it what to protect. I had not asked it to show its work before swinging the hammer.
That is the part no one talks about enough.
Anyone can send a message to an LLM and get a response. The skill is knowing what to ask before you say go. Knowing when an answer sounds exciting but hasn't been grounded yet. Knowing when to slow down and ask the model to show you a plan before it starts executing one.
Judgment is knowing the UI is off. Judgment is knowing the workflow is confusing. Judgment is knowing when something technically works but does not yet make sense as a product.
It is also knowing when not to trust a number like seventy percent.
The models have gotten significantly better at recommending things. But they still need to be pointed at the right constraints. They still need someone to ask the questions that force the work to account for reality — API limits, regression risk, what a user actually needs versus what was literally requested.
That is not a developer skill specifically. It is an operator skill. And it turns out, years of breaking down complex processes, writing clear instructions, and managing outcomes across systems was better preparation for it than I expected.
From Builder to AI Operator
Having a well-defined workspace for an AI agent changes what becomes possible.
The goal, for me, has always been the Iron Man / Jarvis relationship pattern.
Not because I think we are literally there.
But because the operating model is useful: a system that understands the workspace, remembers the mission, knows the tools available, and can help coordinate work without needing everything re-explained.
To get functionally closer to that, I had to define my workspaces in a way that let me trust the agent understood who, what, when, and how to work with the task at hand.
That meant looking for repeatable patterns.
I started recognizing which prompts were no longer one-off prompts.
If I was repeating a workflow, asking for the same kind of review, giving the same caution over and over, or sequencing work the same way across PBIs, that was my signal that it should become part of the workspace.
That judgment usually came from me.
I was not asking the agent to decide what should become a skill. I was recognizing patterns in my own workflow: the kinds of reviews I kept asking for, the kinds of planning loops I kept repeating, the cleanup steps I wanted after each PBI, or the Salesforce CLI workflows I knew would need to become reusable.
Once I saw the pattern, then I could use the agent to help turn it into something durable.
A skill.
A slash command.
A workflow.
A project instruction.
A reusable operating pattern.
That distinction matters.
The agent can help build the skill, refine the skill, or apply the skill.
But the judgment that something is worth turning into a skill comes from understanding the work.
Then, just like working with a colleague, it becomes easier to keep working in the same way because you have taught your counterpart how you operate.
Once this is set up, your prompts start to get smaller.
Not because you have stopped providing expertise, but because the long prompt you used to send about watching out for X, Y, and Z now lives somewhere else. It becomes part of the workflow. It becomes part of the workspace. It becomes part of the durable context the agent can refer back to.
Sometimes those workflows create more artifacts, which then provide even more grounded context for the agent to work inside.
Context is king.
With that in place, my prompts in more recent months started to look like this:
"Let's commit all changes and move onto the next PBI. Are we able to implement all PBIs separately using sub agents in parallel?"
"Let's aim to update that ERD with the current state of the codebase by launching multiple sub agents in parallel to tackle different parts of the codebase."
Those prompts are shorter, but they are not less informed.
They work because the context is no longer only inside the prompt. The context is in the workspace, in the artifacts, in the PBIs, in the specs, in the skills, and in the operating patterns that have been built around the work.
That is when I could stop treating AI as a single chat assistant and start treating it like an operating layer.
Suddenly, asking multiple subagents to review something became less risky. Work was defined inside the workspace. The agent could read the relevant files, reference the artifacts, and understand the task boundaries.
That meant I could start a new session, point the agent at a different part of a feature, and not feel like I was starting from scratch.
It knew where to begin.
It had a better sense of how to proceed.
And just as importantly, it had a better sense of what not to break.
Why This Matters for AgentShelf
Everything above — the workspace setup, the durable context, the operator judgment — I had to figure out myself through trial and error, including a destroyed Storyweaver codebase. Most people are not going to do that. They should not have to.
That is the honest reason I am building AgentShelf: infrastructure that lets someone work the way I work without needing to know everything I know to get there.
