Remix.run Logo
prmph 7 hours ago

Well "most" devs is doing a lot of work here.

I'm not sure about other devs, or even their number, but AI can most definitely NOT produce better code than I can.

I use it after I have done the hard architectural work: defining complex types and interfaces, figuring out code organization, solving thorny issues. When these are done, it's now time to hand over to the agent to apply stuff everywhere following my patterns. And even there SOTA model like Opus make silly mistakes, you need to watch them carefully. Sometimes it loses track of the big picture.

I also use them to check my code and to write bash scripts. They are useful for all these.

thunky 6 hours ago | parent [-]

What you're describing is using it to do something you already can do at an expert level, and you already know exactly what you want the result to look like amd won't accept anything that deviates from what's already in your head. So like a code autocomplete. You don't really want the "intelligence" part, you want a mule.

That's fine, and useful, but you're really putting a ceiling on it's potential. Try using it for something that you aren't already an expert in. That's where most devs live.

Even expert coder antirez says "writing the code yourself is no longer sensible".

https://antirez.com/news/158

mibsl 5 hours ago | parent | next [-]

AFAIU antirez is mostly writing in C, a verbose language where "create a hashtable of x->y" turns into a wall of boilerplate. In high level languages the length diffrence between a precise specification and the actual code is much smaller.

thunky 5 hours ago | parent [-]

He also mentions using it for Python which is minimal boilerplate.

And he didn't limit his take to just C code. He said: state of the art LLMs are able to complete large subtasks or medium size projects alone, almost unassisted, given a good set of hints about what the end result should be.

prmph 4 hours ago | parent | prev [-]

But if the using them as mules is still producing silly mistakes, how will I have the confidence to defer to their intelligence for much more complex stuff?

These things bullshit their way about all the time. I've lost track of how many times they seem to produce something great, only for me, upon deeper inspect, to see what a subtle mess they have made. And when the work is a bit complex, I cannot verify on sight; I'd have to take time to do it.

Also, they absolutely cannot even produce some levels of code. Do you think I can just give them a prompt to produce a haskell-like language, allow them to crank for some hours, and have a language ready made?

Want an example? here is something Sonnet gave me just today:

    const sort = sortKey ? { field: "name", order: "ascending" } as const : undefined
Where sortKey is defined as:

    const sortKey: "name-asc" | "name-desc" | "recently-accessed" | "least-recently-accessed" | undefined
I just realized this a few minutes ago after reviewing the code.

Here is another one:

-------------------------------

Given:

    queryX: <Ent extends EntityNamePlural, Col extends StrKeyOf<Dto<Ent>>>(args
        : {
            entity: Ent
            query: QueryArgs<Dto<Ent>, Col, fOperators>
            auditInfo?: AuditSpec
        }
    ) => Promise<Result<Pick<Dto<Ent>, Col>[]>>

    export type QueryArgs<Rec extends StdRecord = StdRecord, Fld extends StrKeyOf<Rec> = StrKeyOf<Rec>, FltrOp extends FilterOpsAll = FilterOpsAll> = {
        /** Fields to include in results (defaults to all) */
        fields?: Fld[],

        /** Filters to apply */
        filter?: RecordFilter<Rec, FltrOp>,

        /** Sorting to apply */
        sort?: {
            field: Fld
            order: SortOrder
        },

        /** Pagination to apply */
        page?: {
            maxCount?: number | undefined
            startFrom?: {
                sortFieldKey: any,
                idKey: ID
            } | undefined
        }
    }
And:

    const sort = sortKey ? { field: "name", order: "ascending" } as const : undefined
    const xx = storage.queryX({ entity: "cabinets", query: { filter, sort, page: page ? { startFrom: page } : undefined } })
I get this as the type of xx: Promise<Result<Pick<Cabinet, "name">[]>>

Which is obviously wrong. I should be getting the full type, i.e., all columns picked. The problem is that the Column generic parameter is not being properly inferred, which is (probably) due to the sorting by name, since the sort column is defined to have to be part of the query field name, so when field is not provided, TypeScript infers the fields as the sort column name.

Neither ChatGPT nor Claude Opus have been able to solve this after one hour, suggesting all kinds of things that don't work. But I have solved it myself, with:

    export type QueryArgs<Rec extends StdRecord = StdRecord, Fld extends StrKeyOf<Rec> = StrKeyOf<Rec>, FltrOp extends FilterOpsAll = FilterOpsAll, Srt extends Fld = Fld> = {
        /** Fields to include in results (defaults to all) */
        fields?: Fld[],

        /** Filters to apply */
        filter?: RecordFilter<Rec, FltrOp>,

        /** Sorting to apply */
        sort?: {
            field: Srt// StrKeyOf<Rec>
            order: SortOrder
        },

        /** Pagination to apply */
        page?: {
            maxCount?: number | undefined
            startFrom?: { sortFieldKey: any, idKey: ID } | undefined
        }
    }

And:

    queryX: <Ent extends EntityNamePlural, Col extends StrKeyOf<Dto<Ent>>, Srt extends Col = Col>(args
        : { 
            entity: Ent, 
            query: QueryArgs<Dto<Ent>, Col, fOperators, Srt>, 
            auditInfo?: AuditSpec 
        }
    ) => Promise<Result<Pick<Dto<Ent>, Col | Srt>[]>>