How can genuinely useful projects get noticed when everything looks like AI-generated spam?
Asked by
MellowQuasar47
I've been working for months on Anvil, a Python-based control plane for AWS governance and security. It's already being used by two companies, including my own AWS organization, and I built it to make managing AWS accounts and security controls easier. I wanted to share it and get feedback, but project showcases have become heavily restricted because of the flood of mass-produced AI tools. When I did post it in the allowed places, people dismissed it as "AI slop," largely because the documentation was polished, technical, and lengthy. Terms such as "bounded concurrency" were criticized as buzzwords even though they describe the implementation accurately. I was even privately told to stop making AI-generated content, despite having written and tested the project myself. I did use AI to create a repository image and include some AI-oriented skills, but the software, testing, documentation, packaging, and security work are mine. How can independent developers share serious, useful projects and earn credibility in an environment where people assume anything polished is AI-generated?
Answers
The bigger problem is the flood of uninteresting software, not necessarily the use of AI itself. People are reacting to weak projects by assuming the worst, and that unfortunately catches legitimate work too. You can’t control every accusation, so make the evidence easy to verify: show commit history, tests, release artifacts, design decisions, benchmarks, and a simple reproducible example. Then focus on the users who genuinely need the tool instead of trying to convince everyone on the internet.
Reply to this answer
Describe it like you’re explaining it to a technically capable friend, not presenting to a board of stakeholders. Say what problem you hit, what Anvil does, why existing tools weren’t enough, and show one concrete workflow. Precise technical language is fine, but lead with plain English and avoid stacking too many abstract terms. People are filtering aggressively because there is so much low-effort generated software now, so a concise, personal explanation can help the real work stand out.
Reply to this answer
There probably isn’t a single online channel that solves this. Share it with people who actually work with AWS: colleagues, local developer groups, security meetups, makerspaces, and conference audiences. A few users who can explain what the tool saved them will do more for trust than a large number of casual views. Usage, contributions, package downloads, and documented case studies are stronger recognition than an initial popularity spike. A broader organization or respected maintainer partnership can help later, but those usually come after you have some traction.
Reply to this answer
People are understandably suspicious right now, especially when a project has an AI-generated image, a huge wall of polished documentation, or touches security-sensitive systems. AWS is also a specialized area, so many readers won’t immediately understand the value. Start with a much shorter README: explain the specific problem, show a small before-and-after example, provide a quick demo, and move the deeper architecture and feature details into separate docs. Make the project easy to inspect and run safely. Credibility usually comes from a small group of real users, references, and visible development over time rather than one large launch post.
MellowQuasar47: That makes sense. I’ve already shortened the main README and moved detailed material elsewhere. I hadn’t considered how much the generated image or the security implications might affect first impressions, so I’ll rethink those too.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowQuasar47: I appreciate that distinction. I focused so much on making the wording professional and complete that I probably removed the human explanation of why I built it.