Large models are excellent at creating an exciting beginning. Give one a goal and it can write code, generate a page, organize material, or call tools through a sequence of steps.
But a real product rarely asks whether it can work once. The harder question is whether it can work reliably inside clear boundaries—and avoid harming data when it fails. That is the part of AI application engineering I care about most.
Separate capability from permission
A model being able to suggest a change does not mean it should modify production data directly. A tool having access to a system does not mean every task needs all of its permissions.
I prefer to break work into explicit stages:
- Read only the information that is necessary.
- Produce an intermediate result that can be checked.
- Require human approval before consequential actions.
- Keep test, log, or browser evidence after execution.
- Return to a known state when something fails rather than continuing to guess.
Those stages can make a first demo slightly slower. They also make the system far more likely to keep working over time.
Failure is not an edge case
External APIs time out. Web pages change. Model output drifts from a format. Permissions can expire during a run. A workflow that only designs for the happy path turns a small problem into corrupt data or an unrecoverable half-finished task.
Failure fallback is therefore not an exception handler added before launch. It belongs in the main design. If AI metadata generation fails, for example, the core bookmark should still save. If browser QA is blocked by an environment, the task should visibly remain unverified. If automated review has no evidence, it should not be described as complete.
Evidence lets collaboration continue
AI increases construction speed and makes review more important. More useful than “it is done” is a body of evidence another person can continue from:
- which files changed;
- which tests actually ran;
- what was observed in the browser;
- which risks remain; and
- where the next person should resume.
When that information is preserved, AI stops being a one-shot generator and becomes a manageable part of an engineering process.
The AI applications I want to build
I do not train foundation models. I focus on bringing models into real products where permission, data, failure, and accountability are clear. That work may be less flashy than a demo video, but it decides whether an AI capability remains a sample or becomes something users can rely on.