DEV Community: Jessica Cecilia Budianto

Ran out of idea for AI product, so I talked to Gemini

Jessica Cecilia Budianto — Sun, 29 Jun 2025 07:35:57 +0000

As the title suggests, this is a story of how talking to an AI helped me come up with a unique product idea with AI — one that might be different from what people usually create. What you’ll get here is my insight on AI integration into websites that actually can be developed into real tech products. I have 2 versions of websites that I’ll show here: one that’s code is open to the public and one that I might plan to develop further. So pardon if I don’t share the code for the latter 😆

Warning: since this is a story, expect this article to be long.

During preparation for BWAI I was confused on what kind of material I wanted to present. I wanted to do something different, as I didn’t want to talk about something like how to integrate Gemini into your web. I wanted to talk about use cases instead, but couldn’t come up with an idea. Then I discussed with Gemini what I should talk about, and Gemini advised me to use AI to improve user experience.

Then it struck me that generally when people incorporate AI into their code (disclaimer: not everyone’s like this. But even back then when I was asked to create something with AI, I did this too) there can be a tendency to make it too… grandish.

Often, projects are built around showcasing AI itself — instead of using AI to solve a real, everyday problem. Think of license plate recognition or live sign language translators. Impressive? Definitely.

But let’s think of it as if we try to make it as a real business, where what matters the most is sustainability. The budget and the infrastructure can be very challenging. And in the society that is still trying to get used to adopting technology into their daily life, they can be skeptical even more to invest heavily.

Disclaimer: I don’t want to demotivate people to freely explore what they can do with AI. But I’m also aware that some people or communities, they inadvertently “set the bar” that tech products with AI should be cool and look futuristic. And I’m afraid that this is what actually demotivates people to explore AI for a product that’s simpler but actually closer to what the market actually needs.

But anyway, back with my convo with Gemini again. So this was what crossed my mind: what if we try to combine AI with form, like a form assistant? And now maybe some of you wonder: why form?

As a web developer, I realized form is one of the most common kinds of UI that tends to have UX issues. Let’s be honest — filling out forms is boring. Especially when they’re long, unclear, or asking for too much. At some point, we might even blanking out and autopilot filling it. AI these days will definitely beat us in filling these forms if they have our knowledge 😂.

Then I brainstormed with my friend about what kind of form that might require an assistant to fill it. What crossed my mind at first was the tax reporting form, but my friend pointed out that this wasn’t very relatable for students if I wanted to present this in a university. Then we came up with a CV consultant web idea.

I created my very first CV in a career class, preparing to apply for an internship. Since we have never written a CV before, we were shown an example of how a CV looks like. Does this experience sound familiar? When we don’t know what to write on your CV or we don’t consider ourselves good with words, we resort to imitating the stereotype of a successful person's CV. Or now there are lots of CV creator websites which can help us with this.

People think that this is just the issue of fresh graduates, but even now my CV summary still sounds... dry. The reason? It’s not that I don’t know who I am — I just don’t know how to say it right. And I don’t want it to sound sugarcoated too — think this is obvious by how I write this article. So I play it safe even though my description sounds really dry.

But let’s think about it from a hiring perspective. If we want to hire someone for a particular position and there are lots of applicants, we can’t hire everyone right? As someone who will work with this new person, we prefer someone who isn’t just capable in doing their job but also is nice to collaborate with. And from the whole company perspective, we want this new person to bring value to the business. And this can be difficult right if everyone’s CV sounds the same?

So it’s expected for HR to look for the one (people can complain that the one that is chosen not because they’re capable but because they have a connection inside the company but since this is not always the case and a completely different matter, let’s rule this out first). So much like dating huh? And just like in dating — it’s difficult.

There’s an influencer’s tweet that I found even mentioning about a lot of rubbish-like CVs submitted into a company and how difficult it is to find the one. His words can be triggering but I think there’s a silver lining in it.

So, my idea is to create a CV creator website, with a ‘consultant’ inside it that’s powered by Gemini. Hopefully, this ‘consultant’ can help users make their CV more personalized. Because rather than just beautify the content of the CV that the user gives, users can actually consult on how to deliver their message through their CV. The complete open source repo can be found in this repository.

Very first thing I did, I integrated Gemini in my code. I generated the key in Google Cloud API Credentials. I rarely generate key in Google Cloud, and when I did this I had to admit Google is really practical in generating API keys that can easily be used for any API; doesn’t have to be specific only for Gemini use.

Here I didn’t just train Gemini to be a CV consultant, but also to return the answer in HTML format so that I can display it nicely later.

Next I developed the chat. I have never developed a chat product before, so I just developed this based on my interpretation of what's needed in a chat. These are the 3 parts that I initially developed for my chat.

Explanations:
The onSend was initially just a console log. I completed this later in the development
Since the chat with AI is normally just a 1o1 question - answer, I used this format in as a structure for chatHistory
Typically typedQuestion isn’t necessarily to be stored as a state right? When I trigger the onSend, I can just get the value of the target event. But I stored it as a state because I planned to do some magic 🔮

Next on I developed the CV creator part. I keep it super simple with only a single card form component that’s used to fill the Summary of the CV, as this is the one that I will simulate later. There are 2 parts of this component.

Explanations:
Clicking on the inner part is of course to fill in the summary of the CV. Need to be careful not to click the outer part.
The outer part? Let me show it. Let’s say after I write something in the inner part, I click the outer part

Pretty cool right? 😆Fellow coders may say that this is not rocket science. Doesn’t matter, I loved building it. But this is the reason why I stored the typedQuestion as a state.

Finally I added the processing in the onSend. You can check it on the code later. Here is the full flow of the open sourced website. Or you can check it on your own here.

During the development, I realized there is a lot of potential for this website. For example the stored chat history can be exposed to the HR, though for the implementation I know there can be a privacy T&C or something that the users need to agree with. My idea is that maybe by exposing the chat, the HR can get more insights from the candidate aside from their CV.

To end my story, let me show you a slightly more polished version I’ve built. Hope you got some ideas (or at least a smile) from reading this. My approach isn’t the way — just a way. And maybe it’ll spark ✨ something better in you..

React: should state live in parents?

Jessica Cecilia Budianto — Tue, 21 Nov 2023 18:07:37 +0000

(With that cliche sound of N*tfl*x series opening) Previously in my writing...

Yea yea I wrote about Virtual DOM, but that's not what I meant. What I will write today is related with what I wrote in Component Scoping in my previous article. If you haven't read it or in case you forgot already, you can check it here (and boost my views too 😌).

React: how I understand Virtual DOM through useState

Jessica Cecilia Budianto ・ Oct 11

#beginners #react #javascript #webdev

Initial experiment: compare the state change in parent and child
Second experiment: profile the re-render
So, what's the verdict and what's next?
Further Readings

Initial experiment: compare the state change in parent and child

So actually, I have been playing around with useState, doing some tiny experiments. My previous article was actually one of the insights I got from these experiments, and I decided to correlate it with my understanding about Virtual DOM. So now you know that I didn't just understand Virtual DOM last month ✌️

Last time, I placed the state in the Child component. This time, I tried to centralize all states in parent instead. To give you the big picture , here is how the App looks like.

import { useState } from 'react';
import Child from './Child';
import Title from './Title';
import Button from './Button';

export default function App() {
  const [shown, setShown] = useState(false);
  const [shown2, setShown2] = useState(false);

  return (
    <div>
        <Title/>
        <Child order={1} shown={shown} />
        <Child order={2} shown={shown2} />
        <Button order={1} onClick={() => setShown(prev => !prev)}/>
        <Button order={2} onClick={() => setShown2(prev => !prev)}/>
    </div>
  );
}

Now let's start to visit the components one by one.

export default function Title() {
    console.log('Rendering title');
    return <h1>TITLE HERE</h1>
}

Yea very simple right for Title? Just a mere heading and a console.log to inform when this component is rendered.

import { useState } from "react";

export default function Child ({ order, shown }) {
    const [count, setCount] = useState(0);

    console.log('Render child', order)

    return (
        <div onClick={() => setCount(prev => prev + 1)}>
            CHILD {order} {String(shown)} count {count}
        </div>
    )
}

The Child component receives 2 props:

order as the identifier of the component
shown as the state that will be changed from its parent

Aside from the passed props, I also add a local state count for comparison later.

export default function Button ({ order, onClick }) {
    console.log('Render button', order)
    return <button onClick={onClick}>BUTTON {order}</button>
}

Lastly there's also this Button component with passed onClick which will trigger the change in Child, another order as identifier, and console.log.

Now let's see the result here.

It's expected right that Child 1 is re-rendered? Since it accepts props from its parent and the value changes, of course the component will be re-rendered

What about Button 1? Sure it's clicked to trigger change in Child 1 and it accepts props too. But the value doesn't change right, so is it expected?

What about Child 2 and Button 2 also accept props but the value don't even change. Are they expected to get re-rendered too?

And the weirdest one is for Title which doesn't accept any props from its parent, yet it still gets re-rendered.

Now what about the state that only exists in Child component? Since its parent doesn't aware of their existence, the parent should not get re-rendered right?

And yep only the Child itself that is re-rendered. In fact this is already spoiled in my previous article 😂 or to quote it again:

By separating Child component from App, it is only normal if the state change in Child will only re-render Child right? After all only Child knows the existence of count state. And yes it is.

I have heard a saying that props/state change is the one that causes re-render. Not wrong, of course, but there seems to be a caveat.

Sure, props/state change triggers re-render, but it seems not to be the only reason. In fact, the parent component re-render will also re-render its children.

I know some of you will be like:
🗣️ That's why you should pay attention to the documentation

And does it exist in React documentation? Yes, it does. I don't know if you guys can find the more specific statement about this somewhere in the docs, but here is the one I found in useState caveats

useState – React

react.dev

I know that there are a lot of optimization done by React like memoization, but it seems that re-rendering its children after props / state change is remain the component default behavior.

And this actually leads us to one of the most famous performance-related questions:

Is re-render a bad thing?

Second experiment: profile the re-render

In general, labeling something as 'good' or 'bad' is subjective, right? Something that's considered 'good' can be considered 'bad' instead by others, depends on circumstances and preferences. Just like instant noodle that's not healthy, but healthier for your budget 🍜

Goodness how random I am 🤣 but what I'm saying is, we can't judge anything without 'proof'. Only after we prove it, we can take decision whether to improve it or let it slide for higher priorities.

So let's start by separating the code in App into component called Parent as shown below.

import { useState } from 'react';
import Child from './Child';
import Title from './Title';
import Button from './Button';

export default function Parent() {
  const [shown, setShown] = useState(false);
  const [shown2, setShown2] = useState(false);
  const [count, setCount] = useState(0);

  return (
    <div>
        <Title/>
        <Child
            order={1}
            shown={shown}
            count={count}
            setCount={setCount}
        />
        <Child order={2} shown={shown2} />
        <Button order={1} onClick={() => setShown(prev => !prev)}/>
        <Button order={2} onClick={() => setShown2(prev => !prev)}/>
    </div>
  );
}

Doesn't look exactly the same like before right? I deliberately put out the count state into Parent and pass them to Child 1. I also adjusted the Child component as shown below.

export default function Child ({
    order,
    shown,
    count = 0,
    setCount = () => {}
}) {
    console.log('Render child', order)

    return (
        <div onClick={() => setCount(prev => prev + 1)}>
            CHILD {order} {String(shown)} count {count}
        </div>
    )
}

Now for the App, aside from importing the Parent I wrap it with Profiler component which is used to measure the rendering performance. Don't worry if you have never heard of this, you can check the documentation later attached at the end of this article. You'll see how this works after this.

import { Profiler } from "react";
import Parent from "./Parent";

export default function App() {
  const handleRender = (
    _id,
    phase,
    actualDuration,
    baseDuration
  ) => {
    console.log(
      'RERENDERING',
      phase,
      'ACTUAL',
      actualDuration,
      'BASE',
      baseDuration
    );
  }

  return (
    <Profiler id="Parent" onRender={handleRender}>
      <Parent/>
    </Profiler>
  );
}

To give you a brief explanation of parameters in onRender:

phase indicates whether the component is just mounted or there has been state change either in the component or its children
actualDuration is, to make it short, how long the whole wrapped component is rendered.
baseDuration is the one that I bet all of you gets confused with actualDuration 😂 same guys same. Now this one is the estimation how long the component will get rendered.

Oh and also, please ignore the console.log that is printed twice per component re-render. The component is still only gets rendered once per re-render. This is how it looks like.

Either clicking on Child 1 or Button 1 trigger the re-render for the whole components. On mounted it already takes 8ms, longer than estimated 5.5ms to render the whole components. The re-render takes shorter time (1 - 3ms) than the initial render as mentioned in React Profiler documentation.

Now let's put back the count state into the Child again. To avoid confusion, here is how Parent component become.

import { useState } from 'react';
import Child from './Child';
import Title from './Title';
import Button from './Button';

export default function Parent() {
  const [shown, setShown] = useState(false);
  const [shown2, setShown2] = useState(false);

  return (
    <div>
        <Title/>
        <Child order={1} shown={shown} />
        <Child order={2} shown={shown2} />
        <Button order={1} onClick={() => setShown(prev => !prev)}/>
        <Button order={2} onClick={() => setShown2(prev => !prev)}/>
    </div>
  );
}

And the Child component looks like this again.

import { useState } from "react";

export default function Child ({ order, shown }) {
    const [count, setCount] = useState(0);

    console.log('Render child', order)

    return (
        <div onClick={() => setCount(prev => prev + 1)}>
            CHILD {order} {String(shown)} count {count}
        </div>
    )
}

And here is the result.

It takes 7.3ms to perform the initial render for the whole components, but I don't think we can consider the 0.7ms difference is the improvement effect since it's still a small difference. This can be biased by the cache and stuffs anyway.

But what's actually significant is it only takes 0.8ms to render the change on clicking Child component. While it still takes the usual 1 - 3ms to render the change on clicking Button component.

So, what's the verdict and what's next?

Now we know that it definitely takes shorter time to re-render only the child than the whole component, which, is of course a good thing.

Aside from performance, there's actually no use right to put count state in Parent component? If only Child component is the one that needs it, why putting it in its parent? There is no need for its parent component to know the existence of this state unless they also consume it. So in a way, this also encourages us to maintain better architecture right?

But come to think of performance again, 3ms to 0.8ms is not that huge difference right? They are still in millisecond anyway, so small that user won't directly feel the difference. But what about for a page with more complex component structures and more complex data? Would that still be the same?

Lots of more questions right instead of answer? 😂 I didn't plan to give you the exact answer when writing this. But hopefully I manage to intrigue your curiosity to learn deeper, as I plan to research more about re-render in my next writings.

Until then, see ya! 👋

React: how I understand Virtual DOM through useState

Jessica Cecilia Budianto — Wed, 11 Oct 2023 06:54:29 +0000

Honestly. Due to the pressure of ✨ getting things done ✨ while working on my class project using React, all I knew about state in React is simply as a tool in managing data at a component level. And I used to be that using framework due to rising popularity kind of programmer.

But come on, don't lie. Sometimes some of you are still like this right?

But of course, I'm not (or should I say, trying not to be) like that anymore which is why I'm writing this hahaha. Ok enough with the intermezzo. Let's get into this, shall we?

Component Scoping
Virtual DOM
Further Readings

Component Scoping

The thing about React is that it incorporates the 'scoping' mindset using component so well. So well that I forgot that React is still built on top of our sweet old HTML + JavaScript with DOM.

Since I have learned about OOP (Object Oriented Programming) first before React, I see component as a resemblance of object encapsulation where changes will only affect particular component.

Perhaps if you're not familiar with OOP or you didn't get my point, let me give the analogy. Your house consists of several rooms right? There's bedroom, kitchen, etc. If you want only your bedroom to be painted blue, it should be possible right? Not necessarily the whole house has to be painted blue unless you just want to raise a feud.

Below is the example of that in React.

import { useState } from "react";

const Child = () => {
    const [count, setCount] = useState(0);

    return <div onClick={() => setCount(prev => prev + 1)}>COUNT {count}</div>
}
export default Child;

The Child component is then imported into App below.

import Child from './Child';
import Title from './Title';

const App = () => {
  return (
    <div>
        <Title/>
        <Child />
    </div>
  );
}

export default App;

By separating Child component from App, it is only normal if the state change in Child will only re-render Child right? After all only Child knows the existence of count state. And yes it is.

Or if we try to console.log in Child component,

import { useState } from "react";

const Child = () => {
    const [count, setCount] = useState(0);
    console.log('Rendering child')
    return <div onClick={() => setCount(prev => prev + 1)}>COUNT {count}</div>
}
export default Child;

it will look like this.

Virtual DOM

Then that silly late realization came to me: Wait. React is still JavaScript after all right? Then it means there's actually a DOM manipulation for every props / state change right? Or in my understanding, these are the logics to do it in DOM manipulation:

Our algorithm has to specifically know which component that need to be changed. And to solve the which, usually we have to rely on selectors like ID, classname, etc.
After knowing the which part, We have to query the specific component earlier. If such query is not possible (e.g: no selector is available), we might need replace the entire page with the new version, which will re-render the whole body.

Theoritically in programming, query is expensive. And I haven't even mentioned that this DOM change is performed by listening to the variable used as the props / state, perhaps using bind or listener (I haven't researched deeper for this one though). So, always having to listen to changes, find the specific attribute, querying and altering the DOM per change... That's expensive.

But after all framework is meant to improve performance right? And virtual DOM is what React came up with.

Virtual... Sounds so futuristic right? Lol.

You can read more about this virtual DOM in the article I attached below, but just to summarize: it's a mechanism in which React will only re-render (or performing something similar to that crazy expensive computation earlier) after comparing the snapshots of the current and previous situation. Only after there's actually a change, the re-render happens.

Which also means, React won't re-render the component if the state is not changed.

import { useState } from "react";

const Child = () => {
    const [count, setCount] = useState(0);

    console.log('Render child')

    return <div onClick={() => setCount(0)}>Count {count}</div>
}
export default Child;

Really cool huh?

Okay this is the end of my writing today. Gotta save for the next article anyway right? 😌 Think I'll still write about useState again for the next few articles, perhaps something related about the state change between Component and its Child earlier? 👀 Stay tune!

DEV Community: Jessica Cecilia Budianto

Ran out of idea for AI product, so I talked to Gemini

React: should state live in parents?

React: how I understand Virtual DOM through useState

Jessica Cecilia Budianto ・ Oct 11

Table of Contents

Initial experiment: compare the state change in parent and child

useState – React

Second experiment: profile the re-render

So, what's the verdict and what's next?

Further Readings

React: how I understand Virtual DOM through useState

Table of Contents

Component Scoping

Virtual DOM

Further Readings