A solo developer turned all of GitHub into a 3D city you can fly through. He built it in four days by describing what he wanted, not by typing every line. The site is free to walk around. What matters more is the method behind it, because that same method is what makes the software your business keeps postponing suddenly affordable.
There is a website where every developer on GitHub is a building. Ship more code and your tower grows taller. Stay active and your block gets bigger. You type in a username and the camera lifts off and flies across the skyline to that person's door.
It looks like a small game studio made it. It was one person.
And he did not sit and hand-write the whole thing. He told an AI what he wanted, checked what it produced, corrected it, and kept going. Start to live site in four days.
Go See It First. Two Minutes.
The site is called Git City. The address is thegitcity.com. No login, no payment, nothing to install. You open it in a browser and you are standing in the city.
Type your GitHub username into the search box and it flies you to your own building. Type in a developer you admire and go look at their tower. Then just move the camera and drift over the rest of the skyline.
Do that before you read the rest of this. The point of what follows lands harder once you have actually flown through it.
What It Actually Is
Git City renders GitHub as a pixel-art metropolis. It is a visualization, not a tool you plug into your workflow. Here is the plain version of what is real and what is not.
| Question | The answer |
|---|---|
| What is it? | A 3D city where each building is a GitHub user |
| What makes a building tall? | How much that developer has committed and how active they are |
| Can I find myself? | Yes. Search your GitHub username and it flies you there |
| What does it cost? | Nothing. It is free and open |
| Who made it? | Samuel Rizzon, a solo developer, building it in the open |
| Is it useful for my business? | Not directly. The lesson behind it is the useful part |
So no, it will not quote a job or chase an invoice for you. It is a demo. The reason it belongs in front of a business owner is how it got built.
How One Person Built It in Four Days
The developer built Git City with Claude Code and VS Code. In plain terms, Claude Code is an AI coding assistant that sits inside the tool programmers already work in and writes the actual code when you tell it what you want.
He describes the outcome. The AI writes the code. He looks at the result, says what is wrong, and it fixes it. Repeat that loop fast enough and a full interactive 3D app comes together in days instead of months.
The four-day figure is his own claim, from the video where he showed it off. Take it as one person's account, not a benchmark. But the shape of the story is the part that is true across the board now: the bottleneck moved. It used to be typing the code. It is now knowing what to ask for and being able to judge what comes back.
That has a name people are using. Vibecoding. You stop writing every line and start deciding what gets built.
Why This Should Get Your Attention
Think about the last time your team said "it would be great if the software just did X" and then dropped it.
Maybe X was a small internal dashboard so you stop asking the same three people for numbers. Maybe it was a form that turns a client request into a job card without anyone retyping it. Maybe it was a nightly report that lands in your inbox instead of someone building it by hand every morning.
You probably priced it, saw a dev shop and a two-month timeline, and shelved it. That math is the thing that changed.
A visual 3D city in four days is a stunt. A rough internal tool for your own team, built by directing an AI, is not. That kind of build is ordinary now. What the demo shows is simple: the cost of a first working version of custom software has dropped sharply.
I am not telling you to fire your developers. I am telling you the list of things worth building just got a lot longer, because the price per item fell.
Try the Method, Not Just the Site
You do not need to code to feel the shift. You need a clear ask and someone who can drive the tool. Here is the honest sequence.
- Fly through Git City for two minutes so the "one person, four days" fact is real to you, not abstract.
- Write down one task your team does by hand every week that a small piece of software could do instead. One task. Be specific.
- Hand that task, described plainly, to whoever on your team is closest to technical, and have them scope it with a coding agent like Claude Code or Codex. The first version is a prototype, not a product.
The prompt below is the bridge from "annoying manual task" to "something an AI can start building". Paste it into any capable assistant and answer its questions.
Copy This: Scope a Small Internal Tool
Copy the Scoping Prompt
Copy this.
You are my software scoping partner. I run a business and I want to
turn one repetitive manual task into a small internal tool. I am not
technical, so keep every answer in plain language.
The task I want to kill is:
[DESCRIBE THE TASK IN ONE PARAGRAPH. EXAMPLE: "Every Monday my office
manager copies last week's jobs from our booking system into a
spreadsheet, adds up the totals per technician, and emails me a
summary. It takes about ninety minutes."]
Do this, in order:
1. Play it back to me in your own words so I know you understood it.
If anything is unclear, ask me before continuing.
2. Tell me, in one sentence, whether this is a good first candidate
for a small tool or a bad one. Be blunt. If it is a bad fit, say
why and stop.
3. List the smallest possible version that would still save real time.
Not the dream version. The version someone could build in a few days.
4. List what a builder would need from me to start: which systems it
touches, where the data lives, who uses the result.
5. Name the two most likely ways this goes wrong, so I can watch for them.
Rules: no jargon. If you use a technical word, define it in the same
sentence. Every recommendation must be something a small business
could actually run, not an enterprise platform.
Answer its questions and you walk away with a one-page scope you can hand to a developer or an AI coding agent. That page is worth more than the fanciest demo, because it is about your business.
Honest: Where This Breaks
The Git City story is exciting. It is also easy to over-read. Here is the part the highlight reel leaves out.
- Four days for a visual demo is not four days for anything that touches money, customer data, or the law. A pixel-art city that shows the wrong tower height annoys nobody. Software that miscounts an invoice or leaks a client record is a different category. Slow down the moment real stakes appear.
- You still need a human who can read code and judge the output. The AI is fast and confident, and it is confidently wrong often enough that unreviewed work is a liability. Vibecoding does not remove the reviewer. It removes the typing.
- A prototype is not a product. The first working version proves the idea. Turning it into something your team relies on every day, that stays up and stays secure, is more work than the demo suggests.
- Some tasks should not be automated at all yet. If a job needs judgment, sits on sensitive data, or only happens twice a year, the smart move is to leave it alone. Not everything that can be built is worth building.
None of that cancels the point. It sharpens it. The barrier to a first version fell through the floor. The barrier to a trustworthy final version did not. Knowing the difference is the whole skill.
If You Only Do One Thing This Week
Open thegitcity.com, search your GitHub username, and fly to your building. Give it two minutes.
Then write down one manual task your team repeats every week and paste it into the scoping prompt above. Not five tasks. One.
If nothing comes of it, you spent ten minutes and saw a genuinely cool thing built by one person in four days. If something does come of it, you just found the first piece of software your business stopped believing it could afford.