Backend for Frontend - idmontie's Portfolio

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, props.components), {Mermaid} = _components;
  if (!Mermaid) _missingMdxReference("Mermaid", true);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation."
    }), "\n", _jsx(_components.p, {
      children: "A typical game loop for this type of system would look like:"
    }), "\n", _jsx(Mermaid, {
      chart: "graph LR\n  Rules --> LLM\n  InputStates[\"Input States\"] --> LLM\n  LLM --> OutputState\n  OutputState[\"Output State\"] --> GameEngine\n  GameEngine[\"Game Engine\"] --> InputStates"
    }), "\n", _jsx(_components.p, {
      children: "Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods."
    }), "\n", _jsx(_components.p, {
      children: "When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob."
    }), "\n", _jsx(_components.p, {
      children: "For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions."
    }), "\n", _jsx(_components.p, {
      children: "I’m looking forward to more novel use-cases for LLMs!"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


<p>We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation.</p>
<p>A typical game loop for this type of system would look like:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph LR
  Rules --&gt; LLM
  InputStates[&quot;Input States&quot;] --&gt; LLM
  LLM --&gt; OutputState
  OutputState[&quot;Output State&quot;] --&gt; GameEngine
  GameEngine[&quot;Game Engine&quot;] --&gt; InputStates">graph LR
  Rules --&gt; LLM
  InputStates[&quot;Input States&quot;] --&gt; LLM
  LLM --&gt; OutputState
  OutputState[&quot;Output State&quot;] --&gt; GameEngine
  GameEngine[&quot;Game Engine&quot;] --&gt; InputStates</div></div>
<p>Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods.</p>
<p>When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob.</p>
<p>For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions.</p>
<p>I’m looking forward to more novel use-cases for LLMs!</p>


We are starting to see a rise of novel use-cases for AI in products and games using LLMs. Rather than the simple chatbot like experiences we have seen in the past using AI, we are starting to see feedback systems being added to these experiences, providing additional context to the LLM than just the past conversation.

A typical game loop for this type of system would look like:

```mermaid
graph LR
  Rules --> LLM
  InputStates["Input States"] --> LLM
  LLM --> OutputState
  OutputState["Output State"] --> GameEngine
  GameEngine["Game Engine"] --> InputStates
```

Rules can be describes as written-word description, with an additional set of rules telling the LLM to reply using JSON output of a given schema. In this area, I have had success giving LLMs descriptions of output schemas in Typescript and asking for a JSON response that adheres to the type. Other methods of getting a consistent schema are more than likely possible here, as well as additional output methods.

When the asynchronous task of creating and output state is complete, the Game Engine in this case can read, parse, and apply that new state to the world. Any additional interaction would then lead to the next set of input states that can be given to the LLM as a JSON blob.

For a more concrete example, we can imagine a game where we want our player to interact with a set of agents. The input states would be the state of each agent, the user’s interaction, and maybe some global environment data. The rules may be how each agent should behave, the rules of the game, and additional context. The LLM would take these inputs, and the output is instructed to be the next state of each agent. When the LLM returns this data, the Game Engine read it and applies it to the game’s representation of each agent, showing the player the impact of their actions.

I’m looking forward to more novel use-cases for LLMs!


AI Feedback Systems

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    ul: "ul",
    li: "li",
    h2: "h2"
  }, props.components), {Mermaid} = _components;
  if (!Mermaid) _missingMdxReference("Mermaid", true);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:"
    }), "\n", _jsx(Mermaid, {
      chart: "graph LR\n  SPA --> Backend"
    }), "\n", _jsx(_components.p, {
      children: "SPAs also became popular because the codebase could be built into static assets that could be services."
    }), "\n", _jsx(_components.p, {
      children: "However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:"
    }), "\n", _jsx(Mermaid, {
      chart: "graph LR\n  SPA --> NGINX\n  NGINX --> Service1\n  NGINX --> Service2\n  NGINX --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:"
    }), "\n", _jsx(Mermaid, {
      chart: "graph LR\n  SPA --> BEFFE\n  BEFFE --> Service1\n  BEFFE --> Service2\n  BEFFE --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "The Backend for the Frontend ends up serving two purposes:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "It acts as a proxy for all UI requests"
      }), "\n", _jsx(_components.li, {
        children: "It manages and massages the APIs of downstream services to be a consistent API for the UI."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application."
    }), "\n", _jsx(_components.p, {
      children: "The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI."
    }), "\n", _jsx(_components.h2, {
      children: "Moving away from SPAs"
    }), "\n", _jsx(_components.p, {
      children: "A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?"
    }), "\n", _jsx(Mermaid, {
      chart: "graph LR\n  UIServer[\"UI Server\"] --> Service1\n  UIServer --> Service2\n UIServer --> Service3"
    }), "\n", _jsx(_components.p, {
      children: "With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser."
    }), "\n", _jsx(_components.p, {
      children: "But this additional complexity enabled us to:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA."
      }), "\n", _jsx(_components.li, {
        children: "near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:"
    }), "\n", _jsx(Mermaid, {
      chart: "graph TD\n  Server"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


<p>The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph LR
  SPA --&gt; Backend">graph LR
  SPA --&gt; Backend</div></div>
<p>SPAs also became popular because the codebase could be built into static assets that could be services.</p>
<p>However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph LR
  SPA --&gt; NGINX
  NGINX --&gt; Service1
  NGINX --&gt; Service2
  NGINX --&gt; Service3">graph LR
  SPA --&gt; NGINX
  NGINX --&gt; Service1
  NGINX --&gt; Service2
  NGINX --&gt; Service3</div></div>
<p>While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph LR
  SPA --&gt; BEFFE
  BEFFE --&gt; Service1
  BEFFE --&gt; Service2
  BEFFE --&gt; Service3">graph LR
  SPA --&gt; BEFFE
  BEFFE --&gt; Service1
  BEFFE --&gt; Service2
  BEFFE --&gt; Service3</div></div>
<p>The Backend for the Frontend ends up serving two purposes:</p>
<ul>
<li>It acts as a proxy for all UI requests</li>
<li>It manages and massages the APIs of downstream services to be a consistent API for the UI.</li>
</ul>
<p>When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application.</p>
<p>The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI.</p>
<h2>Moving away from SPAs</h2>
<p>A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph LR
  UIServer[&quot;UI Server&quot;] --&gt; Service1
  UIServer --&gt; Service2
 UIServer --&gt; Service3">graph LR
  UIServer[&quot;UI Server&quot;] --&gt; Service1
  UIServer --&gt; Service2
 UIServer --&gt; Service3</div></div>
<p>With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser.</p>
<p>But this additional complexity enabled us to:</p>
<ul>
<li>create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA.</li>
<li>near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded.</li>
</ul>
<p>The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:</p>
<div class="py-8 [&amp;_svg]:m-auto"><div class="mermaid" data-mermaid-src="graph TD
  Server">graph TD
  Server</div></div>


The Backend for the Frontend (BEFFE) is typically stateless and acts as a proxy for other services, including authentication, authorization, and core services. The recent divorce of browser code being rendered by backend services was created by SPAs - Single Page Applications. In simpler architectures, a SPA and service could be as simple as:

```mermaid
graph LR
  SPA --> Backend
```

SPAs also became popular because the codebase could be built into static assets that could be services.

However, as complexity arises with the above architecture and the SPA starts to rely on more services, a thin proxy is typically introduced, like NGINX:

```mermaid
graph LR
  SPA --> NGINX
  NGINX --> Service1
  NGINX --> Service2
  NGINX --> Service3
```

While proxies like NGINX can continue to be useful, using it as a proxy ends up putting a lot of routing and additional API handling logic on the client. The client now ends up also having to support, understand, and embed how to interact with the data rom all the downstream services. To simplify and create consistent contracts with the UI, we can create a proxy service: a Backend for the Frontend:

```mermaid
graph LR
  SPA --> BEFFE
  BEFFE --> Service1
  BEFFE --> Service2
  BEFFE --> Service3
```

The Backend for the Frontend ends up serving two purposes:

- It acts as a proxy for all UI requests
- It manages and massages the APIs of downstream services to be a consistent API for the UI.

When building a UI, only a single service that acts like an API Gateway is required to understand and encode within the application.

The Backend for the Frontend model also allows engineers working on services to separate logic for the UI with the logic from an internal service. An internal service can rely on the Backend for the Frontend to handle things like Authentication, Authorization, Caching, and Rate-limits. These mechanisms may also be implemented as independent services, but the Backend for the Frontend can make multiple API calls per any API request from the UI.

## Moving away from SPAs

A newer development in the UI space is server side render the application. If we are already introducing additional complexity by having a Backend for the Frontend, then why not combine the UI code with the backend service and generate hydrated and cacheable pages via the server instead of using a SPA?

```mermaid
graph LR
  UIServer["UI Server"] --> Service1
  UIServer --> Service2
 UIServer --> Service3
```

With this design, we increase the complexity - the backend not has to be able to render the UI code. It must now render, hydrate, make requests to downstream APIs, and send those server-side rendered pages to the browser.

But this additional complexity enabled us to:

- create truly authenticated and authorized routes – the code for those routes isn’t even streamed to the browser, unlike a SPA.
- near instant page loads – reducing the bundle size by just sending the JavaScript needed to run the page makes this possible. And since API calls are happening within the same network, this saves the user from additional loading spinners after the initial bundle has been loaded.

The general trend of having a Backend for the Frontend comes with additional complexity. It stems from the want to enhance the experience of the user, and probably from a subconscious desire to return to a simpler time:

```mermaid
graph TD
  Server
```


Backend for Frontend

/*@jsxRuntime automatic @jsxImportSource react*/
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    ul: "ul",
    li: "li",
    h2: "h2",
    blockquote: "blockquote",
    img: "img",
    a: "a"
  }, props.components);
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "I’ve been experimenting with ChatGPT, just like everyone else. But why has it become so popular? It truly is a revolutionary piece of technology. Is it The Next Big Thing? Will it really replace all of us?"
    }), "\n", _jsx(_components.p, {
      children: "My day to day is architecture and programming, and I’ve heard all sorts of things on Twitter:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "That ChatGPT can build entire iOS applications"
      }), "\n", _jsx(_components.li, {
        children: "ChatGPT can write whole files of code"
      }), "\n", _jsx(_components.li, {
        children: "ChatGPT can find bugs in code when writing tests"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "When I started by own company Clarity Hub, we had a focus on machine learning to help augment human intelligence. My thought at the time was that we could leverage machine learning to augment and supplement human intelligence. The focus wouldn't be to replace any person's job, but to make it streamlined and easier to accomplish that job. Our journey started with us serving customer success agents with suggested replies and contextual information, but we eventually pivoted to a Dovetail-like application to help product teams gather, annotate, and contextualize customer interviews."
    }), "\n", _jsx(_components.p, {
      children: "We found that augmenting activity with machine learning was not only easier to do from a technology point of view, but empowered users, rather than make them feel like their job was being replaced."
    }), "\n", _jsx(_components.p, {
      children: "Even with the advent of ChatGPT, I still see this being the short term future of it's use."
    }), "\n", _jsx(_components.h2, {
      children: "False Starts"
    }), "\n", _jsx(_components.p, {
      children: "I was curious how much ChatGPT could really do given all of its hype"
    }), "\n", _jsx(_components.p, {
      children: "I asked it to build an Asteroids game using PhaserJS. Don’t worry, this isn’t another article on “Look, I got ChatGPT to build a game!”"
    }), "\n", _jsx(_components.p, {
      children: "I originally just asked ChatGPT to build an Asteroids game using PhaserJS. A very vague prompt, yes, but a great starting point to figure out the limitations of ChatGPT."
    }), "\n", _jsx(_components.p, {
      children: "The response was basically, “No I can’t”:"
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "As an AI language model, I'm not able to write and execute code in real-time. However, I can provide you with a detailed framework to get started with creating an Asteroids game in PhaserJS."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "This was followed by instructions on how I could do it myself."
    }), "\n", _jsx(_components.p, {
      children: "The next steps of course are to be more specific, asking ChatGPT to build the application to build specific functionality:"
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Add the code to let the player shoot asteroids. If the player gets hit by 3 asteroids, its game over"
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Most interactions with ChatGPT seem to go like this:"
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.img, {
        src: "/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_1.jpg",
        alt: "Flowchart workflow"
      })
    }), "\n", _jsx(_components.p, {
      children: "This flow eventually leads to either:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Not getting what you want."
      }), "\n", _jsx(_components.li, {
        children: "Getting what you want across many different responses, and then you must manually coalesce all of the different responses together to form the result you want."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Once I like the set of responses that ChatGPT has given me, I’ll ask ChatGPT to summarize for me so that I can improve the prompt further:"
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Take everything we just talked about and give me a prompt to ask you in the future that encapsulates all of the requirements."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "A More Natural Flow"
    }), "\n", _jsxs(_components.p, {
      children: ["I’ve talked with ChatGPT on a variety of topics, but the majority of questions relate to coding. I actively use Github Copilot, which utilizes the ChatGPT engine in the backend. I’ve built ", _jsx(_components.a, {
        href: "https://marketplace.visualstudio.com/items?itemName=CapsuleCat.sora-by-capsule-cat",
        children: "Sora by Capsule Cat"
      }), " to have ChatGPT generate entire coding files for me as well with project context. Even then, I still use the ChatGPT UI as well."]
    }), "\n", _jsx(_components.p, {
      children: _jsx(_components.img, {
        src: "/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_2.jpg",
        alt: "Flowchart line"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["I find that the above flow leaves me less fatigued, and more productive - at least in the context of side-projects that I’ve used ChatGPT. Research shows that when we read code and attempt logic puzzles, we use a completely different part of our brain than when we use language [", _jsx(_components.a, {
        href: "https://hub.jhu.edu/2020/12/17/brain-activity-while-reading-code/",
        children: "link"
      }), "]. In the above chart, you can imagine that when we write prompts, we utilize some logical reasoning, but we lean heavily on language as we talk with ChatGPT. Then when we get a response, a completely different part of the brain kicks in to read and write code."]
    }), "\n", _jsx(_components.h2, {
      children: "The Hard Part About Coding"
    }), "\n", _jsx(_components.p, {
      children: "Eventually this leads to “the hard part about coding” which anecdotally everyone will tell you that surprise, it isn’t the coding part. What is nice about ChatGPT though is that even though the hard part isn’t writing code, it does take time, thought, and energy."
    }), "\n", _jsx(_components.p, {
      children: "If the hard part of coding isn’t coding, then what is it? The non-exhaustive list is that it’s teamwork, communication, debugging, and requirements gathering. Oversimplifying, it’s the writing prompts part of the chart."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>I’ve been experimenting with ChatGPT, just like everyone else. But why has it become so popular? It truly is a revolutionary piece of technology. Is it The Next Big Thing? Will it really replace all of us?</p>
<p>My day to day is architecture and programming, and I’ve heard all sorts of things on Twitter:</p>
<ul>
<li>That ChatGPT can build entire iOS applications</li>
<li>ChatGPT can write whole files of code</li>
<li>ChatGPT can find bugs in code when writing tests</li>
</ul>
<p>When I started by own company Clarity Hub, we had a focus on machine learning to help augment human intelligence. My thought at the time was that we could leverage machine learning to augment and supplement human intelligence. The focus wouldn&#x27;t be to replace any person&#x27;s job, but to make it streamlined and easier to accomplish that job. Our journey started with us serving customer success agents with suggested replies and contextual information, but we eventually pivoted to a Dovetail-like application to help product teams gather, annotate, and contextualize customer interviews.</p>
<p>We found that augmenting activity with machine learning was not only easier to do from a technology point of view, but empowered users, rather than make them feel like their job was being replaced.</p>
<p>Even with the advent of ChatGPT, I still see this being the short term future of it&#x27;s use.</p>
<h2>False Starts</h2>
<p>I was curious how much ChatGPT could really do given all of its hype</p>
<p>I asked it to build an Asteroids game using PhaserJS. Don’t worry, this isn’t another article on “Look, I got ChatGPT to build a game!”</p>
<p>I originally just asked ChatGPT to build an Asteroids game using PhaserJS. A very vague prompt, yes, but a great starting point to figure out the limitations of ChatGPT.</p>
<p>The response was basically, “No I can’t”:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>As an AI language model, I&#x27;m not able to write and execute code in real-time. However, I can provide you with a detailed framework to get started with creating an Asteroids game in PhaserJS.</p>
</blockquote>
<p>This was followed by instructions on how I could do it myself.</p>
<p>The next steps of course are to be more specific, asking ChatGPT to build the application to build specific functionality:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Add the code to let the player shoot asteroids. If the player gets hit by 3 asteroids, its game over</p>
</blockquote>
<p>Most interactions with ChatGPT seem to go like this:</p>
<p><img alt="Flowchart workflow" src="/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_1.jpg" style="max-height:500px;margin:auto;text-align:center"/></p>
<p>This flow eventually leads to either:</p>
<ul>
<li>Not getting what you want.</li>
<li>Getting what you want across many different responses, and then you must manually coalesce all of the different responses together to form the result you want.</li>
</ul>
<p>Once I like the set of responses that ChatGPT has given me, I’ll ask ChatGPT to summarize for me so that I can improve the prompt further:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Take everything we just talked about and give me a prompt to ask you in the future that encapsulates all of the requirements.</p>
</blockquote>
<h2>A More Natural Flow</h2>
<p>I’ve talked with ChatGPT on a variety of topics, but the majority of questions relate to coding. I actively use Github Copilot, which utilizes the ChatGPT engine in the backend. I’ve built <a href="https://marketplace.visualstudio.com/items?itemName=CapsuleCat.sora-by-capsule-cat">Sora by Capsule Cat</a> to have ChatGPT generate entire coding files for me as well with project context. Even then, I still use the ChatGPT UI as well.</p>
<p><img alt="Flowchart line" src="/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_2.jpg" style="max-height:500px;margin:auto;text-align:center"/></p>
<p>I find that the above flow leaves me less fatigued, and more productive - at least in the context of side-projects that I’ve used ChatGPT. Research shows that when we read code and attempt logic puzzles, we use a completely different part of our brain than when we use language [<a href="https://hub.jhu.edu/2020/12/17/brain-activity-while-reading-code/">link</a>]. In the above chart, you can imagine that when we write prompts, we utilize some logical reasoning, but we lean heavily on language as we talk with ChatGPT. Then when we get a response, a completely different part of the brain kicks in to read and write code.</p>
<h2>The Hard Part About Coding</h2>
<p>Eventually this leads to “the hard part about coding” which anecdotally everyone will tell you that surprise, it isn’t the coding part. What is nice about ChatGPT though is that even though the hard part isn’t writing code, it does take time, thought, and energy.</p>
<p>If the hard part of coding isn’t coding, then what is it? The non-exhaustive list is that it’s teamwork, communication, debugging, and requirements gathering. Oversimplifying, it’s the writing prompts part of the chart.</p>


I’ve been experimenting with ChatGPT, just like everyone else. But why has it become so popular? It truly is a revolutionary piece of technology. Is it The Next Big Thing? Will it really replace all of us?

My day to day is architecture and programming, and I’ve heard all sorts of things on Twitter:

- That ChatGPT can build entire iOS applications
- ChatGPT can write whole files of code
- ChatGPT can find bugs in code when writing tests

When I started by own company Clarity Hub, we had a focus on machine learning to help augment human intelligence. My thought at the time was that we could leverage machine learning to augment and supplement human intelligence. The focus wouldn't be to replace any person's job, but to make it streamlined and easier to accomplish that job. Our journey started with us serving customer success agents with suggested replies and contextual information, but we eventually pivoted to a Dovetail-like application to help product teams gather, annotate, and contextualize customer interviews.

We found that augmenting activity with machine learning was not only easier to do from a technology point of view, but empowered users, rather than make them feel like their job was being replaced.

Even with the advent of ChatGPT, I still see this being the short term future of it's use.

## False Starts

I was curious how much ChatGPT could really do given all of its hype  

I asked it to build an Asteroids game using PhaserJS. Don’t worry, this isn’t another article on “Look, I got ChatGPT to build a game!”

I originally just asked ChatGPT to build an Asteroids game using PhaserJS. A very vague prompt, yes, but a great starting point to figure out the limitations of ChatGPT.

The response was basically, “No I can’t”:

> As an AI language model, I'm not able to write and execute code in real-time. However, I can provide you with a detailed framework to get started with creating an Asteroids game in PhaserJS.

This was followed by instructions on how I could do it myself.

The next steps of course are to be more specific, asking ChatGPT to build the application to build specific functionality:

> Add the code to let the player shoot asteroids. If the player gets hit by 3 asteroids, its game over

Most interactions with ChatGPT seem to go like this:

![Flowchart workflow](/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_1.jpg)

This flow eventually leads to either:

- Not getting what you want.
- Getting what you want across many different responses, and then you must manually coalesce all of the different responses together to form the result you want.

Once I like the set of responses that ChatGPT has given me, I’ll ask ChatGPT to summarize for me so that I can improve the prompt further:

> Take everything we just talked about and give me a prompt to ask you in the future that encapsulates all of the requirements.

## A More Natural Flow

I’ve talked with ChatGPT on a variety of topics, but the majority of questions relate to coding. I actively use Github Copilot, which utilizes the ChatGPT engine in the backend. I’ve built [Sora by Capsule Cat](https://marketplace.visualstudio.com/items?itemName=CapsuleCat.sora-by-capsule-cat) to have ChatGPT generate entire coding files for me as well with project context. Even then, I still use the ChatGPT UI as well.

![Flowchart line](/media/2023-07-23-chatgpt-coding-loop/Flowchart_Template_2.jpg)

I find that the above flow leaves me less fatigued, and more productive - at least in the context of side-projects that I’ve used ChatGPT. Research shows that when we read code and attempt logic puzzles, we use a completely different part of our brain than when we use language [[link](https://hub.jhu.edu/2020/12/17/brain-activity-while-reading-code/)]. In the above chart, you can imagine that when we write prompts, we utilize some logical reasoning, but we lean heavily on language as we talk with ChatGPT. Then when we get a response, a completely different part of the brain kicks in to read and write code.

## The Hard Part About Coding

Eventually this leads to “the hard part about coding” which anecdotally everyone will tell you that surprise, it isn’t the coding part. What is nice about ChatGPT though is that even though the hard part isn’t writing code, it does take time, thought, and energy.

If the hard part of coding isn’t coding, then what is it? The non-exhaustive list is that it’s teamwork, communication, debugging, and requirements gathering. Oversimplifying, it’s the writing prompts part of the chart.
