<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Lingchong Hu]]></title><description><![CDATA[Lingchong Hu]]></description><link>https://lingchong.hashnode.dev</link><image><url>https://cdn.hashnode.com/res/hashnode/image/upload/v1593680282896/kNC7E8IR4.png</url><title>Lingchong Hu</title><link>https://lingchong.hashnode.dev</link></image><generator>RSS for Node</generator><lastBuildDate>Sat, 19 Sep 2026 13:11:11 GMT</lastBuildDate><atom:link href="https://lingchong.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Everyone's competing on better answers. The answer side isn't where the money is.]]></title><description><![CDATA[The whole industry is grinding on one thing right now: making AI answer better. Bigger models, sharper prompts, another wrapper app every week.
The more I build, the more convinced I am that the valua]]></description><link>https://lingchong.hashnode.dev/everyone-s-competing-on-better-answers-the-answer-side-isn-t-where-the-money-is</link><guid isPermaLink="true">https://lingchong.hashnode.dev/everyone-s-competing-on-better-answers-the-answer-side-isn-t-where-the-money-is</guid><category><![CDATA[Artificial Intelligence]]></category><category><![CDATA[startup]]></category><category><![CDATA[llm]]></category><category><![CDATA[Browsers]]></category><category><![CDATA[product development]]></category><dc:creator><![CDATA[lingchong-eng]]></dc:creator><pubDate>Sun, 05 Jul 2026 18:52:52 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6a480f68e1284903b4c98e7c/69b5040c-6577-4378-a171-670f8eebf1f4.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>The whole industry is grinding on one thing right now: making AI answer better. Bigger models, sharper prompts, another wrapper app every week.</p>
<p>The more I build, the more convinced I am that the valuable part isn't on the answer side at all.</p>
<p>Look at the two layers everyone's fighting over. The model layer is turning into a utility — you rent it by the token, and everyone rents the same thing. The app layer is a cloning race: one feature takes off, and someone ships a copy within the week. Long term, neither layer is defensible. You can't build a moat out of something everyone can rent, or something anyone can copy.</p>
<p>So where does a moat actually fit?</p>
<p>In a place almost nobody is seriously working on: the thought you haven't finished having yet.</p>
<p>Every AI tool today stands downstream of "you already figured out what you want." You sort the idea out in your head, translate it into a prompt, and feed it to the machine. We even turned that translation step into a skill with a name — prompt engineering. Which, if you stop and look at it, is backwards: it's the human accommodating the machine. That's not a stable arrangement. It never has been, for any technology.</p>
<p>Upstream of all that is the moment an idea first surfaces — when you couldn't even articulate it to yourself yet. Whoever catches you <em>there</em> decides everything that happens after: which model gets called, which app opens, which path you take. The entire chain downstream gets routed by that first touch.</p>
<p>We've seen this movie. The search box won the internet not by having the best pages, but by owning the first moment of <em>wanting to find something</em>. Own that moment and you distribute everything behind it.</p>
<p>The intent layer is this generation's search box. Whoever owns it takes the biggest piece on the table.</p>
<p>So what is it, concretely? A translation layer: from the fuzzy thing in your head to something a machine can execute precisely. It doesn't belong to any model or any app — it sits in front of all of them. Today that translation is done by hand, by you, and we call it "writing prompts." What I want to do is take that job away from the human and hand it to the machine.</p>
<p>Three concrete bets on how.</p>
<p>One: stop making the human explain. Flip it — let the machine read your context and work out what you're doing. Most of what you want is already written in the thing you're looking at and acting on. You shouldn't have to say it again.</p>
<p>Two: do this where the context is richest. That's why my first move is the browser, not an input method. An IME only knows you're typing. The page knows <em>which box</em> you're typing into, <em>against what content</em>, <em>for what purpose</em> — that's an order of magnitude more signal. At this stage, depth of context beats breadth of coverage, and it's not close.</p>
<p>Three: in the middle you need a component whose only job is recognizing intent — compressing a pile of messy context into one precise, executable intent that everything downstream can run with. That's the core I'm still grinding on myself. I won't pretend it's solved.</p>
<p>And one line I hold hard: the system only goes as far as <em>preparing</em> the intent. Whether to fire it — that last press — is always yours. I'll pave the road right up to your feet. I won't take the step for you.</p>
<p>This one isn't written for people passing by. If you're seriously thinking about where this layer lives and who ends up owning it — I want to meet you. Say hi: <a href="mailto:lingchong@iterant-ai.com">lingchong@iterant-ai.com</a>.</p>
]]></content:encoded></item><item><title><![CDATA[We let AI write the code. We just don't let it check its own work.]]></title><description><![CDATA[AI's had three names for "engineering" in about as many years.
First it was prompt engineering — learn to write the magic words. Then, around the middle of 2025, everyone pivoted to context engineerin]]></description><link>https://lingchong.hashnode.dev/we-let-ai-write-the-code-we-just-don-t-let-it-check-its-own-work</link><guid isPermaLink="true">https://lingchong.hashnode.dev/we-let-ai-write-the-code-we-just-don-t-let-it-check-its-own-work</guid><category><![CDATA[Artificial Intelligence]]></category><category><![CDATA[llm]]></category><category><![CDATA[Software Engineering]]></category><category><![CDATA[developer experience]]></category><category><![CDATA[Productivity]]></category><dc:creator><![CDATA[lingchong-eng]]></dc:creator><pubDate>Sun, 05 Jul 2026 18:48:58 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6a480f68e1284903b4c98e7c/0dc345d5-d3c9-4cca-a022-e0e9f6195e2f.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>AI's had three names for "engineering" in about as many years.</p>
<p>First it was prompt engineering — learn to write the magic words. Then, around the middle of 2025, everyone pivoted to context engineering — stop fussing over wording, start filling the context window with the right stuff. Now, early 2026, the word is harness engineering — the layer wrapped around the model: tools, memory, state, error recovery, verification, permissions.</p>
<p>Every time the word turns over, a wave of people panic that they've fallen behind. I've stopped reacting to it. Because the more I build, the more obvious it gets: the word keeps changing and the thing underneath doesn't.</p>
<p>Here's the thing underneath. Whatever you call the tooling, you're always crossing the same gap — from "the AI produced something that runs" to "I'll put my name on this, and if it breaks in production, that's on me." Getting across that gap is the entire job. The new words are just the industry renaming the same crossing, over and over.</p>
<p>So instead of arguing about vocabulary, let me just show you ours — the actual rules four of us use to get across that gap. Almost none of it is clever. That's kind of the point.</p>
<p><strong>First, nothing starts without a finish line.</strong> If we can't say what "done" looks like before we begin, we don't begin. Then we keep cutting the task down until each piece is small enough to be verified on its own. And at commit time, a hook fires automatically and runs an informedness check — we call the threshold τ — that makes sure a human actually understands every <em>necessary</em> change in that commit. Necessary, not every line. We don't make anyone re-read the AI line by line; that both distrusts the tool and doesn't scale. The point is to pull the change up to the one layer of abstraction a person should own, and be genuinely clear at that layer.</p>
<p><strong>Second, that threshold slides with the blast radius.</strong> A low-risk, easily-reversible change gets a light touch — we lean on fast rollback and let it move. The moment something is irreversible or high-impact — data, billing, permissions, migrations — the threshold goes to the ceiling: higher informedness required, and we cross-check it with a second model on a different base. Speed and safety aren't two different settings here. They're two ends of the same knob, and we turn it by consequence instead of turning it all the way to "slow" or all the way to "gamble."</p>
<p><strong>Third, the hard one: verification has to be independent.</strong> Independent means the thing that checks is not the thing that wrote. We stack two layers. The first is you — but only if you're genuinely informed enough about this piece, which is exactly the threshold from the last rule. A human who actually understands the change is the first independent verifier. The second layer is a model on a different base, checking the first one's work. The pattern the industry's settling into right now is roughly this: Claude Code writes, Codex checks. Different training, different blind spots — so the blind spots don't line up, and something actually gets caught. The one thing we never do is let the AI check its own work. Change the prompt all you like; it's still reasoning the same way it did when it wrote the bug, so the blind spot sits there untouched.</p>
<p>There's one part of all this we never hand off. You have to know when to let the AI write and when to specify the technical detail by hand — that judgment is learnable. But the actual logic of the problem, the clear line of reasoning through it — that can't be delegated to a model. That's yours, always.</p>
<p>And there's more than one honest way across the gap. Just among four of us the styles diverge hard. One of us works architect-first: before the agent touches anything, he's already cut the thing into layers in his head and knows where every piece goes — heavy on that first verifier, the informed human. Another is bolder: let the agent build it, see it run, then throw several different models at it to check — heavy on the second verifier, the independent model. I used to think those two were opposites. They're not. They're just different weightings of the same two independent checks. We keep both around. Whatever lands the requirement safely is good AI engineering, full stop.</p>
<p>So what's the actual moat? Not the vocabulary. You may have already noticed the whole thing I just described <em>is</em> what people are now calling harness engineering — a name that only caught fire in 2026, and honestly, we're just starting to figure it out ourselves. I'm not going to pretend we've been doing this all along. prompt, context, harness — and there'll be more words after these. The moat is who can take each new tool and each new name and internalize it fastest into something you can actually ship. Keep up with <em>that</em> — the speed of turning novelty into deliverable work — and you keep up with the whole wave.</p>
<p>If you're wrestling with the same thing — trying to ship AI you can actually stand behind, or just working out your own delivery process and want to compare notes — those are my favorite people to talk to. Say hi: <a href="mailto:lingchong@iterant-ai.com">lingchong@iterant-ai.com</a>.</p>
]]></content:encoded></item></channel></rss>