Article
2026-08-20
9 min read
Most stories about AI in software development go something like this: “I asked the AI to write a function, and it saved me twenty minutes.” That’s fine. But it’s not what changed how I work.
What changed was using AI to enforce process, to make sure the right work happens in the right order, even when I’m tempted to skip steps under deadline pressure. Not code generation. Process enforcement.
This is the story of how I built that system, what surprised me along the way, and why it’s still not finished.
The Problem: Enterprise Salesforce at Scale
I work in a large Salesforce org. Hundreds of Lightning Web Components, hundreds of Aura components, thousands of Apex classes, hundreds of triggers. Multiple product lines. Cross-functional teams sharing the same sandbox. The kind of environment where a single deployment can break something three teams away from you.
In that context, the cost of skipping design isn’t “a little rework.” It’s a failed deployment at 9 PM on a Thursday, a defect ticket that takes longer to fix than the original feature, or a change that quietly breaks a validation rule nobody remembers writing.
I kept running into the same pattern: I’d start building before I fully understood the problem. The code would work, but it wouldn’t be the right code. And I’d lose context between sessions, yesterday’s decisions evaporating overnight, forcing me to re-derive everything from scratch.
I needed something that would slow me down at the right moments and speed me up at others.
The Skill System: Structured Prompts, Not Chat
The core of what I built is a system of over 20 specialized skills for Claude Code, organized by lifecycle phase: design, code generation, validation, deployment, and documentation.
Each skill isn’t a prompt that says “write me an Apex class.” It’s a structured workflow with guardrails. The AI doesn’t just generate output, it follows a process.
Take the pre-development skill. When I invoke it, the AI enters plan mode. It researches the codebase, identifies affected areas, and produces a design document, problem statement, solution options with tradeoffs, a recommended approach, and a regression impact assessment. It doesn’t write a single line of code. It can’t. The skill explicitly prevents it from jumping to implementation.
I didn’t design it that way on the first try. The first version would happily start creating metadata files the moment I approved the plan. I had to correct it, “no, the next step is to write the document, not build the thing”, and that correction became a permanent feedback memory. The AI learned that plan approval means “write the design doc,” not “start coding.”
That’s a small example of something I didn’t expect: the system gets better not just from what I build, but from what I correct.
Another skill handles post-development documentation. After I finish implementing something, this skill compares what I actually built against the original pre-dev design. It captures deviations, where I changed course and why, and flags what needs regression testing. The output is a post-dev document that sits alongside the pre-dev one, creating a paper trail.
I’ll be honest: there were moments early on when writing a pre-dev doc felt like unnecessary overhead. “I already know what I’m going to build. Why am I documenting options I’m not going to pick?” But then I’d hit a deployment issue two weeks later, go back to the post-dev doc, and find the exact context I needed to debug it. That’s when the overhead started feeling like insurance.
The Document Chain: Pre-Dev to Post-Dev
The pre-dev and post-dev documents form a chain, a lightweight audit trail for every piece of work.
Pre-dev documents answer: What’s the problem? What are the options? What do we recommend? What might break?
They’re deliberately high-level. No code blocks. No method signatures. Just enough to communicate intent and get alignment before anyone writes a line of code. A typical pre-dev doc has a problem statement, two or three solution options with pros and cons, a recommended approach in one or two sentences, and a note about which existing test classes need to be re-run.
Post-dev documents answer: What did we actually build? Where did it deviate from the plan? What did we learn?
One post-dev doc I wrote for a defect fix includes full before-and-after code appendices, not because the code is interesting, but because the deviation is interesting. The original design called for a simple field update. What I actually built required refactoring a controller and adjusting two components, because the data model behaved differently than the design assumed.
That deviation is the valuable part. It’s the thing I’d forget in a month and have to re-learn the hard way.
Solving the Cold Start Problem
Here’s a problem nobody warns you about with AI-assisted development: every conversation starts from zero.
You spend an hour getting the AI up to speed on your codebase, your ticket, your constraints. You make good progress. You close the session. The next morning, you open a new conversation and, nothing. The AI has no idea who you are, what you were working on, or what decisions you made yesterday.
I solved this with a three-layer context system:
Per-ticket notes. For every active ticket, I maintain a short context file with decisions, constraints, open questions, and related tickets. At the start of each session, if I mention a ticket number, the AI reads its context file before doing anything else.
Cross-ticket theme files. Some context spans multiple tickets, business rules, object model decisions, shared patterns. These live in their own files and get referenced as needed.
Handoff documents. At the end of a session, or when the scope shifts from design to implementation, a handoff skill writes a summary: what was decided, what’s next, and a ready-to-paste resume prompt for the next conversation.
On top of that, the AI maintains persistent memory files, preferences, project state, and feedback corrections that carry across every session. If I tell it “don’t summarize what you just did at the end of every response,” that correction sticks permanently.
I didn’t expect the handoff documents to matter as much as they did. But there’s something about forcing yourself to articulate “what’s next” at the end of a session that sharpens your thinking. It’s not just for the AI, it’s for me.
What Changed
The honest answer is: I stopped deploying surprises.
Not because the AI writes perfect code, it doesn’t. But because the system forces me through a design step before I touch code, and a reflection step after I finish. Those two bookends catch most of the problems that used to surface in production.
Some specific things I noticed:
Deployment issues got caught earlier. One time, a linter silently reformatted a metadata file during deployment, stripping out related list configurations. Another time, picklist values failed to deploy without any error message, they just didn’t appear in the org. Both of these got documented in post-dev documents, which meant the next time something similar happened, the context was already there.
Design decisions became traceable. Months after building a feature, I could go back to the pre-dev doc and understand not just what I built, but what I didn’t build and why. That’s surprisingly useful when a new requirement touches the same area.
The feedback loop compounds. Every correction I make, “don’t jump to implementation,” “always use block format for conditionals,” “add a modification log entry for every file change”, becomes a permanent behavior adjustment. The AI doesn’t make the same mistake twice. Over time, the corrections slow down because the defaults get better.
But not everything worked on the first try. Some skills were too rigid and slowed me down on simple changes. Some were too loose and didn’t enforce enough. The pre-dev skill went through several iterations before the approval gate worked the way I wanted. And there was a stretch where I questioned whether all this documentation was worth the effort, until the first time it saved me from a two-hour debugging session.
This Is a Living System
I want to be clear about something: none of this is finished. The skills and artifacts are continuously enhanced as new patterns emerge.
The early skills were rough. They did one thing, sometimes clumsily. Later skills benefited from the feedback loop, the AI had already internalized corrections from earlier work, so it started from a better baseline.
Some skills were added reactively. A deployment went sideways, and I built a skill to prevent that specific failure mode from happening again. A new integration pattern showed up in the project, and the relevant generation skill got updated to handle it. The system evolves with the project.
If you’re reading this and thinking “I’d never build 20 skills,” that’s fine. I didn’t build 20 skills on day one. I started with one, the pre-dev design skill, because skipping design was my most painful gap. The second skill came a few weeks later, when I realized I was losing deployment context. The rest accumulated over months.
Start with the one that solves your biggest pain point. Grow from there.
Closing Thoughts
The value isn’t in any single skill. It’s in the system, the way design documents feed into post-dev reflections, the way context files prevent cold starts, the way feedback corrections compound into better defaults over time.
And the system is never done. Every new project brings new patterns, new failure modes, new opportunities to sharpen the workflow. That’s the part I didn’t expect to enjoy as much as I do: the meta-work of improving how I work.
AI becomes most useful when it enforces the discipline you’d skip under pressure. But only if you keep shaping it as your work evolves.