I am building an AI-powered eBay pricing tool and sharing the whole process here. ML models, scraping infrastructure, calibration experiments, product decisions. Follow along if you like technical detail. Early days, everything is being built from scratch.
Everyone is trying to make AI agents smarter with better prompts. I think the real unlock is making the environment smarter instead.
I've been building a .NET development agent. It writes code, commits, ships PRs. But the code quality doesn't come from the prompt. It comes from pre-commit hooks, architecture tests, and Roslyn analyzers that mechanically reject anything that doesn't meet the standard.
The agent proposes. The environment accepts or rejects. The agent revises. Same loop, every time.
The interesting part: none of the quality enforcement depends on AI. It's dotnet build and dotnet test. Deterministic pass/fail. The same tools that catch a human's mistakes.
So the agent is completely generic. What's custom is the box it works inside. Swap Claude for Gemini tomorrow and the quality guarantees still hold, because the intelligence is in the validation layer, not the model.
I think this pattern generalises beyond code. Any domain where you can express "good output" as automated checks becomes a domain where AI agents can work reliably. Finance, compliance, data pipelines. The hard part isn't the AI. It's knowing which checks matter and making them airtight.
@CodveAi This take made more sense 2 years ago when AI coding was autocomplete. Now I give Claude Code my full repo, test suite, and project conventions. It writes code that passes existing tests. Closer to a junior dev pair programming than the 'AI writing code' Notch is imagining.
The 'WHEN to stop' point hits hard. AI makes it trivially easy to over-engineer. I've caught myself building abstractions for one-time operations because Claude suggested them. The discipline to say 'three similar lines is fine, don't abstract this' is more valuable now than ever.
@gagansaluja08 This is exactly right. My CLAUDE.md file is 500+ lines of conventions, anti-patterns, and testing rules built up over months. Claude Code follows them and produces code I'd actually merge. Same model without that context file produces noticeably worse output in the same repo.
@manoj_dharani Labelling training data. 143K pairs manually classified to train a product matching model. Every batch makes the model marginally better at separating real comparables from false positives. Tedious but the accuracy compounds.
The edge that's hardest to replicate: knowing when the output looks wrong. AI can write any function you prompt, but choosing between an in-memory filter and a database query over 100K rows requires understanding performance. The code looks identical until it times out in production.
@GergelyOrosz The Uber number is the most useful data point here. 31% AI-authored at a company investing heavily means the industry average is probably far lower. The gap between 'engineer with Claude Code and a well-structured repo' and 'team that tried Copilot autocomplete once' is enormous.
@alvarobartt@huggingface@nvidia Running ONNX inference on an RTX 5070 Ti for product matching right now. 5.8ms per pair batched. Haven't tried self-hosted embeddings yet, still using OpenAI's API. How does nemotron-8b compare on shorter text like product titles and descriptions?
@simonw The best vibe-coded tools solve a 5-minute annoyance you'd never allocate proper dev time to. I've got a growing folder of throwaway scripts for data validation and HTML parsing. None are maintainable but they all get used daily.
Seeing the same with .NET 8. Six months ago Claude would push me toward Python for anything ML-related. Now it writes idiomatic C# ONNX inference code without prompting, handles EF Core migrations, and generates Playwright browser automation. The agent harness matters more than the training data mix.
@BreakerCulture How do you handle pricing when the same card has wildly different sold prices? Like a card that sold for , 2, and 5 in the same week. Do you price to the median, the most recent, or something else?
@NavSha Once you try it you don't go back. I run it with a CLAUDE.md file that has all the project conventions baked in. Gives the agent enough context to make good decisions without asking permission every 10 seconds. What are you building with it?
@eshanchordia@chamath@AllInPodcast@stripe@mercury What's the total monthly saving after all the cuts? As a solo dev I skipped most of these entirely, but AI subscriptions are now my biggest line item. Curious whether the maths works out to a net reduction for a 4-person team or you've just traded one stack for another.
@dahldoescards 184 sales in a week is insane velocity. Do you track how the average sale price shifts as volume peaks like this? Curious whether the late buyers end up paying more from FOMO or less as saturation kicks in.
Yesterday I posted about using statistical analysis to build product taxonomies. N-grams, community detection, one LLM call to refine.
It works for common products. But it breaks on long-tail categories where there isn't enough data to find patterns statistically.
So I flipped the approach. GPT-5-nano defines the taxonomy upfront (what axes exist, what values are valid). A local 4B model extracts values from each title.
Tested the 4B model on 200 listings across 10 categories. 82.9% recall, 44.7% hallucination rate. It finds values in the title text that shouldn't be extracted. A PS3's "60GB" gets pulled into a PS5 storage field. "Cobalt Star Bundle" becomes a colour.
It never once correctly said "this axis isn't present." Zero true negatives out of 200 samples.
The model doesn't need help finding things. It needs to learn when to say no.
Fine-tuning now. 1500 labelled examples across 30 product categories, GPT-5-nano as teacher. The local model learns the teacher's restraint at 1000x less cost per inference.
Saw the same problem at a smaller scale. Gave a coding agent access to my database migration system. It confidently created a migration that dropped a column it decided was unused. The column was not unused. The fix wasn't restricting the agent entirely, it was explicit deny rules for destructive operations. Guardrails don't slow the agent down, they just stop the expensive mistakes.
Same approach but through a CLAUDE.md context file. Coding standards, anti-patterns to avoid, test naming conventions. The biggest win was adding a 'lessons learned' section that grows as the project does. Agent dropped a database column once, so now there's a rule against deleting columns without explicit approval. Every mistake becomes a permanent guardrail.
What's the use case that needs 190 agents? Most multi-agent setups I've seen top out at 3-5 with clear role boundaries. At 190 the coordination problem changes completely. Are these all doing distinct tasks or is it more like a swarm where many agents work the same problem in parallel?
Most people reach for an LLM first when they need to categorise messy text data. I tried the opposite. Run statistical analysis first. N-grams, co-occurrence matrices, community detection. Let the patterns in the data surface naturally. Then one LLM call refines the output via structured JSON. It cleans labels, merges synonyms, drops junk. Cost difference: running the LLM on 126 product categories individually would cost pounds and produce inconsistent schemas. One cleanup call per category costs a fraction of a penny and the statistical foundation keeps results reproducible.
Built a pipeline that automatically discovers product variants from eBay listing titles. N-gram extraction finds candidate values. Mutual exclusivity analysis groups values that never co-occur ('Disc' and 'Digital' for PS5). Louvain community detection forms axes. Then one structured LLM call refines the noisy statistical output. Statistics handle the 80% cheaply. The LLM fixes the messy 20%. Cost per category: under a penny. Tested across 126 product categories, 82.9% listing coverage.