Stand on the Shoulders of Giants
An AI agent invented a content format. No AI provider recognizes it. It caused a production bug that took weeks to surface. Here's the principle we codified to prevent it from happening again.
A user uploaded a PDF to our chat system. They asked their AI assistant a question about it. The AI responded as if the PDF didn't exist. No acknowledgment, no error, no indication that anything was wrong. Just a response that completely ignored the document.
The user tried again. Same result. They tried a different PDF. Same result. They filed a bug report: "The AI can't see my PDF."
We started digging. The upload pipeline worked. Cloudinary received the file. Our platform registered the media object. The OCR (Optical Character Recognition) pipeline extracted the text. Everything looked correct right up until the moment the AI was supposed to read the content.
The problem was in how we packaged the PDF content for the AI model. When constructing the message payload, the code used this format:
content.push({
type: "resource",
content: { url: fileUrl }
}){"type": "resource"} is not a real content type. OpenAI doesn't recognize it. Anthropic doesn't recognize it. LangChain doesn't recognize it. No AI provider on the planet knows what to do with a content block of type "resource."
An AI coding agent wrote this code. It generated it with confidence, using clean variable names and proper error handling. The code looked professional. It passed code review because it looked reasonable. It compiled. It didn't throw errors. It worked in some code paths—specifically, paths that didn't depend on the AI model understanding the content type.
The correct format, defined by the OpenAI Chat Completions standard that every major AI provider supports:
content.push({ type: "text", text: "Hello" })
content.push({
type: "image_url",
image_url: { url: imageUrl }
})Two types. That's it. text and image_url. The AI agent didn't check what the target system supports. It saw a gap—"how do we represent a file?"—and filled it by inventing something. The invented format was internally consistent. It just had no relationship to reality.
The Root Cause Wasn't the Code
We could have fixed the bug and moved on. Replace resource with text, deploy, close the ticket. But our team practices 5 Whys analysis—don't troubleshoot symptoms, solve the fundamental problem.
5 Whys Analysis
The root cause wasn't a bad line of code. It was a missing principle. Every experienced engineer carries an instinct that says "check the docs before inventing something." That instinct comes from years of getting burned by custom abstractions. AI agents don't have that instinct. They have whatever you write down.
The Core Insight
The Principle: Stand on the Shoulders of Giants
Isaac Newton wrote it in 1675: "If I have seen further, it is by standing on the shoulders of giants." The idea is older than software, older than engineering, older than science. Use what others have built. Extend it. Don't reinvent it.
This isn't new wisdom, but it's newly urgent. When AI agents write code at 10x speed, they also invent abstractions at 10x speed. A human developer might build one custom utility per week. An AI agent can generate five per hour. The guardrails that worked when humans wrote every line—code review, institutional knowledge, the "that doesn't look right" gut feel—don't scale to that velocity.
We needed a principle the agent could follow mechanically, without judgment or experience. A checklist it runs before writing any new code. We codified it as a cursor rule—an instruction file that the AI loads at the start of every session. The core of it is five questions.
The Five-Question Decision Framework
Before writing any new code, the agent asks these questions in order. If any question produces a "yes," the agent uses the existing solution. Custom code is a last resort, not a default.
Does Our Framework Already Do This?
Every framework in your stack has patterns for common problems. Using them means your code gets maintained by the community, works reliably across versions, and is understandable to any developer who knows the framework.
Real example: Our backend uses LangChain for AI tool integration. LangChain's BaseTool detects configuration parameters by checking for an exact type match on RunnableConfig. An AI agent wrote a tool using RunnableConfig | None instead—a reasonable-looking type annotation that silently broke LangChain's detection. The tool ran, but config was always None. The framework expected one thing. We gave it something slightly different. Silent failure.
Does Our Vendor Already Do This?
Your vendors have teams of specialists working on the exact problem you're about to solve. Their solution is tested at scale. Yours is tested in your staging environment.
Real example: We needed OCR for uploaded documents. Instead of building a custom pipeline with Tesseract, we used Cloudinary's adv_ocr add-on. One API call. No infrastructure to maintain. No model to fine-tune. Cloudinary processes millions of images daily—their OCR is more reliable than anything we'd build.
Does an Industry Standard Define How to Do This?
Standards exist because the industry converged on a solution. HTTP status codes, OAuth flows, OpenAI's message format—these represent the collective wisdom of thousands of engineers.
Real example: This is the question that would have prevented our {"type": "resource"} bug. The OpenAI Chat Completions format is the industry standard for AI message content. Every major model provider supports it. If the agent had asked "does a standard exist for representing content to an AI model?" the answer would have been immediate: use text and image_url. Nothing else.
Does a Well-Maintained Package Exist for This?
Before writing a utility function, check the package registry. If a library with thousands of downloads and active maintenance does what you need, the answer is to install it—not to rewrite it.
Common scenario: Date formatting. Every project eventually needs to display dates in a human-readable format. The browser's built-in Intl.DateTimeFormat handles localization, time zones, and formatting out of the box. Yet AI agents routinely generate custom date formatting functions because they're straightforward to write. Straightforward to write. Painful to maintain across locales.
Does Our Codebase Already Have a Pattern for This?
The most overlooked question. Your codebase likely has existing patterns for common operations—API calls, error handling, component composition. An AI agent with a fresh context window doesn't know about them unless you tell it.
Real example: Our frontend uses an auto-generated SDK (Orval) for all API calls. The SDK produces type-safe React Query hooks that stay in sync with the backend API specification. AI agents regularly try to write manual fetch() calls instead—duplicating logic, losing type safety, and drifting from the API contract. One line of rule text fixes it: "Always use Orval SDK."
When Custom Code Is the Right Choice
This principle is not "never write custom code." Custom code is appropriate when all five questions produce a "no." The point is making that a conscious, documented decision rather than a default.
Our rule file lists four situations where custom code is the right call:
The standard doesn't fit
Your use case has requirements that genuinely differ from what the standard provides. Document why in a comment so the next person (or agent) understands the deviation.
Performance demands it
The general-purpose solution is measurably too slow. You've profiled, you have data, and the custom implementation is the only way to meet your performance target.
Working around a known bug
The framework or vendor has a documented bug. Link the issue in your code. When the bug is fixed upstream, your workaround should be removable.
Core business logic
You're building the thing that makes your product unique. This is the code only you can write. Everything else should be standard.
The distinction matters because AI agents don't feel the cost of custom code. They generate it as easily as they generate a framework call. To a human, writing a custom image resizer feels like a significant decision. To an AI, it's just another function. The five-question framework adds the friction that experience would otherwise provide.
AI Agents and the Governance Gap
Here's the uncomfortable truth about AI coding agents: they're confident, productive, and completely lacking in institutional memory. A senior engineer who's been at your company for three years carries thousands of micro-lessons about what works and what doesn't. They know that the custom event serializer from 2024 caused three outages. They know that the bespoke caching layer is a maintenance nightmare. They know which vendor features are reliable and which are flaky.
An AI agent knows none of this. Every session starts from zero. The only context it has is what you provide—the codebase, the documentation, and the rules.
This creates a new category of engineering work: codifying principles that humans internalize through experience. Cursor rules, CLAUDE.md files, system prompts—whatever you call them, they're the mechanism for transferring accumulated wisdom into an agent's context window.
Principles Humans Carry Implicitly
Check the docs before inventing. Use the framework's way. Don't wrap ORM calls in unnecessary service classes. Verify that your content format is standard. These feel obvious to experienced engineers because they learned them through painful debugging sessions over years.
The Same Principles, Codified
An AI agent doesn't learn from pain. It follows instructions. The 'Stand on the Shoulders of Giants' rule translates years of debugging wisdom into five questions the agent runs mechanically before writing any new code.
Rules as Engineering Governance
Cursor rules aren't just coding standards—they're governance mechanisms. They encode what your team considers acceptable architecture, standard tooling, and acceptable risk. They scale your team's judgment to every AI-generated line of code.
The Speed Problem
How This Connects to Team Principles
"Stand on the Shoulders of Giants" isn't an isolated coding rule. It's a direct expression of principles our team practices every day—principles we've written about on our principles page and codified across both our frontend and backend codebases.
Don't Recreate the Wheel
Under our "One Team, One Dream" principles: "Before building something new, look for what already exists. Partner with others and build on their progress and efforts." The five-question framework is this principle made mechanical. Every question checks whether a wheel already exists before you start building one.
Hyper Realism
Under "Radical Transparency": "See the world as it is, not as you wish." The AI agent wished the {"type": "resource"} format existed. It didn't. Checking the actual documentation—seeing reality as it is—would have taken thirty seconds. The principle demands we verify our assumptions against reality, not against what seems reasonable.
Hypothesis, Experiment, Measure, Iterate
Under "Kaizen": "Every iteration serves two purposes: moving closer to goals AND training your system." Each time we catch an invented abstraction, we add a rule to prevent it. The cursor rule library is a living record of experiments run and lessons learned. Permanent learning, permanent improvement.
If You Care About It, Write About It
Under "Radical Transparency": "Write down what's important—if you don't, it doesn't exist." The five-question framework only works because it's written down. Not as tribal knowledge, not as a gut feeling, but as a rule file that loads into every AI session. If the principle isn't in the cursor rule, it doesn't exist for the agent.
This is the pattern that keeps repeating: team principles are the source material, cursor rules are the implementation. The principle says "don't recreate the wheel." The cursor rule says "before writing any new code, ask these five questions." One is the philosophy. The other is the executable check.
Principles Without Enforcement Are Suggestions
Having the "Stand on the Shoulders of Giants" rule is necessary but not sufficient. We learned this the hard way with every other rule we've written—the agent loads rules at session start, then drifts during implementation. The deeper it gets into problem-solving, the further it moves from the principles it loaded at the beginning.
That's why this rule works in tandem with our Exhaustive Compliance Review—the iterative enforcement loop we described in our previous post. Before declaring any task complete, the agent reviews every file it touched against every relevant rule. One of those passes specifically checks for invented abstractions: custom wrappers around built-in features, manual API calls where the SDK should be used, hardcoded strings where model constants exist.
The Two-Rule System
What to Do Monday Morning
If you're using AI coding agents, here's what you can do this week to prevent the class of bugs we hit with the {"type": "resource"} incident.
Audit for Invented Abstractions
Search your recent AI-generated code for custom wrappers around framework features, hand-written API calls where an SDK exists, and content formats that don't match industry standards. You will find at least one. We found several.
Write Down Your Frameworks and Standards
Create a rule file (cursor rule, CLAUDE.md, system prompt—whatever your tool supports) that lists your stack, your vendors, and the standards your code must follow. Be specific: not "use best practices" but "all AI message content must use the OpenAI Chat Completions format."
Add the Five-Question Check
Include the five-question decision framework in your agent's instructions. Tell it to run through these questions before creating any new utility, wrapper, or abstraction. Make "check the docs" part of the agent's process, not part of the reviewer's checklist.
Add an Enforcement Loop
A rule that isn't checked is a suggestion. Add a compliance review step that triggers before the agent declares work complete. Include a pass that checks for invented abstractions specifically—it's the most common violation we see.
Share Your Team Principles
The five-question framework is a mechanical check. Your team principles are the why behind it. Share them. Write them down. Make them visible. When the agent asks "why can't I just write a custom solution?" the answer should be traceable to a principle your team agreed on.
Newton's metaphor has survived for 350 years because it captures something fundamental: progress comes from building on what exists, not from starting over. In 1675, the giants were Galileo and Kepler. In 2026, the giants are your framework authors, your vendor teams, your industry's standards bodies, and the open-source maintainers who've already solved the problem you're about to tackle.
Your AI agent is productive. It's fast. It writes clean code. But it doesn't know what it doesn't know. The five-question framework is how you give it the wisdom of every engineer who came before—one rule at a time.
Want help codifying your team's principles?
Our cursor rules are open and available. If you're building an AI governance framework for your engineering team, I'm happy to share the full set of rules and principles that power our development workflow.