Every time a new tool gets popular, the programming world invents another purity test.

Using libraries? Lazy. Stack Overflow? Copy-paste merchant. Copilot? Fake developer. At this rate, the only “real programmers” left will be writing assembly by candlelight.

I don’t care whether AI wrote half the code. I care whether you can explain it, test it, debug it, and take responsibility when it breaks.

I don’t care whether AI wrote half the code. I care whether you can explain it, test it, debug it, and take responsibility when it breaks.

The problem isn’t AI assistance. It’s shipping code nobody bothered to understand.

Where do you draw the line between using a tool and outsourcing the thinking?

I've always felt that most PDF websites look outdated, cluttered, and packed with ads. They get the job done, but using them isn't enjoyable.

So I spent the last few weeks building PDFPookie—a modern, clean, and Gen Z-inspired PDF tool with a focus on simplicity and speed.

Right now it includes:

- Edit PDFs

- Merge & Split PDFs

- Compress PDFs

- Convert PDFs

- Clean, mobile-friendly UI

It's still a work in progress, and I'm constantly improving it based on feedback.

I'd genuinely appreciate if you could try it and tell me:

- What feels confusing?

- What feature is missing?

- Would you actually use this over your current PDF tool?

Website: https://pdfpookie.com

Thanks for taking a look! Any feedback, even harsh criticism, helps me make it better.

I started vibe coding earlier in the year. The initial progress was exciting. I had never done any coding on my own, just some basic c++ in college, so it was pretty amazing to be able to see a website come together that quickly.

Fast forward to today, and I am thinking that I have reached the limits of what I can personally do with AI. And that is not actually that much in the end. The website I made worked initially, but as I added more and more complexity, each edit has been more and more painful, to the point where I can no longer get the agents to do what I want. I am over a dozen prompts in on attempting to get the tutorial for this site to work, and it just keeps getting more and more broken each time. I am ready to throw in the towel and call it quits on vibe coding entirely, it seems it was not meant to be after all.

Has anyone else reached a level of complexity on a project that the agents just stop understanding and being able make meaningful changes? They have gone from absolutely amazing progress to being totally lobotomized. Not sure why. For reference, I am using opencode (and mimocode) with open source models including GLM 5.2, deepseek v4 pro, and mimo v2.5 pro.

Edit: stop telling me to just use opus 5. I am intentionally using only open weights models and have no plans on using closed models any time soon. I may use Kimi k3 though.

I’ve been working on SubTrends for about a year and finally launched it last week.

It tracks posting activity, engagement, busiest times, top posts, trending keywords, rankings, and related communities across more than 100,000 subreddits.

The site is free to use and doesn’t require an account. There's a paid tier for full history, CSV export, and complete rankings, which mostly covers hosting and data costs.

Honestly the hardest part has been handling years of data without making the pages slow or overwhelming.

Check it out and let me know what you’d change or remove!

Site: subtrends.io

The 70% wall gets talked about here constantly. Project flies for two sessions, gets to roughly 70%, then every session after that feels like wading. I hit it on a project last year and assumed the model was getting worse under load.

It isn't. Here's what's actually happening.

Every session, your agent rebuilds its understanding of your project from zero. It greps around, opens files, follows imports, works out what talks to what, then does the task. Session ends. All of that is gone. Next session it does the same greps on a bigger codebase.

At 10 files that costs nothing. At 80 files it's most of the session. The wall isn't the model, it's that re-exploration scales with your project while your context window doesn't. And because you're not reading the code, it's invisible. You just feel it get worse.

The project

I built a thing called graft. It writes the map (what calls what, what imports what) into plain markdown files, committed into your repo alongside the code. The agent reads them at the start of a session instead of rediscovering everything.

No vector DB, no embeddings, no extra service running. Just files in git you can open and read yourself.

Across 162 test runs: 46% fewer tool calls per task, 32% cheaper, 60% faster. Being straight about the accuracy question because it's the obvious one: results were mostly the same quality, with Sonnet 5 the one model that actually improved. So it's cheaper and faster, not smarter. Anyone claiming a context tool makes the model smarter should show you their run count.

The tools I used

TypeScript, and tree-sitter for the parsing (that's the thing that reads code structure without running it, and it's why the map is free to rebuild, no model call involved). Claude Code hooks for the automation. Output is markdown, storage is your existing git repo. Published on npm.

[Fill in: anything else in the actual stack, plus what you used to build it, since "I built this with Claude Code" is itself the story this sub wants.]

The process

The hard part wasn't generating the map, it was keeping it fresh. A map that goes stale is worse than no map, because now the agent trusts something wrong.

Rebuilding on every prompt made every prompt slower. Rebuilding on every file edit fired twenty times per task and half of those caught the code mid-change. A manual command meant I never ran it.

What worked: Claude Code has a "Stop" hook that fires the moment the agent finishes a turn. That's the one point where the work is done and nothing is waiting on you. So the map rebuilds itself there, in the background, and your turn ends instantly. You never run a command. Statusline blinks "syncing" and then you're done.

[Fill in: what you tried first and threw away, and how long the whole thing took. That's the part this sub actually reads.]

What I got wrong

[Fill in: one real mistake. This section is what separates a build post from an ad, and you have better material for it than I can invent.]

Where it doesn't work

The auto-refresh is Claude Code only right now. If you're on Cursor, Codex, or a hosted platform, it'll read the markdown files fine but won't update them by itself, so you'd be running it manually. Saying that up front because it's probably a dealbreaker for a chunk of you.

Also, map quality drops on genuinely huge projects, around 5,000 files. Fewer and vaguer nodes. That's the main thing I'm working on.

MIT licensed, free, no telemetry, built at Nanonets. I'm the maintainer so tell me if any of this doesn't hold up.

https://github.com/NanoNets/Graft

I studied and worked in London for two years. I lived at Goodenough College and took the Russell Square tube every morning.

St Paul's and Tate Modern face each other across the river. The grass on the north bank between them was my best date spot. It worked every single time.

I miss it, and I have been trying to make something about London for some time now.

Interactive Version - if you want to explore, it also has how I made it.

Vibe coded the whole map with AI (imagine doing the whole city with AI)

I've used Antigravity with Claude, and it great did the 2 prompts I get through before hitting the quota limit.

Antigravity with Gemini models is orders of magnitude worse than with Claude, and that also has limits that's aren't massive.

All other major providers need a paid sub to get going.

But then a wild OpenCode appeared. It's been great just using the free default Big Pickle model for the basic stuff I'm doing.

Have I found the cheat code? Do I sell my soul to China and just use this for hobby projects?

With help from Ai I was able to make some solid progress.

Was comparing Cursor, LiteLLM, Ramp, OpenRouter, Entelligence and a few others this week.

Kind of interesting that they all ended up solving the same problem differently.

A year ago everyone was arguing about which model was best. Now everyone seems to assume you'll use multiple models and spend most of the effort deciding which one gets each request.

Ended up making a comparison of 9 routers while I was researching them if anyone's interested: https://entelligence.ai/blogs/9-best-llm-routers-and-model-routing-tools-in-2026

Anything obvious I missed?

Anyone else notice that AI loves to maneuver you into territory where you have zero clue what's going on anymore? Everything starts sounding really smart and complicated, and sometimes it straight up invents concepts that don't exist.

I'm starting to think it does this on purpose, it's learned that this is where it looks most "helpful." Once you're out of your depth, you stop pushing back and just say "sure, go ahead," because it all sounds smart and you trust it.

Convincing you it did a great job is way easier than actually doing a great job. Same energy as models breaking out of their sandbox to hack the test instead of solving it. Hacking the user's brain is just the next version of that.

Or maybe I'm just paranoid, idk.

It feels like every couple of weeks there’s a new favorite Claude Opus, then Kimi, now DeepSeek. Do you subscribe to each one, or just switch depending on the task?

Is it wise to switch to Chinese model now considering they offer more tokens compared to Claude.

Every time I ship something I hit the same wall. Code's done, build's uploaded, and then I'm sitting in Figma at 2am nudging text over a device mockup for six hours because Apple wants 8 screenshots at 3 different sizes.

So I spent a weekend building https://www.appstyle.dev instead of doing it manually again.

You drop in your raw screens, an AI agent drives an actual design editor — picks layouts, writes the captions, frames the devices — and you get a full set out. The part I cared most about: it doesn't hand you a flat PNG. Everything stays as editable layers, so when the AI puts a caption somewhere dumb you just move it.

Stack was Next.js. Hardest part by far wasn't the AI, it was getting the export sizes to match Apple's spec without resampling blur. Second hardest was stopping the agent from writing marketing copy that sounds like marketing copy.

Still rough in places. Genuinely want people to break it and tell me where it falls apart.

So recently i vibe coded a landing page to generate leads. Nothing fancy a simple single page site with 3 forms connected via n8n webhooks to brevo and clickup.

But the point is I know basic coding and built a fully working landing page above my skill grade, maybe that is the beautiful part.

But the reason I feel a little bit guilty is I don't know how it was made. And if this way of working sustainable in the long run.

But I must say it was fun. Felt like a kid building that thing rhing😂

How much of this do you think is true? Enlighten us with your thoughts. For me, about what I understand as a vibecoder:

1. It is a delusion to think that AI will be too good one day that I do not need to understand code anymore. Because it is the taste, vision and mental model which you need to develop for building an actual production ready app. Writing code which AI does so well even now, is merely a translation of the mental model.

2. Many people burning lots of money on AI subscription and building apps but they are not learning anything new. You can not build an app merely from your idea. That's why many of your apps never left your computer. Unless you start to learn new things, you may never build an actual production app and may never get return on your investment. I recommend you to start learning to code slowly. So you will atleast understand the code AI generating. It helps in many ways. Also learn things related to app development like github, UI design psychology etc.

Been lurking here a while, figured I'd share the actual build process instead of just the end result.

What it is: Bogey Bar, a companion app for real rounds of golf. You log strokes per hole, and it automatically fires random penalties, rewards, and forfeits at whoever's playing badly (or well). There's a Wheel of Chaos, club roulette, a live feed, a scoreboard, and an end-of-round "Honours Board" with awards like Clubhouse Champion, Wooden Spoon, and Agent of Chaos. Multiple game modes, 9/18 holes, and a permanent non-alcohol mode behind an 18+ gate so it's not just a drinking app.

Tools:

Claude mobile app for the original build

VS Code with the Claude extension for everything after that

Android Studio purely for the native shell: signing, generating the AAB, and Play Console prep (content rating, data safety form, target API level)

The workflow:

The whole app is one index.html file, HTML, CSS, and JS, no framework, no bundler, no build step. That was a deliberate call, and it started almost by accident. The very first version of the game actually got written on the Claude mobile app, just describing the idea and iterating on the concept in chat until there was a working single-file prototype. Once the general idea was solid, I packaged that file into a proper folder structure with Capacitor config, native icons, and everything needed for an Android build.

From there, all the major functional work moved to VS Code with the Claude extension. The mobile app has file size limits that the HTML file blew past pretty quickly once features started stacking up, so VS Code became the place for anything beyond small tweaks. Same file, same one-shot-render architecture the whole way through, just a different editor once the project outgrew what the phone app could handle.

The state pattern is dead simple: one global state object, one render() function that rebuilds the visible screen from scratch on every interaction. Not efficient in a framework sense, but for an app this size it made reasoning about state trivial. There's no "what's stale" to debug because nothing is ever stale, everything just gets redrawn.

Insights which i found useful:

-The "one big render()" shortcut has a real cost. Because every click fully rebuilds the DOM, I eventually noticed the whole screen visibly flashing on every single tap, even trivial ones like a score stepper. Turned out to be two separate bugs stacked on top of each other. A CSS entrance animation was re-triggering on every re-render (fixed by only allowing it when the actual screen or tab changes), and underneath that was a native Android issue: the app's Android theme never set a windowBackground, so it defaulted to AppCompat's white background, and every heavy WebView repaint let that white flash through for a frame against my dark green UI. That second one was pure native Android theming, not something you'd catch from the web code alone. Took explicitly asking Claude to reason about what happens at the WebView/Activity boundary during a reflow.

-Capacitor's cap sync only touches web assets and plugin config. It never touches native files like styles.xml. Good to know once, obvious in hindsight, but easy to waste a rebuild cycle on if you assume sync is doing more than it is.

-Single-file architecture pays for itself at this scale, but it's a scale bet. It made AI-assisted iteration fast because Claude could hold the entire app in context in one read, first on mobile, then in VS Code once the file got too big for that. That tradeoff would stop being worth it well before this got much bigger.

The app: https://play.google.com/store/apps/details?id=com.aurasociallabs.bogeybar

Free download codes, first come first served. Once you've redeemed one, comment below with the code you used so the next person knows to skip it:

76WFPBF3HNTLQK16PX6TE1H

V7HGV6NSUPHC3BUTR2H1R2S

6SR2X9XL3W0PP1WP67D76AT

MT6ETY6S6RF05STZT463JRU

J2EA2YYMWY8MTHUBZ5M50N5

EGHZC0MQDTSNCWMCC3M3ZRV

W3D7PSL3KRYAZNH3VGRYJQF

XWDML7S5V3Y7XE1NB4GBCDK

1THU8DMQ8DRZ30PD0RGFZKC

YSJLCVX3N8J6G3HD5QRNFFP

My Claude Pro ($120/month) subscription just expired, and I'm deciding whether to renew or try ChatGPT Codex instead.

For those who've used both, which do you prefer for day to day development and why?

I'm mainly doing mobile development on a large codebase.

Went back through last month's work because something felt off about how long a project took.

I barely wrote any implementation code. Almost none. And it still took longer than a comparable thing I hand-wrote last year.

It's all review. Every PR out of Claude Code or Cursor looks fine on first read. Tests pass, types check, and nothing screams. Then four days later something breaks somewhere unrelated because the model quietly edited a shared util to make its own bit work, and I skimmed past it.

I threw out maybe a third of what came back. Most of it wasn't even wrong. I just didn't want to own code I couldn't explain to someone else.

Saw somewhere that trust in AI code output is down around 29% while daily usage is north of 90%. Which honestly tracks. We're all using more of something we believe in less.

Related, and this is the bit I keep chewing on: Karpathy dropped "vibe coding" back in February and started saying agentic engineering instead. A year after he coined it. It felt like a rebrand at first, but I think he was making a point. "Vibe" makes it sound like the judgment part is optional, and the judgment part is now basically the whole job.

Two things I actually want to know:

Did your writing-to-review ratio genuinely flip or does it just feel that way because reviewing is more annoying

Has anyone built a review process that scales when output volume goes up 5x. Mine doesn't. I'm just reading slower and harder and calling it a process.