Forem: Wildan S. Nahar

How I rebuild my hobby project in over 2 weekends with ChatGPT & Claude

Wildan S. Nahar — Sat, 28 Feb 2026 01:15:06 +0000

Overview

I rebuilt my hobby project in over 2 weeks with the help of OpenAI's ChatGPT and Antrophic's Claude (Sonnet 4.5). In this post, I am going to share the details on how I do it: the fun things, the trade-offs, and takeaways.

Background

I started this project called github-langs (site: https://gitstats.wildans.us) back in 2017. It was the very first time for me to get into so-called open-source project. I remember vividly that Hacktoberfest got me into it.

For those who don't know, "Hacktoberfest" was a month-long activity that held by DigitalOcean and GitHub (at least how it was in 2017) where developers around the world try to collaborate each other in the spirit of open-source project: everyone can be anything from maintainer to contributor and users.

And I did become one of them. I created the github-langs project, a web-based application to visualize the language distribution for a given github account. This is how it looked back then (and still is at https://gitstats.wildans.site):

Super simple. You enter a GitHub username and once it's found on GitHub database, it will visualize the language distribution (if an account does have repository with certain language, of course). Some of the features are the following:

Toggle between colorful and white-only color
Download the bar chart
Share to X and Facebook

And that's it.

Goals

I have been meaning to rebuild this project from several years ago. But due to other commitments and stuffs, I haven't really gotten the time to do it. I have some ideas, both for the features as well as technical improvements, but it was just playing around over my head. Haven't really put it into concrete, actionable ideas.

Generative AI

Since this become a thing, I can see that people with limited technical proficiency and knowledge can really build something out of nothing. Then I think; with my "enough" technical knowledge and proficiency, surely I can make that long, sleep ideas come into reality, can't I?

So I give it a shot.

New look

Here is what it looks like now (you can access this via https://gitlingo.app).

Homepage

Account overview

Search result - language distribution

As you can clearly see, there are major overhaul for the functionality and UI/UX. I could say this new version offers simple, intuitive, and "elegant" look.

Journey

Instruction

First and the foremost, this isn't something that can be done with "one-shot" prompt like: "Hey Claude, I want a new version of this new app with the details. Please build me for it."

I was inspired with this project called "whenwords" (https://github.com/dbreunig/whenwords); basically a relative time formatting library that only defines specification and let the AI generate corresponding language-specific implementation. It was quite game-changing.

So I thought I can try it. Not really by creating a spec and then generate multiple github-langs in many different language, but more of how to write a good spec as well as test scenarios so that the output and outcome works as I would expect.

Steps

Weekend 1

As a disclaimer, I already know the "what, why, and somewhat how" to do it so it's easier for me to define this into AI-readable software specification.

So in the first weekend, it was really all about putting my thinkings into well-defined specification. In the beginning, I mainly wrote 2 specs: backend and frontend. From high-level view, here's how they looked like:

# Overview
# Architecture
# Stacks
## Detailed architecture
## Flowchart
# Functional requirement
# Non-functional requirement
# API contracts (only for backend)

And when writing the specification, I was also constantly consulting with ChatGPT to get the best out of it. So essentially, ChatGPT is used as "technical spec consultant" while Claude is mainly for the "coder".

And when working with Claude, here's the visualized workflow:

So by the end of the week (2-day work), I get a pretty good foundation for the backend / APIs.

Weekend 2

The focus was to built an MVP for the frontend to iterate on. Using the same workflow as shared above, the work is more about "give a clear, well-defined feature to be implemented with certain success criteria and test scenario" and less about "build something out of nothing" (which was the goal of the first week). So mainly I just create a couple of task list with some details and check by myself if it's implemented the way I would have wanted it.

Example of the .md task:

## What

Add a segmented control: `Top 10`, `Top 25`, `All`.

## Why

Prevents unreadable charts and makes the UI instantly feel professional.

## How

- Sort languages descending by count (this is already done by the backend)
- If Top 10/25 selected: slice N and sum the rest into `{ name: "Other", count: sum}`
- You can get creative about the color for "Other"
- Apply this to all charts
- Ensure the `10` and `25` are configurable so we can easily change/extend in the future if we want other segment

## Success criteria

- Switching Top-N updates chart instantly
- "Other" appears only when applicable

Conclusion

Overall, this is quite satisfying result. I got really a solid codebase with really production-grade checklist as well as comprehensive tests. In particular, since the backend and frontend are written in TypeScript, I can easily jump between those easily without much of cognitive load or context-switching if they would've been written in different language.

If anyone is interested to take a look at the repo, please head over here: https://github.com/wildan3105/GitLingo.

Next steps

There are many things I want to do. However, 2 areas I want to focus on:

Feature development

GitLingo still in the early "product-market fit" so to say. I'd like to get users trying on and have a say on what's good, what can be improved, what should be removed, etc.

But I also have some ideas around the features to add and things to improve so let's see how things evolve from here.

Workflow adjustment

In terms of workflow, personally, I'd like to code again. Because I believe at the end of the day it's my project, I initiated it and maintain it so I need to know the ins and outs of it.

On the other hand, I can't lie that AI can be super fast and with the right information, can build things the way I would have done it or even better than I could do.

So, let's see!

How to Make an Effective & Efficient Pull Request

Wildan S. Nahar — Fri, 04 Sep 2020 12:16:27 +0000

As a software engineer, our day to day job is to solve problems primarily by coding. Several years ago, we used to use FTP (File Transfer Protocol) to move our local code to the remote server. But that is highly non-practical, not secure, and hard to track the changes. So here comes the version control, a tool that is used to track the code changes (author, file, commit, and timestamp) and to ease the collaboration among software engineers. And the best way to introduce changes using version control is via Pull Request (PR).

Pull request for me is a "discussion platform" where every software engineer can jump in to review the code changes and approve it. But oftentimes, we don't do it in the correct way thus lead to headaches both for the reviewer and pull requester. In this post, I will share my knowledge that I get from experiences when creating a pull request to several repositories within my company.

Why

Before we go into the details, I think it's a good practice to raise the fundamental question:

Why do we need to create an effective and efficient pull request?

That's an interesting question. At first, I believe it's not necessary if we only have a pair of programmers and sit close each other. At this point, we can just ask our partner to review it directly in our local machine or even if we create a pull request, it doesn't need to follow any rules, because our partner must have known what we are doing all the time.

But, what if someday we need to work with hundreds of programmers from different teams across countries and in different timezone? The standard of each team's repository must be different: the branching strategy, the unit tests, the coding guideline, and PR review process itself. So this is when an effective and efficient PR is useful.

The effective and efficient PR consists of a set of basic rules that are meant to be generic, so hopefully, everyone can follow it. This PR approach has some characteristics which are has reasonable-sized, focused, and does not have side-effects. Those are needed to reduce the reviewing time, introduce no bug, and eventually to solve the actual problems.

General Idea

The first thing to notice when creating a pull request is to focus on the goal. What is the goal of the PR? Is it for fixing bug? Is it to introduce new error code? And so on. Once we define the goal, we can make the solution that is implemented in the code (addition/deletion). And the code should reflects that solution. Nothing more. So how can we do that? Here are my tips.

1) Focus to solve the problem
The PR should only do one thing and do it right. Let's say the goal of the PR is to introduce new error code and how to handle it. So the solution to that goal is registering new error code. In addition, unit test to prove the change is working properly and not breaking the current implementation.

For example, here is the simple PR to delete unused deployment files.

In contrast, in this screenshot below shows how the goal is not clearly stated.

2) Code changes should reflect the solution
Sometimes we are too excited to create a PR that does a lot of things. This is totally not a good practice. For instance, in the big feature PR, we also fix typo or translation or formatting. Instead of creating PR that does a lot of things, we can create another small and quick-to-review PR for that specific goal. So the changes are still aligned with the main goal.

An example of clean and straightforward PR.

However, this PR is doing unnecessary changes: extra line.

This type of unnecessary changes can actually be prevented by having a git pre-commit hook. In that hook, we can do formatting such as running a linter tool to standardize the code format (no-console statement, space, comma-dangle, and so on).

3) Create a pull request template

DISCLAIMER

PR template is only available for GitHub (as long as I know), not sure about the other platforms such as GitLab or Bitbucket.

A template could be very useful. With the little effort to create a template (typically with the name PULL_REQUEST_TEMPLATE.md in the root folder in GitHub), it can hugely improve our pull request review process. We can define the goal of the changes, the type of changes, and also the checklist which is a list of the repository's code policy. You can see the example of my team's pull request template below.

At a glance, as a reviewer, we can see the summary of the PR by just looking or screening at the PR description. Even better, a repository that has a built-in PR template provides a consistent and well-structured PR description so if the repository has so many incoming PRs, it won't be a problem for reviewers since there's already a standard for creating a PR description.

4) Follow the proper commit convention
Git commit acts as a short description that reflects the changes we've made to the file(s). Essentially, it should only have one goal and or context (and in my opinion should be stateless). There are many commit conventions out there, but the ones that I trust so far are angular and commitizen. The proper commit message will help the reviewers when they try to search something specific in the PR and want to fully understand what is the requester trying to achieve. But still, the file changes are the source of truth for the review process. Best practice from me is to avoid using a single word for each commit message. Use full sentence instead so the reader won't be confused.

Good, easy-to-read commit messages.

Unclear, incomplete commit messages.

Conclusion

This post is meant to cover the basic understanding on how to create an effective and efficient pull request. It doesn't explain much details as it aims to give the reader the brief principal to create an elegant PR so that the review process can run smoothly and focus on the substantial and significant things. Happy coding!