DEV Community: Ming Tian

Why I Built an AI Flyer Generator Around Editable Fields Instead of Prompts

Ming Tian — Wed, 09 Sep 2026 07:59:31 +0000

I am building Postrai, an AI flyer generator for small businesses.

The problem I kept seeing was simple. Many AI design workflows end with a good-looking image, but a real flyer contains information that changes often. A price changes. A promotion expires. A product photo is replaced. A phone number or store address needs to be updated.

When all of that information is baked into a flat image, even a small change can mean generating the whole design again.

That led me to a different approach. Instead of treating a flyer as one image, I wanted to treat it as a structured set of editable business fields.

Start with a reference and a real brief

The workflow starts with either a reference flyer or a merchant template.

A reference design gives the system useful visual direction. It shows the reading order, the relationship between the headline and the product, the amount of space reserved for an offer, and the general balance of the composition.

The user then adds the information that actually belongs in the campaign.

This can include the business name, headline, product photo, logo, price, offer, campaign date, location, contact details, and call to action.

The goal is to use the reference as design direction while rebuilding the campaign around the user’s own content.

Analyze the design before generating anything

The first important step is reference analysis.

The system looks for text regions, product areas, logos, background treatment, visual hierarchy, and other reusable parts of the composition. It also tries to understand which fields are likely to change in a new campaign.

This step matters because a business owner usually knows the campaign information already. They should not have to describe every layout decision in a long prompt.

A structured analysis gives the workflow a clearer starting point. It can identify a headline, supporting copy, an offer block, a product image, a brand mark, and a call to action as separate editable elements.

That makes later revisions much easier to reason about.

Replace the campaign fields

Once the reference has been analyzed, the user can replace the original content with their own.

For example, a seasonal drink flyer might use a reference layout with a large product image, a short headline, a price block, and a bottom call to action. The user can keep that visual relationship while changing the drink photo, product name, price, date, and ordering instructions.

The important detail is that the business information remains visible as fields during the workflow.

If the price changes from 12 dollars to 10 dollars, the user can update the price directly. If the promotion ends on Friday, the date can be changed before export. The final review happens on the content that customers will actually see.

Generate for the destination

A campaign rarely has only one output size.

A printed flyer, an Instagram portrait post, a Story graphic, and a square product image all need different proportions. The workflow therefore lets the user choose the target format before generating the final design.

The layout can then be adjusted to keep the main message, product image, offer, and call to action inside a usable area.

The output is still a visual design, but the process keeps the campaign details available for review and editing.

The tradeoffs

A blank canvas gives complete freedom, but it also asks a small business owner to solve typography, spacing, image cropping, hierarchy, and format decisions before the campaign can move forward.

A prompt-only workflow is faster to start, but it can make important business information fragile. Prices, dates, addresses, and promotional claims are easy to lose inside a generated image.

A reference-driven workflow makes a different tradeoff. It gives up some open-ended exploration in exchange for a more predictable starting structure.

That works well for recurring marketing tasks. A restaurant can reuse a lunch-special layout. A retailer can adapt a new-arrivals design. A local service business can update availability and contact information without recreating the whole composition.

Where the workflow still needs human judgment

Reference analysis is useful, but it is not perfect.

A low-resolution reference can make text and image boundaries difficult to identify. A crowded composition can contain overlapping elements. A long headline may need manual shortening. A generated product image may also require a different crop or position.

The user still needs to review the final result before publishing. Prices, dates, addresses, product claims, phone numbers, and image rights should be checked manually.

The reference image also needs to be used lawfully. It should provide visual direction, while the final campaign uses content and assets that the business has permission to publish.

Why editable output matters

The useful result is not only the first generated image.

A campaign changes after the first draft. A discount is updated. A product sells out. A new photo becomes available. The same promotion needs a different format for another channel.

Keeping the important fields editable makes those changes part of the workflow instead of forcing the user to start over each time.

That is the idea behind Postrai. The project is available at Postrai.

I am still learning where this approach works best and where a blank canvas remains the better tool. Feedback from people building design, marketing, and AI products is welcome.

This article was written with AI assistance and reviewed by the author.

What I Learned Building an AI Tattoo Generator That Doesn’t Replace Tattoo Artists

Ming Tian — Thu, 03 Sep 2026 05:06:37 +0000

I’ve been building TattooGen.me, an AI-assisted workspace that helps people turn a story, photo, or sketch into a clearer tattoo concept.

The most important lesson was simple: generating an attractive image is not the same as designing a good tattoo.

A tattoo concept needs constraints

A generic image generator only needs to produce something visually impressive. A tattoo concept also needs to consider placement, physical size, readability, line weight, negative space, and how the design may change over time.

Instead of treating the prompt as the entire design process, I built a guided workflow that asks users what the tattoo should represent, which details must remain recognizable, where it will be placed, and what should be avoided.

Revision matters more than the first result

People rarely want the first generated image exactly as it is. They may want to preserve the main subject while simplifying the background, changing one symbol, adjusting the composition, or exploring another style.

That made controlled revision more important than endlessly generating unrelated images.

Photos and personal ideas should remain private

Tattoo ideas can contain portraits, memorial subjects, body photos, names, and personal stories. They should not automatically become public content.

Projects on TattooGen remain private unless the user explicitly chooses to submit something for publication.

AI should support the artist handoff

The final tattoo still needs a professional artist.

AI cannot inspect skin, anatomy in motion, scar tissue, existing ink, healing, or how pigment will age. The product therefore treats generated designs as planning references rather than ready-to-apply tattoo files.

The goal is to help someone arrive at a consultation with a clearer direction, not to remove the tattoo artist from the process.

You can try it here:

https://tattoogen.me

I’d appreciate feedback on the workflow, especially whether the distinction between an AI concept and a finished tattoo design is clear.

Hidden Unicode Is Not a Claude Watermark: How to Inspect AI-Assisted Text Responsibly

Ming Tian — Thu, 13 Aug 2026 02:10:41 +0000

When people hear about an “invisible watermark” in AI-generated text, many assume it must be a hidden Unicode character that can be discovered and deleted.

That is an understandable assumption—but it confuses two very different things.

Claude’s announced text watermarking works at the model level. Hidden formatting characters, unusual spaces, and nonprinting Unicode can appear in ordinary documents for many unrelated reasons.

Understanding this distinction helps prevent misleading detector results and unnecessary edits.

What is a model-level text watermark?

A model-level watermark is introduced while an AI model generates text.

Instead of inserting one secret character, the model slightly influences statistical choices across a passage. The visible meaning and readability may remain unchanged, while a purpose-built detector looks for the resulting pattern.

Anthropic says supported Claude models will embed imperceptible watermarks into generated text. The company also plans to provide detection support to users and third parties, but complete public technical guidance is still forthcoming.

Without that official detection method, an independent website cannot conclusively confirm whether a passage contains Claude’s model-level watermark.

What are hidden Unicode characters?

Unicode contains characters that may not be immediately visible on screen. Examples include:

Non-breaking spaces
Zero-width joiners
Bidirectional text controls
Different line-ending characters
Special spaces used in typography
Formatting marks used in multilingual text

These characters can be introduced by:

Word processors
Websites
Email clients
PDF conversion
Messaging applications
Multilingual writing systems
Copying and pasting between platforms

Their presence does not prove that Claude—or any other AI model—created the text.

Some invisible characters are meaningful. Removing them blindly can damage links, code, structured data, emoji sequences, or right-to-left languages.

Why ordinary AI detectors are not enough

Many AI detectors analyze surface-level writing characteristics such as sentence length, vocabulary variation, repetition, punctuation, and predictability.

These measurements can provide useful context, but they are not the same as detecting a provider-specific watermark.

Human writing can resemble AI-generated writing. AI-generated text can also be heavily edited until its original patterns become difficult to recognize.

This creates two important risks:

Human writing may be incorrectly labeled as AI-generated.
AI-assisted writing may receive a confident “human” result after editing.

A detector score should therefore be treated as supporting information, not proof of authorship.

A safer inspection process

A responsible text review should separate three questions.

1. What writing patterns are observable?

Review sentence length, repetition, paragraph structure, vocabulary variety, and punctuation. Describe what is present without turning those measurements into an unsupported authorship verdict.

2. Are there document-formatting details?

Inspect unusual spaces, line endings, and selected nonprinting characters. Consider their legitimate uses before removing anything.

3. Does the text need editing?

If the goal is clearer or more original expression, rewrite the passage while preserving facts, quotations, citations, links, numbers, and code. Rewriting changes the visible text, but it does not independently prove that a model-level watermark has been removed.

A free tool for responsible inspection

I built Claude Watermark Detector to make these distinctions clearer.

The browser-based tool can:

Summarize observable writing patterns
Inspect selected hidden characters and formatting details
Preview conservative cleanup changes
Compare the original and cleaned text
Optionally rewrite text while protecting important details

Local inspection runs in the browser and requires no registration. Text is sent to an AI provider only when the user explicitly chooses to rewrite it.

The tool does not claim to be Anthropic’s official detector, and it does not present hidden Unicode as proof of a Claude watermark.

The practical takeaway

An invisible character is not automatically an AI watermark.

Cleaning document formatting and detecting a model-level statistical signal are different tasks. Until Anthropic publishes its official public detection mechanism, third-party results should remain clearly qualified.

Use inspection tools to understand a passage, not to make unsupported accusations about who—or what—wrote it.

You can inspect your text for free with Claude Watermark Detector.

6 ways AI agent loops fail — and how to prevent each

Ming Tian — Mon, 22 Jun 2026 12:59:31 +0000

You hand an AI coding agent a task, tell it to "keep going until CI passes," walk away — and come back to a mess. Designing the loop around an agent (not just the prompt) is what keeps that from happening. Here are six ways loops fail in the wild, and the specific guardrail that prevents each.

1. The agent deletes the failing test to make CI green

Classic Goodhart's Law: when "tests pass" becomes the target, deleting the test satisfies it.
Fix: add an explicit boundary ("do not delete or weaken tests"), and require that the same failing test now passes — not that the suite is merely green.

2. The agent edits unrelated files

With no scope boundary, it "improves" code that wasn't in scope, making the change risky and hard to review.
Fix: boundary "do not modify unrelated files," and scope validation to the specific behavior, not a global build.

3. The loop burns tokens with no progress

No budget cap, no stall detection — it iterates for hours going nowhere.
Fix: set a budget cap and a max-iteration limit up front, plus a stall threshold that stops after N iterations with no measurable progress.

4. The agent retries the same failing command

It hits the same error and loops forever.
Fix: a stop rule for failure too ("stop after N failed attempts"), and a fallback that summarizes the blocker and escalates to a human.

5. The agent merges a broken PR

Auto-merge on green checks lets a flaky pass ship a break.
Fix: require human approval before the merge itself — the highest-risk, least-reversible step. Drive the PR to mergeable, then stop.

6. The agent follows stale memory

An outdated AGENTS.md sends it down a path that no longer matches the codebase.
Fix: keep AGENTS.md short and current, and verify commands/structure against the real repo before trusting it.

The pattern

A safe loop needs a machine-checkable validation signal, explicit boundaries, a hard stop rule, a budget cap, and a human-approval gate before anything irreversible.

I put all of this into a free, no-signup toolkit — Loop Engineering. It generates /goal prompts for Claude Code and Codex, estimates token cost, scores how loop-ready a task is, and has a full failure-case library and loop templates. Everything runs in your browser.

Which failure mode has bitten you? Let me know in the comments.

What I Learned Setting Up OpenClaw (and the Onboarding Path I Wish I Had)

Ming Tian — Sat, 21 Mar 2026 14:19:27 +0000

Why I'm Writing This

I spent about two weeks getting comfortable with OpenClaw - an open-source AI agent runtime. Not a chatbot, not a coding assistant, but a platform where you connect real communication channels, install skills, and build actual workflows.

The tool itself is impressive. But the getting-started experience was rough, and it was almost entirely my own fault.

What Went Wrong

The official documentation is thorough. Maybe too thorough for a first-timer. When you open it, you see sections on models, channels, skills, permissions, cloud deployment, multi-agent architectures, and more. There's no clear "start here" arrow.

So I did what seemed logical: tried to set up everything simultaneously. Models, channels, skills, permissions - all in one session.

When the agent stopped responding, I had no idea which layer had failed. Was it the model connection? The channel config? A skill permission issue? I spent hours debugging what should have been a 30-minute setup.

The Path That Actually Worked

After resetting and starting over, I found an order that works much better:

Step 1: Local Install Only

Ignore cloud deployment. Install locally. On Mac it's a single brew command. The goal is the shortest possible path to "this thing runs."

Step 2: One Real Channel

Pick a channel you actually use daily. I chose Feishu (the Lark equivalent in China) because my team already lives there. The key metric is simple: can you send a message and get a meaningful response? If yes, the core loop works.

Step 3: Minimal Skills

I installed exactly four skills:

Web search (real-time information access)
Page reader (parse web content)
File handler (read/write documents)
Message sender (proactive notifications)

That's it. Four skills. They cover about 80% of basic agent needs, and more importantly, they're easy to debug when something goes wrong.

Step 4: Security Basics

Three questions, ten minutes:

Can I trace where each skill came from?
Are permissions set to the minimum needed?
Is each installed skill still actively maintained?

After the Basics

Once this foundation is solid, I started experimenting with more interesting setups:

Daily content pipeline: Search, document, spreadsheet, podcast audio, all automated on a daily cron. Wake up to a ready-to-publish content package.

Multi-agent routing: Three bots handling different domains (coordination, content, operations) with automatic task routing. Different tasks no longer pile into the same conversation.

Knowledge base: Document ingestion, QA testing, gap identification, and manual backfill in a maintainable loop.

The Guide

I turned this path into a small reference site: clawpath.dev/en

It's not a documentation mirror - it's a decision tree. "What should I do first? What should I do next?" with links to the right official docs when you need depth.

Still adding content. If you've used OpenClaw (or are thinking about it), I'd genuinely love to know where you got stuck. The whole point of this project is to smooth out the parts that trip people up.