Hacker News Reader

Comment by ipsento606 | Hacker News Reader

> Software engineers are scared of designing things themselves.

When I use a framework, it's because I believe that the designers of that framework are i) probably better at software engineering than I am, and ii) have encountered all sorts of problems and scaling issues (both in terms of usage and actual codebase size) that I haven't encountered yet, and have designed the framework to ameliorate those problems.

Those beliefs aren't always true, but they're often true.

Starting projects is easy. You often don't get to the really thorny problems until you're already operating at scale and under considerable pressure. Trying to rearchitect things at that point sucks.

View on HN

To be blunt, I think it's a form of mania that drives someone to reject human-written code in favor of LLM-generated code. Every time I read writing from this perspective that exceeds a paragraph, I quickly realize the article itself was written by an LLM. When they automate this much writing, it makes me wonder how much of their own reading they automate away too.

The below captures this perfectly. The author is trying to explain that vibe-coding their own frameworks lets them actually "understand" the code, while not noticing that the LLM-generated text they used to make this point is talking about cutting and sewing bricks.

> But I can do all of this with the experience on my back of having laid the bricks, spread the mortar, cut and sewn for twenty years. If I don’t like something, I can go in, understand it and fix it as I please, instructing once and for all my setup to do what I want next time.

I think the bit you quoted is a tie in with an earlier bit:

“ I can be the architect without the wearing act of laying every single brick and spreading the mortar. I can design the dress without the act of cutting and sewing each individual piece of fabric”

To me, this text doesn’t read as being entirely written by an LLM, there is definitely an air of LLM about it though, so maybe the first draft was.

Those additional jumbled incoherent mixing of metaphors don't make it any better.

> it's a form of mania

Correct. The history is rife with examples of manias taking hold of societies, I recommend "Memoirs of Extraordinary Popular Delusions and the Madness of Crowds" by Charles Mackay[1], it's an absolutely fascinating book.

[1]https://www.gutenberg.org/ebooks/24518

> absolutely fascinating book

Indeed. Thank you for posting this link.

> Every time I read writing from this perspective that exceeds a paragraph, I quickly realize the article itself was written by an LLM.

Likewise, I think that this mentality is a modern day conversion disorder.

"Everything I don't agree with is an LLM, I have no proof it just feels good!"

It’s the ‘woke’ of the computer world.

Yeah the “not invented here” syndrome was considered an anti pattern before the agentic coding boom and I don’t see how these tools make it irrelevant. If you’re starting a business, it’s still likely a distraction if you’re writing all of the components of your stack from scratch. Agentic tools have made development less expensive, but it’s still far from zero. By the author’s admission, they still need to think through all these problems critically, architect them, pick the right patterns. You also have to maintain all this code. That’s a lot of energy that’s not going towards the core of your business.

What I think does change is now you can more easily write components that are tailor made to your problem, and situation. Some of these frameworks are meant to solve problems at varying levels of complexity and need to worry about avoid breaking changes. It’s nice to have the option to develop alternatives that are as sophisticated as your problem needs and not more. But I’m not convinced that it’s always the right choice to build something custom.

I'm not sure.

The cost of replacement-level software drops a lot with agentic coding. And maintenance tasks are similarly much smaller time syncs. When you combine that with the long-standing benefits of inhouse software (customizable to your exact problem, tweakable, often cleaner code because the feature-set can be a lot smaller), I think a lot of previously obvious dependencies become viable to write in house.

It's going to vary a lot by the dependency and scope - obvious owning your own react is a lot different than owning your own leftpad, but to me it feels like there's no way that agentic coding doesn't shift the calculus somewhat. Particularly when agentic coding make a lot of nice-to-have mini-features trivial to add so the developer experience gap between a maintained library and a homegrown solution is smaller than it used to be.

my problem with frameworks has always been that the moment I want to do something the framework writers aren't interested in, I now have three problems: my problem, how to implement it in the underlying platform and how to work around the framework to not break my feature.

Yes this happens in every framework I've ever used. My approach used to be to try to work around it, but now I've got these local exceptions to what the framework does and that is inevitably where problems/bugs pop up. Now I simply say "we can't implement the feature that way in this framework, we need to rework the specification." I no longer try to work against the framework, it's just a massive time sink and creates problems down the road.

It's like designing a kitchen and you don't make all the spaces some multiple of three inches. Now, standard cabinets and appliances will not fit. You will be using filler panels or need custom cabinetry. And anyone who later wants countertops or different cabinets will be working around this design too. Just follow the established standard practices.

I'm so glad software engineering isn't my job. I love solving problems, and I'm somewhat better at using code to do it than my peers (fellow scientists), but I would hate to have a boss/client that says "it needs to do X" and the framework writer (or SDK, ala Android/Xcode) say "no, that hurts my profits/privacy busting".

Software companies all understand that so its not really a problem. Maybe in companies where the software isn't the main product

I've never found something that was impossible to implement in any framework or SDK. Even in Android SDK land, you can easily get access to an OpenGL surface and import the whole world via the NDK. There's nothing limiting other than the OS itself and its mechanism.

Same with Web framework. Even React (a library) has its escape hatches to let in the rest of the world.

okay, push notification without going through firebase. go!

Where is your copy of the android source code for the device you’re manufacturing? Because that’s how you can get the full feature set. Otherwise you will be restricted by Android aggresive suspending and killing policy.

Where did I say I was manufacturing a device? You just proved my point.

You wrote

> I would hate to have a boss/client that says "it needs to do X" and the framework writer (or SDK, ala Android/Xcode) say "no, that hurts my profits/privacy busting".

An answer to such request should be: "We would need to ship a custom version of Android". Just like if you need to setup a web server on a Linux system, you would need to be root. You don't choose a shared hosting and then complain about the lack of permissions.

that's amazing, shared hosting on the device I bought. no thank you. I'll root the damn thing and do as I please. If future devices don't allow that, I won't have a reason to carry them in my pocket.

In Clojure land, the mantra has long been "libraries over frameworks" for this reason.

Yeah, I'm huge on using LLMs for coding, but one of the biggest wins for me is that the LLM already knows the frameworks. I no longer need to learn whatever newest framework there is. I'll stick to my frameworks, especially when using an LLM to code.

after 3 decades as SWE I mostly found both i) and ii) to not be true, for the most part. a lot of frameworks are not built from the ground up as “i am building a thing to solve x” but “i had a thing and built something that may (or may not) be generally useful.” so a lot of them carry weight from what they were originally built from. then people start making requests to mold the framework to their needs, some get implemented, some don’t. those that don’t good teams will build extensions/plugins etc into the framework and pretty soon you got a monster thing inside of your codebase you probably did not need to begin with. i think every single ORM that i’ve ever used fits this description.

Totally. Frameworks also make it a lot easier for new team members to contribute. React, for example, makes it a lot easier to hire. Any project with moderate size will require some kind of convention to keep things consistent and choosing a framework makes this easier.

Now look at the cross team collaboration and it gets even harder without frameworks. When every team has their own conventions, how would they communicate and work together? Imagine a website with React, Vue, Angular all over the place, all fighting for the same DOM.

> Those beliefs aren't always true, but they're often true.

You can probably tell with a high certainty, from the API in an hour or so.

And there was a time when using libraries and frameworks was the right thing to do, for that very reason. But LLMs have the equivalent of way more experience than any single programmer, and can generate just the bit of code that you actually need, without having to include the whole framework.

Critically, they will also enable faster future migration to a framework in case it proves useful.

As someone who’s built a lot of frontend frameworks this isn’t what I’ve found. Instead I’ve found that you end up with the middle ground choice which while effective is no better than the externally maintained library of choice. The reason to build your own framework is so it’s tailor suited to your use cases. The architecting required to do that LLMs can help with but you have to guide them and to guide them you need expertise.

I would like a more reliable way to activate this "way more experience."

What I see in my own domain I often recognize as superficially working but flawed in various ways. I have to assume the domains I am less familiar are the same.

Claude's a smart junior engineer who's read a lot of books but is lacking in real word experience.

It definitely eliminates a lot of tedium, but needs a lot of guidance if you want good results.

> can generate just the bit of code that you actually need

Design is the key. Codebases (libraries and frameworks not exempt,) have a designed uniformity to them. How does a beginner learn to do this sort of design? Can it be acquired completely by the programmer who uses LLMs to generate their code? Can it be beneficial to recognize opinionated design in the output of an LLM? How do you come to recognize opinion?

In my personal history, I've worked alongside many programmers who only ever used frameworks. They did not have coding design sensibilities deeper than a social populist definition of "best practice." They looked to someone else to define what they can or cannot do. What is right to do.

Reply on news.ycombinator.com