Unfortunately I think devs nowadays (me included) are insanely bad compared to the devs back in the day who actually had to learn about their computers.
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.
...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.
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.
> 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.
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.
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.
The biggest mistake is that people trusted a company that, in reality, isn't that different from Apple. Just because everyone claimed Android as the true open source alternative to iOS, when only AOSP was that.
Google (before the sell-off) promoted a morality in 'don't be evil' that was a stark contrast to other tech firms. The adverts they carried were minimal. Their "free" stuff was top of the line, better than people were getting from paid services.
Apple (under Jobs) sold themselves as counter-culture, they used popstars (unironically), and design, to sell the idea that if you were your own person, or followed fashion, then you bought Apple.
I think the goodwill from those days still provides the foundations of their cultural position now. Although they chip away at those foundations.
OpenAI looked like it could follow Google's early model, until it didn't.
The writing was on the wall for "don't be evil" when Google started the process of acquiring the much reviled DoubleClick back in 2007, nearly 20 years ago at this point. That's longer than most people reading this have been in the tech industry; a generation has never seen Google be anything other than increasingly extractive and monopolistic.
They built products people like, and specially Apple has good reputation for building reliable, long-lasting and easy to use stuff for most people, leading to a heavy user adoption. But heavy user adoption without the proper regulation and company ethics leads to, well, monopolistic practices.
i mean Apple kind of used that position for building a good reputation. their whole thing is/was how secure their devices were and how they had human verification on all apps that went through the app store with a clear intents file (a file the describes exactly WHY an app needs permission for bluetooth/etc), and a secure enclave that prevented even the FBI from getting in (while apple refused to give them a backdoor). Hackers and tinkerers will find a lot of these measures to be an annoyance and authoritative control, but a lot of people just want their phone to a product, not the user.
> Because Apple always did this, everybody knew this and people buy Apple exactly because of this.
Is that really so? Does the average iPhone user actually factor the app store tax into their decision to purchase the device? Or do they just assume that is just how all software works because they have no exposure to software ecosystems outside the iPhone app store
> Does the average iPhone user actually factor the app store tax into their decision to purchase the device?
As I'm the IT tech support for some family members, I certainly do. A lot less drama and garbage when using Apple products (generally speaking).
I've sysadmined Linux for a living for many moons now, and used to run Linux and then FreeBSD at home, and I switched to Apple for personal stuff during the PowerPC and early Mac OS 10.x timeframe because I did enough fiddling with tech at work and minimized it at home.
I used Linux desktops at work in the pre-COVID era when we still had offices and such. I now use a Apple laptop as I can get Unix-y tools to admin: I spend >80% of my time in Terminal (the rest in Safari and Mail).
They factor in a more "clean" appstore yes. Not the tax itself but they usually appreciate apple having more polished apps in general (given that the Google Playstore is full of trash).
Google play store is only full of trash if you go hunting for trash. I'd like to see the actual stats of people affected by play store malware vs malware available on the play store.
I'm not saying it's not a problem, but I am saying it's not a problem that has caused any problems with any Android user I've ever met.
I am not talking about the malware, I am talking about the apps that are bloated with advertisements or try really hard to push a subscription upon you. Lots of "free" apps try to push you into a subscription once installed.
People do not buy Apple because of this. They buy Apple for other reasons and this comes along with it. Apple could allow side-loaded apps and not a single person would switch
> Google now pulls the rug on Android which is a whole different story because it used to be open. The whole idea of Android was to be open.
This is the narrative for us in developed nations, but the majority of users today are people who were in developing countries and got a mid-tier smartphone to chat with friends and do banking with the same values as Apple users.
this is that xkcd "regular people can only name a few common feldspars" meme. over 90% of consumers have no knowledge at all of tech corps' philosophy on user freedom, they just buy cheap phones that have good cameras and run instagram and tiktok well.
>If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t.
How is producing more lines of code any good? How does quality assurance work with immeasurable code bloat? I want good software not slopware with 2000 different features. A good product does few things, but does these really well. There is no need to constantly add lines of code to a working product.
I roll both of these at work, from auth to cashless payments to regular online payments. It's not as hard as people make it out to be. Probably a lot harder at big companies with huge attack surfaces and attention though.
I think the main argument usually is time savings. Personally I just always do E-Mail and password auth, yea its old and not the shiny new thing, but it doesn't require me to integrate 200 different ways of doing auth.
We should be able to demand users remembering their passwords, I dont like to cater towards users who simply dont want to put in the work to use my product.
Will I lose potential users over this? Yes. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
Great for you but that's not the case for a lot of B2B contracts we have. A lot of them require integrating with their SSO, not just for login but for permissions too
Do permissions follow the same model everywhere with SSO or do you now have to set up permission logic everywhere for new customers? Like company A uses "admin" as role while company B uses "management" for essentially the same role?
Same here, Just email + password, no google dependency initially. If more users ask we will think of it. but again you don't need a cloud vendor for all this.
You do you but most businesses if given the option between supporting OAuth to reduce friction on signups, or only supporting password auth, will choose the option that makes them more money.
You don't have to use a 3rd party service for OAuth. You can do it in house.
Yea I know, I just don't want my app to have a google logo on it, or whatever other companies people use to login with. E-mail and password will forever be my go to solution.
I want intentional users not the ones that click "sign up with google", try out the app once and never come back. Also I don't have the time to learn how to properly integrate more auth methods into my app. I want my own user table, I want predictability on how a user model looks and I want to be in control of everything.
reply