This year, a common question I get asked now is how I get so much done across several clients, products, repositories, and infrastructure environments.
The easy answer is AI, however it is also the least useful and accurate answer.
AI is involved in a wide array of what I do now, but I do not hand a chatbot a vague outcome and wait for a finished product. The results come from a workflow built around experience, explicit decisions, durable project knowledge, and a clear path from a business requirement to verified execution.
The model can produce code. That is not the scarce part.
The scarce part is knowing what should be built, what it affects, what assumptions are hiding inside the request, where the existing system will resist it, and what must be true before the work can honestly be called complete.
That is the part I bring to the table.
I do not begin with the prompt
Most weak AI-assisted work begins with a request that describes the visible result:
Add team management to settings.
That sounds reasonable. It is also nowhere near enough information to execute safely.
Does a team belong to an account, workspace, organization, or project? Who can create one? Do invitations already exist? Which permissions are inherited? Does moving the screen require moving the API boundary, or is this only a navigation correction? What happens to existing URLs, authorization rules, analytics events, and tests?
The screen is the final expression of a relationship model. If the relationship model is wrong, a polished screen only makes the mistake more convincing.
Before I ask AI to build anything, I try to identify:
- the actual business outcome;
- the user or operator affected;
- the existing system behavior;
- the ownership and relationship model;
- the constraints we cannot casually violate;
- the decisions that have already been made;
- the assumptions that still need to be challenged;
- the smallest useful definition of complete;
- and the evidence that will prove the change works.
This is execution framing. It converts an idea into something an engineering system can act on.
ChatGPT is where I pressure-test the problem
My work with ChatGPT is conversational, but it is not casual.
I use it to externalize the moving parts of a problem, expose contradictions, compare architecture choices, inspect product assumptions, and translate founder language into implementation consequences. I may arrive with a client request, screenshots, a frustrated observation, a database problem, or half a product strategy. We work it until the shape of the real problem becomes visible.
The back-and-forth matters. I have decades of pattern recognition, but that does not mean my first framing is always complete. A useful collaborator can challenge a premise, identify a missing dependency, or show that three apparently separate issues share the same underlying cause.
Sometimes the result is a recommendation. Sometimes it is a blueprint. Sometimes it is a phased implementation plan that another agent can execute. Sometimes the correct result is telling a founder that the feature they asked for is solving the wrong problem.
AI contributes speed, synthesis, recall, and additional perspectives. I remain responsible for judgment.
That division of labor is important. I am not outsourcing the decision. I am using AI to make the decision more thoroughly examined and more legible before anyone starts changing the product.
Cursor is where the plan meets the repository
Once the work has been framed, I move closer to execution.
Cursor has access to the actual codebase. It can inspect routes, models, services, migrations, components, tests, and established project conventions. That makes it the right environment for answering questions that cannot be resolved from a product description alone:
- Where does this behavior actually live?
- Is the requested relationship already represented in the data model?
- Which frontend assumption disagrees with the backend?
- What other consumers depend on this service?
- Can the change be made logistically, or does it require an architectural correction?
- Which tests prove that the implementation matches the requirement?
But repository access is not the same thing as project understanding.
A codebase can show an agent what exists. It cannot reliably explain why a compromise was made six months ago, which client assumption was rejected, what failed in staging, or which apparently obsolete path still supports a paying customer.
That missing layer is why I built STRATA.
STRATA gives the team durable memory
STRATA is a shared project memory system for technical teams. It captures the context that normally disappears into chat threads, individual machines, completed AI sessions, and someone’s recollection of a meeting.
It is intentionally not a task manager or an archive of every word anyone typed. The goal is to preserve durable knowledge:
- what changed;
- why it changed;
- what broke;
- how it was fixed;
- which decisions were made;
- which assumptions remain unproven;
- and which environment details will matter again later.
My team can work in Cursor, Claude, Codex, a terminal, WSL, or PowerShell without treating each surface as an isolated brain. STRATA provides shared memory through a central API and fast project-local retrieval through a SQLite workspace index.
The effect is simple: the next person or agent does not have to rediscover the project before contributing to it.
That changes AI from a sequence of clever but disconnected sessions into something closer to an operating system for continuous technical work.
The documents have different jobs
Throwing every fact into one enormous context file would technically create shared knowledge. It would also create a landfill.
I separate project knowledge by purpose.
Blueprints describe the system
A blueprint records the durable shape of a product or technical domain. It can describe architecture, ownership boundaries, data relationships, services, environments, conventions, constraints, and important known risks.
Blueprints answer:
What must someone understand before changing this system?
They are not generated once and worshiped forever. They evolve when the system or our understanding of it changes.
Plans describe intended execution
A plan turns a defined outcome into ordered work. It identifies scope, dependencies, affected layers, verification requirements, sequencing, and stopping points.
Plans answer:
Given what we know, how should this change be executed?
The best plans are specific enough for an implementation agent to proceed without inventing product policy along the way. They also leave room for the repository to contradict our expectations. Discovery is part of execution, not evidence that planning failed.
Handoffs describe the changed state
A handoff records what was actually done, what was verified, what changed from the original plan, what remains open, and what the next person or agent needs to know.
Handoffs answer:
Where are we now, and what should happen next?
This is one of the largest differences between useful AI work and token-burning iteration. Without a handoff, the next session reconstructs state from Git history, stale plans, partial chat context, and guesswork. With one, the work can continue from a known position.
Memory events preserve small but consequential discoveries
Not every lesson deserves a new blueprint. A staging configuration issue, an API quirk, a rejected client assumption, or the reason a deployment path behaves strangely may only require a concise durable note.
These smaller events prevent expensive rediscovery without burying the team in raw transcripts.
SQLite makes context local and fast
STRATA uses a central PostgreSQL-backed service for shared team memory and documents. At the workstation level, it builds a local SQLite index from handoffs, blueprints, plans, reports, and agent instruction files.
That local index matters more than it may sound.
AI tools work better when relevant context is easy to retrieve, close to the repository, and consistently structured. SQLite gives agents and developers a fast, offline-searchable view of workspace knowledge without forcing every interaction through a remote service or stuffing every document into every prompt.
Context should be available, not omnipresent.
The goal is not to make the context window as large as possible. The goal is to retrieve the smallest set of reliable information needed to make the current decision.
The generalized workflow
The specific tools can be replaced. The sequence is what matters.
1. Begin with the business requirement
Describe the desired outcome, who needs it, why it matters, and what currently prevents it. Do not begin by prescribing a component, endpoint, or database table unless that choice has already been validated.
2. Interrogate the request
Ask what the request assumes about ownership, permissions, lifecycle, data, navigation, integrations, and existing behavior. Separate confirmed facts from likely conclusions and unresolved bets.
3. Retrieve durable project context
Review the relevant blueprints, previous decisions, handoffs, known constraints, and recent discoveries. Give the agent project-specific truth before asking it to reason from generic patterns.
4. Inspect the actual implementation
Use a repository-aware agent to compare the desired outcome with the current system. Look for affected layers, implicit coupling, existing conventions, and contradictions between the product model and the code.
5. Create an executable plan
Define phases, files or domains likely to change, dependencies, migration concerns, backward compatibility, tests, and acceptance criteria. Make business decisions explicit so the implementation agent does not quietly make them for you.
6. Execute in bounded phases
Keep each phase coherent and verifiable. An agent should be able to implement a slice, test it, report what it discovered, and stop without leaving the repository in an unknowable state.
7. Verify outcomes, not activity
Files changed and tests passed are useful signals. They are not the business outcome. Verify the user flow, authorization behavior, data integrity, failure states, operational effects, and the original acceptance criteria.
8. Record the handoff
Capture the resulting state, deviations from the plan, verification performed, unresolved questions, and recommended next action. Preserve any discovery that would otherwise have to be learned twice.
9. Update shared memory
Index the new documents and sync durable knowledge so the team and future agents inherit the result. The completion of one task should improve the starting conditions of the next.
The compounding advantage
This workflow does not eliminate mistakes. It does something more useful: it makes reasoning inspectable, work resumable, and discoveries reusable.
Every completed project leaves behind more than code. It leaves behind a better model of the system.
That is where the advantage compounds.
The next feature begins with a stronger blueprint. The next debugging session can find the last failure. The next agent knows why a strange constraint exists. A teammate can enter a project without depending on my memory or waiting for me to retell its history. A plan can be judged against business requirements before implementation consumes a week.
This is also why founders and clients experience my work differently from someone who merely knows how to operate an AI coding tool. I am not selling access to a model they can also subscribe to. I am bringing the ability to turn their goals, assumptions, and constraints into an execution system that can reliably deliver software.
The AI is leverage. The workflow directs it. Experience decides where it should be applied.
You do not need my stack
You can reproduce most of this with different tools.
Use a shared folder instead of STRATA. Use another AI IDE instead of Cursor. Use text search instead of SQLite. Use issue templates, architecture decision records, or a well-maintained internal wiki.
But preserve the principles:
- separate business decisions from implementation choices;
- give agents durable project-specific context;
- distinguish system truth from planned work and completed work;
- make plans executable and verification explicit;
- record discoveries instead of repeatedly paying to rediscover them;
- and make every finished task improve the context available for the next one.
The winning AI workflow is not the one with the most agents, the largest prompt, or the newest model.
It is the one that lets good judgment survive the distance between an idea and its execution.