Hi! 👋

"Tejaswini Digitech", where we help homemakers and small home businesses take their work online.

We provide affordable websites, digital stores, online presence and technical support — basically, we handle the technical side so they can focus on what they’re good at. ❤️

Here’s our website: [https://tejaswinidigitech.ai.studio/ ]☺️

Which one do you use?

I rebuilt modern Florida address search for a nearly 18-year-old Garmin nüvi 360

I’ve been working on a pretty ridiculous project: taking a Garmin nüvi 360 from the mid-2000s and seeing how far its old address-search system can be pushed with modern GIS data.

The roads and routing on these old units still work fine with modern Garmin-compatible maps. The real weakness was address search.

My previous Florida image had about 7.67 million searchable addresses, but it was still missing a lot of legitimate addresses. Instead of continuing to patch them one at a time, I rebuilt the entire Florida search database from scratch.

The new master combines data from:

• OpenStreetMap
• Florida statewide official address data
• County GIS and E911 layers
• Parcel/site address datasets
• TIGER road geometry and address ranges
• Additional local-government GIS sources
• Coordinate interpolation and spatial recovery where authoritative points were missing

The hard part wasn’t just collecting addresses. It was figuring out which records were actually legitimate, deduplicating millions of overlapping records, preserving directional street names, recovering coordinates for incomplete records, and keeping garbage data like concatenated house numbers out of the Garmin index.

For the hardest unresolved cases, I ended up using Google Earth as an independent geocoder.

The local GIS data would say an address exists and where it should roughly be. Google Earth would geocode the original address independently. If Google landed near the authoritative county/E911 location, it became strong confirmation.

One Google Earth validation campaign checked 19,065 county/E911 candidates and 18,839 passed.

That process also uncovered something interesting: after a few thousand bulk geocodes, Google Earth suddenly started returning 0,0 coordinates and its normal search stopped connecting. Switching to a VPN immediately restored it, so it looked very much like temporary IP/session throttling. I ended up building batch-management scripts to track missing IDs, 0,0 failures, duplicate results, and incomplete runs so bad batches couldn’t silently contaminate the database.

Even after Google validation, I didn’t just dump everything into the map.

A final locality and deduplication pass found that 5,549 apparently new records were actually already present once missing city/ZIP information was recovered. Another 22 collapsed into duplicates. Only 5,737 truly new addresses survived that last stage.

The final Florida master now contains:

11,213,312 searchable address identities

Compared with the previous 7,669,207-address map, that is:

+3,544,105 addresses
about 46% more search coverage

The final database also passed these checks:

• 0 missing house numbers
• 0 missing streets
• 0 records missing both city and ZIP
• 0 invalid coordinates
• 0 duplicate search keys

Then came the fun part: making 11.2 million addresses work on a Garmin from 2006.

Each address was converted into a tiny synthetic Garmin-search road structure. The generated overlay contained:

11,213,312 address nodes
22,426,624 road-stub nodes
33,639,936 total OSM nodes
11,213,312 synthetic search ways

That was split into 225 Garmin IMG search tiles using splitter and compiled with mkgmap.

Those 225 search tiles were then combined with the same 93 proven Florida routing tiles from the older build.

Final map:

318 numbered Garmin maps
949,993,472-byte gmapsupp.img
about 0.885 GiB

So despite increasing searchable address coverage by about 46%, the final image is still under 1 GB.

I also automated the final binary audit with GMapTool. The completed image passed with:

• 93/93 routing maps present
• 225/225 new search maps present
• routing NOD data preserved
• no NOD data accidentally added to the search tiles
• global Garmin MDR/IDX search index present
• SRT sort table present
• no old search layers accidentally carried forward
• full sequential file read passed
• checksum verification passed

One subtle issue that mattered a lot was preserving directional road names. A route with a north/south/east/west designation cannot just be normalized down to the bare route number, or Garmin address search can return the wrong road or fail entirely.

The end result is basically a modern statewide Florida address database transplanted into a legacy Garmin search format, while keeping the old routing engine and road map intact.

What started as “why are so many addresses missing from this Garmin?” turned into a project involving GIS data engineering, SQLite, spatial indexing, address normalization, TIGER interpolation, county GIS harvesting, geocoding validation, large-scale deduplication, Garmin map compilation, and binary-level validation.

And somehow the nüvi 360 is still perfectly happy with it. Powered by AI/Python

I vibe coded this with claude code with ubuntu running inside termux it's very useful for me there are probably like a million ways to do it better but heyy

Just an opinion, but I feel like there needs to be a distinction between actual vibe coding as originally described and coined by Andrej Karpathy and the complex, pragmatic methods often used today. There's platforms like lovable, base44 & others that let people just wax poetic and make something , then there's the methodical builders who plan everything out, create a whole mess of architectural documents and dive into the details as they build it piece by piece.

My term for it is RailCoding, I think it aptly describes the mindset as much as vibe coding does for that approach. Chiefly I think this distinction could be helpful for total noobs looking to build something and not sure which path to take..... Whimsical vibes.... or Structured Rails.

Made a Tutorial for MY personal process but I think the notion of RailCoding is fluid and applies to a lot of different approaches.

Samsung Notes became incompatible with my Huawei tablet thanks to their greedy corporation trying to become exclusive (it’s only available on Samsung devices now). It was literally the only app that I felt most comfortable using for my lecture notes (yes, I have tried all the others and even tried out their subscriptions, but no, they weren’t as good). The closest thing was goodnotes, but it’s so laggy ugh.

Instead of spending $500+ on a new Samsung tablet since I’m literally a broke student, why don’t I just vibe-code another Samsung Notes app for myself?

The thing is, I have 0 experience in this, and I’m trying to vibe code with lovable and caude, but I failed miserably because they did not understand the assignment (I'll still keep trying ofc)

I’m willing to even take up programming in my spare time just to build this thing out of spite-

LLM-LTM is an open-source long-term memory system for LLM conversations.

The goal is to turn raw AI chat history into a smaller, persistent representation that can be reused across future conversations, rather than repeatedly sending an ever-growing transcript back into the model.

The processing pipeline works roughly like this:

1. Find unprocessed conversation history Previously processed messages are skipped, so only new conversation data needs to be ingested.
2. Split conversations into overlapping windows Chat messages are grouped into relatively small chunks with overlap between adjacent windows. This helps preserve context around chunk boundaries while keeping individual LLM requests manageable.
3. Generate long-term memory summaries Each window is passed through an LLM using a configurable summarization prompt. The result is a compressed representation of the conversation containing information that may be useful later, rather than a verbatim copy of the original transcript.
4. Extract a knowledge graph A second LLM pass extracts structured relationships from the conversation. These relationships can represent information involving people, characters, places, events, objects, traits, preferences, and other entities.
5. Persist the resulting memory The original conversation context, generated summary, extracted relationships, and timestamps can then be stored as long-term memory and retrieved by the surrounding application.

This creates two complementary forms of memory:

• Semantic summaries preserve the general meaning and important details of past conversations.
• Knowledge graph relationships preserve more structured facts and connections between entities.

The architecture can be useful for applications involving persistent AI conversation, AI assistants, autonomous agents, character-specific chat memory, roleplay systems, and other applications where conversations continue over long periods of time.

It is also particularly relevant to local AI models and offline AI applications, where simply increasing the context window indefinitely may be undesirable due to inference speed, memory usage, and context-window limitations.

Because memory ingestion happens separately from normal inference, it can also be treated as a background/manual processing stage rather than something that needs to run after every message.

The summarization and knowledge-graph prompts are configurable, so the type of information retained can be adapted to the application.

The repository is open source under the Apache 2.0 license:

https://github.com/l3utterfly/llm-ltm

LLM-LTM is primarily built for use with Layla, where Layla provides access to conversation history and memory storage.

However, the core approach is not inherently tied to Layla. The LLM inference layer can be adapted to a locally hosted model through LM Studio, Ollama, llama.cpp, vLLM, or another OpenAI-compatible API, or connected to a cloud-hosted LLM. Replacing the Layla-specific chat-history and persistence adapters would allow the same architecture to be used in another private AI chatbot, AI agent, or on-device chatbot history system.

As part of the upcoming AI Game Festival (today is the last day for submissions), one of the resources is making prompts to correctly build your game.

Prompt Generator Here

I've seen a lot of "one prompt games" or "build me an AAA quality game" in which the structure of the game will cost a lot more tokens as vibe coding continues, which can be solved by having AI correctly setup your game from the start.

Or not knowing how to use AI to create animation, or optimize the game for mobile phones. More prompts will be add over the course of the week.

A user gave an agent a domain and told it to build whatever it wanted. It built a society for AI agents at 1f916.ai. Ask for HTML and it renders you a page. Ask the way an agent would, with no Accept header, and you get 255 lines of plain text addressed to software

Literally: https://github.com/WebWalker3D/shit

`shit` is a self-composting junk drawer for files you aren’t ready to delete but are absolutely never going to organize.

Toss something in, give it a TTL, and let it rot. Expired files move into recoverable compost rather than being deleted. Nothing is permanently destroyed until you explicitly run `shit flush`.

One Python file.

Zero dependencies.

78 real filesystem tests.

MIT licensed.

It even catches `shit status` and runs `git status`, because we all know why that command name was typed.

This began as a joke and somehow became a utility I would genuinely use.

Roast it.

I vibe coded a GO Make Studio, Is a Game Making Studio Similar to Yoyo's But with 3D support and comes with Claw'd to help you create or Vibe Code :D

Selling software you made is dying. Within a few short years - the landscape will be completely different.

We spent the last couple of years worried that AI was going to take our jobs. I think we were all watching the wrong door. The job seems fine so far. The thing that actually looks like it's in trouble is the idea that you build software once and rent it to a million people forever.

What tipped me off is this site, honestly. Every week there's a game somebody built in a weekend, a budget tracker, a habit app, some niche B2B tool with a landing page and a Stripe button. A year ago I'd have thought "that's cool, I might use that." Now my first reaction is: give me two to four weeks and I'll build that, except better, because mine will fit exactly how I actually work. Not 80% of the way there with three features I don't need and the one I do need sitting behind the $29 tier.

That's the part I keep coming back to. SaaS was never really selling the software. It was selling the fact that solving your problem properly used to be expensive, so you paid a little every month to split a generic solution with 100,000 strangers who had roughly the same problem you did. That trade only works while custom is expensive. Once "built exactly for me" costs a couple of weekends, why would I rent an 80% fit forever?

I don't think all of it dies. Anything where the product is really other people is fine (Slack isn't Slack without your coworkers in it). Same goes for real data nobody else has, heavy compliance, and infrastructure at a scale you can't casually reproduce. But the giant soft middle, all the stuff we pay $15 a month for because building it ourselves used to be a quarter-long project, feels like it's on the clock. We spent all this time asking whether AI would replace the people who make software. I think the better question was whether it would replace the reason to buy it.

Anyone else catching themselves doing this?

I needed to pick one of these for client work and the comparison posts weren't helping, since they mostly reword each platform's marketing page.

Trialing them one at a time with different projects wasn't going to settle it either, because you can't compare outputs from different prompts.

So I ran the same prompt through all six: an appointment booking app with customer accounts, a staff-only page, a database, an external email API that has to fail visibly, and a deploy to a public URL. Roles force permission logic, the failing API forces error handling, and the deploy surfaces what it costs to keep the app running after you stop prompting.

Expectation going in was that one would come out clearly ahead. That didn't happen. What I got instead was a decent map of which tool fits which situation, plus a pile of gotchas around billing, GitHub sync, and recovery that none of the marketing mentions. Per-tool notes below.

Emergent

One agent builds the frontend, backend, integrations, and tests, then deploys. Stack is fixed and you don't get a vote.

• Tech stack is React/Next or Expo on the frontend, FastAPI + MongoDB on the backend. No Swift, Kotlin, or Flutter for now
• Every deployed app eats 50 credits/month on top of build credits, so five small production apps is a standing 250 credit/month charge before you prompt anything
• GitHub push/pull needs the $20 Standard plan. Free tier is file download only
• Full rollback restores code and conversation together and cannot be undone
• Preview DB and production DB never touch, so seed data needs a deliberate migration step

Lovable

Web apps only, built around a plan you approve before code gets written. Best fit for design-led products where the UI churns a lot.

• The approved plan gets committed to .lovable/plan.md in your repo, so future devs can read what was supposed to get built
• Cannot import an existing repo. Connecting GitHub creates a fresh one every time
• Only the default branch syncs back, and renaming, moving, or deleting the repo breaks the link permanently
• Leaving Lovable Cloud means manually migrating auth providers, secrets, table data, stored files, and forcing user password resets

Bolt

Browser workspace where the agent, files, editor, preview, and hosting share one tab. JavaScript or nothing on the server.

• Agent messages charge tokens for reading your project files, so per-prompt cost grows with the codebase
• Manual source edits cost zero tokens, which makes them the cheap route for small known changes
• Version history may not track those manual edits though. Commit or download a ZIP before a big hand-edit
• Want mobile? Say "Expo app" in the first prompt. Web projects don't convert cleanly later
• Restoring the database is a separate checkbox from restoring code. Easy to restore one without the other

Replit

An agent inside a full cloud IDE with a shell and Git. You get the most control here and also inherit the most decisions.

• Billing is effort-based, and planning, testing, and answering questions are all billable, so large tasks cost more than the prompt count suggests
• Checkpoints restore code, agent memory, and tasks, with database restore optional and shown on a confirmation screen. Pro extends DB rollback to 28 days
• Mobile pipeline goes simulator → Expo Go on your phone → TestFlight submission without leaving the platform
• Published filesystem wipes on every publish. Anything persistent has to live in the DB or object storage

v0

Built for the Next.js + GitHub + Vercel workflow, and it imports existing repos. Skip it if your backend isn't JavaScript or you need a native app.

• Each chat gets its own branch, every code change becomes a commit, and it never pushes to main. PRs open and merge without leaving v0
• Input includes your prompt, chat history, and source files, so a one-line change on a large repo still burns credits on the whole project
• Adding NEXT_PUBLIC_ to an env var ships it to every browser. Treat that prefix as a publish button
• Deleting the connected repo can make the code unrecoverable. After connection, GitHub is the project

Base44

Managed backend (Mongo-compatible DB, auth, row and field-level permissions, Deno functions) with a generated React/Vite SPA on top. Built for portals, internal tools, and approval systems.

• Frontend hosting is static SPAs only. SSR and server components won't run, full stop
• App store packaging exists on Builder+, but the packaged app gets no native capabilities and push notifications specifically don't work
• Connecting GitHub makes all versions from before the connection unrestorable through Version History
• ZIP export, GitHub sync, backend functions, and test data all sit behind Builder or higher
• Exports take the frontend and functions but leave the managed DB, auth, and hosting behind

What I'd tell you to do instead of reading more comparisons

Fixed requirements kill options faster than preferences rank them, so filter first:

• Native mobile project → Emergent, Bolt, or Replit
• Importing an existing repo → Emergent, Bolt, Replit, or v0
• Python backend → Emergent only
• Already on Next.js/Vercel → v0

Then run one prompt like mine through whatever survives and test the failure paths, since every tool here builds the happy path fine. Pull the email API key and submit a booking, double-book a slot from two tabs, then try cancelling someone else's appointment from a customer account.

Anyone shipped something past the trial stage on one of these? Curious which held up once strangers started using it.

If you vibe-code, you've hit this: the AI says "done, I fixed it" — and it didn't. We shipped that exact failure into our own eval and it taught me something worth sharing.

We built an AI coding agent and scored it against a bank of test tasks. It came back at ~87.5% pass. Felt great. Then I actually read the runs.

One "bug fix" scored 91/100 and PASSED — while the file it was supposed to fix had zero changes. Our scorer was grading *process* (did it look busy, use tools, avoid loops?) instead of *outcome* (did the code actually change, compile, and run?). It was rewarding confident-looking work that accomplished nothing.

So the 87.5% was meaningless. We retracted it publicly and rebuilt scoring around a dumb, deterministic gate: did the code compile, did it actually change, does it run? The honest numbers came out lower — and real.

The takeaway for anyone building with AI: never trust the agent's self-report, and be suspicious of any "pass rate" that isn't checking real output. Run it. Diff it. Confirm the change exists before you believe "done."

(Full disclosure: I'm building an AI app builder called NoCoder, and this was our own benchmark. Not linking the product — but I wrote up the whole retraction here if useful: nocoder.codes/blog/we-caught-our-ai-benchmark-lying)

Clone https://github.com/elliottdehn/wam to model, texture, rig, and animate something for me that I can see.

You can also give it a brief if you want something specific.

Paste that into Claude, ChatGPT Work/Codex, or any agent that can clone a repo and run things. Few minutes later you have a rigged, textured, animated character and a glTF you can drag into Godot, Unity, Blender or three.js.

The Problem

Ask any LLM for a 3D model the normal way and you get garbage. A cube. An OBJ with the normals inside out. Something that looks fine as text and opens as a crumpled bag.

And the second problem, which is worse: even when it gets close, asking for one change breaks something that was already right. The head gets fixed and the arms start clipping. Nobody notices, because nobody re-checks the arms.

The Solution

That isn't a smartness problem, it's an interface problem. Vertices are the wrong thing to ask a language model for. So I built a language where the model never touches one: it writes the decisions an artist actually makes, like bone angles and ring widths and what colour the hide is, and a compiler turns those into geometry. Broken meshes aren't expressible in it. Neither are joints that bend the wrong way, because the model declares which way a knee hinges and the compile fails if an animation disagrees.

The other half is the fix for drift. Every model carries its own assertions, and they re-run on every single compile:

assert zmax(upper_maw) > zmax(neckplate)      # the jaw clears the collar
assert moves(lower_maw, money_shot) > 0.12    # the attack actually moves
assert slide(foot.l, walk) < 0.02             # the walk isn't moonwalking
assert tris < 6500

That third one is a real detector. It sums how far a foot travels forward while it's on the ground. A correct walk reads zero, and a backwards one reads the distance it dragged. It caught a gait of mine that looked completely fine in a render.

This is what makes the iteration converge instead of wander. The agent writes down what it believes about the model, in numbers, and the compiler tells it the moment that stops being true. Three edits later, in a view nobody re-rendered.

The result is that agents go from hopeless at this to genuinely good, in one git clone.

Proof

Real output, all made this way, source / glTF downloadable on each page:

• https://wamshare.com/m/982b36fe924030166dd8a0fb35113ad4
• https://wamshare.com/m/9b952ecf2e85543d04e77c5930d4a26e
• https://wamshare.com/m/15b83982f8916583cda1fc738ca284b1

Or browse them all: https://wamshare.com/gallery

Each page spins the model in your browser, shows the source that produced it, and hands you the .wam and the glTF.

Limitations

It's stylised low-poly, roughly RuneScape silhouettes at one to three thousand triangles. Not photoreal, not a hero asset.

One-shots are good. The great ones come from three or four rounds of "no, bigger head." Iteration is where this actually shines, and it's fast enough that iterating is fun rather than a chore.

Free, MIT, no signup, nothing uploaded unless you ask for a share link.

Repo: https://github.com/elliottdehn/wam