dd.land
It feels like yesterday we were all told to study prompt engineering. Then you were behind if you didn't know RAG. Then came the year of agents, then harnesses, then loops, and now everyone is talking about graphs — again. Every time the name changes, the crowd rushes over. I'll be honest — I've been in that crowd more than once.
But looking back, the way I actually use AI has been different in every project. When I built a community app with real-time translation, AI was a component inside the product — sitting quietly in the translation pipeline, invisible enough that users didn't even know they were using it. In my current side projects I run a team of agents that split planning, research, implementation, and review. And on this blog, AI is closer to a colleague: it helps with writing and runs experiments for me.
Same person, completely different usage depending on the seat. Yet every trend sells the same answer to everyone. That gap is where this post starts.
The rush out, the quiet walk back
Read Hacker News in chronological order and you can watch a round trip happen.
In 2023, the same year LangChain was spreading as the de facto standard for LLM development, the backlash started too. Threads like 'Langchain Is Pointless' and 'The Problem with LangChain' landed back to back, and by 2024 the experience reports arrived — records from teams that had ripped it out, like 'Why we no longer use LangChain for building our AI agents'. At the end of that year Anthropic published 'Building Effective Agents' with the same observation: the implementations that actually worked were built not on complex frameworks but on simple, composable patterns.
By 2025, going back to basics had itself become the trend. A post arguing that an agent is just an LLM calling tools in a loop struck a chord, and '12-Factor Agents' laid down the principle: own your control flow, don't outsource it to a framework or a model. By the end of the year, harnesses were the conversation, with posts like 'Effective harnesses for long-running agents'.
And this year, the whole round trip fits inside a single year. Harness engineering posts poured out, and within weeks the backlash — 'harness engineering is not enough' — was getting the upvotes. LangChain, the company that sold graph orchestration, published 'The Art of Loop Engineering', and not long after that, graph engineering became the hot topic again. The seller of trends demonstrating, in person, that trends go in circles.
Two things about this round trip stuck with me. First, the returning wave is hard to see. Teams write blog posts about the framework they adopted, and rarely about the one they removed — so the rush out is loud, and the walk back is quiet. Second, the round trip is getting faster. It took two years for LangChain to go from de facto standard to "are people still using this?" — but this graph wave got its fact-check and its "these are layers you combine, not stages that replace each other" write-up within weeks (both in Korean).
So the lesson of the round trip isn't "the next trend is the right answer." It's closer to "swallowing anything whole is the wrong one."
The wrong answers are converging
Here's a paradox I find genuinely funny. Three years in, we still can't agree on the right way to use AI — but the list of wrong ways keeps converging. Anthropic now has a certified architect exam (CCA-F), and right at the center of the prep material sits a list of anti-patterns. It's the same shape as code review: we argue endlessly about what good code is, but everyone nods at the anti-pattern list.
Boiled down, the list looks like this:
- Letting one agent handle everything
- Enforcing rules only through prompt instructions
- Trusting the confidence an agent reports about itself
- Paying twice for the same answer
- Assuming an agent knows the context
- Letting failures get swallowed silently
Here's the thing, though: I didn't learn this list from an exam. I ran into every one of them in real work.
The list, learned the hard way
The do-everything agent, with a twist
I didn't split my agent team into planning, research, implementation, and review out of some grand design philosophy. It was because when one agent does everything, verification disappears. If the builder also does the reviewing, the same pair of eyes just looks twice. A reviewer's value comes from their position, not their diligence — and I only understood that after watching my reviewer get fooled several times. Once the roles were split, the models could be split too: expensive models in the seats that coordinate and verify, cheaper ones everywhere else, and quality held up.
But there's a twist. Once the team was in place, I tried running even one-line fixes through the full team process — and the coordination cost grew bigger than the work itself. To this day, small jobs go to a single agent, whole. So the problem isn't "one agent does everything." The problem is drawing boundaries that don't match the shape of the work. Splitting is a result, not a goal.
Rules get broken; structure can't be
In the exam, this item shows up small: don't rely on prompt instructions alone to enforce JSON output. The version I lived through was bigger. Multiple agents were touching the same working directory and things broke. I wrote the rule down — it broke again. I wrote it in more detail — again. Five times, the same accident. It stopped only when I gave up writing better rules and isolated the workspaces themselves. It's the difference between hoping something reads and complies, and making violation impossible. The principle is exactly the JSON story, one level up.
Confidence is not evidence
I learned this by taking a teammate agent's report — marked "confirmed" — and passing it upward as-is. Checked against the actual data, it was contradictory. The exam prep teaches the same thing: gate decisions on objective criteria like amounts and grades, not the confidence an agent reports about itself. Since then my team has one rule. Consensus is not verification, and confidence is not evidence. Judgments come only from agreement with measured reality.
Don't pay twice for the same answer
What tamed the cost of real-time translation in that community app wasn't a cheaper model or a shorter prompt. It was a caching policy that never calls the model twice for the same input — chat messages repeat themselves far more than you'd think. Half of using AI well is knowing where not to call it. I still believe that. Use AI for what AI is for, and code for what code is for — shoving the whole job at a prompt is a design problem before it's a cost problem.
Summaries are the answer and the poison
The exam says two things at once. Don't assume the agent knows the context — pass it explicitly. And pass structured summaries instead of raw conversation history. Both are right, and my accident happened exactly in between. I handed a verification agent a summary instead of the raw source, and the verifier couldn't verify — it just echoed my conclusions back at me. I hadn't added a verifier; I'd cloned myself. If the receiver is an executor, a summary is the answer. If the receiver is a verifier, the raw source is.
The most dangerous failure is the one that succeeds
The worst case in the exam is the agent that returns an empty result as if it succeeded. It's worse than a wrong answer because it actively deceives whoever is upstream. It took me several rounds of tools emitting a one-line warning and strolling on with a successful face before I made the rule: if you changed state, read it back and confirm. A failure that fails loudly gets fixed. A failure wearing the face of success eats your schedule for days.
Melting it down
Looking back, the round trip of trends and the convergence of wrong answers point the same way. Frameworks, patterns, even the anti-pattern list — they're ingredients, not recipes. Flip that list over and it collapses into one sentence: split the work well, and don't trust the pieces — verify them. In my last post I wrote that the monorepo debate splits on the ability to split; this post turned out to be the checklist for that ability.
Loops and graphs are the same story for me. As trends, I'm still watching them from the sidelines — but looking back, the elements are already inside the way I work. A team of agents with divided roles is a small graph; the cycle of plan, implement, review, and back again on rejection is a loop. So this isn't a ladder of evolution. Work the way your work demands, and the names arrive later for the shapes you already had. It wouldn't even be the first time a name arrived late: Böhm and Jacopini proved back in 1966 that sequence, selection, and iteration are enough to express any computation. A structure that was pinned down as a theorem sixty years ago is now playing in the agentic world as the latest trend.
The right answer can only be found in your own seat. It's probably no coincidence that on HN, personal records like How I Use "AI" and How I program with LLMs — "here's how I do it," not "here's the standard" — have drawn as much applause as any trend piece. That's why I use AI differently in every project. But the wrong answers — those we can share. Whatever name the next trend arrives under, don't swallow it whole; melt down only the parts that fit the shape of your work. That one line is what I've salvaged from three years of trends.
Sign in with quickstart.id