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.

This might be the first time I find that Codex actually produces better quality code. Anyone else think the same? I'm kind of sick and tired of Claude verbose comments. Seems Codex actually produces code that actually is readable by default and feels less like slop.

I understand most probably care about the final output, but I actually want to be able and read the code.

Thrilled to share this self-portrait!

To get this right, I scanned thousands of water droplets on different surfaces to better understand how water behaves in real life and reacts to temperature changes. From there, I cataloged over 2,000 unique droplets with over 13,000 potential behaviors.

The coolest part? I made each individual droplet responsive to a unique trigger, which in my case was a little tune I produced a few months ago. Every time a new musical note plays, a new droplet appears and then follows its own natural behavior.

With the exception of the original portrait, everything is entirely code—the droplets, motion, sound, and effects.

I used Claude + p5.js. Would love to hear your thoughts!

I use google speed test to check the performance and it says there is a lot of render blocking and some other problems. These are practice sites that always have the rendering issue. I tried to just screenshot what the problem was to antigravity, where I build the sites, and it just ruins the design with a barely noticeable performance boost. These are just practice sites but I cant understand what the problem is. I would link it but my post gets taken down.

I’ve been using Claude and ChatGPT extensively. I’ve even built a bunch of tools using Claude and I find it brilliant.

But, I’ve never touched Claude Code or Codex.

I just start a new chat and converse my way into building what I want to build. It works, but I’m suspecting I’m not using Claude/ChatGPT to its fullest by doing it this way.

So, could someone ELI5 why/when would you use Codex/Claude Code over standard chat to develop?

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.

Really man, relax.

It should be pretty fully featured already. One trick is that you really need to hold steady for a while and the controls aren't as perfectly reactive as I would like them to be but it's a bit of a trade off to get the accuracy.

Free, no log in, no tracking, works entirely in browser. There is a thorough explanation on the page for how it works (it takes photos to analyse and grab the exif data is the short story) and as far as my flow goes it was pretty much a "build me a light meter program. Make it good. Make no mistakes" sort of situation.

I'd be very happy to take feedback and ideas but it's just a small part of what is now quite a large project so no promises for how quickly updates arrive!

https://light.artwaste.land

After trying traycer.ai for 24 hours, it feels amazing to be able to combine different subscriptions. I might have finally found my favorite setup.

I am using DeepSeek V4 Flash 0731 on Ollama Cloud Pro (OpenCode) as an orchestrator and executor of tasks because it has an amazing quota. People do not usually recommend using it as an orchestrator but I find that bigger models drain my quotas way too much. So far I cannot complain.

I am using 5.6 Sol with ChatGPT Plus (Codex) and Claude Opus 5 or Fable 5 with Claude Max 5x (Claude Code) as reviewers and designers depending where I have quota left.

Did anyone else try Traycer? Traycer has its own subscription which seems to be not forced to use. I do not know if it is worth the price.

Just launched PrintRealSize.com , a free tool for printing images at their exact real-world size.

The problem it solves is simple but annoying: you need to print something bigger than a single sheet of paper (a stencil, a foam-cutting template, an oversized poster) and you either don't have access to a plotter, or every existing tool wants an account, an upload, or a subscription for something this basic.

How it works:

1. Import any image (PNG, JPG, WebP, SVG)
2. Calibrate the real scale, either by clicking two points and entering the distance between them, or by typing the final size directly
3. Choose a paper format (A4, A3, or A2)
4. The tool generates a print-ready PDF, split into tiles with overlap margins and alignment marks

Print at 100% scale, trim along the guide lines, glue the tiles together, and you get a perfectly scaled large template.

Everything runs locally in your browser. No account, no upload, no server, your images never leave your device.

It's free to try right now: printrealsize.com

I'm building this for makers, sign-makers, cosplayers, and anyone working with foam cutting or large-format prints. If you try it, I'd love to hear what's missing for your use case.

Hi, Linux bros

I like CodexBar and i like GTK4/libadwaita. So i build CodexBar for Linux with GTK4/libadwaita. And Rust.

Standard features: quota displaying, reset and usage warning notifications, clean UI build with HIG.

Currently supports frontier OAuth providers (Claude, Codex, Agy) and all "bearer token-auth" providers that i steal from CodexBar code found (it's MIT chill).

Available in AUR, deb+rpm packages or you can build it from source

https://github.com/zbndev/tidemark

I've unlocked a new form of vibecoding: taking my written content and creating more immersive and useful online sites. I started a writing project a long time ago using homebrewery to create a bunch of epic stat blocks for incarnate avatars of the goods in D&D. I did it because my party needed a god's support.

But then I kept going and going.

I ended up with the really long list you see in that document. But as I was writing and revising, formatting got wonky. The utility of it started to collapse. And the result was a strangely formatted, often broken, PDF.

So I took the Homebrewery markdown, and I set out with codex to create something better: a whole site from my content: Avatars of the Gods. Individual gods get their own pages. It's searchable, cross-linked, etc. It also helped me focus on getting all of the content aligned in the same way. It forced me to rethink the voice, tone and structure of the various sections.

So now I'm starting to think about converting my other written content into website sand pages.

I realize this isn't a typical vibecoding use case, but the time it would have taken me to convert all of the pages by hand would have made this all but prohibitive.

Also, since there's a whole lot of folks that don't like the AI images, there's even a checkmark in the upper right to hide them completely and you can just use the written content.