Week 10
1 - Ecommerce Page Automation
I built an AI system that generates product videos automatically for full e-commerce catalogs. (Cuts ~$20K per collection photoshoot and increases on-site conversion rates by ~30%) Here's what happens behind the scenes: → Firecrawl extracts product images directly from any e-commerce collection link → Calico AI transforms those into realistic model videos that capture fit, fabric, and movement → Every clip begins and ends on the original product image for seamless looping → All output is auto-tagged, categorized, and delivered straight into Google Drive → The whole pipeline processes in batch with absolutely no manual work The bottom line: brands can now equip every single SKU with a video asset, not just their hero products, and the conversion boost kicks in right away. Flat images just don't perform anymore. Shoppers need to see how a product moves and drapes before they hit buy. If you want the complete breakdown, here's how to get it: 1️⃣ Like this post 2️⃣ Connect with me (so I can DM you) 3️⃣ Comment "AI ADS" I'll send you the full n8n workflow, every prompt, and a detailed walkthrough video, completely free. No more $30K studio productions. No more second-guessing whether your product pages are leaving revenue behind.
--
Short answer: Partially true, but heavily exaggerated. The workflow described is technically feasible, but the claims about quality, cost savings, and conversion lift are likely marketing hype. Let’s break it down technically.
1. Scraping product images with Firecrawl
True and straightforward.
Firecrawl can extract:
product images
product titles
product metadata
collection pages
from e-commerce sites.
Typical flow:
collection_url → crawl → parse DOM → extract image URLsBut two practical issues:
Many stores block crawlers (Cloudflare / bot protection).
Image resolution may be too small for video generation.
So extraction works, but not always cleanly.
2. Turning product images into model videos
This is the weakest claim.
Calico AI reportedly converts product images into motion clips.
Technically this would require something like:
Image → Video diffusion
Human pose synthesis
Clothing simulation
Examples of similar tech:
Runway Gen-3
Pika
Stable Video Diffusion
Kling
The problem
If you only provide flat product photos, the model must hallucinate:
body shape
fabric physics
garment fit
lighting
That usually produces unreliable realism, especially for:
apparel
shoes
accessories
For accurate e-commerce product videos, brands normally need:
multi-angle images
mannequin scans
garment simulation
3D assets
So fully automatic SKU-level video generation from single images is still unreliable.
3. Seamless looping video
This part is easy.
Technique:
or
Many ad tools already do this.
4. Batch automation with n8n
Completely realistic.
n8n can orchestrate:
This is standard agentic workflow automation.
5. "$20K photoshoot savings"
This depends on the brand.
Typical fashion photoshoot costs:
Model
$500–$3,000
Studio
$1,000–$5,000
Photographer
$1,000–$5,000
Post production
$2,000–$10,000
Large brands can easily spend $20k–$50k per collection.
So the cost comparison is plausible, but the AI video quality rarely matches studio shoots yet.
6. "30% conversion increase"
Highly suspicious.
Video on product pages does increase conversion, but typical ranges:
Shopify research
10–20%
Wyzowl video stats
15–30%
Retail case studies
5–25%
But those are usually high-quality product videos, not AI-generated clips.
So 30% as a blanket claim is marketing.
7. Realistically what this pipeline can do
What the system likely produces:
AI motion loops
social-media style product clips
pseudo-model videos
TikTok/Instagram ads
It can work for:
dropshipping
small DTC brands
fast catalog video generation
It does not yet replace:
professional fashion shoots
luxury brand visuals
precise garment representation
8. Why posts like this go viral on LinkedIn
They combine three buzz trends:
AI agents
no-code automation (n8n)
e-commerce growth hacks
But many are lead magnets to sell:
courses
workflows
prompt packs
The "comment AI ADS" trick is classic LinkedIn growth hacking.
✅ Conclusion
The architecture is real:
But the claims about quality and conversion impact are inflated.
Think of it as:
AI-generated catalog motion assets, not studio-grade product videos.
2 - Autoresearch
Karpathy just open-sourced autoresearch.
AI that trains AI, indefinitely:
autoresearch runs 100 ML experiments overnight on a single GPU. The agent writes the code, runs the training, iterates and keeps what works.
Your entire job is maintaining a single Markdown file, one that describes the research strategy. What to explore, what to prioritize, what tradeoffs matter. The agent reads it, reasons about it, and decides what to try next.
That's the only lever you control.
The bottleneck isn't compute. It's your program. md.
Here's what's happening under the hood:
Autonomous git loop, committing every improvement
Every experiment = exactly 5 minutes, fairly compared
Optimizes architecture, hyperparameters, optimizer
Human edits the prompt. Agent edits the code.
Single-GPU, one file, fully open-source
https://github.com/karpathy/autoresearch
--
Yes — but the viral description you posted is partly true and partly exaggerated. Let’s break it down precisely.
1. The project is real
Andrej Karpathy did open-source a repo called autoresearch.
It is an agent-driven ML experimentation loop that runs on a single GPU. (Medium)
The idea:
An LLM coding agent edits ML training code
Runs experiments
Evaluates results
Keeps improvements
Commits changes automatically
So the core claim — “AI running research loops automatically” — is legitimate.
2. What the system actually does
Autoresearch turns the ML workflow into an automated loop:
Agent proposes a change (architecture / hyperparameter / training code)
Runs training experiment
Evaluates performance
Keeps or discards the change
Commits results to Git
Repeats the loop
Essentially:
This automates trial-and-error experimentation, which is a huge part of ML research. (Medium)
3. The Markdown control file (true)
Your post mentioned:
“Your job is maintaining a single Markdown file”
This part is mostly correct.
The repo uses something like:
This file describes:
research directions
constraints
hyperparameters to explore
architecture ideas
The agent reads this and decides experiments.
So humans provide strategy, agents handle execution.
4. The “100 experiments overnight” claim
This is context-dependent marketing.
The repo runs very small training jobs (Karpathy’s nano models), so:
Each run is short
Experiments are capped by a fixed time budget
Posts saying “100 experiments overnight” are examples, not guarantees.
5. The 5-minute experiment claim
Also partially true.
The framework often enforces a fixed wall-clock limit per run so experiments are comparable.
Example idea:
But this is configurable.
6. What autoresearch really is (important)
Technically, it’s not magical AI research.
It’s closer to:
Automated hyperparameter + architecture search with an LLM controlling the loop.
You can think of it as combining:
Neural Architecture Search (NAS)
AutoML
LLM coding agents
Git-based experiment tracking
7. What it is NOT
The hype posts imply:
❌ “AI researchers are obsolete” ❌ “AI trains AI indefinitely” ❌ “AGI research machine”
Reality:
It works on tiny toy training loops
Search space is limited
LLM reasoning can still break experiments
Results still need human evaluation
So it’s an interesting research tool, not a replacement for researchers.
8. Why researchers are excited
The real significance:
This moves ML toward agentic research loops:
If scaled, future labs might run:
with minimal human intervention.
✅ Verdict
Karpathy open-sourced autoresearch
✅ True
Agent runs ML experiments automatically
✅ True
Human controls only a Markdown file
⚠️ Mostly true
100 experiments overnight
⚠️ Depends on config
AI trains AI indefinitely
❌ Overhyped
3 - Text to SQL
𝐘𝐨𝐮𝐫 𝐓𝐞𝐱𝐭-𝐭𝐨-𝐒𝐐𝐋 𝐢𝐬 𝐟𝐚𝐢𝐥𝐢𝐧𝐠 𝐛𝐞𝐜𝐚𝐮𝐬𝐞 𝐨𝐟 𝐨𝐧𝐞 "𝐡𝐢𝐝𝐝𝐞𝐧" 𝐭𝐫𝐚𝐩... 𝐚𝐧𝐝 𝐢𝐭'𝐬 𝐍𝐎𝐓 𝐭𝐡𝐞 𝐋𝐋𝐌'𝐬 𝐟𝐚𝐮𝐥𝐭. 🤯
If you've ever tried to build a natural language interface for a production database, you know the pain. You ask a simple question, the LLM writes valid-looking SQL, but it returns zero results or throws a join error.
Why? Because most RAG-based SQL tools rely on Vector Search to find tables.
𝐓𝐡𝐞 𝐓𝐫𝐚𝐩: Vector Search is great at semantic matching, but it's "blind" to relational logic. It can find "Publishers" and "Payments," but it misses the "Bridge Table" that connects them because the bridge table's name isn't semantically related to the query.
𝘘𝘶𝘦𝘳𝘺𝘞𝘦𝘢𝘷𝘦𝘳 𝘣𝘺 𝘍𝘢𝘭𝘬𝘰𝘳𝘋𝘉 is the project that finally treats your schema like the web of relationships.
🛠️ 𝐓𝐡𝐞 𝐓𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥: 𝐒𝐜𝐡𝐞𝐦𝐚-𝐚𝐬-𝐚-𝐆𝐫𝐚𝐩𝐡 Instead of flattening your metadata into a vector database, 𝘘𝘶𝘦𝘳𝘺𝘞𝘦𝘢𝘷𝘦𝘳 transforms your entire schema into a Graph:
Tables are Nodes.
Foreign Keys are Edges.
When a user asks a question, 𝘘𝘶𝘦𝘳𝘺𝘞𝘦𝘢𝘷𝘦𝘳 doesn't just "guess" which tables to use. It uses graph algorithms (like BFS and Shortest Path) to discover the join paths automatically.
📊 𝐏𝐞𝐫𝐟𝐨𝐫𝐦𝐚𝐧𝐜𝐞 & 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧 𝐆𝐚𝐢𝐧𝐬
𝘔𝘶𝘭𝘵𝘪-𝘏𝘰𝘱 𝘙𝘦𝘢𝘴𝘰𝘯𝘪𝘯𝘨: Successfully resolved a 5-hop query on the BIRD benchmark (e.g., jumping from superpower → capability_matrix → stakeholder_registry → resource_requisition → budget_allocation).
𝘌𝘧𝘧𝘪𝘤𝘪𝘦𝘯𝘤𝘺: By identifying exactly which "bridge" tables are needed, it reduces context window clutter. No more dumping 50 DDL statements into a prompt and praying.
𝘌𝘹𝘵𝘦𝘯𝘴𝘪𝘣𝘭𝘦: Supports Gemini 1.5 Pro, GPT-4, and Claude 3.5 via LiteLLM.
As someone who bridges research and production, here is what to watch out for: 𝘈𝘮𝘣𝘪𝘨𝘶𝘰𝘶𝘴 𝘑𝘰𝘪𝘯 𝘗𝘢𝘵𝘩𝘴. If your database has multiple ways to join two tables (e.g., a "User" linked to "Order" as both a 'Buyer' and a 'Recipient'), the graph needs data sampling to resolve the semantic intent. QueryWeaver handles this by sampling column data to add more context to the nodes, a critical step many open-source tools skip.
𝐑𝐮𝐧 𝐢𝐭 𝐋𝐨𝐜𝐚𝐥𝐥𝐲: You can spin this up in seconds via Docker: docker run -p 5000:5000 -it falkordb/queryweaver
--
Short answer: The core idea is correct, but the post exaggerates the novelty. Using a graph representation of a database schema for Text-to-SQL is a known technique in research and production systems. What they describe is technically sound, but it’s not a breakthrough and not the only solution.
Let's break it down.
1. The “hidden trap” in Text-to-SQL is real
Most LLM Text-to-SQL systems fail because of schema selection, not SQL generation.
Typical pipeline used in many RAG tools:
Problem:
Vector search retrieves tables based on semantic similarity, not relational connectivity.
Example:
User question:
"How much revenue did publishers generate last month?"
Actual schema:
Vector search may retrieve:
But the join path requires intermediate tables:
This is a multi-hop join problem.
So yes — this problem is very real in production.
2. Schema-as-Graph is a legitimate solution
What the post calls “Schema-as-a-Graph” is straightforward:
Nodes:
Edges:
Example graph:
Then run a graph algorithm like:
BFS
Shortest path
Steiner Tree
to identify join paths.
This is a well-known technique in database query planning and KG reasoning.
3. This is not new
The idea existed long before LLMs.
Similar research:
RAT-SQL
schema graph encoding
IRNet
graph-based schema linking
BRIDGE
relational graph reasoning
Graphix-T5
graph-aware text-to-SQL
Even enterprise BI tools use similar logic.
So QueryWeaver is not inventing the concept, just implementing it.
4. Graph search + LLM is actually a strong architecture
A robust modern Text-to-SQL architecture looks like this:
This reduces hallucinations dramatically.
Instead of dumping:
you send:
which fits much better in an LLM prompt.
5. The ambiguous join problem is real
The post correctly mentions:
multiple ways to join tables
Example:
Orders table:
Which join should be used?
or
Graph traversal alone cannot solve this.
You need additional signals:
• column descriptions • data sampling • query intent • query history
So the data sampling trick they mention is reasonable.
6. The BIRD benchmark claim
The BIRD benchmark is a known Text-to-SQL benchmark.
BIRD Benchmark
It includes complex multi-hop queries.
A 5-hop query is plausible, but:
many models already solve similar cases
the benchmark alone doesn't prove production robustness
So that claim is possible but not groundbreaking.
7. FalkorDB background
FalkorDB
FalkorDB is essentially:
Optimized for:
graph traversal
shortest path queries
relationship queries
So representing schema as graph in FalkorDB makes sense technically.
8. Where this architecture actually shines
This approach works best when:
Database has:
Examples:
enterprise ERP
healthcare data
financial systems
logistics platforms
In small databases, vector retrieval alone is enough.
9. What the LinkedIn post gets wrong
The post frames it like:
Vector search = broken Graph schema = solution
Reality:
Good systems use both.
Typical production architecture:
Each solves a different problem.
10. The real state-of-the-art Text-to-SQL architecture
If you build this today, the best pipeline is:
The graph layer is one component, not the entire solution.
Final Verdict
Vector search fails for joins
True in many cases
Schema-as-graph improves Text-to-SQL
True
QueryWeaver invented the idea
False
5-hop reasoning breakthrough
Overhyped
Useful technique
Yes
So the post is technically grounded but marketing-heavy.
Last updated