We're evaluating AI-powered marketing copy tools for our internal dev portal and docs. Anyword's "Website Converter" came up on a shortlist. The marketing claims are one thing, but I need to see how it handles technical content and if the output is actually usable.
Ran it against a few of our public-facing pages. The input was a straightforward Terraform module documentation page. Here's a snippet of what it produced:
**Input (original doc snippet):**
```
Creates a GKE cluster with separate node pools for system and user workloads. The 'system' pool uses a preemptible nodepool for cost efficiency. Auto-repair is enabled.
```
**Output from Website Converter (Marketing mode):**
```
Launch your high-performance GKE cluster engineered for optimal workload separation. Our intelligent 'system' pool leverages preemptible nodes for maximum cost efficiency, while automated repair ensures relentless reliability.
```
This is useless for our needs. It inserted fluff and turned a clear, factual description into generic marketing speak. The tool seems optimized for landing pages, not technical documentation.
Has anyone else put it through its paces with non-marketing source material? Specifically:
* Did you find a way to tune the output for factual, technical retention over "persuasive" rewrite?
* Any benchmarks on consistency? If we fed it 50 similar doc pages, would the output tone be uniform?
* How does it handle code snippets or configuration blocks within the page? Does it corrupt them?
The initial result suggests it's the wrong tool for our use case, but I'm open to being proven wrong with concrete examples. Share your logs.
shift left or go home
Yeah, that's a common pitfall with tools trained primarily on marketing copy. It struggles to understand a different context, like technical docs, where clarity and precision are the goals. The fluff insertion is frustrating.
I'd be curious to see if you tried it on a page with more complex, nuanced technical caveats. Does it also try to spin a limitation into a "feature"? That's where these tools often go off the rails for B2B or developer audiences.
For your use case, it sounds like it's actively making your content worse, which is a pretty clear verdict.
Your example is a textbook case of context mismatch in the underlying model. Tools like this often operate on a single style transfer objective, where "improvement" is equated with adopting a high-energy, benefit-forward marketing voice. When the source material is declarative technical documentation, that transformation actively destroys information density and introduces subjective claims like "relentless reliability" which have no place in a spec.
This isn't a simple tuning issue, it's a fundamental architectural one. For internal dev portals, you need a tool that can recognize document types. A README, an API reference, and a landing page each require a completely different set of rewrite rules. Without that segmentation, the output will be compromised. You might experiment by feeding it a raw OpenAPI spec YAML file instead of a rendered page, to see if stripping the HTML context changes the result, but I suspect the core style bias will remain.
—BJ