“The only people I've heard saying that generated code is fine are those who don't read it.” Are you sure these people aren’t busy working rather than chatting? (haha)
But in all seriousness it depends on what you’re doing with it. Writing a quick tool using an LLM is much easier than context changing to write it yourself. If you need the tool, that’s very valuable.
Also as a webdev, it writes basic CRUD pretty good. I am tired of having to build forms myself and the LLMs are usually really good at that.
Been building a new app with lots of policies and whatnot and instructing a LLM is just much faster than doing the same repetitive shit over and over myself.
If you were tired of writing forms yourself, had you looked at https://jsonforms.io/? Just specify the the data you need, or extract it from the api spec and go. Display the form uniformly every time across your site. No need to burn AI time.
I typically avoid any most abstractions or third party dependencies. Yea it could be neat, but I still need a lot of custom logic here and there.
Same reason I avoid stuff like GraphQL.
A little update: upon viewing the page on phone, for me the "comitter" field in the demo is going out of bounds... Really not speaking for their product.
I think you're missing the point of the commenter. A third party library is a new dependency. Since there's new vulnerabilities almost every week in the npm ecosystem, if you can do something without a third party, it's probably better.
With LLM driven code you can generate code once, and then if anything is shitty about it you can always manually update it yourself without the need of an LLM. It's a dependency of convenience, not an app-dependency.
From the description of the recommended tool it sounded to me like something that you use to deterministically generate code from a spec, which you could then modify if you like. That would be the same kind of dependency as the LLM workflow you describe, except that the abstraction is well-defined in a way that the LLM is not. Whether it's good or not is a different question.
That would be nice if it were the case but from what I can gather from this interesting dependency graph, there's a hard dependency on its renderer and schema.
I don't know or care about that specific tool, or really what you do at all, I was just reacting to how the principle you stated conflicts with the practice you described. How you reconcile those is up to you.
Mate, that's literally what you implied, innit? You probably "can" do it yourself, but you choose not to - I wonder why? Also the point of sarcasm is to communicate it in such way that it is obvious, without using the "/s" signifier. You know like, telling a joke at a party that you don't have to explain.
Isn't that the whole concept of "technical debt" though? This has been how software has been developed for quite a while, even pre-LLM. Sometimes your boss puts a thousand things on your plate and you take shortcuts on less important things to save time, and sometimes it works out well and sometimes it doesn't.
Yea because having 200 different abstractions and DSLs makes stuff easier for sure! Why not use all the stuff that was popular 6 years ago like Prisma, GraphQL and Redux, whoops suddenly you need a whole team of devs knowing all kinds of unecessary abstractions.
Based on the examples you provided, I think the term you're looking for is "external dependencies" not "abstractions"
Edit: Incidentally, I tend to treat "code made by an LLM" and "external dependencies" pretty much the same. Pretty low trust, with a strong interface between it and any code that matters
Having a JSON file handle a form schema I provide abstracts away directly building the form myself with actual tech supported by most browsers, hence why I call it abstraction.
I usually only use stuff that either is raw Js, HTML, CSS or whatever builds on top of it. Never something that introduces some DSL and generates files for said environments.
> Prisma, GraphQL and Redux, whoops suddenly you need a whole team of devs knowing all kinds of unecessary abstractions.
Ah, let me guess / you're one of those non-technical PMs who can finally shove it to the devs - by spitting out unreadable HTML storing all it's data in a flat file? Oh boy, do I have news for you...
I am actually a full stack dev working with Vue and Laravel a lot atm. Also have quite some experience with Golang. I like lightweight frameworks and simple stuff, and yes, I avoid solutions by people trying to be smart over being simple.
...which means you depend on the LLMs? Of course strictly "to save time". It's not like you are slowly forgetting how to start a project in the first palce or implement that db integration, right?
LOL why would I ever forget how to start a project or how to connect to a DB or make migrations and whatnot, brother generating a web form for creating and updating models is not that big of a deal. A LLM can do this while providing a11y attributes and proper styling in like 10 minutes. This includes creating a migration which I take a look at and correct if needed, creating the model, creating required policies, creating the controller endpoints which i correct in case its needed, creating a template file for the crud operations with search and pagination and whatnot while making it somewhat look good.
I can do all of this myself, but why would I waste 1-2 hours (per model) on doing all that myself if I can just instruct some stupid LLM to do it for me? It's repetitive boilerplate.
This is a weird thing to point out. I've always had to look up how to start a project even before LLMs, even with years of experience. With React there's vite, React router, nextjs, tanstack. With nodejs there's Koa, hapi, express, and tons others.
Most fullstack engineers are likely not starting a lot of new projects at work, and may only be doing it a few times for side projects, LLM or no.
I‘ve used it in a previous engagement. Unfortunately it’s not customizable enough, and performance for deep forms is really bad. Also, I‘d definitely use agents to set it up.
This the core unspoken bone of contention in most AI arguments I think: most people either arent writing code with strict quality requirements or dont realize where their use of AI is violating them.
That said most of the world's most useful code has strict quality requirements. Even before AI 90% of SLOC would be tossed away without much if any use, 9% was used infrequently while 1% runs half the world's software.
I think this misses the scale of the problem. Review never fixed tech debt, nor did it fix relevant/bloated test suites. It didn't solve complexity, or eliminate footguns. Very few people (I would argue almost noone) had developed theories for what all of these even were, or how to spot them in code.
Reviewers aren't perfect, far from it. And we just gave them ~20x more code to review. Incentives mean that taking 20x longer to review is unacceptable. So where do we go from here?
I'm really amused at how quickly things changed from "yes, the AI is writing it all, but I'm carefully reviewing every line" to "it would take too long and be too confusing to review any of it"
Agreed. Reviewing code takes so much longer and is far more exhausting than writing it, and you still don’t understand the logic as well or intuitively as you would if you write it.
Code reviews should be done by someone other than the author though, so the only thing that changes with ai generated code in that respect is the amount of it
Before: One person writes the code (and likely understands it thoroughly), another person reviews the code to spot obvious mistakes or shortcomings. Now: AI writes the code, a person reviews it to spot obvious mistakes or shortcomings.
In the before case, you have a person who has a deeper understanding of the code and in the AI case, you don’t, instead you have even more code to review.
When a competent programmer is writing the code, the human written code tends to be higher quality too. So it’s not just about review quantity but the quality of code being reviewed. Some people claim the AI writes great code, but that just hasn’t been my experience yet (at least with the models I’ve tried, including Opus). They still make ridiculously bad decisions regularly.
>When a competent programmer is writing the code, the human written code tends to be higher quality too
This is a great idea, but on average is deeply untrue. Far and away most programmers today write significantly worse code than LLMs. Also LLMs are fantastic at generating high level summaries and comments in code
> Far and away most programmers today write significantly worse code than LLMs
Your experience with LLMs do not match my own. Not to say that I haven’t experienced terrible human written code where I’ve wondered what the author could possibly have been thinking, but overall, I still find LLM written code to be on the poor side.
Like, the code itself is ok, but the wider picture reasoning and abstractions are bad. It also makes really dumb decisions far too often. Or doggedly shoehorns its first idea in no matter how badly it fits.
If you try to create a new iOS/macOS software project and sign it with a "com.apple." prefix in the bundle ID, Apple's system blocks it… for example.
It's pretty clear this type of ID'ing is an issue in general, unfortunately. Companies often protect themselves as a band-aid but not others in the same situations since the problems aren't frequent enough to warrant a design change. So, when it does become a problem, it could end up being a deep one.
More than likely LINE was paying a lot of font licensing fees for some font usage somewhere and paying one time to develop this font will pay for itself. Corporate font announcements always crack me up because they try to make something incredibly mundane sound like high art. But this was probably a financial decision!
My question would be more like "how do you convince the shareholders that this expense is necessary?" Because I bet that for most people this is just Arial or whatever word uses
But in all seriousness it depends on what you’re doing with it. Writing a quick tool using an LLM is much easier than context changing to write it yourself. If you need the tool, that’s very valuable.