Koder

Full-stack engineer — shipping & building AI — Azure certified — Blockchain & QuantFinance background

[Koder @koder0x]

the last item is the one that should scare you most. silent eval regressions means your system degraded and nothing told you. no exception, no alert, no failed test. just slightly worse outputs shipping to production for days

everything else on this list is hard but detectable. silent regressions are the failure mode where you only notice in hindsight, usually after a user complaint or a manual review

observability as a first-class discipline (also on the list) is the only real answer. if you can't trace why output quality dropped between last tuesday and today, you're not running a production system, you're running an experiment you forgot to close

[diva @divaagurlxw]

As an AI Engineer. Please learn

>Harness engineering, not just prompt engineering

>Context engineering, not just long prompts

>Prompt caching vs. semantic caching tradeoffs

>KV cache management, eviction, reuse, and memory pressure at scale

>Prefill vs. decode latency and why they optimize differently

>Continuous batching, paged attention, and throughput optimization

>Speculative decoding vs. quantization vs. distillation tradeoffs

>INT8, INT4, FP8, AWQ, GPTQ, and when quantization hurts quality

>Structured output failures, schema validation, repair loops, and fallback chains

>Function calling reliability, tool contracts, argument validation, and idempotency

>Agent guardrails, loop budgets, tool budgets, and termination conditions

>Model routing, graceful fallback logic, and degraded-mode UX

>RAG architecture: chunking, embeddings, hybrid search, reranking, and freshness

>Retrieval evals: recall, precision, grounding, attribution, and citation quality

>Evals: golden sets, regression tests, adversarial tests, LLM-as-judge, and human evals

>LLM observability as a first-class discipline: traces, spans, tokens, latency, errors, and drift

>Cost attribution per feature, workflow, tenant, and user journey not just per model

>Safety engineering: prompt injection defense, data leakage prevention, and permission boundaries

>Multi-tenant isolation, cache safety, and cross-user context contamination prevention

>Fine-tuning vs. in-context learning vs. RAG vs. distillation and when each is the wrong tool

>Latency, quality, cost, and reliability tradeoffs across the full inference stack

>Production failure modes: hallucinated tool calls, malformed JSON, stale retrieval, runaway agents, and silent eval regressions

[Koder @koder0x]

the diagram above is textbook for this. nine specialized agents, memory manager, validator, critic, fix loop... and the actual LLM call is almost a footnote. the orchestration layer is already bigger than the model layer

the part most people underestimate is the failure surface. each agent boundary is a new place for context to degrade, for a wrong assumption to propagate silently, for a fix loop to cycle forever on a broken state. reliability engineering in multi-agent systems is closer to distributed systems than to prompt engineering

"getting an LLM to answer questions is the easy part" is already true. getting nine of them to agree on a consistent world state without one quietly corrupting the others, that's the actual job now

[Koder @koder0x]

this is genuinely exciting, writing the harness on the fly is a different class of leverage than static orchestration, and the worktree isolation per subagent is a smart call for anything that touches the filesystem

but the long-running task problem doesn't disappear, it just shifts shape

my "horse war thesis": you have 10 steps, step 3 silently returns something plausible but wrong, and now every downstream agent is confidently building on a bad premise no thrown error, no retry signal, just compounded drift baked into the synthesis step

adversarial verification helps a lot here, but only if the inter-agent contract is typed tightly enough that "wrong" is actually detectable; qualitative steps are the dangerous ones because the verifier has no ground truth to diff against, just vibes

also curious about the compaction boundary in deeply nested fan-outs when the synthesizer summarizes N results, that step is lossy by definition; same failure mode as single-context goal drift, just one level up

the classify-and-route pattern probably needs explicit schema validation at each handoff, not just natural language passing otherwise you're trusting the whole chain on prompt coherence alone

very keen to see how observability tooling evolves around this, right now debugging a failed workflow sounds like archaeology

[Koder @koder0x]

Vibe coding at scale runs into one wall before anything else: cost.

Sonnet 4.6 is still my daily driver.
Solid tool use and a price that makes heavy use viable without thinking about it.

Not the top benchmark. The one that stays in the agent loop.

What's in your stack?

[Koder @koder0x]

code still needs to be read, reviewed and reasoned about after it's generated. the bottleneck moved from writing to evaluating, and evaluating well requires the same technical depth as before. maybe more, because now you're reviewing at a pace no human ever wrote at

English gets you the first draft. the rest is still engineering

[Koder @koder0x]

this is basically socratic method applied to code review. the key move is "have her restate her understanding first" before filling gaps. that's active recall, not passive reading, and it's the difference between thinking you understand a PR and actually being able to defend the design decisions in it

the running checklist is smart too. without it the conversation drifts into whatever feels interesting instead of what's load-bearing. seen too many "explain this codebase to me" sessions that end with the human nodding along but unable to explain a single edge case on their own

stealing the eli5/eli14/elii framing, that's a clean way to signal depth without having to negotiate it every time

[Koder @koder0x]

the agent has been growing

started as a REPL. now it looks more like agent coding tools do
a real TUI. still read-only on the repo, but the scaffolding is there

two models. one for heavy reasoning, one for support tasks
the architecture is where all the interesting decisions live right now

checkpoints aren't a feature. they're the design constraint everything else builds around

not there yet. that's fine
building the harness before the ride

[Koder @koder0x]

tried Opus 4.8 3-4 times today and it blasted in one shot what other models were grinding on. the intelligence bump is noticeable even in the prose, before you even get to the technical output

also worth knowing: Anthropic specifically called out honesty improvements this release. more likely to flag uncertainty, less likely to let flaws in its own code go unremarked. for anyone using it seriously for coding that's not a minor detail

[Koder @koder0x]

Claude Code, making changes across multiple files.

Not in one shot. Multiple steps, each surfaced in the TUI, sequential and deliberate.

That's not raw model output. Something upstream is working before the model touches a single line. The prompt isn't passed through, it's processed. Decomposed into a structured sequence of actions, each scoped, each ordered.

That layer is the harness. And most people using these tools have never had a reason to think about it.

I haven't looked at the leaked Claude Code source. Still haven't. These observations come from the TUI alone, and they're already enough to reframe how you think about what these tools actually do.

The model handles execution. The harness handles intent translation, breaking a vague instruction into a concrete action graph the model can follow step by step. Not a small problem. Arguably the harder one.

Building my own agent, I had to design that layer from scratch. Still early, still incomplete, but every decision I've made so far lives there, not in model selection.

The model matters, but it's rarely the bottleneck people think it is.

[Koder @koder0x]

"Perfect Claude Code setup" seen three this week. None of them explained what comes with it.

Here's what you're actually adding with every MCP.

A trust boundary
Author intent could not close the attack surface. Clumsy implementation leaks context, exposes credentials, opens injection vectors.

Token weight
Tool definitions load into context before you write a line. You're paying for features you may not invoke in every session.

Reasoning overhead
Wider tool surface → more decisions before it touches your code. That's not free either.

One MCP you've audited and actually need, fine. Proliferation is where setups become liabilities.

Every super setup thread stops right before the work that actually matters.

[Koder @koder0x]

exactly, and the failure mode is subtle. eviction policies that look reasonable in isolation start dropping load-bearing context under pressure. you don't notice until the agent makes a decision that would've been obviously wrong if it had seen message 12 from 40 messages ago. silent degradation is worse than a hard failure here, at least a crash tells you something

[Koder @koder0x]

The criticism of AI dev tools usually goes: it made mistakes, needed rework, took extra cycles.
All true. Also completely beside the point.

Software development has never been smooth. Rework is not a bug in the process, it's the process. The dev cycle has always included wrong turns, misread specs, refactors, and debugging sessions that eat entire afternoons.

What AI changes is the multiplier on top of that.
Same messy process. Dramatically higher throughput.

Want to talk about production bugs? Fine. AI is human-governed. A misuse problem is a human problem. And there is no serious evidence that competent AI-assisted engineers ship more defects to prod.

What there is evidence of: Claude Opus catching security issues a tired engineer at 6pm would have missed. Boilerplate that does not steal cognitive budget. Features that used to take days.

Not perfect was never the bar. The bar is net faster, net better, in the right hands.
It clears that bar easily.

[Koder @koder0x]

frontier models are deeply sycophantic by default, it's basically baked into RLHF. Anthropic ones have it in reduced form in my experience, but it's still there

anecdotally each new release seems to ship with a slightly more critical spine than the last, hoping that trend holds

but honestly it's also a system property more than a model property. same base model can be a yes-machine or a rigorous critic depending on what's in the system prompt

most products optimize for validation because users rate "you're absolutely right" higher in the short term. the sycophancy you're seeing is often as much a product decision as a training one

[Alexandre Mutel @xoofx]

I'm thrilled to release CodeAlta - one of the first efficient AI coding-agent TUIs built entirely in C#/.NET 🚀

I've been developing and using it daily for the past 3 months, and I hope you enjoy it as much as I do! 🤗

Retweets are highly appreciated! 🙏

CodeAlta brings you a beautiful, colorful timeline interface, multiple threads in the same workspace, a real prompt editor experience, quick file viewing/editing with syntax highlighting, in-app model provider configuration, a multi-agent-ready environment, and much more! ✨

[Koder @koder0x]

The next model drop won't fix your AI dev workflow issues.

Everyone's waiting for it. Bigger context. Better reasoning. Higher benchmarks. As if the ceiling is always the model.
It's not.

Model capability and harness quality are two different axes. Benchmarks measure the first in a vacuum. Production lives on both.
A supercomputer cluster with a poorly designed internal network doesn't punch at its weight class. Raw compute, bottlenecked by infrastructure. The model is the cluster. The harness is the network.

Concrete proof — Claude Code vs GitHub Copilot.
Both can run Anthropic models. The output delta is tangible. It's coming from how CC orchestrates AI agents. The way it manages multi-step tasks, sequences tool use, and structures what the model sees and when. That's an engineering achievement, not a benchmark one.
Same DNA. Better armor. Different result.

The uncomfortable implication.
A well-engineered harness can extract more from today's models than the next model drop will hand you for free.
The engineers obsessing over model upgrades while shipping mediocre context pipelines and shallow agent orchestration are optimizing the wrong variable.

The leverage is in the harness. Most people aren't looking there.

[Koder @koder0x]

started building my own AI coding agent

first real test: a private quant finance codebase, cold start, no context

it oriented itself. knew where it was

the meta part. using an agent to build an agent designed around human checkpoints. not autonomous runs. surgical interventions

v0.1.0a1. early & incomplete. but it works

[Koder @koder0x]

Delegating long running tasks to AI coding agents is a bad bet.
Not because AI can't handle it. Because you don't know step 3 is wrong until step 6 is done.

The compounding problem. Every step downstream of a poisoned one inherits the poison. You are not losing the time spent on that step. You are losing everything built on top of it. Tokens burned. Hours gone. And the longer the chain, the deeper the damage by the time you surface it.

The supervision math doesn't add up. AI already compressed your development loop. The speed is there. So what exactly are you gaining by removing yourself from the checkpoints? Spare time while the model runs? The ROI calculation only works if nothing goes wrong. And something always goes wrong.

Tight loops are not slower. They are safer at the same speed. Short delegation, verify, next step. You catch the poison at step 3, not after step 6. The throughput difference is marginal. The risk difference is not.

On agentic being the next level after vibe coding. It isn't. Vibe coding is agentic by design. The moment you're prompting and iterating instead of writing every line, you're already in an agentic loop. The vibe → agentic "evolution" is a content narrative, not an engineering one. Optimizing for delegation length is not a productivity metric. It just sounds like one.

Bottom line. The question was never whether AI can run a multi-step plan unsupervised. It can. The question is whether you can afford to discover the damage only after the chain is complete. Most of the time, you can't.