DEV Community: Muhammad Refel Hidayatullah

Vibe Coding Tools - Vibespecs CLI

Muhammad Refel Hidayatullah — Fri, 31 Oct 2025 03:00:58 +0000

The Era of Generative Coding — and Why I Finally Gave In

I’ve never been a big fan of what people now call vibe coding.
To me, coding has always been about clarity, structure, and intent — not just getting something to work because an AI said so.

But here’s the thing: in tech, if you don’t evolve, you get left behind.
That’s just natural selection in motion.

So instead of resisting the wave, I decided to understand it.
I started exploring how AI can be used not just as a helper, but as a collaborator in building better systems.

And that’s how I found myself deep in the world of AI Generative Code — or, as people casually call it today, vibe coding.

A CLI for Machine-Friendly Specs

One of the biggest challenges I’ve noticed when working with AI tools is communication.
Machines don’t “understand” code the way humans do — they interpret patterns, context, and structure.

So, I started building a CLI tool that can generate machine-readable specs, designed to help both developers and AI models speak the same language.

This CLI integrates with multiple AI providers to generate consistent and detailed specification documents.
Think of it as a translator — it turns human intent into structured instructions that AI can process effectively.

The goal isn’t to replace developers.
It’s to make sure that when we code with AI, the results are predictable, explainable, and high-quality.

Output support JSON, YAML & TOON (Token Object Oriented Notation)

More About Toon

Features

Hybrid Processing: Combines heuristic parsing with AI refinement for optimal accuracy and speed
Interactive Wizard Mode: Guided interactive refinement when AI is unavailable
Multiple AI Providers: Supports OpenAI, Anthropic Claude, OpenRouter, and GLM (ZhipuAI)
Intelligent Caching: LRU cache minimizes redundant API calls
Flexible Configuration: Environment variables, .env files, and config files
Validation: Built-in spec validation against schema
Multiple Formats: Output to JSON, YAML, or TOON (Token-Oriented Object Notation)

We’re now entering an era where how we write code matters less than how well we can describe it.
If we can teach the machine to understand our intent — that’s where true collaboration begins.

Learn More About Installation & Usage Here

HttpOnly Cookies: A Secure Solution for Sensitive Data

Muhammad Refel Hidayatullah — Mon, 03 Feb 2025 10:40:56 +0000

Throughout my 5-year career in frontend development, almost every application I built utilized JWT Tokens. Typically, these tokens were stored in the browser’s storage, such as localStorage or sessionStorage. Initially, I felt comfortable with this method due to its simplicity and convenience, and many articles also used localStorage or sessionStorage as the standard example.

However, as I gained a deeper understanding of hacker tactics, I began to question the security of using localStorage, especially for sensitive data. This led me to explore HttpOnly Cookies, which turned out to be the best solution for securely storing JWT Tokens.

HTTPOnly cookies are cookies that have the HTTPOnly attribute, which prevents client-side scripts from accessing the data stored in the cookie.

Why should we implement HttpOnly Cookies?

1. Protection against XSS (Cross-Site Scripting):
HttpOnly Cookies cannot be accessed via JavaScript, providing better security against XSS attacks.
2. Automatic management by the browser: Cookies are automatically sent with every HTTP request to the appropriate domain, reducing implementation complexity.
3. Effortless for frontend developers: Frontend developers no longer need to manage JWT Tokens or store them in the browser’s storage, reducing the client-side security management burden.
4. Security attribute settings: Attributes such as Secure, SameSite, and HttpOnly strengthen data protection by restricting how data can be accessed and transmitted.

Client -> Server: Login Request The client sends a login request containing the username and password to the server.
Server -> AuthService: Validate credentials The server forwards the credentials (username and password) to the authentication service for validation.
AuthService -> DB: Query user by username The authentication service queries the database to retrieve the user record based on the provided username.
DB → AuthService: Return user record The database returns the user record (e.g., hashed password, role, etc.).
AuthService -> Server: Return user authentication status The authentication service returns the authentication status to the server (valid or invalid).
Server -> JWTValidator: Generate JWT If the credentials are valid, the server requests the JWT Validator to generate a JWT based on the user’s data.
JWTValidator → Server: Return JWT The JWT Validator generates and returns the JWT to the server.
Server -> Client: Set HttpOnly Cookie with JWT The server sends the JWT to the client as an HttpOnly cookie, which is stored in the browser.
Client -> Server: Authenticated Request The client sends an authenticated request to the server, automatically including the HttpOnly cookie with the JWT.
Server -> JWTValidator: Validate JWT from Cookie The server sends the JWT from the cookie to the JWT Validator for validation.
JWTValidator → Server: Return JWT validation status The JWT Validator checks the token’s validity. If valid, the request is processed; otherwise, a 401 Unauthorized response is sent to the client.
alt Valid JWT If the JWT is valid, the server processes the request (e.g., fetching data or resource) and returns the response to the client.
else Invalid JWT If the JWT is invalid, the server responds with a 401 Unauthorized status.

Conclusions

By implementing HttpOnly Cookies, we can enhance the security of our website and protect users from potential attacks, particularly those related to XSS. I hope this article provides valuable insights. If you have any suggestions or more practical approaches, feel free to discuss them with me. Keep learning and stay curious!

PoC

Summary of TDD that I tried to learn

Muhammad Refel Hidayatullah — Mon, 27 Jan 2025 14:40:53 +0000

1. The Cycle of TDD

- Write a Test First

Before writing implementation code, write a test that specifies how the code should behave. This test will typically fail at first because the code hasn't been implemented yet.

- Write Just Enough Code

Write only the code necessary to make the test pass. Do not add features beyond the scope of the test.

- Refactor

Once the test passes, refactor the code to improve its quality without changing its functionality.

2. TDD Mindset

- Start with Failure (Fail First):

Get used to writing tests for features that do not yet exist. This requires discipline and the mindset that "failure is normal" at the beginning of the process.

- Small, Focused, and Iterative

Avoid trying to implement large features all at once. TDD encourages breaking work into small parts and focusing on one thing at a time.

- Design by Tests

TDD is not just about writing tests; it's also about design. Writing tests before code forces you to think about the best way to design APIs or functions to make them easy to test.

3. Testing Approaches in TDD

- Unit Test

Focus on the smallest unit of code, typically a function or class.

Ensure tests are deterministic (the same result every time they run).
Use mocking or stubbing to isolate external dependencies.

- Integration Test

Test interactions between multiple units.

Ensure modules work well together.
Focus on data flow between components.

- End-to-End (E2E) Test

Test the entire system from the user's perspective.

Use this only for key features, as these tests are time-consuming.

4. Strategies to Avoid TDD Failures

Write Accurate Tests

Don't just test the "happy path." Write tests for edge cases or error scenarios:

Zero values (0)
Empty strings
Invalid inputs (e.g., null or undefined)

- Use Coverage Reports

Ensure your code is thoroughly tested. Use tools like Istanbul, Jest, or SonarQube to check test coverage.

- Manage Dependencies

Avoid tight coupling between modules. Use techniques like:

Mocking to replace dependencies with fake versions.
Inversion of Control (IoC) or dependency injection to make components easier to test.

5. Organizing Tests

a. Clear Test Structure

Use the Arrange-Act-Assert (AAA) format:

Arrange: Set up all data, dependencies, or initial conditions.
Act: Call the function or perform the action you want to test.
Assert: Verify that the result matches the expected outcome.

b. Use Descriptive Naming

Test names should be clear and explain what is being tested.

c. Organize Test Folders

Keep tests in a well-organized folder structure.

6. Design Principles for TDD

a. Single Responsibility Principle (SRP)

Ensure functions or classes have only one responsibility, making them easier to test.

b. Open/Closed Principle

Design components to be extensible without modifying existing code.

c. Dependency Injection

Avoid creating direct dependencies inside a class. Instead, inject dependencies from the outside.

7. Advanced Concepts in TDD

a. Test Doubles

Mock: Replace real objects with fake ones to control behavior and verify interactions.
Stub: Provide fake responses for a function.
Spy: Track how a function is called.

b. Behavior-Driven Development (BDD)

An advanced form of TDD, where tests are written in a human-readable language, often using frameworks like Cucumber.

Scenario: Adding two numbers
Given I have numbers 2 and 3
When I sum the numbers
Then the result should be 5

8. Advanced Tips

1. Outside-In Development (London School TDD)

Approach: Start with high-level tests like integration or acceptance tests before moving to unit testing.

Main Principle: Focus on behavior rather than implementation. Develop the system based on how components should interact.

Example:

Start with testing an API endpoint (e.g., REST or GraphQL), then move to the service, repository, and class-level implementation.

Benefits:

Avoid over-engineering by ensuring only necessary code is written.
Focus on functional outcomes.

2. Mutation Testing

Concept: Evaluate test quality by introducing small changes (mutations) in the source code and checking if tests catch those changes.

If tests don't fail after a mutation, it indicates a lack of coverage or precision.

Tools:

JavaScript: Stryker
Java: Pitest

Benefits:

Measure how robust your tests are against code changes.
Identify high-risk areas for bugs.

3. Mocking and Stubbing Best Practices

When testing components that depend on external services or APIs, use mocking and stubbing.

General Principles:

Use mocks to verify interactions (e.g., whether a method was called).
Use stubs to provide fixed responses (dummy data) from dependencies.

4. Property-Based Testing

Concept: Instead of testing specific cases, define general properties or rules that must always hold true.

Example: "The result of merging two arrays must always equal the combined length of both arrays."

Tools:

JavaScript: Fast-check

Benefits:

Discover hidden bugs by testing many input combinations.
Ideal for complex algorithms like sorting or encryption.

5. Golden Master Testing

Concept: Used for legacy systems or complex code without prior documentation or tests.

Take a snapshot of the current behavior or output (golden master) and use it as a baseline for future tests.

Benefits:

Enables refactoring of old systems without breaking functionality.
Highly effective for large or monolithic systems.

6. Contract Testing

Concept: Ensure that the contract between two services, such as an API and its consumer, is not broken.

Tools:

Pact (for API contract testing).

Benefits:

Increases confidence when making changes or iterating on dependent services.
Reduces integration risks.

7. Exploratory Testing with TDD

Approach: Combine TDD principles with manual exploration for new features or experimental algorithms.

Method:

Write initial tests to "lock in" known behavior.
Use additional tests to explore how the code reacts to new inputs or scenarios.

Benefits:

Uncover edge cases that might have been missed.
Accelerate validation of new functionality.

8. Delayed Implementation

For cases where a feature or function cannot yet be implemented (e.g., due to unfinished dependencies), use a test placeholder.

describe('New Feature', () => {
  it('should handle specific edge case (TODO: implement)', () => {
    // Tes sementara
    expect(true).toBe(true); 
  });
});

Benefits:

Reminds the team to complete pending parts.
Breaks work into manageable steps.

9. Working with Legacy Code

If legacy code lacks tests:

Add Characterization Tests to "lock in" current behavior.
Write tests for small parts of the code you plan to modify.
Gradually refactor while ensuring tests pass.

Benefits:

Introduces TDD into systems that were not initially designed for it.
Reduces refactoring risks in legacy systems.

Code commit best practice with commitizen & pre-commit

Muhammad Refel Hidayatullah — Thu, 24 Aug 2023 10:26:01 +0000

In this opportunity, I will share about Git hooks, Commitizen, and ESLint for linting. Coincidentally, on this occasion, I will be using Angular projects.

Let's say we already have Angular projects. And then, you need to install several dependencies.

Step 1

npm i -D husky eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

STEP 2
You need to setup husky in your project with run this command

npx husky install

That command will generate the .husky/pre-commit file. pre-commit file will look like this.

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npm run test

STEP 3
Setup commitizen for template commit message. This is a beautiful feature to organize commit messages, especially when working with a fairly large team. For setup commitizen you need to run this command:

npm i commitizen

and add this on your package.json

"config": {
    "commitizen": {
      "path": "cz-conventional-changelog",
      "jiraOptional": true
    }
  }

This isn't finished yet, you need to run the following script.

npx husky add .husky/prepare-commit-msg "exec < /dev/tty && git cz --hook || true"

If successful, it will create a new file inside the .husky/prepare-commit-msg folder. You can test this by running the commit with empty message:

git commit -am ""

and choose one of the options. in this case i will choose feature

next, you need to fill scope of changes.

next, you need to fill short description about changes

and then, they provide for longer description. For this input, it's optional, you can leave it empty.

And next, they ask whether there are any breaking changes or if there will be any other open issues. If you choose 'y', they will ask for your explanation.

commit message on gitlab will look like this:

It appears tidy and easy to understand for documentation or your code reviewer.

Conclusion

This feature is very helpful for describing what you're doing with code changes and greatly assists code reviewers.
for Linter git hooks / pre commit will posted at next article.