umairnadeem123

yeah you can see exactly why a comment/post scores the way it does. case is one of the factors

IMO this is solving the wrong problem. the session log is just noise - its like attaching your google search history to a stackoverflow answer to "prove" you did the research. nobody wants to read 500 lines of an agent going back and forth debugging a race condition.

the actual problem is that AI produces MORE code not better code, and most people using it aren't reviewing what comes out. if you understood the code well enough to review it properly you wouldn't need the session log. and if you didn't understand it, the session log won't help you either because you'll just see the agent confidently explaining its own mistakes.

> have your agent write a commit message or a documentation file that is polished and intended for consumption

this is the right take. code review and commit messages matter more now than they ever did BECAUSE there's so much more code being generated. adding another artifact nobody reads doesn't fix the underlying issue which is that people skip the "understand what was built" step entirely.

almost definitely AI-generated: https://hn-bot-detector.vercel.app/s/e7Qhw8yh

> I tried to avoid writing this for a long time, but I'm convinced MCP provides no real-world benefit

IMO this is 100% correct and I'm glad someone finally said it. I run AI agents that control my entire dev workflow through shell commands and they are shockingly good at it. the agent figures out CLI flags it has never seen before just from --help output. meanwhile every MCP server i've used has been a flaky process that needs babysitting.

the composability argument is the one that should end this debate tbh. you can pipe CLI output through jq, grep it, redirect to files - try doing that with MCP. you can't. you're stuck with whatever the MCP server decided to return and if it's too verbose you're burning tokens for nothing.

> companies scrambled to ship MCP servers as proof they were "AI first"

FWIW this is the real story. MCP adoption is a marketing signal not a technical one. 242% growth in MCP servers means nothing if most of them are worse than the CLI that already existed

NGL the flaw in this piece is the same flaw in every "AI will replace X" argument - it assumes the bottleneck was ever the typing.it wasn't. the bottleneck is knowing what to build and why.I use AI agents for probably 80% of my code output now and IMO i'm more productive than ever, but only because i spent years "ape coding" first and can immediately tell when the agent is heading somewhere stupid. the people i see struggling with AI coding are exactly the ones who skipped that part. tbf the calculator analogy that keeps coming up in this thread is backwards - nobody is arguing you don't need to understand math to use a calculator. that's literally the point. you DO need to understand it, which is why "ape coding" isn't going away as some niche hobby.it's the prerequisite

yikes- fair points on being skeptical of arxiv quality, thats a real problem. IMO the content of the paper either holds up or it doesnt regardless of who wrote it

practical takeaway for builders: agent context docs seem to help only when they contain non-obvious project constraints, not generic rules. in my own workflows, the useful bits are things like failure patterns/edge cases or antipatterns ("don't do X") collected over time. this paper is a good reminder that context quality matters more than context volume.

? not sure i follow

def useful to show what models recommend in real use (over just meaningless benchmarks), but i still think small prompt wording and repo setup changes can change the outcome quite a bit so id love tighter controls there. having tried claude code with opus 4.6 with slightly different repo setups gives wildly different results IME. i also generally prefer to avoid the NIH syndrome and prefer using off-the-shelf libraries and specifically tell CC to do so - influences the choice outcomes by a lot

this is what happens when a "public" key type quietly turns into a privileged key type without forcing people to re-scope it, not really a dev mistake IMO, it's a platform design bug and google needs hard separation between publishable and secret keys or this repeats every time they ship a new API. pretty disappointed in google tbh, looked up to them for security for the longest time

honestly the best way to beat my detector is to just write worse

ah yes. looks like it was going over the max token limit. if you retry, will work again!

I work at a large social media company - it has become a popularity contest on who can ship more AI slop the fastest. Real productivity gains are questionable tbh. Slop is replacing more slop.

something deeply ironic about this.

the connection draining feature is really clever. weve dealt with connection storms from app crashes before and the standard playbook is just to restart everything and hope the thundering herd doesnt immediately repeat. having the proxy absorb that chaos at the wire protocol level is much better than trying to handle it in application code, especially when you have 20+ microservices all competing for the same connection pool.

the unique_id() sequence is interesting too - monotonically increasing cross-shard IDs solve a real pain point for pagination. with UUIDs you end up doing cursor-based pagination with composite keys which makes your ORM code ugly fast.