Forem: André Gardi

AI Integration in JavaScript: Parse Natural Language to JSON with Node + React

André Gardi — Fri, 02 May 2025 14:22:12 +0000

What We’re Building Today

Adding AI to your JavaScript app is easier than you think. We’ll leverage a LLM to read human-written input, but set it to reply into structured JSON. This way, your Node.js backend can easily parse and use the data.

As a practical example, our users describe a family and the App is going to generate a visual representation of the family's tree.

Current LLMs are so good that we can ask something like “Give me the Simpsons family”, it will generate Homer, Margie, Bart, Lisa and Maggie.

It also works with multiple idioms out of the box. Here is a Spanish request:

Elena está casada con Afonso, tienen 3 hijos y 5 nietos.

The prompt

Getting consistent output from an LLM requires thoughtful prompt design. These are the prompt engineering principles I use most often:

Specify the Format We explicitly instruct the LLM to respond in JSON format to ensure our app can parse the output cleanly.
Provide Examples Always include at least two clear examples in your prompt. Edge cases are also welcome, that helps the AI to anticipate instead of getting confuse.
Let the AI Improve Your Prompt Ask the LLM to refine your initial prompt. It often returns a more detailed version. This also helps verify you and the AI are aligned on the task.

Using those principles, I ended up with this prompt.

You are a family tree editor. You will receive instructions to modify a family tree in JSON format. Follow these rules:  

1\. Input format:  
{  
  "userMessage": "instruction to modify the tree",  
  "currentFamily": \[family members\]  
}  

2\. Family member format:  
{  
  "id": number,  
  "name": "string",  
  "gender": "male/female",  
  "mid?": mother\_id,  
  "fid?": father\_id,  
}  

3\. Processing rules:  
\- "mid" indicates mother's ID  
\- "fid" indicates father's ID  
\- For new members without names, generate realistic names  
\- Handle complex relationships (same parents can have multiple children, parents can have children with different partners)  
\- If any mentioned person doesn't exist, create them with appropriate relationships  
\- Assign new IDs sequentially (next available number)  

4\. Output rules:  
\- Return ONLY the updated JSON array of family members  
\- No explanations, commentary, or non-JSON text  
\- Maintain consistent JSON formatting  
\- Include all existing members plus new/changed ones  

Example input 1:  
{  
  "userMessage": "Add a son to Ava",  
  "currentFamily": \[  
    { "id": 1, "name": "Amber McKenzie", "gender": "female" },  
    { "id": 2, "name": "Ava Field", "gender": "male" },  
    { "id": 3, "mid": 1, "fid": 2, "name": "Peter Stevens", "gender": "male" }  
  \]  
}  

Example output 1:  
\[  
  { "id": 1, "name": "Amber McKenzie", "gender": "female" },  
  { "id": 2, "name": "Ava Field", "gender": "male" },  
  { "id": 3, "mid": 1, "fid": 2, "name": "Peter Stevens", "gender": "male" },  
  { "id": 4, "fid": 2, "name": "James Field", "gender": "male" }  
\]  

Example input 2:  
{  
  "userMessage": "Peter has a brother that is son of Mario",  
  "currentFamily": \[  
    { "id": 1, "name": "Amber McKenzie", "gender": "female" },  
    { "id": 2, "name": "Ava Field", "gender": "male" },  
    { "id": 3, "mid": 1, "name": "Peter Stevens", "gender": "male" }  
  \]  
}  

Example output 2:  
\[  
  { "id": 1, "name": "Amber McKenzie", "gender": "female" },  
  { "id": 2, "name": "Ava Field", "gender": "male" },  
  { "id": 3, "mid": 1, "name": "Peter Stevens", "gender": "male" },  
  { "id": 4, "name": "Mario", "gender": "male" },  
  { "id": 5, "mid": 1, "fid": 4, "name": "Michael", "gender": "male" }  
\]

Choosing a Cost-Effective Model

AI services like OpenAI offer different models — some are super smart but expensive, others are simpler but much cheaper. You often don’t need the most powerful option.

For our family tree app, I tested a few models and found that "gpt-4.1-mini" is good enough, even being a lightweight version. You should try your prompt on different models and pick a cost-effective one, when possible.

Connecting to the LLM

This is just an API call in which you will send the prompt, model and API key. OpenAI provides an npm package that wraps the request, so I am using it.

const OpenAI = require('openai');  
const { instructions } = require('./instructions');  

const client = new OpenAI({  
    apiKey: process.env.OPENAI\_API\_KEY,  
});  

async function callOpenAI(userMessage, familyData) {  
    console.log(instructions);  
    const response = await client.responses.create({  
        model: 'gpt-4.1-mini',  
        input: \`  
            {  
                "userMessage": "${userMessage}",  
                "currentFamily": ${JSON.stringify(familyData)}  
            }  
        \`,  
        instructions: instructions  
    });  
    familyData = JSON.parse(response.output\_text);  
    return response.output\_text;  
}  

module.exports = { callOpenAI };

To avoid having the API key on client side, I coded this block on a Node backend app and used dotenv to inject my key to process object.

The prompt I described before, was saved on a separated file that we are importing as instructions. The userMessage is the "prompt" the user actually typed on the form. The real prompt sent to LLM is a long text messaged composed by all this elements and the current family data.

With that set, we can import callOpenAI on a controller. I am using express to manage the API endpoint.

const { callOpenAI } = require('../services/open-ai');  

const handleOpenAiRequest = async (req, res) => {  
    try {  
        const { prompt, familyData } = req.body;  

        if (!prompt) {  
            return res.status(400).json({ error: 'Prompt is required' });  
        }  

        if (!familyData) {  
            return res.status(400).json({ error: 'Family data is required' });  
        }  

        const response = await callOpenAI(prompt, familyData);  
        res.json({ response });  
    } catch (error) {  
        console.error('Error processing OpenAI request:', error);  
        res.status(500).json({ error: 'An error occurred while processing your request' });  
    }  
};  

module.exports = { handleOpenAiRequest };

Client side

On the front-end I started a blank project with create-react-app. I added FamilyTreeJS for visual representation. For getting the updated family tree from our Node API, I did a simple fetch POST requesting sending the user message on the body. You can check the detailed implementation on the github repo bellow.

Github repo

https://github.com/andregardi/llm-json

Using Test-Driven Development to Get Better AI-Generated Code

André Gardi — Mon, 21 Apr 2025 14:26:23 +0000

This is not a vibe coding tutorial. But most developers agree that AI writes better code when you give it clear instructions. Well written tests naturally include these clear details about what the code should do.

This got me thinking — maybe test-driven development is actually a more reasonable way to use AI for coding? I decided to try it myself and see how it worked.

TDD Basics

You don’t need to master TDD to understand the next steps. Just understand the basic cycle: write a failing test (Red), make it pass (Green), then improve the code (Refactor). That’s enough to start.

Environment

We’ll write our code in JavaScript, but the principles apply to any language. We’re using Cursor AI as our editor, but other tools like Windsurf should give similar results.

Exercise 1

Let’s begin with a simple Fizz Buzz. I set up a minimal Node.js app with vanilla JavaScript and added Jest for testing. I wrote some tests — but intentionally avoided using the words ‘Fizz’ or ‘Buzz’ anywhere.

const { myFunction } = require('./index');

describe('myFunction', () => {
    it('should return the number itself', () => {
        const result = myFunction(49);
        expect(result).toBe(49);
    });
    it('should return pine on multiples of 3', () => {
        const result = myFunction(9);
        expect(result).toBe('pine');
    });
    it('should return apple on multiples of 5', () => {
        const result = myFunction(10);
        expect(result).toBe('apple');
    });
    it('should return pineapple on multiples of 15', () => {
        const result = myFunction(15);
        expect(result).toBe('pineapple');
    });
});

Then I gave a very simple prompt:

On exercise-1 folder update index.js based on the tests

The result:

export function myFunction (num) {
  if (num % 15 === 0) return 'pineapple';
  if (num % 3 === 0) return 'pine';
  if (num % 5 === 0) return 'apple';
  return num;
}

Now we can add tests for features we did not implement yet.

    it('should greet on string input', () => {
        const result = myFunction('Joe');
        expect(result).toBe('Hello Joe');
    });
    it('should return the number itself on strings that contains a number', () => {
        const result = myFunction('forty-nine');
        expect(result).toBe(49);
    });
    it('should return the number itself on strings that contains a number with space and case insensitive', () => {
        const result = myFunction('Forty nine');
        expect(result).toBe(49);
    });
    it('should return pine on strings that contains numbers multiples of 3', () => {
        const result = myFunction('Nine');
        expect(result).toBe('pine');
    });
    it('should return apple on strings that contains numbers multiples of 5', () => {
        const result = myFunction('ten');
        expect(result).toBe('apple');
    });
    it('should return pine on strings that contains numbers multiples of 15', () => {
        const result = myFunction('fifteen');
        expect(result).toBe('pineapple');
    });

Again I prompted the AI to update the index.js. But the new code was converting the strings to numbers with a limited hardcoded object:

   const numberWords = {
     'one': 1, 'two': 2, 'three': 3, 'four': 4, 'five': 5,
     'six': 6, 'seven': 7, 'eight': 8, 'nine': 9, 'ten': 10,
     'eleven': 11, 'twelve': 12, 'thirteen': 13, 'fourteen': 14, 'fifteen': 15,
     'forty-nine': 49, 'forty nine': 49
   };

To improve the code I asked:

Using the numberWords object is not a good way to convert. Would a third-party lib make a better job converting the string into numbers?

The agent installed the words-to-numbers package resulting in the following index.js:

const wordsToNumbers = require('words-to-numbers').wordsToNumbers;

function myFunction(input) {
 // If input is a string
 if (typeof input === 'string') {
   // Try to convert string to number using the library
   const possibleNumber = wordsToNumbers(input);

   // If conversion was successful and result is a number
   if (typeof possibleNumber === 'number') {
     // Apply the same logic as numbers
     if (possibleNumber % 15 === 0) return 'pineapple';
     if (possibleNumber % 3 === 0) return 'pine';
     if (possibleNumber % 5 === 0) return 'apple';
     return possibleNumber;
   }

   // If not a number word, return greeting
   return `Hello ${input}`;
 }
  // If input is a number, apply the original logic
 if (input % 15 === 0) return 'pineapple';
 if (input % 3 === 0) return 'pine';
 if (input % 5 === 0) return 'apple';
 return input;
}

Code was working, but it could be improved. The Fizz Buzz logic was duplicated. Something satisfying to work with tests, is that I can ask AI for refactors on index.js knowing that any broken feature would be caught by index.test.js on terminal.

I asked a final prompt:

Extracting the numbers logic into a separate function would improve code readability and maintainability.

const wordsToNumbers = require('words-to-numbers').wordsToNumbers;

function processNumber(number) {
  if (number % 15 === 0) return 'pineapple';
  if (number % 3 === 0) return 'pine';
  if (number % 5 === 0) return 'apple';
  return number;
}

function myFunction(input) {
  // If input is a string
  if (typeof input === 'string') {
    // Try to convert string to number using the library
    const possibleNumber = wordsToNumbers(input);

    // If conversion was successful and result is a number
    if (typeof possibleNumber === 'number') {
      // Apply the same logic as numbers
      return processNumber(possibleNumber);
    }

    // If not a number word, return greeting
    return `Hello ${input}`;
  }

  // If input is a number, apply the original logic
  return processNumber(input);
}

module.exports = { myFunction };

All tests passed:

Exercise 2

Fizz Buzz was easy to test. I wanted to see if the same approach would work in a real-world scenario. So I applied the same testing principles to a React application, this time including an HTTP request.

I used create-react-app and removed the boilerplate to start a blank application. The goal is to search a user with https://api.github.com/users/ and present the result.

I added tests to App.test.js that cover the following:

Signals that “Github search” is readable from begin.
Mocks fetch.
Reads User Name from an input.
Clicks on the search button.
Requests the API with the User Name as parameter.
Reads “Loading…”.
Handles both success and failure scenarios.

Then I prompted:

Based on App.test.js update App.js as a React clean code expert.

This was the resulting App.js. Being honest, I did not expect it to work on the first try. But that is the result I got out of the box:

The component’s logic works perfectly, but styling isn’t easily testable in unit tests. I decided to try asking the AI to improve the style and make it look like the actual Github page.

Prompt Engineering Tip: Before using a prompt, ask AI to refine it for better results.

Before:

You are a great designer. Make this look great! Using @https://github.com/ aesthetics is welcome. But keep it minimal. Centralize and space elements, meaning to fill more of the screen. Replacing the Loading text with a loading icon is welcome.

After:

Transform this component into a visually polished design while preserving its core functionality. Key requirements:

Aesthetic Approach:

Adopt GitHub’s clean, minimal design language (@https://github.com/)

Maintain functional simplicity while elevating visual appeal

Layout Principles:

Center all elements vertically and horizontally

Maximize screen real estate usage with balanced spacing

Create clear visual hierarchy

Specific Enhancements:

Replace “Loading…” text with a subtle animated spinner/icon

Use GitHub-inspired typography and color palette

Implement smooth state transitions

Constraints:

Don’t alter the core data-fetching logic

Keep the component structure fundamentally the same

Maintain all existing functionality

The result should feel like a native GitHub UI element — professional, understated, and highly functional.

The result was actually very good:

GitHub Repository

Code for both exercises is available on GitHub. Check the individual commits if you want to compare code between each step applied.

GitHub - andregardi/tdd-ai: Using Test-Driven Development to Get Better AI-Generated Code