How I Build With AI
AI helps me research, organize, compare, test, draft, and build. It does not decide the purpose, set the boundaries, verify the facts, protect the voice, or take responsibility for the result. I do.
What AI helps with
Organizing source material and open questions.
Comparing possible directions.
Drafting structures and testing alternatives.
Finding inconsistencies that deserve another look.
Producing technical and editorial work under explicit constraints.
Repeating mechanical checks that should not depend on memory.
The point is not to make the tool look clever. The point is to make the work clearer and more useful.
What remains human
I remain responsible for the purpose, the question, the boundaries, the lived context, the evidence, the voice, the final edit, the ethical judgment, and the public consequence.
A generated answer can be polished and still be wrong for the room. It can be structurally valid and still make a poor product decision. It can be efficient and still shift a cost onto somebody who never agreed to carry it. Those are not choices I delegate.
How I check sources and claims
I separate what is visible in the work from what requires outside verification. Statistics, dates, studies, laws, health or safety claims, climate and energy claims, financial claims, current events, and platform rules are checked against current, reputable sources before publication.
When the evidence is missing, the options are plain: remove the claim, rewrite it as a clearly marked interpretation, or do not publish it.
How I handle visuals and synthetic material
Real product evidence comes first. I use the approved Dorian portrait without changing identity. Product interfaces are taken from actual, reviewable states. Generated or synthetic material is disclosed when it is material to what a viewer is being asked to believe.
I do not use a synthetic face, fake testimonial, fabricated interface, or generic AI image as proof. A local fallback, draft, preview, hosted run, production deployment, and public result are different states and are labeled that way.
Where AI fails or distorts
AI can flatten a specific person into a generic audience, turn a useful distinction into a slogan, repeat the same structure until the work feels manufactured, or make an uncertain claim sound settled.
It can also mistake variation for listening. If a person asks to change one part of a result, generating something entirely new may be fast, but it may answer the wrong question.
My response is to narrow the task, protect the context, inspect the evidence, and keep the limit visible.
Current example: Calqen
Calqen takes an occasion, conditions, a style direction, and a supplied wardrobe, then returns three complete look options. The meaningful product decision was not simply generating another outfit. It was making refinements respect what the person asked to change, preserving unrelated choices where possible, and showing the source pieces behind the recommendation.
The case study also records what Calqen does not claim: exact try-on, body rendering, fit certainty, independent ownership verification, adoption, customer demand, measured sustainability impact, or product-market fit.
Read the Calqen case study: https://www.dorianhartwood.com...
Future case studies
Future case studies will be added only when there is enough public evidence to show the constraint, the decision, the revision, the limit, and the current state. A concept, a private draft, or a clean-looking demo is not automatically a case study.
Corrections and accountability
If a public claim, caption, link, image, or product-state description is wrong, I prefer to correct it in place and preserve what changed. If the repair cannot be made safely, I remove or roll back the affected element.
The standard is not that mistakes never happen. The standard is that the record does not become smoother than the truth.
Contact
For writing, product storytelling, carefully scoped systems work, or a conversation about human-centered AI:
Contact Dorian: https://www.dorianhartwood.com...
