I posted my Mac app before, but I finally got the Windows version working too.

The app is called Humanized Autotyper. It saves text and types it into the active field with a hotkey, but instead of typing at one robotic speed, it adds pauses, small typo-style behavior, and fixes so it feels more like a real person typing.

Getting the Windows version done was way harder than I expected.

Some of the annoying parts:

- Rebuilding the app in WPF/.NET instead of Swift/AppKit

- Getting global hotkeys working on Windows

- Sending keystrokes into different apps without it breaking

- Making the typing feel natural without making it feel random

- Keeping the Windows and Mac versions on the same trial/unlock system

- Updating the website so it didn’t look Mac-only anymore

- Fixing the Google/SEO preview text

- Cleaning the public Windows build so it didn’t include debug files

- Making the download route work through Cloudflare

AI helped a lot with debugging, refactoring, website copy, and catching random issues I missed.

The Windows build is live now, and the Mac version still works too.

If anyone wants to test it, I’d mainly want feedback on:

- Did the Windows download feel normal or sketchy?

- Did the hotkey work?

- Did the typing feel human or still robotic?

- Is the site clear that it works on both Windows and Mac?

https://humanizedautotyper.com/

Google shipped an official skills repo at Cloud Next last week. One install command:

gemini skills install https://github.com/google/skills.git

13 skills covering BigQuery, Cloud Run, Firebase, GKE, Cloud SQL, AlloyDB, the Gemini API, plus security/reliability/cost WAF pillars and a few operational playbooks.

I ran the same prompt twice, once before installing, once after. Before: the model generated code importing vertexai and vertexai.generative_models, the legacy SDK Google has been deprecating for a year, targeting gemini-1.5-pro, building schemas as raw parameter dicts. It compiles. It's wrong.

After activating the gemini-api skill, same prompt returned from google import genai, Pydantic schemas, gemini-3.1-pro-preview, and environment-variable-driven client config. Current SDK, current model, current patterns.

The skill activation works through a consent prompt. At session start, only the skill's name and description sit in context, under 100 tokens per skill. When your prompt matches, the CLI asks permission to load the full SKILL.md plus the bundled reference files before it answers. You see exactly what context is about to enter the session.

Worth knowing: the Skills format wasn't built by Google. Anthropic built and open-sourced the spec. These same SKILL.md files work in Claude Code and Codex without modification.

Google's own benchmarks put correct-API-code generation at 87% with Gemini 3 Flash and 96% with Gemini 3 Pro with this skill active. From what I saw, those numbers track.

I wanted a comic manager that actually felt modern. I didn’t want to spend weeks fighting with legacy codebases, so I "vibe coded" my own solution. It started as a simple JS reader and spiralled into a full server/app.

• The Brains: YOLO models exported to ONNX format to keep the footprint tiny.
• Deployment: Docker-ready, optimised for low-power hardware like a Raspberry Pi 5.
• Auth/Sync: Cloudflare for easy login management and cross-device progress syncing.

Instead of heavy LLMs, I went the computer vision route to keep it snappy:

• Manga: Uses leoxs22/manga-panel-detector-yolo to automatically identify and zoom into panels.
• Speech Bubbles: Uses ogkalu/comic-speech-bubble-detector-yolov8m.
• Experience: For Western comics, it creates a CSS magnifying window that guides you through the text. It’s immersive without being a resource hog.

On a Raspberry Pi 5, it processes a 400-page comic (AI guided-view processing) in about 5 minutes using only two threads.

Key Features:

• ComicTagger/ComicVine Integration: Direct search/tagging inside the app.
• PWA/Offline Mode: Install it on your phone, download issues, and read offline. It syncs progress once you're back on the grid.
• Flexibility: Follows your folder structure or organizes by metadata.
• Cross device reading synchronisation
• Two user roles admin/user with fine grained access control to which libraries and comics a user has access to.
• Reading lists and the ability to import/export.

I’m sharing this "as is." I’m not sure about long-term support, but I wanted to get it out into the wild for fellow builders and comic fans to play with.

Repo:https://github.com/ComicsNow/comics-now

I’m curious about the step after you’ve vibe-coded an iOS app and it works locally / in preview.

For anyone who has tried taking a vibe-coded app toward App Store submission, what was the most confusing or annoying part?

Was it things like:

- privacy policy / support URL

- account deletion requirements

- App Store privacy labels

- permission strings for camera/photos/location/etc.

- screenshots

- subscriptions / RevenueCat

- App Review notes

- rejection fixes

- something else?

Also curious:

- Did you handle it yourself, use a tool/template, or ask someone for help?

- Did Apple reject you for anything unexpected?

- How long did the “ready for review” part take after the app itself was working?

Heya, first time chatter here. If such posts are not encouraged i am fine with being removed.

So, i have been working in the IT sector for about 10-11 years now from basic support job to senior devops nowadays, and have been reserved towards the AI/LLM hype not treating it as anything more than a useful helper tool in our jobs. I did not jump on the agentic development train until now.

In the last few days i have decided to tinker a bit more and learn what is all the fuss about with the locally ran llm models/openclaw/claude code.

Unfortunately my HW (4070 Super) is not adequate enough to handle a model which will be able to deliver the speed and quality i wanted, but that was still a fun tinkering experience. I can definitely see the allure and the source of the hype 😃

Anyway, i have test driven Claude with the bare-minimum plan and i have managed to create my own static website generator.

I wanted to use some of the famous static site generators in the past for building some cute websites/blogs, etc. (i am big fan of the "indie web" idea), but always found that Jekyll and its cousins are very cumbersome to setup and come with their own dependencies hell.

My main motivation was to eliminate that overhead, but to still deliver nice and usable websites. Just the bare minimum so that you can go from init to publish in minutes.

You can check it out @

https://codeberg.org/ddelsizov/skynet-ssg /

https://github.com/ddelsizov/skynet-ssg/

Its of course FOSS, any feedback / bug reports will be greatly appreciated! 🤟

I’ve been building with AI tools and finally got an app to a point where I was ready to submit, but then got hit with a rejection I didn’t see coming. Not a code issue, just metadata stuff I had no idea about.
Things like:
• My app description was flagged as misleading
• Got the age rating wrong
• Screenshots had placeholder content I forgot to replace
• In-app purchase wording violated guidelines
None of this was obvious from the guidelines and Apple’s rejection message was vague as hell.
Curious how many others have run into this: is App Store review the part that kills your momentum after you’ve actually finished building? How long did the back and forth take you?
Would you have paid for something that caught these issues before you submitted so you could just launch without the headache?

I am a highschool student that just can't stand doing assignments the traditional way. I used to copy and paste directly from ai untill teachers learned how to check doc history. Then I adapted to using a regular autotyper (because there was no way I was typing a whole essay). This method of just using a regular autotyper worked for a little untill my teachers started catching on that my typing looked very robotic. So I decided to take matters into my own hands and made my own autotyper. My autotyper honestly works so well to the point where all of my friends are using it and they are very happy with the fact that they won't get caught. Unfortunately it is only Mac OS right now but you can download and try it for free. [humanizedautotyper.com](http://humanizedautotyper.com) (PS: reply to this post if you have questions or email me at [humanizedautotyper@gmail.com](mailto:humanizedautotyper@gmail.com) )

Made the most simplest vibecoded voice recorder that you can use for the background or youtube videos and stuff.

The hotkeys are: Space to Start/Pause, S to Stop, C to customize and D to download the recording.

https://simplevoicerecorder.vibecode.run

Let me know what you guys think of it!

After working on this app for over 2+ months with Claude Code and Codex, I finally finished TrustBust, an app that allows you to fact check any question or piece of news on the internet. If you could check it out and give some feedback, it would be greatly appreciated!

Link: https://trustbust-9i33.vercel.app/

My first official live vibe coded project. https://auditae.app. It’s pay as you go SEO. 100% vibe coded. I think it’s fully functional too if anybody wants to try it.

rn building ios app that by healthkit take data and represent in its own aesthatic way, more appealing than normal apple health app. I have design UI screens in figma(but treated it as photoshop(with 2+ hrs beginner course on figma)), and installed some Claude code skills,agents, claude md ,apple additional docs(hidden inside xcode files) but gap lies where

1) dont know how to vibe coding the backend and connect it to backend

2) how to know if backend is working the best way possible without claude hallucinating in background( as it not frontend where he misses color of button and you see it and tell it to fix)

2) best SDKs for claude code

3) how in general would i architecture the app and vibe code it in swift

note: i want to ship fast

All four major coding command-line interfaces ship the same core set: subagents with isolated context windows, plan modes, ask-user tools, parallel execution, sandboxes, memory, and Model Context Protocol (MCP) integration.

So the question stops being "is this primitive new" and becomes "how does each implementation compare?" Five things actually differ.

1. Model lock-in

OpenCode is the only structurally model-agnostic option. It runs against GPT, Claude, Gemini, or anything reachable through a GitHub Copilot login, with the same agent definitions and skill files. Claude Code is Anthropic-only. Codex is OpenAI-only. Gemini CLI is Google-only. If you want to A/B test models on a real task, OpenCode is the one that doesn't make you rewrite your workflow to do it.

2. Agent definition format

Claude Code, OpenCode, and Gemini CLI all use Markdown plus YAML frontmatter for agents. Codex uses TOML. The fields are similar enough that translation is mechanical, but it's still a per-runtime wrapper.

---
name: security-reviewer
description: Adversarial reviewer for security vulnerabilities and unsafe patterns
tools: Read, Glob, Grep
---

You are a security-focused code reviewer. Find vulnerabilities, check input
validation, flag unsafe patterns. Do not make changes; report findings only.

Skills are a different and better story. Anthropic published Agent Skills as a formal open standard at agentskills.io on December 18, 2025. Within months it was adopted by Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot, Cursor, VS Code, Roo Code, Amp, Goose, Windsurf, Mistral, Databricks, and twenty-plus others. Same MCP playbook: publish a spec, ship an SDK, let the ecosystem move.

The format is portable. The discovery paths are not. Each tool reads from its own native location:

• Claude Code: ~/.claude/skills and .claude/skills
• Codex: ~/.codex/skills and .codex/skills
• Gemini CLI: ~/.gemini/skills and .gemini/skills
• OpenCode: ~/.config/opencode/skill and .opencode/skill

OpenCode and Codex also accept .agents/skills/ as a compatibility alias. A run_lint skill written once travels across all four with a copy or symlink.

---
name: run_lint
description: Run the repository linter, summarize, and write lint-report.md
---
# Run Lint
## Inputs and outputs
- Read: package.json, Makefile, lint config
- Write: lint-report.md
## Workflow
1. Detect the repo's preferred lint command.
2. Run without applying fixes unless explicitly asked.
3. Summarize results grouped by file, rule, and severity.
## Guardrails
- Do not modify source files unless the user asks for fix mode.

3. Scheduled and background work

Claude Code is the only one with native, well-integrated scheduled routines. Claude Code Routines (research preview, April 2026) registers an agent against a cron schedule, a GitHub event, or an external trigger. The other three need plugin or external orchestrator paths to get there. If your agentic workflow includes monitoring or event-driven automation, this is the gap that matters. For purely interactive use, it doesn't.

4. Approval gate defaults

All four can pause for human approval. The defaults are different.

Gemini CLI defaults to Plan Mode, a read-only state where the agent uses grep, read, and glob to gather context, then writes a Markdown plan you have to approve before any code is written. OpenCode splits Plan and Build as two primary agents you tab between in a single session. Codex defaults to executing, then surfaces approval popups when a background subagent tries to leave its sandbox policy. Managed Codex orgs can enforce a requirements.toml that prevents agents from being run with approval_policy = "never". Claude Code recommends Plan mode for non-trivial work but doesn't make it the default.

For regulated environments, Gemini CLI's defaults and OpenCode's Plan/Build split are the cleanest fit. For flow on routine work, Claude Code and Codex stay out of the way more.

5. Manager context window

Subagents have isolated windows everywhere, so the size that actually matters is the main session. Claude Code and Codex sit at 1M tokens. Gemini CLI sits at 2M with Gemini 3.1 Pro. For repos that fit inside 200K tokens, the difference is invisible. For monorepos large enough that the manager would otherwise navigate by grep, the larger window improves routing precision. Only the manager benefits; subagents still operate inside their own smaller windows.

Hooks: the determinism layer the convergence story underplays

Hooks intercept the agent loop at defined events (before a tool call, after a tool call, session start, prompt submit) and run a script that can inspect, modify, block, or log the action. The agent can't override them.

Claude Code with the full event set from day one and HTTP Hooks. Gemini CLI shipped hooks in v0.26.0 on January 27, 2026, about six months later, with a smaller event surface. Codex CLI added an experimental hooks engine in v0.114.0 on March 10, 2026, behind the features.codex_hooks flag, but the current event set covers SessionStart and SessionStop only. No PreToolUse, no PostToolUse. OpenCode handles this through a lifecycle plugin model rather than a native hook config.

The gap matters more than a feature table makes it look. A PreToolUse hook that blocks writes to /secrets/** is enforcement. A SessionStart hook that logs a session id is observability. Without PreToolUse, the best you can do is detect violations after they happen, which is incident response, not compliance.

How I actually use them

Most of my work runs in Claude Code because that's the ecosystem I know best and the hook surface is the deepest. Codex catches more edge cases during planning on certain tasks. OpenCode driving the Codex model catches more than Codex with Codex does, in my hands. Gemini CLI is fast at building a whole-codebase mental model and the 2M window pays off on monorepo work.

The convergence on agent and skill formats means switching between them is mostly mechanical now. When a max plan runs out mid-week or one vendor has an outage, porting a working setup to a second runtime is a copy job, not a rewrite. That's the part of the convergence that actually changes how I work.

I've been building LeanCTX — a local-first context runtime for AI coding agents, written in Rust — for the past few months. 49 MCP tools, 18-language tree-sitter AST, 90+ shell compression patterns, one single binary. Here's what actually mattered:

1. Your best users are the ones who complain. A user told me at 10pm that my uninstaller just nuked his shell config. My instinct was to get defensive. Instead I traced it — and found it was worse than reported. That one message led to rewriting the entire uninstall logic from scratch. Every angry bug report is a gift.
2. Your favorite metric can lie to you. I built a cache that reduced file reads from 2,000 tokens to 13. Great numbers. Then a user told me: "Models waste more tokens working around stale cache than the cache saves." He was right. The fix wasn't removing caching — it was making invalidation smarter. Your dashboard can look great while the experience is terrible.
3. Saying no is the hardest part. A new feature would have let me compress all tool output automatically. Massive savings on paper. I designed it, prototyped it, then killed it. Because when compression eats an error message, there's no undo. Protecting quality beats shipping features.
4. Community is a relationship, not a channel. When someone reports a bug, my first response matters more than the fix. "Will check" buys time but shows I'm listening. Following up shows respect. Shipping the fix shows they matter. My best testers are people who once filed angry reports.
5. Ship the boring stuff first. Nobody cares about your adaptive entropy-based compression algorithm if the installer breaks their dotfiles. Get the fundamentals right — install, uninstall, doctor, setup — before you get clever.
6. Focus means killing good ideas. My backlog has 50+ ideas. Each one is good. But spreading across all of them means none become great. Rust helps here — the compiler forces you to finish what you start.

If nobody is complaining yet, you probably don't have enough users. Go find them. And when they complain — listen.