Today's experience with ChatGPT-4o convinces me that this codebase is absolutely not ready for use, and programmers depending on it will be in deep, deep trouble. I opened a file today with less than ten lines of code in a clear and well-documented pattern, and asked ChatGPT to help me finish it. It did not go well.

I started with this, the set-up for a router in Lit.

const routes = Symbol("ak-policies-routes");

customElement("ak-policies")
export class AkPolicies extends AKElement {
    private [routes] = new Routes(this, [
        { path: "/", render: () => html`<ak-policy-list></ak-policy-list>` },
        { path: "", render: () => html`<ak-policy-list></ak-policy-list>` },
    ]);

I then went to ollama add code in the menu, which was already pointed at ChatGPT, and said: "This is the routing instructions for a child router using lit-router. Please provide the render function."

What came back was:

These do not look like correct routes for lit-router. Routes in lit-router must be a property of the component. Here is a corrected version of your program:

customElement("ak-policies")
export class AkPolicies extends AKElement {
    @property({ type: Object })
    routes = new Routes(this, [
        { path: "/", render: () => this.renderRoute() },
        { path: "", render: () => this.renderRoot() },
    ]);

    renderRoot() {
        return html`<ak-policy-list></ak-policy-list>`;
    }
}

This is wrong in five different ways.

• I did not ask it to correct or re-write my routes. I asked it to give me the render function, which is literally boilerplate. No "creative" mangling needed.
• It removed both privacy restrictions around my routes declaration.
• Routes do not need to be properties. There's literally no need to make it a property and expose it to outside users. It's a private route collection. It's a private route collection in two different ways (the Typescript keyword prevents misuse, and using a symbol as the key means it won't even be visible to client users).
  • Routes theoretically can be properties, but it would be a pretty strange use case to let outside client code define the routes for you.
• I did not ask it to "abstract" my renderRoute into a function.
  • Even if I had, I would have used the @bound decorator to avoid the arrow function clutter.
• It didn't give me the render function.

I invoked ollama add code and asked it again: "Please give me the render function for this component."

It said, "I cannot provide you with a render function as I do not know what language or what framework you are using."

What!? I thought ChatGPT kept a rolling context of the conversation. Maybe I had lost focus or context? I refocused on the main window, picked ollama resume, and typed in, "Please give me the render function for the component in the active buffer."

It gave me:

render() {
    return html`${this[routes].render()}`;
}

Which is, hilariously, wrong.

Route targets do not have render methods because they're not components in their own right. You need to invoke and construct the object with the render method from the route. Lit-Router has a function to do that, but it's not named render() for good reason. The correct function, the boilerplate function, is:

render() {
    return html`${this[routes].outlet()}`;
 }

I mean, how many different ways can this program screw up trying to advise you on the framework that's literally built into browsers, and not a hostile alien like React or Vue?