I won't make your
product sound generic.

I refuse to write around a product I do not understand

A technical article can be grammatically clean, properly optimized, and completely dead. You feel it when the writer keeps circling the feature because they never ran it, never found the failure state, and never decided what the reader should do when the happy path ends.

I write code and technical content because I want to get past that performance. If the article teaches an implementation, I want the implementation in front of me. If the documentation describes a contract, I want to know where that contract breaks.

Technical content should have a pulse

Tech documentation and developer content is an absolute necessity. Crack it and you've captured more market than anyone in your niche. Suck at it, or try to automate it with AI, and developers will smell it from so far away you won't even see them running.

The practical boundary is adoption. Documentation can help someone decide, integrate, and recover. It cannot repair a weak product, create demand where none exists, or prove category leadership on its own.

Developers still meet a product through its explanations as surely as they meet it through the interface. A guide can take the fear out of trying something new. A vague page can make a sound product feel unfinished.

Strong technical content needs another human being behind it. Tutorials need decisions. Explanations need a point of view. Repeating the consensus in cleaner English makes me interchangeable with the writer who published the previous search result.

AI can move the work without doing the thinking

I use AI to prepare research, inspect a corpus, try variations, and attack a draft. It can help me build fixtures and chase a claim back to its source. That is useful work.

I will not ask a model to manufacture product understanding or personal judgment. Plausible prose is dangerous around technical products because it can sound finished before anyone has checked whether it is true. The final page needs an owner who knows why each claim is there and what evidence would force it to change.

What I do and what I refuse

I work on developer documentation, runnable tutorials, technical articles, and the content systems that help people find them. The published subjects range from localization and code review to AI agents, retrieval, and inference.

I refuse to:

• invent a personal story because the opening needs color
• hide a weak argument under an SEO brief
• publish code I cannot run or a result I cannot trace
• turn an engineer into the unpaid ghostwriter for a careless draft
• chase output volume until every article sounds like it came from the same machine

You can inspect the work

I've worked with Semrush, Adobe, TinyFish, Mastra, Manicule, OpenComputer, Firecrawl, Graphite, Mem0, and Centus.

The portfolio links to published articles, and the projects expose the tools I build around documentation and AI search. Read those before believing a claim on this page. Work should carry its own proof.