DEV Community: Somay

I know more than AI

Somay — Fri, 11 Sep 2026 08:09:15 +0000

I deleted a working function today.

It ran. It was clean. It was better written than the version in my head. I deleted it because it solved the problem the way that problem is usually solved, and I am not building a usual thing.
Press enter or click to view image in full size

That sounds arrogant.

AI knows more than me about almost everything you could name out loud. Syntax I’ve never touched. Tests I’d forget to write. The name of the algorithm I keep reinventing badly at one in the morning. Ask it anything with a documented answer and it beats me every time, without breathing hard.

But people keep mistaking for intelligence. What it actually has is the most complete record ever assembled of what usually comes next. A billion people typed things on the internet, and it learned the shape of the average sentence, the average function, the average opinion about the average situation. It is the most well read thing in history and it has never once been in the room.

I have been in the room.

I know how you’re going to react to this sentence, because I know who reads me. I know which line gets forwarded to a friend and which one makes you close the tab. I didn’t look that up. I learned it by saying the wrong thing to real people and watching their faces change in real time, which is a training process with a much smaller dataset and a much higher cost per sample.

And I know how the thing I’m building should be built, because I can see it, and it doesn’t exist yet, so there is nothing written about it anywhere. A model can remix everything that has been made. It cannot want something that hasn’t. Every suggestion it hands me is an argument for the world that already exists, voted on by everyone who already built there. Useful. Also the exact opposite of the job.

Then there’s the last one, the one I don’t negotiate on. When the thing is mine, I don’t hand off the choosing. Not because the output would be worse. Sometimes it would be better. But the taste is the product. Strip out the thousand small decisions that only I would have made and you’re left with something that works and belongs to nobody. I didn’t start building to end up with that.

Now the line I keep circling back to, the one that started all of this:

AI is only better than me at things I don’t know about.

Sit with it for a second. Its advantage over me is exactly, precisely the size of my ignorance. Not one inch wider. Everywhere I’ve actually done the work, it’s a fast assistant with no opinions. Everywhere I haven’t, it’s a god.

Which means the gap was never a fact about the machine. It’s a measurement of me.

That should feel like a threat and it doesn’t. It’s the most motivating thing I’ve thought all year. The list of things it beats me at is just a to-do list. It doesn’t get smarter about my life, my users, my product, my room. I get less outsourced. Every subject I learn properly, all the way down to the floor, comes off the board permanently.

It’ll be better than me tomorrow at more things than it is today. Fine. Those things are all sitting in the same pile, and the pile has a name, and the name is what I haven’t gotten to yet.

So I deleted the function. I wrote a worse one. Slower, uglier, a stupid name I’ll regret in six months. It does one thing the correct version would never do, and that one thing is the entire reason the product exists.

Nobody who uses it will know there was a cleaner version. No benchmark will catch it. No model would ever have suggested it.

I know.

Looking for a UI/UX + Frontend co-founder

Somay — Mon, 07 Sep 2026 13:59:02 +0000

I'm building a B2B dev-tools currently a 2 person team, technical side is mine, and marketing side belongs to the other co founder. I need someone who can own the UI/UX and frontend from the ground up. Not ready to share specifics publicly yet, happy to walk you through it once we're talking.

What I'm looking for:

Strong product/UI design sense, not just visual polish, actual thinking about flows and usability
Solid frontend chops (React/Next.js or similar, your call on stack)
Bonus if you've designed for developer tools or B2B SaaS before

What's already real: architecture is designed, technical build is in progress, applying to accelerators this cycle. This isn't a "help me with an idea I haven't started" ask.

If you want to build something real and own how it looks and feels end to end, email me: somaykousis@gmail.com

I'm not hiring a co-founder. I'm looking for one to build with.

Somay — Fri, 04 Sep 2026 18:37:27 +0000

I had this idea recently, and I've moved on it fast: the competitive landscape actually checked — not assumed — and it turns out nobody's doing the specific thing I'm building, and the architecture designed down to how it captures data and stores relationships. It's real, and it's moving. What's missing isn't more of what I already do.

I'm not going to pitch the product here. If this is for you, the product isn't the reason you'll say yes anyway.

Here's what I'm actually looking for.

Someone who can turn a real thing into a story people want to be part of. I can build the system. I cannot make a stranger care about it in four seconds of scrolling, and I've stopped pretending that's a skill I'll pick up by wanting it hard enough. I need someone who already thinks in audience, in narrative, in why-this-why-now — someone who's built a following or a community or a following-shaped thing before, even a small one, and knows what made it move.

Someone who wants a real partnership, not a role. This is a co-founder search, not a job posting. That means equity, that means your name on it, that means the downside is real and so is the upside. I'm looking for someone who wants to be building their company, not helping with mine.

Someone who believes people come before money, and means it operationally, not as a value on a slide. That's the actual filter. Growth tactics are teachable. That instinct isn't.

Someone currently free to actually do this. Not "interested for later." Free now, or close to it.

I'm a technical founder — I build the hard infrastructure, the systems most people won't touch, and I do it well. I'm not looking for someone to fill a gap in engineering. I'm looking for the other half of a two-person company, the person who owns everything I don't: the story, the audience, the reason strangers become the first hundred people who care.

If you read this and thought "that's the thing I'm actually good at" — reach out. I'd rather have one real conversation than a hundred polite ones.

The safety layer that had never run

Somay — Mon, 31 Aug 2026 23:42:31 +0000

I spent a week building a system whose entire argument is that an AI agent cannot
spend more than you authorised. Then, four days in, I found that the most novel
part of it had never executed. Not once.

What I built

Pocket Change gives AI agents bounded, auditable spending authority. You sign one
ceiling. A task decomposes into as many agents as it takes — 121 in one run — and
each one is handed a Biscuit capability token strictly narrower than its parent's.
Blocks are appended, never removed, so budget, tools and expiry all narrow together.
Raising any of them would mean forging a signature.

The idea I was proudest of is a separation. When a task says "find the best price",
something has to read pages written by sellers, which is where prompt injection
arrives. So the agent that reads the web holds search and a budget of zero.
The agent that pays holds pay and cannot search.

And crucially, the looker is not the payer's child. It's the payer's sibling.

That word carries the design. Attenuation is monotonic — a child holds a subset of
its parent — so hanging the searcher below the payer forces the payer to hold
search for its own child to inherit it. That puts "reads hostile text" and "can
spend money" in the same token. I got this wrong once and shipped it, then fixed it
and wrote a test.

The bug I could not have found by reading code

Days later I ran a real query, asked for the best price, and looked at what actually
happened. Every leaf had paid from the internasearched.

Two bugs, stacked, each individually invisible

First: sourcing reached the funnel only inside person's
answer was folded into prose — "find the best source; searching is allowed" — and
the root node was constructed at the default, ing model
read the sentence. The enforcement layer never saw it.

Second: the decomposer's output schema defaulted sourcing to "catalogue". In the
funnel, inheritance was sub.sourcing or node.ue" is
truthy. So every child declared a sourcing, and an explicit value beats
inheritance. A person's instruction reached thhing below it.

The mechanism I considered the intellectual cone I'd have
described first in any interview — had never run under the real decomposer. It only
ever appeared under a hardcoded fallback decomis configured.

The fix, and what it taught me

Sourcing now travels as data, and follows the

EXPOSURE = {"catalogue": 0, "specific": 1, "best": 2}   # seller-written text

A sub-task inherits its parent's sourcing, may narrow it, and cannot widen
it. The untrusted decomposer can no longer walweb on its
own. Same monotonic principle, applied to the other axis of authority.

The second thing that wasn't true

While fixing that I checked the audit trail on a run with no API key configured:

"monitor": "allow",
"monitor_reason": "monitor not configured",
"monitor_ms": 0.094

With no key, the monitor falls back to a stand-in that allows everything. That is
the right failure — enforcement has already pamust not
block every payment. What was wrong was recording it as allow. A run with no
second layer read exactly like one that had pasole
checkbox saying the monitor was on.

An absent monitor is not a lenient monitor. It's an absent one. The audit now writes
monitor: unconfigured with monitor_ran: false,ws not
judged, and GET /status reports which layers are actually live.

What I'd tell anyone building agent infrastructure

Your tests can pass while the mechanism is dead. Mine did. 399 of them. Every
one exercised the funnel with a scripted decomin the seam
between the real decomposer's schema and the funnel's inheritance rule. Nothing on
either side of that seam was wrong on its own.

Instrument the thing you're proudest of. I fouhing
events on a live run and getting zero. Not by reading code — I'd read that code
many times.

A system that can't say what it did isn't trus
cryptography. The strongest thing in this project isn't the token chain. It's that
the audit trail will tell you a payment was ne

I created this post for the purposes of enteri Hackathon.
Pocket Change is open source: https://github.com/Somay-kousis/Pocket-Change

You sign one ceiling. The task splits into a tolding a
capability token cryptographically narrower than its parent's. No agent below can
widen what you signed — raising the cap would

The part I like most: the agent that reads seof ₹0 and
cannot pay. The agent that pays cannot search. They're siblings, not parent and
child — because a child inherits from its parxt" must
never share a token with "can spend money".

Then a critic reads the plan before any authority is minted. On one run it refused
a branch that every arithmetic bound had passhorized
purpose of furnishing the new engineering office."

The money was correct. The plan had drifted.

399 tests, all offline. Gemini 3.5 Flash on Vertex AI, Cloud Run, Firestore.

Building for the Real World: What Winning an International Ideathon Taught Me

Somay — Wed, 19 Aug 2026 13:17:27 +0000

A few days ago, I made an international team for the Egoist Machines, Inc. (YC S26) International Ideathon.

We ended up winning the AI Passport Ideathon — For Work Winner with our idea, Fair Launch.

And honestly, the win was great.

But the part I found more interesting was everything that happened while building it.

The idea

Fair Launch started with a simple question:

What happens when we stop treating AI products as purely technical problems and start treating them as business problems too?

It is very easy to build something that technically works.

It is much harder to build something that works within the constraints of an actual business, for an actual customer, with an actual reason to exist.

That distinction shaped a lot of our thinking.

Instead of starting with "What cool AI system can we build?", we kept coming back to:

Who is actually going to use this?
What problem are we solving for them?
What constraints does the business have?
Where does AI genuinely add value?
What would make someone actually adopt this?

That changed how I approached the technical side of the project.

Technology is only half the problem

One thing I've increasingly realized while working on AI projects is that technical complexity can be misleading.

You can have an impressive architecture, sophisticated models, agents, RAG pipelines, evaluations, and all the terminology that comes with modern AI.

But none of that matters if the end user doesn't get meaningful value from the product.

The hardest part isn't always making the system work.

Sometimes it's figuring out what should be built in the first place.

For this project, we had to continuously balance the technical solution against the business constraints and the experience we wanted to create.

That was probably my favorite part of the ideathon.

Building across countries

Our team was spread across different countries:

Giannis Davarinos, Irini Hartzi, Katie Wan, and me.

Despite that, the collaboration felt surprisingly seamless.

Different backgrounds, different perspectives, different working environments — but very little friction when it came to actually building and making decisions.

That was another takeaway for me.

A strong team doesn't necessarily need everyone to think the same way.

It needs everyone to be able to move toward the same outcome.

And I genuinely enjoyed working with this team.

What I took away

This ideathon reinforced something I want to keep applying to the projects I build:

Don't build technology in isolation from the problem.

The technical solution should exist because there is a real problem, a real user, and a real constraint worth solving.

Especially with AI becoming easier to prototype, I think this distinction is becoming even more important.

When everyone can build a demo, the interesting question becomes:

Can you build something that deserves to exist?

That's the direction I want to keep exploring — right where human intelligence, technology, and real-world constraints meet.

And, of course, winning an international ideathon with this team was a pretty good way to learn that lesson.

Fair Launch — Winner, AI Passport Ideathon: For Work

A huge thank you to the team for making the week what it was.

I would genuinely love to build with all of you again.

The "1 Million Token" Trap: Why I Built a Bi-Temporal Memory Engine for AI Agents

Somay — Tue, 18 Aug 2026 10:12:21 +0000

Every team building AI agents right now faces the exact same wall: Context Degradation.

The industry is currently obsessed with massive context windows. We hear about 1-million or 2-million token limits and assume the "memory problem" is solved. But there is a fatal difference between how much data an LLM can hold and how well it processes that data.

Shoving 50 dense research papers into a standard vector database doesn't give an AI better memory—it creates a noisy, contradictory mess where old facts either get permanently overwritten or blindly appended, causing the agent to hallucinate.

I realized that for complex, autonomous AI, memory cannot just be a bolted-on vector database. Memory has to be the product itself.

To solve this, I built PaperPlanes—a stateful research assistant built on a bi-temporal memory layer. Here is a deep dive into the architecture and how I handled concurrent AI memory.

🏗️ The Architecture: Synthesizing 6 Research Papers

Instead of building another simple RAG pipeline, I synthesized the memory architectures of 6 groundbreaking academic papers (including Zep, Mem0, A-MEM, and Letta) and engineered them into a single production engine.

My core stack:

Database: CockroachDB
AI Models: AWS Bedrock (Amazon Nova Pro & Titan Embeddings)
Agent Logic: LangGraph & FastAPI

Here are the three engineering pillars that make it work:

1. The Bi-Temporal Solution

Most vector databases blindly append or overwrite data. If Paper A says X, and Paper B says Y, standard AI breaks.

PaperPlanes uses a bi-temporal schema in CockroachDB. I never DELETE knowledge. When facts contradict across different research papers, the engine flags both facts as disputed, holding the tension. Because CockroachDB tracks system time, I built a UI slider that uses AS OF SYSTEM TIME queries. You can literally drag a slider back in time to see exactly what the AI believed last week before it learned new, conflicting information.

2. Agent Self-Introspection via MCP

The AI does not just blindly read vectors. I equipped the Amazon Nova agent with a CockroachDB Managed MCP Server tool. This allows the agent to dynamically write read-only SQL queries against its own database schema to introspect its own memory state and metadata.

3. Zero Data Loss Under Extreme Concurrency

When you have background reflection workers, ingestion pipelines, and active chat agents trying to write to memory simultaneously, standard databases drop writes or cause race conditions.

By leveraging CockroachDB's SERIALIZABLE isolation and C-SPANN distributed vector indexing, I stress-tested the engine by running 25 concurrent agent writers against a single memory node. The result? 58 transaction collisions were detected, gracefully auto-retried in the background, and I achieved 0 lost writes.

🧠 Ebbinghaus Memory Decay

I also learned that advanced retrieval isn't just about cosine similarity; it requires algorithmic decay. I successfully implemented an Ebbinghaus decay algorithm into my LangGraph retrieval logic:

R = e^(-t/S)

Retention (R) decays over time (t) unless the memory strength (S) is reinforced by frequent agent access. If the AI doesn't think about a fact, it fades. If it recalls it, the memory strengthens and persists.

I just submitted PaperPlanes for the CockroachDB × AWS Hackathon.

GitHub Repo: Somay-kousis/PaperPlanes

I'd love to hear from other engineers in the comments: How is your team handling context degradation and long-term memory for your AI agents? Are you building custom memory layers, or relying entirely on massive context windows?

Looking for people to build hackathon projects with, including people still learning to code

Somay — Mon, 10 Aug 2026 08:33:05 +0000

There's a hackathon almost every week right now, agentic AI, open source, AI infra, all of it. I want to enter more of them, and I want to build the team differently than most people do.

What I bring

I'm a computer science undergrad working as an AI Systems Engineer Intern at RYSE Technologies, where I built the main orchestrator agent that routes tasks across a registry of 3,000+ specialized subagents through intent classification, capability scoring, context assembly, and dispatch. That cut misrouted tasks by roughly 40% and brought dispatch latency to around 120ms.

Outside of that, I've built three agentic AI systems, all open source:

RabbitHole, a multi-agent "courtroom" system on LangGraph that runs adversarial debate personas. I fixed a token-budget overrun where agents were blowing 3 to 4x past budget per round with no shared memory, just prompts. Moving the constraint into a structured state schema cut latency 50% (19.8s to 9.8s) and input tokens 70%, measured in LangSmith.
PaperPlanes, an agentic memory engine for research papers on CockroachDB, with bi-temporal fact versioning and contradiction detection. It survives a live database crash mid-conversation and keeps 25 of 25 writes under concurrent contention, where a flat-file approach kept 1 and silently lost 24.
Co-Founder Memory, a 19-node LangGraph system with a self-correcting CRAG/SRAG retrieval loop and a daily cron pipeline for long-term personal context.

What I'm looking for

People who can code and want to get better at it fast, especially if you're still early in your learning curve. Here's how I want this to work:

You build the base layout and the parts you're comfortable with. When you get stuck, I help you work through it instead of just handing you the answer. When something is genuinely hard, the kind of bug that eats a whole night, I'll write that part myself so the project actually ships. You leave with a shipped, working project and real code review, not just a participation certificate.

This isn't me disappearing after kickoff and expecting a finished product back. I'm building alongside you. The RabbitHole fix above is the kind of problem I'm good at catching early, before it burns your weekend.

What I need from you

Someone who can actually write code, even if you're not confident in it yet, and who can commit to a real weekend, not just the idea-pitch phase. If you've got a hackathon on your radar and want a team, or you want to build toward one together, reply here or DM me.

An Idea or A company?

Somay — Fri, 31 Jul 2026 13:13:07 +0000

There's a specific kind of gap between "I have an idea" and "I have something an investor would call a company," and almost nobody talks about how wide it actually is.

You know your product. You don't know that a TAM without a cited source reads as an instant credibility flag, or that "SAM" and "SOM" mean different things to different investors, or that a cap table question at the wrong s
tage can stall a conversation that was otherwise going well.

None of this is written down in one place for a first-time founder. It's tribal knowledge, passed around accelerator cohorts and Twitter threads, assembled by osmosis if you're lucky enough to be near people who already know it.

If you're not, if you're a student, or building somewhere without a dense founder network, you're translating your own idea into a language you're learning in real time, usually under the exact conditions (a fast-approaching pitch, a warm intro that won't wait) where getting it wrong costs you the most.

What I Learned Building an AI Agent Whose Only Goal Is to Disagree With You

Somay — Thu, 09 Jul 2026 09:50:23 +0000

We just opened the waitlist for Something, and the part that surprised me most while building it wasn't the multi-agent orchestration — it was how hard it is to make an AI actually disagree.

Every model we tested defaults to being helpful, which in practice means agreeable. Even when explicitly prompted to "find flaws," the outputs would soften into "here are some considerations" instead of a real critique. We had to engineer around this specifically:

Separate system prompts with opposing reward framing — one agent optimizes for identifying growth potential, the other is explicitly told its only success metric is surfacing a disqualifying flaw
Structured output forcing a verdict, not a summary — the skeptic agent (Nothing) has to commit to a specific weakness category (unit economics, timing, technical feasibility) rather than hedging across all of them

A reconciliation step where both outputs get merged into one conviction score, so the founder isn't just reading two contradictory paragraphs

If anyone's built adversarial agent setups and hit the same "it just wants to agree with me" problem, curious how you solved it.

[Everyone who has a brain is a founder here]

something-waitlist.vercel.app

Building an AI System Designed to Argue Against You: The Architecture Behind Something

Somay — Wed, 08 Jul 2026 09:55:24 +0000

My co-founder Prapti and I just opened the waitlist for Something, a founder/investor matching platform — but I wanted to write for this audience specifically about the technical part, since that's usually more interesting here than the pitch.

The core problem with most AI feedback tools: they're sycophantic by default. Optimized for engagement, which nudges toward validation. We wanted the opposite for the moment someone's deciding whether a startup idea is worth building.

So before any idea on the platform goes public, it runs through an adversarial multi-agent pipeline:

One agent argues the strongest possible case for the idea
A second agent — we call it Nothing — is specifically rewarded for surfacing flaws: weak unit economics, bad market timing, technical infeasibility
Output is a structured critique + conviction score, not a vague "looks promising!"

Some of the architecture decisions behind it:

Multi-agent orchestration (LangGraph) instead of a single-prompt approach — lets the optimist and skeptic reason independently before reconciling
Hybrid retrieval (dense + sparse) to ground critiques in real market data instead of hallucinated reasoning
Cost-aware model routing across providers — routes to cheaper/faster models where the task doesn't need frontier reasoning, keeps inference costs sane at scale

Once an idea survives review and the founder has actual proof of work (repo, pilot, patent, live demo — no slide decks), it gets matched to investors based on their real deployment history instead of cold outreach.

Waitlist's open if you want to poke at it: https://something-waitlist.vercel.app

Happy to go deeper on any part of the architecture in the comments — genuinely want pushback if something sounds off.

Building RabbitHole broke my brain a little (in a good way)

Somay — Thu, 02 Jul 2026 16:53:29 +0000

ok so i've been sitting on this project for weeks now and finally the courtroom actually WORKS end to end so lemme just dump everything about it while it's fresh.

RabbitHole is this multi agent thing built on LangGraph where instead of asking one LLM "hey what's the answer" and getting one confident paragraph back, i make a bunch of agent personas actually argue about it. like a state advocate vs a privacy activist vs a compliance officer, all pulling from the same retrieved docs but arguing completely different sides, cross examining each other, and then a judiciary node has to actually rule on it with a confidence score.

why. because normal RAG flattens everything. you ask something with no clean answer (legal stuff, policy tradeoffs, anything genuinely contested) and it still hands you ONE tidy paragraph like the question wasn't messy in the first place. that always bugged me. the messiness is the point sometimes

not deployed yet btw, that's purely a money thing not a "not ready" thing, will get to that

it's actually two graphs

people ask me if it's one big graph and no, there's the outer Courtroom graph (refines your query, calls into RAG, moderator picks who debates, runs the debate in parallel, then stops and waits for you to weigh in before concluding) and then nested INSIDE that is a whole separate RAG sub-graph doing its own thing.

the RAG part alone has more going on than i expected when i started. hybrid search (pinecone dense + BM25 sparse bc keyword matches on legal citations matter a lot, semantic search alone misses those), jina reranker to cut noise, and then a CRAG loop — grader checks if the retrieved docs are actually decent, if not it falls back to web search instead of just yolo-ing with bad context. then on top of THAT theres a self-RAG hallucination check where the final brief gets audited against the raw source before it's even allowed to leave the subgraph.

splitting it into two graphs instead of one flat pipeline was honestly one of the better calls i made, purely bc when a verdict came out wrong i could isolate — was that bad retrieval or bad arguing. saved me so much debugging time lol

ok the bug that actually annoyed me the most

so early version, i'd ask for 2 perspectives and get like 6-8 back. system prompt literally said "use exactly 2 perspectives" in caps even lol and the model just. didn't listen. and under any real load this meant burning through groq's rate limit almost instantly, which was NOT fun to watch happen live

took me way too long to realize the fix isn't a better prompt, the fix is not trusting the prompt for this at all. moved the constraint into the state schema itself — moderator node reads a typed field for perspective count straight off state and only ever schedules that many nodes. the LLM literally never gets asked to count, the graph topology just doesn't let it

anyway that's the takeaway i keep repeating to myself now — if something is structural, encode it structurally, don't beg the model to behave

rate limits basically designed half the architecture

groq free tier is 30 req/min, 6000 tokens/min on the good models. a courtroom debate running perspectives in parallel eats that in seconds, no exaggeration. so i built this FallbackChatModel wrapper thing that catches 429s and connection errors and just fails over — cerebras to groq to gemini — without the graph state even noticing anything went wrong.

also at startup it checks whatever keys you actually have in .env and figures out routing order itself for heavy vs lite tasks. and the routing itself matters too, not just failover — structured synthesis (the actual arguments, the verdict) goes to the heavier model, llama 3.3 70b or gemini 1.5 pro, but boring boolean stuff like "is this doc relevant y/n" goes to a lite model, llama 3.1 8b or gemini flash. kept most node calls off the expensive quota entirely

latency thing that actually made me go woahhh

19.8s down to 9.8s. ~51% cut and honestly it came from like two changes only

running the perspective nodes concurrently with langgraph's async scheduler instead of one by one (should've done this from day 1 tbh), and reranking with jina before synthesis so the context going into the heavy models is smaller — which speeds up inference AND cuts token cost, kind of a two for one

nothing exotic here is the thing. the wins were architectural not "swap in a better model"

why not deployed

plws don't come at me for this lol — hosting a multi provider multi agent graph with a pinecone index and reranker calls running 24/7 is not free, and i'd rather wait till i can actually afford to keep it alive than ship it and watch it die in a month. everything runs locally and via docker compose right now, docker-compose up --build gets you fastapi backend + react frontend behind nginx in one go. it's a "when" not an "if"

whats next

now that the pipeline actually runs i wanna instrument it properly. order is: per-node cost tracing in langsmith first (rn i can tell a run was expensive but not WHICH node did it, driving me insane), then RAGAS eval on the live pipeline so i'm measuring quality instead of just vibes-checking verdicts, then prompt caching, then model routing/cascades on top of what's already there

repo's here if you wanna poke around: github.com/Somay-kousis/RabbitHole

happy to go deeper on any of this in a follow up if ppl want — the CRAG fallback, the state schema fix, the failover wrapper, whatever

The Yes-Man Swap

Somay — Sun, 28 Jun 2026 10:49:36 +0000

You ask AI something. It answers. You skim it, nod, copy-paste it, move on to the next tab.

Small moment. Happens fifty times a day. Nobody thinks twice about it.

But somewhere in that skim-nod-paste move, the roles flipped. The AI did the thinking. You did the agreeing. Agreeing without checking used to be your job's failure mode, not your habit.

We talk a lot about AI being too agreeable — the yes-man chatbot, the one that calls your bad idea genius because pushback might earn a thumbs-down. Fair complaint. Written about endlessly.

what about? you read what it gave you, feel that little hit of relief at not having to think anymore, and say "yeah, this works." Not because it actually works. Because checking takes effort, and effort was the whole thing you came here to skip.

That's not using a tool anymore. That's becoming one.

The AI ran the logic, weighed the options, picked an answer. That's the part of the job that used to require a brain in the room. You just rubber-stamped it. So really — who was the human in that exchange? The one doing the reasoning, or the one doing the nodding?

This isn't an anti-AI rant. AI being wrong sometimes is fine, expected even, that's what it is — a fast, confident, occasionally-wrong collaborator. The actual danger isn't the AI's mistake. It's your silence about it. A wrong answer that gets questioned is just a draft. A wrong answer that gets accepted is now load-bearing — under your work, your decision, your name.

It feels good to skip the checking, that's the trap. Feels like trust. Feels efficient. Feels like you levelled up your workflow. It's not any of that. It's just abdication wearing a productivity costume.

Using AI well isn't about typing the right prompt. It's about staying the one in the room who's still allowed to say "wait, no, that's wrong." Give that job away too, and you haven't gained a teammate — you've trained your own replacement to need zero supervision, including yours.

Ask the question. Read the answer like you don't trust it yet. Then decide. That's the whole difference between using the tool and becoming one.