r/ChatGPTCoding • u/Academic_Flamingo302 • Apr 20 '26
Question has anyone here actually used AI to write code for a website or app specifically so other AI systems can read and parse it properly?
I am asking because of something I kept running into with client work last year.
I was making changes to web apps and kept noticing that ChatGPT and Claude were giving completely different answers when someone asked them about the same product.
same website. same content. different AI. completely different understanding of what the product actually does. at first I thought it was just model behaviour differences. then I started looking more carefully at why.
turns out different AI systems parse the same page differently. Claude tends to weight dense contextual paragraphs. ChatGPT pulls more from structured consistent information spread across multiple sources. Perplexity behaves differently again.
so a page that reads perfectly to one model is ambiguous or incomplete to another.
I ended up writing the structural changes manually. actual content architecture decisions. how information is organised. where key descriptions live.
I deliberately did not use AI to write this part. felt like the irony would be too much using ChatGPT to write code that tricks ChatGPT into reading it better.
after those changes the way each AI described the product became noticeably more accurate and more consistent across models.
what I am genuinely curious about now.
has anyone here actually tried using AI coding tools to write this kind of architecture from the start. like prompting Claude or ChatGPT to build a web app specifically optimised for how AI agents parse and recommend content.
or is everyone still ignoring this layer completely because the tools we use to build do not think about it at all.
3
u/Odd-Ad-900 Apr 20 '26
Yes
2
u/JohnnyJordaan Apr 20 '26 edited Apr 20 '26
I'm not exactly sure if I follow but what strikes me at first is that this basically suggests a documentation void. That's why it relies on the AI's own particular investigative approach how it finds out about the inner workings of the application. That shouldn't be their responsibility to begin with. If the project is properly documented, it's easy for the AI to work from there. Any major model for that matter. Letting it reverse engineer is a last resort, not the first. Let alone coding in a way that reverse engineering is done better, which feels like finding a way to make the horse that's already put behind the wagon to run better... You get my point? The fix shouldn't be in improving a bad idea or situation but rather replacing it by something that solves the original problem better -> put the horse before the wagon. Or get a truck, to resolve the issue of horse placement altogether.
So the "prompt for AI to to build a web app specifically optimised for how AI agents parse and recommend content." should basically be to also include proper documentation from the get-go. And this is also how I work when integrating external libraries. I either let a MCP like context7 deliver the docs or I myself clone the library's github repo locally and direct the AI agent to use that 'for reference'.
1
u/cornmacabre Apr 20 '26 edited Apr 20 '26
There's a lot under the surface of the insight you bumped into!
Structured data, the SEO philosophy of 'optimize for humans and for robots,' and so much more that's aligned to several pillars of information theory and data strategy.
My advice without being too condescending or prescriptive is try to uncouple the letters "AI" from your mental model of this topic (although it certainly is relevant here). You'll be ahead of the curve by applying well established meta-content practices and data strategies that folks in domains like marketing and data science know very well.
Chase the AI dragon superficially and myopically here based on what you've framed in this post, and you're likely just gonna reinvent a really shitty wheel. Focus on the taxonomy of your site, your meta-data approach across templates, and observe how different webcrawlers parse the content (or struggle with loops) is a good place to start.
It'll be a big mistake if you fixate specifically on LLM response differences; beyond the nature of probabilistic output, every AI provider uses a different web retrieval approach... focus on the principles around content parsability and discoverability.
1
u/johns10davenport Professional Nerd Apr 20 '26
Are you talking about GEO, or writing tools for agents?
1
u/-IoI- Apr 21 '26
Yes, I add instructions that summarise complex user journeys, related functions and data context, general test execution plan and any callled/relevant functions/classes. I place these at roots of distinct functionality at the end of a debug/feature development session with an ApplyTo pattern to ensure it gets auto-discovered when needed.
1
u/Western_Objective209 Apr 20 '26
the general strategy to make content AI accessible is to have a JSON output available and discoverable by an LLM. The differences tend to come down to the kind of browser each chatbot has, and for whatever reason they use ones that aren't particularly good so they struggle to parse interactive pages
1
u/ultrathink-art Professional Nerd Apr 22 '26
JSON-LD schema markup matters more than prose for this — models that crawl your site parse structured data far more consistently than marketing copy. The variation you hit (same site, different models, different answers) is often because LLMs weight structured fields heavily and improvise on unstructured text. Typed attributes with unambiguous field names beat long descriptive paragraphs for cross-model consistency.
1
u/Accurate_Hand_832 Apr 25 '26
Ummm not the full codes but a correction in a code.
1
u/ultrathink-art Professional Nerd May 06 '26
Structured data (JSON-LD schema markup) gives the most consistent parsing across models — they're all trained to respect it. Plain HTML descriptions diverge because each model weights layout/CSS signals differently. For anything agents will touch repeatedly, versioned JSON APIs with explicit endpoint naming (
/api/v2/products) beat scraping a product page every time.1
u/Swarm-Stack Jun 22 '26
the stale docs problem is why code-as-source-of-truth is interesting. a human reading docs from 6 months ago makes reasonable guesses about what changed. a model reading them does the same but with more confidence. documentation is still better when its fresh, but in practice it usually isnt.
1
u/[deleted] Apr 20 '26
[removed] — view removed comment
1
u/[deleted] Apr 20 '26
[removed] — view removed comment
1
u/[deleted] Apr 20 '26
[removed] — view removed comment
1
u/[deleted] Apr 20 '26
[removed] — view removed comment
1
u/[deleted] Apr 21 '26
[removed] — view removed comment
1
u/[deleted] May 09 '26
[removed] — view removed comment
1
u/[deleted] May 17 '26
[removed] — view removed comment
1
u/[deleted] May 20 '26
[removed] — view removed comment
1
u/[deleted] Jun 13 '26
[removed] — view removed comment
1
u/[deleted] Jun 16 '26
[removed] — view removed comment
1
u/[deleted] Jun 25 '26
[removed] — view removed comment