Point of view · Software delivery
AI is powerful. It still needs someone who understands why.
AI can accelerate software delivery dramatically. It does not remove the need to manage intent, architecture, assumptions, and product judgment.
The answer first: small AI tasks can feel magical because the goal and context fit inside one clear interaction. Larger projects accumulate dependencies, conventions, history, and hidden reasoning. Reliable AI-enabled delivery makes those constraints durable, gives the model bounded work, checks the result automatically, and keeps a human responsible for whether the output is the right product decision.
Why small AI tasks appear magical
A small, isolated task often has a short path from request to answer. The model can see the relevant code, the expected output, and most of the important constraints at once. If the work is easy to verify, a good result can arrive in minutes.
That experience is real, but it is easy to generalize too far. A successful one-file change does not prove that the same prompting style will preserve the intent of a product across weeks of work.
Why larger projects are different
As a project grows, the model has to navigate dependencies, architecture, team conventions, previous decisions, hidden assumptions, and requirements that keep changing. Some of that information lives in code. Much of the reason behind it does not.
The code records what was implemented. It does not always record why that decision was made.
Human intent is part of the system
A technically plausible answer can still be the wrong product decision. It might satisfy a ticket while undermining the user journey, duplicate a capability that already exists, or choose a clean abstraction that conflicts with the team's actual operating constraints.
AI does not reliably preserve a project's “why” unless that reasoning is documented and actively managed. A human still has to connect the implementation to the problem, decide which tradeoffs are acceptable, and recognize when a locally correct answer points the product in the wrong direction.
Context rot and context drift are different problems
Context rot
The signal degrades
The working context fills with stale details, irrelevant history, and conflicting instructions. Important constraints become harder to find, so output quality drops even if the original goal has not changed.
Context drift
The work moves off course
The implementation gradually diverges from the original intent. Each step may look reasonable on its own, but small assumptions compound until the result solves a different problem.
My operating model
I treat AI-enabled work as a delivery system, not a long conversation that is expected to remember everything. The goal is to make the important context inspectable, refreshable, and testable.
- Bound the task. Give each unit of work a concrete outcome, a clear scope, and a definition of done.
- Point to durable sources of truth. Keep requirements, domain rules, and team conventions in files the model and people can reread.
- Record specifications and architecture decisions. Document not only what was chosen, but the constraints and reasoning behind it.
- Make assumptions explicit. Surface uncertainty before it quietly becomes implementation.
- Use automated checks and tests. Turn important expectations into fast feedback instead of relying on confident-looking output.
- Keep human review accountable. Review for product intent, risk, maintainability, and user impact—not just syntax.
- Refresh context deliberately. Start a clean pass from current sources when a thread becomes noisy or the requirements change.
Practical controls
Before
Frame the work
State the problem, relevant constraints, non-goals, source files, and observable success criteria.
During
Control the path
Keep changes bounded, verify assumptions, and update durable decisions when the understanding changes.
After
Check the outcome
Run tests, inspect behavior, review the diff, and ask whether the result still serves the original reason for the work.
AI is a strong tool when used correctly
AI is useful for exploring options, drafting implementation, reviewing changes, tracing unfamiliar systems, and compressing the time between an idea and observable feedback. The mistake is not using it. The mistake is treating it as magic and removing the structures that help any project preserve intent.
The practical advantage comes from combining AI's speed with explicit context, automated evidence, and human responsibility for the “why.”