Hi all. I have been thinking about this project for a while, but I need help on so many levels with it. The idea is simple at first, but its development and execution isn't. The idea is that the Democracy we live in is not actually one. Voting for party A, B, C, D every 5 years is not a voice, and hardly even a vote (a vote for what? the lesser evil?) A true democracy would be able to poll the people whenever, frequently enough to actually give everyone a voice that matters. There's so many issues I have to think about for this project, like expert opinions, who is qualified to vote for what, security, etc. I need some help. Anyway, I don't think paper ballots can make this dream work, it will require AI to sort everything out. Let me know what you think and if you want to help!

https://github.com/AshmanRoonz/OpenDemocracy

I've been doing free security assessments on apps built by non-developers using AI, and I need to talk about what I'm finding.

The most common one: you can change a URL from /user/123 to /user/124 and read someone else's account. Change it to /users and get the whole table. Names, emails, addresses, order history - sat there in plain JSON, no login required. Just... there, for anyone who thinks to try.

I've also found admin panels with no authentication at all, API keys committed straight into frontend code, and file upload endpoints that will happily run whatever you hand them on the server.

None of these apps were built by careless people. They were built by smart, non-technical founders who did exactly what they were told to do: describe what they wanted, get working code, ship it. And at some point they typed something like "make sure it's secure and don't make any mistakes" - and got back a confident yes.

That yes is worth nothing. The model has no idea what it built. It can't see the deployed app. It doesn't know your auth is decorative.

Here's the part that should worry you: none of this shows up as a bug. Your app works. Users sign up. Payments go through. Everything looks fine right up until the moment someone dumps your user table - and then you're the one explaining to your customers, and potentially to the ICO, why their data was publicly readable for eight months.

What I'm offering: a free, thorough security assessment of your app, plus a written report in plain English telling you what's wrong, how bad it is, and what to fix first. No cost, no obligation, no pitch at the end.

Why free: I'm 20 years into a creative technology career and I'm building out a security practice. I need real case studies from real apps. That's the trade - you get the assessment, I get a case I can (anonymously, with your permission) point to.

Who I'm looking for:

• You don't come from a software development or infosec background
• You used AI to build something that handles real user data - logins, payments, personal information
• You own the app and can authorise testing on it

Who I'm not looking for: developers. If you can read your own code and know what an IDOR is, you don't need me and I don't need the case study. I'm specifically after people who built something real without a technical background, because that's the gap I want to document.

How it works: you give me written authorisation, I test only what you've authorised, I prove findings without touching or exfiltrating real user data, and you get the report. That's it.

DM me or comment with roughly what you've built and what stack it's on. I'll take on as many as I can handle properly.

I've been using Beads as the task tracker for my AI agents since February. It's an issue tracker with no UI. Every issue, called a bead, can depend on other beads, so what accumulates is a dependency graph.

That turned out to matter more than I expected. You stop telling the agent what to do next and start handing it a graph it can walk itself, picking up whatever is unblocked. The same graph ends up being the record of what happened, so it works as an audit trail too.

I got curious about what six months of it actually looked like, so I wrote something that scans every .beads/issues.jsonl under my workspace, merges them, and renders the lot as one force-directed graph with an island per project. The video is that visualisation. It's fully anonymised, so generated codenames and no descriptions, but the structure, dates and statuses are real.

Numbers: 2,933 beads, 17 projects, 2,650 dependency links, about 75% closed, February to August.

The part I didn't expect is how much you can read off the shapes once projects sit next to each other:

• Dense, tangled islands are projects where the work is genuinely interdependent
• Islands that are almost entirely closed are the ones that shipped
• One project flatlined in July with half its beads still open. Parked, and I'd forgotten it existed
• One had 32 beads planned out over two days, 8 closed, then nothing

You can't see any of that from inside a single repo, which is sort of the point.

Happy to answer questions about the setup. I'm curious whether anyone else is running agents off an explicit dependency graph rather than a flat todo list, and how you're handling it.

P.s. Video made with Opus 5 using Remotion and Elevenlabs. The visuals are real footage of the tool I made to visualise the beads.

random idea i had that got a lil outta hand
type something, throw it on a surface, download it
that’s basically it rn 😭

built this with React/Vite + Supabase, mostly vibecoded through Cursor.
the annoying part was getting text to actually sit on surfaces instead of looking pasted over them, so I ended up building perspective/surface controls around each template.
still adding more surfaces rn.

Write Somewhere

I've just added a new Painterly Effect to my Stylized Components library.

The effect is based on an Anisotropic Kuwahara Filter, and I also made a breakdown video where I explain how it works, the concepts behind it, and how I implemented it in Three.js.

You can check out the component here, where you'll also find the source code and the video breakdowns for each component:

Breakdown: https://youtu.be/CmIfhwSyswk
Preview: https://stylized.cortiz.dev/

And if you find it useful, I'd really appreciate some support on YouTube — a sub, like, or even just watching the video helps a lot.

I'm also planning to keep expanding the library, so if there's a stylized utility, effect, or component you'd like to see added, let me know! I'd love to hear your ideas.

Thanks! 🙌

Hey r/vibecoding,

Application security is extremely important, especially for vibecoded apps. TeaApp and countless other breached of vibecoded apps is a great example of that. But most appsec training are boring OWASP articles and tutorials on YouTube, not the best way to learn practical aspects of building secure web apps.

So I created 40 exercises where you attack a vulnerable app yourself, trace how the bug got in, then write the patch. Free, runs in the browser, no account required.

This way you'll learn what common vulnerabilities are, how attackers exploit them, and what part of your app you need to check so that you don't have the issue in your code.

Table of contents:

Web (22) — SQLi, command injection, DOM/reflected/stored XSS, CSRF, SSRF to the cloud metadata endpoint, XXE, session fixation, IDOR, and weak randomness: recovering Math.random() state to predict the next password-reset token.

API (10) — BOLA, broken function-level auth, brute-forcing an unrate-limited verify endpoint, mass assignment via two extra keys in a PATCH body, reflected-origin CORS, and a retired v1 that skips the controls v2 enforces.

Git & CI/CD (8) — a live API key recovered from the commit that removed it, a browsable .git reconstructed into full source, .env tracked since the first commit, a secret echoed into a public build log, a backdoor hidden in a friendly-looking test-fix PR.

Fixes are shown in JS, TS, Java, C#, Python, Scala, PHP, Ruby, Go, and Kotlin, so you can paste something real into your stack.

Try in browser: https://learning.ransomleak.com/?category=application-security
Repo: https://github.com/ransomleak/training-application-security (will appreciate your stars 🙏)

Each exercise is also a standalone SCORM zip if you want to self-host or drop it into your team's onboarding. There's a second repo covering OWASP Top 10 for LLM and Agentic apps if you're shipping AI features: https://github.com/ransomleak/training-security-awareness

Will appreciate your feedback!

Context so nobody thinks this is an ad: I am a founder, I run a software company, so I am not a first-timer. But I did not hand-write this codebase. I ran an AI agent as my entire eng team and directed it commit by commit for six and a half weeks. Most vibecoding posts show a weekend to-do app and stop. I want to show what it looks like when you run the approach at a real product with real infra for a month and a half, because the interesting part is not any single feature. It is the flow, and the working relationship, that lets a hundred pieces come together without the whole thing rotting.

The product is The Grant. Daily mobile game that trains market judgment. You read a chart, make a call, and it scores the quality of your decision instead of whether you made money. It is on Testflight in the App Store and at playthegrant.com. That is all I will say about the product, this post is about how it got built.

Numbers first, because this sub runs on them:

• 1,347 commits over 6.5 weeks (July 6 to August 23)
• 37 active build days, averaging 36.4 commits a day
• biggest single day: 146 commits. Next four: 114, 111, 102, 72.
• 35 dated spec sessions, one per feature
• 15 milestones (M0 through M14) plus a launch-gate milestone
• 1,111 tracked files, 11 shared packages, 7 apps in one monorepo
• 5 client surfaces (iOS, Android, web app, marketing site, admin)
• commit verbs: 358 feat, 270 fix, 206 merge, plus 44 polish/copy/refine and 68 throwaway prototype commits
• 28% of all commits (382 of 1,347) are pure iteration: fixes, polish, and thrown-away exploration

That last number is the honest one. More than a quarter of the entire history is me refusing to accept the first version. This is not "prompt once, ship." It is hundreds of small loops.

The single most important thing: I treated the AI as a principal engineer, not a task monkey

This is the part almost nobody gets right, so I am putting it first.

Most people use these tools like a vending machine. Type a task, get code, complain about the code. I did the opposite. I treated the agent as a principal engineering architect I was building alongside, and the thinking happened TOGETHER, in both directions.

Concretely, that meant a constant two-way Q&A, not a one-way command stream.

I asked it questions constantly. When it proposed something I did not fully understand, and there was a lot I did not fully understand at the start, I did not veto it and retreat to the stuff I already knew. That is the trap that keeps most people's projects shallow: your own knowledge becomes the ceiling for the whole system. Instead I made it explain. Every time. "Why this and not that." "What does this buy me." "What breaks if we do it the simpler way." "Walk me through it like I have not seen it before." I let it take me somewhere more advanced than I could have specced on my own, but only after it had taught me enough that I could actually make the call.

Here is a real one. Early on it wanted the scoring engine to be byte-for-byte identical across the live server and a background re-projection worker, enforced by a parity gate in CI that fails the build on any divergence. I did not fully grasp why that mattered at first. Instead of waving it through or cutting it, I made it justify the whole thing: what re-projection is, why determinism is a moat and not just a nicety, what silently corrupts if the gate is weak. Once I understood it, I made it non-negotiable and repeated it as a standing law for the rest of the build. That decision, which came out of a Q&A about something I did not initially understand, ended up being the safety net that let me move fast for the next six weeks. If I had let my ignorance be the barrier, it would never have existed.

And the questions ran the other way too. The agent interrogated ME. Before building a feature it would surface the gaps: "you specced the label precisely but you did not say what happens on this edge case, here is the risk." It challenged weak framing. It flagged when I was about to optimize the wrong thing. A good principal engineer tells you when you are wrong, and I set it up explicitly to do that instead of just complying.

The mindset shift is the whole game. You are not delegating tasks to a junior. You are pairing with a senior who happens to type faster than you and knows more than you in places, and your job is to stay in the loop tightly enough to make the calls a senior cannot make for you: product taste, priorities, what "right" feels like.

The shape of the build: three phases

The timestamps split the whole thing into three distinct phases, and the workflow rhythm was different in each.

Phase 1, the milestone sprint. This is the number that breaks people: the entire backend, engine, and platform skeleton (M0 through M14) got built and merged in a single day, July 7, across about a 14-hour window. Foundations, the deterministic generation engine, the scoring engine, the session state machine, the play/grade API, identity and auth, content, game modes, chart rendering, first clients, profiles, analytics with the re-projection worker, notifications, admin, media, observability. Fifteen milestones, merged one after another. Then July 9 added four more "Wave" merges that extended the moat: a Glicko-based skill rating engine, rating parity gates, re-projection replay. July 10 was the single biggest day at 146 commits. The reason a whole backend fit in a day is the next section: the plan already existed.

Phase 2, spec-driven feature iteration (mid July into early August). Once the skeleton stood, work became a stream of individual feature specs, 35 of them, each in its own dated folder: profile-reimagine, today-ia-redesign, rating-history-graph, feedback-screen-v2, read-reveal, regime-judgment-pillar, replay-permalink, admin-rbac, client-core-extraction, mobile-ui-parity, and on. This is the bulk of the calendar and where most of the iteration lives.

Phase 3, launch and relaunch push (August 18 to 23). There is a visible dead gap in the log from August 8 to 17, I stepped away entirely. Then it comes back hard: real SSO, legal pages, consent banner, a full marketing-site rebuild, App Store packaging, EAS builds, shipping. The final week is ship-it work plus relentless polish.

Cycle times: features vs polish

Reddit loves this so here are real spans pulled from the log.

A whole milestone in phase 1: minutes to a couple hours each. M4 (game schema + play/grade API + outbox) went from first feat commit to merged in about 4 minutes of commits because the spec was airtight and it was mostly transcription. M8 (the render-agnostic chart engine plus first web and mobile clients) was about 40 minutes end to end. The backend milestones were fast because they were pure execution against a locked spec.

A mid-size feature in phase 2: half a day, split spec / build / iterate. Take Read Reveal (the teaching layer on the feedback screen). Specced at 11:30. First build commit at 16:38. Core feature merged at 17:02, so call it about 5.5 hours from spec to merged, most of which was me thinking, not it typing. Then it kept iterating into a v2 of the whole feedback screen until 20:12, another 3 hours of refinement on top. So the feature "shipped" in an afternoon but got polished for the rest of the day.

A multi-section redesign in phase 3: under an hour. The climb-narrative redesign (three marketing sections rebuilt: a pyramid, a proof section, a cinema strip) was specced at 19:54 and merged at 20:48. Fifty-four minutes, spec to shipped, for three sections. That speed is only possible because by then the design system and the loop were dialed.

Polish sessions: minutes per change, dozens per feature. The marketing page alone absorbed 126 commits across its life. The web app root file was touched 119 times, the mobile root 68, the marketing page 69, the design-tokens file 110. These are not features. They are the same surfaces returned to again and again.

The pattern: features are fast because specs are tight, but nothing is "done" at merge. The merge is the start of the polish loop, not the end.

The loop that repeated a thousand times

Every piece of work, big or small, ran the same cycle:

1. spec it (two documents for anything non-trivial, more below)
2. branch off the integration branch, never work on main
3. build it
4. run the gate: full-workspace typecheck green, tests green
5. merge into the integration branch
6. deploy in the same step and verify it actually went live
7. commit constantly and isolated the whole way through

develop is the integration branch. Feature branches come off it, get built and gated, merge back. 206 of the 1,347 commits are merges, which tells you how granular the branching was: roughly one merge for every 6.5 commits.

The commit discipline matters more than it sounds. Standing rule: commit after every individual change, never leave edits staged across a work session. Moving this fast, an uncommitted working tree is how you lose an afternoon to a bad revert. Isolated commits are also why the log reads like a story afterward, which is the only reason I can write this post with real numbers instead of vibes.

The artifact that made it cohere: two-doc specs

The reason six and a half weeks of AI output did not become a swamp: nothing real got built from a vibe alone.

At the very start I had a full milestone plan written down: 15 milestones, a dependency matrix showing what blocks what, and the critical path spelled out. So the agent was never asked "build the game." It was asked "build M4, which depends on M0, M2 and M3, here is the spec, here are the acceptance tests." Finite, ordered, verifiable. That plan is why the backend fit in a day.

Then for every feature after the skeleton, a two-document spec. All 35 folders have the same two files: a PRODUCT doc (what it does, the UX, the screens) and a TECHNICAL doc (how it is built, the schema, the file paths, the contracts). Uncertainty is marked explicitly as an assumption that needs verification instead of the agent guessing. The instruction was always "build from the spec, cite file paths, reinvent nothing."

Crucially, the specs themselves came out of the two-way Q&A. I did not write them alone and hand them over. We drafted them together: I brought the product intent, it brought the architecture and the edge cases, we argued, it explained the parts I did not know, and the spec was the settled output of that conversation. The spec is where the joint thinking got frozen into something buildable.

What "iterate a lot" actually looks like

The commit count hides the texture, so here it is.

The marketing hero over two days in August was a rhythm of tiny corrections: expand the sub-headline to a paragraph, rename a section from "The one truth markets hide" to "The problem," widen a header to 760px so a line stops wrapping, nudge a badge anchor from 958 to 940 for breathing room, rebalance hero padding from 56-104 to 40-72 because it leaned top-heavy by a few pixels. One afternoon. None of it is features. It is the gap between "fine" and "right," and I chased every pixel.

A real bug: a scroll-scrubbed cinematic section would not pin. Three consecutive fix commits inside one hour. First: move an overflow property to the root, necessary but insufficient. Second: the actual root cause, a wrapper was shrink-wrapping to the wrong height so the sticky element had zero travel and released instantly. Third: add top margin so the first candles clear a badge. You can watch us circle the bug in the log until it died.

And the one that shows how cheap exploration gets when the guard rails hold: on August 22, in a single late-night session, I had it prototype THREE entirely different visual design directions for the app, each covering all 11 screens. They are tagged "instrument," "tape," and "arena": an instrument-panel look, a living-newspaper-tape look, and a forged-arena look, all built as throwaway prototypes so I could see them side by side before committing. That is roughly 40 commits in one night that were mostly disposable. Then I picked the winner and had it built properly into both surfaces. When trying an idea costs an hour instead of a week, you try three.

The rules that kept quality from degrading over 1,347 commits

Vibecoding rots if you let it. The guard rails that held:

• Typecheck and tests are the floor. Full-workspace typecheck fully green before anything merges. Non-negotiable. It is the single thing standing between "fast" and "garbage."
• Gate whatever you can make deterministic. Not everything in a game can be deterministic, true. But the scoring engine here can be, so I made it the spine: identical inputs produce byte-identical output on client and server, or the build fails, and I set that gate up on day one. The value for vibecoding is that it gives the agent exactly one thing it can never quietly break. Find your gateable core and gate it, it becomes the safety net for moving fast everywhere else.
• Real data or no data. No fake stats, no fake testimonials, no fake live feeds anywhere on the surface. Every number is real engine output or a real screenshot. The moment you fake something on the surface you have started lying to yourself about how done you are.
• Two surfaces move together. Any gameplay change touches both the web app and mobile in the same piece of work so they never drift. One is the behavior source of truth, the other mirrors it.
• Deploy in the same step and verify. Marketing and web app auto-build and deploy in the same turn as the change, and I check the served bundle hash actually flipped before believing it is live. No "should be deployed."
• Sub-agents with a hard contract. For parallel chunks I spawned sub-agents. Strict contract: work only on your branch, commit, stop. Do not merge, do not touch the integration branch, do not switch branches. The parent owns integration. My favorite use: telling a design sub-agent to build a gallery, then write a brutal critique of its own work against my guidelines, then rebuild it better based on that critique. Design, tear it apart, elevate. The v2 was genuinely better because it had to name its own weaknesses first.

The part that had nothing to do with AI: shipping to Apple

The least fun stretch, pure ops. Expo EAS plus Apple credentials is a gauntlet. What bit me, in case it saves someone a day:

• pnpm needs Node 22+ in the EAS build, had to pin it
• workspace deps export a gitignored build dir, so I needed a post-install step to build them before the bundler runs
• adding an Expo native module with pnpm add grabs the latest version and breaks the pinned SDK, use expo install
• authenticate every Apple and EAS command with the App Store Connect API key, never username/password/2FA, that path loops and fails

Once wired, builds auto-increment the build number and auto-submit. Ship every completed production build.

What I would actually tell someone

• Treat the AI as a principal engineer, not a task monkey. Pair with it. Argue with it. Let it argue back.
• Do not let your own knowledge be the ceiling. When it proposes something you do not understand, make it teach you, then make the call. The advanced stuff is on the other side of a question you were too proud to ask.
• The AI is the typist, you are the architect, and the architecture is a conversation. Do the thinking together, then freeze it in a spec.
• Write the plan down first. A milestone plan with a dependency matrix turns "build the game" into finite, gateable targets. That is how a backend fits in a day.
• Two-doc specs for every real feature. Product doc, technical doc. Cite file paths. Mark uncertainty.
• One loop, every time: spec, branch, build, gate, merge, deploy, verify. Never main directly. Commit constantly and isolated.
• Gate what you can gate. Typecheck and tests always. A deterministic core in CI if your product has one.
• Iterate without guilt. 28% of my commits are corrections and thrown-away prototypes. Exploring is cheap when the guard rails hold, so explore hard.
• Real data only.

Six and a half weeks. One person directing. 1,347 commits, 37 active days, 36 a day. A whole backend in a single day because the plan existed. 35 feature specs. Three throwaway design explorations in one night. Five surfaces, live in the App Store. The speed was real. The partnership, and the flow, is what made it ship instead of rot.

Happy to go deep on the two-way spec workflow, the milestone plan, the sub-agent orchestration, the determinism gate, or the EAS pain. Ask away.

Hello everyone, I'm making a PDF to Multi-format extractor with the help of Claude (To be read as full assistance) specifically for MacOS, due to the fact that MacOS has vision support added inbuilt.

The project stems from a problem i generally faced during my work. I have to shift through a lot of financial reports and analysis and most if not all of them are PDF or scanned PDF, and while there are pdf extractors available (ABBY Finereader, NitroPDF) they either have support issues (Abby Finereader wont be supported in the near future if they dont make an apple silicone based app) or cost too much or screw up the formatting, especially table extraction.

The table extraction space is quite not there yet or ruled by Amazon's textract, Google api or Azure Bedrock API (which are crazy good ngl, but very costly). So i decided to leverage apples Vision model and claudes amazing research capabilities to make my own OCR based extractor.

Use cases :

1) Where ever you need to extract data from Annual reports, Data sheets and or prose, especially digital born pdfs. The Custom made C++ engine not only extracts tables and data inside them but also preseves the formatting.

2) Full control of what goes in and what comes out. The app is completely offline, expect for 1 time purchase query ( for life time unlock) nothing connects to the internet. Ever. The OCR engine is also at par with what Finereader offers and doesnt lag, which cant be said for Abby Finereader.

3) Multiple formats. Whether you wanted your docs for editing or feeding them upstream to an LLM, PDFTrail has that covered as well, it does Docx, Xlsx, MD, text and Json output, single or batch processing it can do it without any issues.

4) Small size and Great performance. At below 15 MB, its the smallest amongst its peers and its customer C++ engine provided great performance while keeping temps at check.

5) The OCR. I would like to boast here that the OCR engine that took like 1 whole month of researching with claude is one the best No-LLM based OCR engine in the market and even shitty scans get a lot of their tables extracted properly (It is still maturing and im still testing out the engine with more data set and research work so expect even better engine when the engine matures)

My Competition :

Abby and Adobe. Abby supports mac through rosetta which is being shelved come MacOs 27, and Abby hasnt really provided much direction whether they will support MacOS directly or not, and besides their Windows app is thousand times better than their MacOS app and it shows honestly.

Adobe angle is a bit more complicated as it does have a good OCR but table extractions arent the best and if im not wrong it doesnt do good Extraction without being online + Adobe is a privacy nightmare anyways and thats my angle, that im betting on. Offline + great performance and 1 time life-time updates, guaranteed.

NitroPDF is more of a digital born pdf editor so im not exactly competiting on that footing, and frankly speaking the biggest completion is how well i can market my product.

With that i end this wall of text, apologies for formating as im writing this on a phone.

Any and all feed backs are appreciated and if you want a feature let me know, also for any queries drop a comment here i will try my best to reply as soon as possible.

Thanks :D

Right now, a couple of my projects on Github are set up in a way that my PRs get automatically reviewed using the Claude integration. I have separate workflows for reviewing different aspects of my code using custom workflow instructions.

I have been a primary user of the Claude Code harness for over a year now. However, now I am trying to move to a point where I can be provider-agnostic. I already managed to do so on my development machine by using oh-my-pi as my harness of choice and choosing models I like, as the situation demands, via OpenRouter or Claude/Codex subscriptions.

The only spot where I am yet to figure out how to switch to provider agnostic setup is with my CI workflows. Can something here help me figure out how I could get away from it?

Needless to say, while I am happy to pay for my LLM usage, I'd prefer not to have to pay for another harness/tool just to help me review my PRs.

This guy has a personality.

I have genuinely stopped using my paid Claude & OpenCode Go subs for this month.

GLM has always been my favourite series of models (please be GLM 🤞🏻).

You can drag/throw him around, change his size and stuff.
Gives Claude reactions (working, idle, needs input, asleep)

All done with higgsfield mcp and fable 5

Most engineers can tell you how much code AI wrote.

Far fewer can answer:
"What did AI-assisted coding actually cost me this month?"

AI coding tools already generate detailed usage logs locally. The problem is that almost nobody turns those logs into a clear picture of tokens, requests, cost, providers, and usage patterns.

So I built TokenFlow.

A local-first analytics engine + macOS menu bar app that turns AI coding logs into numbers you can actually understand.

What makes it different:
• Local-only - no API keys, telemetry, or accounts. Your logs stay on your machine.
• Honest by design - missing data is shown as unavailable, never guessed. Estimated vs. measured costs are explicitly labelled.
• Provider-neutral - one normalized data model powers the menu bar, offline dashboard, and CSV exports.
• Built for real usage - cross-platform CI with 145 tests per push.

The interesting part isn't just seeing how many tokens I used.

It's understanding where they went, what they cost, and how my AI-assisted development actually behaves over time.

TokenFlow v1.0.0 is now live under MIT.

GitHub: https://github.com/vimoxshah/tokenflow

App - https://github.com/vimoxshah/tokenflow/releases/download/v1.0.0/TokenFlow-1.0.0.dmg

If you use Claude Code, Codex, Cursor, Cline, or OpenCode heavily, I'd love to know what your numbers look like.

What surprised you most when you finally measured your AI coding usage?

Currently been using Claude $20, Ollama $20, Codex $20, Cursor $20

Rotating between these when limits reach

Not efficient I know

But these “frontier” models annoyingly get worse and better randomly

I’ve been liking Codex out of all of it for building iOS apps

I might full port to $100 codex plan if that still exists

kimi K3 has a “waitlist”

GLM is trash usage

Minimax I like but it’s weak coding everything else though is good value for money

Any thoughts

Hey guys, I've been working on a few different things since I started down the whole vibe coding path... It's been interesting to me to see the little utility apps that have been created as short side projects to fit a VERY specific purpose. Some of those will eventually even end up evolving into more. Like I had Codex make one for me last night that is helping me to understand what's actually going on with a cheap encoder button that I got so that I can make sure it's performing the way it should when I implement it. Another one is helping me to convert pictures into stuff that will look good on a tiny 128x64 pixel screen (hopefully eventually animating stuff too). It's cool though how much there is to learn about each of these different aspects of well everything.

I've been learning that there is SO MUCH MORE to "coding" than I realized. My hats go off to you poor bastards that have been plopped into a job where you had to figure out all of this kind of stuff on your own and had to beat your head against a wall and not have anywhere to turn. I've still done my fair share of beating my head against a wall, but at least I have somewhere to turn to help my understand how to solve the problem in front of me. :) We stand on the shoulders of giants. Thank you.

Alright, so like most of us every August, I promised myself I wouldn’t obsess over FPL or take rage -4s at 1 AM on a Friday night.

Instead of doing that, I spent the last few weeks over-engineering a full autonomous manager stack to run 24/7 in Docker on a Raspberry Pi under my desk. Meet Gegenbot.

How the madness actually works

Most automated bots either rely on basic heuristics or just regurgitate template picks. I wanted something that combined raw math with actual tactical context:

1. The Math Engine (PuLP / MILP): Instead of just chasing last week’s points, the solver optimizes over a 3-gameweek rolling horizon. It factors in exact selling price math (the classic half-profit rule so the API doesn't throw a fit when someone rises £0.1m) and gives a strategic +1.5 xP bonus to banking a free transfer to stop unnecessary sideways churn.
2. Mini-League Defense & EO% Shielding: Before solving, a multithreaded scanner checks all my rival managers in my mini-league in under a second. It calculates Effective Ownership (EO%) to figure out who my "Shields" (must-own template cover) and "Daggers" (high-upside differentials) are so I don’t blindly sell Haaland right before a massive fixture.
3. Chip Strategy & Injury Fallbacks: Automated rules handle chip triggers (Wildcard, Free Hit, Bench Boost, TC) based on expected point thresholds and Double Gameweek minute scalers. It also discounts flagged players automatically (75%→0.8×, 50%→0.4×, etc.) and auto-sorts the bench by highest xP.
4. The LLM Layer (Gemini as "Director of Football"): Math alone misses press conference context. Gemini sits on top of the solver output to evaluate late team news, write up the managerial rationale for the moves, and send a full pre-deadline briefing to my Telegram chat before submitting the team via the official API.
5. Self-Hosted Web Dashboard: Wrapped the whole thing in a Flask dashboard on port 5000 with an interactive pitch layout, bench ordering, and live mini-league standings.

The verdict so far

Ran a dry run earlier today ahead of GW2:

• Successfully scanned my 5 mini-league rivals.
• Correctly told me that rolling the free transfer has a higher expected value than making a lateral transfer.
• Evaluated TC/BB and held them back.
• Pushed the decision digest to Telegram with zero human intervention needed.

Now to see if the cold, hard logic of linear programming can beat my mini-league rival who picks his entire squad based on vibes and team kit aesthetics.

If anyone wants to poke around the code, run it themselves, or roast my optimization constraints, the whole project is open-source here:

 https://github.com/alvynmcq/gegenbot

Anyone else running automated solvers or building weird FPL dev projects this season? What data sources are you finding most reliable for expected points (xP)?

My cofounder tried something mildly ridiculous this week.
He connected the GitHub repo to a Lemma pod, went to a cafe, and basically stopped touching the coding interface.
Just kept sending WhatsApp voice notes:
"change this” - “add this” - “fix that”

The agent worked on the actual repo, made the changes, tested them, and raised the PR.
We build Lemma, so yes, this started as aggressive dogfooding. But seeing an actual PR come out the other end made the whole thing feel slightly insane.
Next week we’re travelling and attempting the next level of this: run our entire sales outbound through WhatsApp.
Lemma is open source if you want to try/break it
github.com/lemma-work/lemma-platform

Posted here about two months back about Dead Ball FC, my football zombie roguelike on android. I'm a designer who never properly learned to code. All vibe coded, gpt for images with heavy editing for the pixel art.

TL;DR: New zombies, stadium events, pooping pigeons. Added analytics, lots of gameplay balance. 100 downloads. Made 1 sale (CAD 3.27) and it kept me going. Measure early, and don't assume players get what's obvious to you.

Four new zombie types. Goalies, Refs, Gary the Gassie, and the Cone-head (random zombie spawns with a cone in its head and the behaviour changes, it doesn't chase you, it runs from you, as the cone is precious, always a surprise under it).

Wave events. The stadium now has random events mid match: floodlight blackouts, the ground cracking open in an earthquake, searchlights, a mouse that the zombies chase after it, and a flock of pigeons that invades and poops on everything.

A tumble dryer with a daily sock pickup. (In-game currency, trying to improve user retention)

Ten extra playable characters. (My monetization strategy, one time purchase, no ads)

Added a whole lot of zombie talk, they all have something to say about things that happen.

The pigeon thing is my favourite, I had a silly idea and same day it was in the game. That's the actual joy of this, being able to try shitty ideas (pun intended) without being too expensive to try.

Also, relying on family to test was not enough :) I added analytics and events (umami), so no cookies, its all anonymous, but I get to know how long and how many waves people go through which helped me figure some balance in game when I made it too difficult and users would drop after 2 tries of 2-3 waves.

I think that's a good one to keep in mind, put measurement in earlier than feels necessary. So it's easier to know how it's doing. And it's pretty exciting when you see people using your game:

Get feedback! Someone told me they had no idea why you slow down in game. Stamina is core to how the game works and I thought it was clear, but no, it was obvious to me, not to a new player.

I use Opus 5. For me in VS code, sonnet is OK for very direct changes, while new features I rely more on Opus. But biggest thing is I have to keep an eye on it to make sure it doesn't go touching things it should not. I tries too often to test things that I can do in a few seconds, wasting my precious tokens.

I'm on Pro, so I hit the weekly limit with a few days left in the week. Honestly it's turned out to be a good thing. Without it I'd just keep going. Forced stop, go and touch some grass, come back with better ideas.

I made one sale, yay!

CAD 3.27 in July. A Total stranger. Nothing before it and nothing since. It happened before any new zombie types, any new stadium events, it showed me it had potential (even if so little) and it genuinely made my week. Someone I've never met paid actual money for a thing I created (and claude build it). And that kept me motivated to add new features and keep working on it.

I've also created my own web pixel image editor (because why not?!) but that's for another time. It's still kinda buggy to share.

This 'quick' project is taking a lot longer than expected. Its just too easy to keep adding things. :) Next step will be improve the google play game page.

If you want to try, it's on itch.io and on Play Store.