u/reubenzz_dev

I keep asking Claude to build custom TipTap plugins. Works great until I test undo, then the history gets weird with duplicate entries, loops, and other changes

I found that the issue is that Claude forgets to set setMeta():

appendTransaction(tr, oldState, newState) {
  // Auto-format on keystroke
  newState.doc.descendants(node => {
    if (shouldFormat(node)) tr.insertText('x', pos);
  });
  return tr;  // Missing: tr.setMeta('plugin', true)
}

Without it, every keystroke that triggers your plugin adds to the undo stack. Press Ctrl+Z and you're stuck in duplicate entries. Same thing happens with every custom node I ask Claude to write. Works perfectly in the editor, broken undo history.

ok so I've been using Claude through OpenCode to scaffold some auth logic, and I noticed it keeps generating the exact same insecure pattern with Supabase

Has anyone else run into this? Every time I ask Claude through OpenCode to set up Supabase auth with roles, it generates this:

if (user.user_metadata.role === 'admin') {
  // Allow access
}

works in local but user_metadata is client-writable any authenticated user can hit the Supabase /auth/v1/user endpoint and set their own role to admin

I've seen this happen 5+ times in the last week using Claude through OpenCode for different projects.

and yes I've tried prompting..."claude make no mistakes"

I've been scanning projects built with Claude Code and found a pattern that keeps showing up:

export function middleware(request) {
  const token = request.cookies.get('session')
  if (!token) return NextResponse.redirect('/login')
  // proceeds — token presence checked, but never verified
}

The token is never passed to admin.auth().verifySessionCookie(). So any value in that cookie including a forged or expired one gets through. Works perfectly in dev. No errors.

The correct version calls verifySessionCookie(token, true) and handles the rejection. Claude never adds this step unless you explicitly ask, and sometimes not even then.

becareful in prompting out there devs

I spent the last few weeks analyzing what Supabase bugs AI actually generates. Specifically: code that compiles, passes type checking, and looks production-ready but is vulnerable.

RLS misconfigs. The agent writes policies that look correct but are backwards:

-- Agent generates this (backward)
CREATE POLICY "users can read own data"
ON public.users
FOR SELECT
USING (auth.uid() != id);  -- Should be = not !=

Unsigned webhooks. Your agent sets up the route but forgets to verify the signature:

// Missing signature verification
export default async function handler(req, res) {
  const event = req.body; // Never verified
  // Process event...
}

JWT claims trusted without validation. Takes the JWT payload as is:

// Agent assumes user_id came from a real JWT
const userId = req.body.user_id; // Could be spoofed

Hardcoded anon keys in client. Puts the private key where it shouldn't go.

Missing user ID checks in queries. Queries that should filter by user never do.

Hey everyone,

If you are building workflows with coding agents (Cursor, Claude Code, Aider), you've inevitably hit the semantic hallucination wall. The agent confidently generates an API integration, the syntax is flawless, and it passes standard TS/ESLint checks. But it hallucinated instead of the actual endpoint, or it forgot a required idempotency key.

When the code breaks at runtime, feeding the stack trace back to the agent usually results in it hallucinating a different non-existent method to fix the first one. then it burns tokens trying to fix it.

I built api-doctor, an open-source CLI and agent skill, to solve this. Here is how the architecture grounds the agent:

1. Fluent Chain Flattening (AST Parsing) Instead of dumping massive OpenAPI specs into the prompt (which destroys context limits and skyrockets MCP token costs), api-doctor runs locally. It uses oxlint under the hood to parse the codebase's Abstract Syntax Tree (AST). Because modern SDKs use fluent method chaining, the parser flattens nested MemberExpressions to map exactly what the agent is trying to execute.

2. Deterministic Semantic Verification It cross-references that flattened AST operation against lightweight, pre-compiled JSONB schemas of provider SDKs (currently supporting Supabase, Resend, Auth0, Stripe, etc.). It isn't guessing if the code is right—it runs fixed, deterministic rules. It catches missing tenant scopes, unhandled { data, error } contracts, and deprecated endpoints.

3. Agent-Native Feedback Loop Instead of the human running the CLI, you expose api-doctor directly to the agent as a native skill (or via pre-commit hooks). The agent writes the code, calls api-doctor to statically analyze its own output, and receives a strict terminal report of exactly which lines violate the API contract. The agent then fixes its own hallucination before you ever attempt to compile or execute the code.

The framework is fully open-source (MIT) and runs 100% locally on the CPU, so you aren't sending your proprietary code to a third-party cloud just to validate an API call.

I’d love to get this community's feedback on the architecture. Specifically, I'm curious how you all are handling the tradeoff between exposing massive OpenAPI specs via MCP (high token cost) versus giving agents hyper-specific, deterministic local linters like this.

It's a simple CLI that scans your code and flags issues until you fix fake or broken API endpoints generated by AI.

I've been struggling with AI agents hallucinating fake API methods lately so I built the tool to validate my integrations locally and thought it might also be useful for others so I published it on GitHub and NPM but I didn't expect that it will get this much traction.

Nothing crazy since it's only a few hundred of downloads but it's very motivating to me that it gained that many users in just a short period of time and lots of people are providing feedback that they love the idea and also sending feature requests which will help me improve the CLI for the next version that I will release.

I'd really appreciate it if you can give it a try and I would love to hear your feedback: https://github.com/qualtyco/api-doctor

Happy to answer any questions!

https://preview.redd.it/70zigmgm8i9h1.png?width=818&format=png&auto=webp&s=2f25d31171dd2cf42723f74fe1114f72ed755bcb

hey QA engineers, I'm a student currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? 

With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?
2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue especially if your product QA is a API or SDK

hey I'm a student currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? 

With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?
2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who's had customer experience with this issue especially if your product is a API or SDK

hey startup engineers, I'm a student currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? 

With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?
2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue especially if your product is a API or SDK

hey startup engineers, I'm a student currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? 

With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?
2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue especially if your product is a API or SDK

hey startup engineers, I'm a student currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? 

With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?
2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue especially if your product is a API or SDK

Hey devrel engineers,

I'm currently doing research on how your positions manage or handle issues when developers in your community complain about a broken implementation or setup? With all the new coding agents we all know that devs are just making agents read docs and relying on it to properly implement things based on those docs.

So now I have two questions:

1. How do you currently find out when a developer's integration is broken?

2. If agents are now generating most integration code, has that changed anything for your team?

Would love to hear with anyone who is facing this issue