This is all about the tooling most companies choose when building software: Things with more than enough boilerplate most code is trivial. We can build tools that have far less triviality and more density, where the distance between the code we write and business logic is very narrow.. but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers, so we end up with tools where we might not be more productive, but we might feel productive, even though most of that apparent productivity is trivially generated.

We also have the ceremonial layers of certain forms of corporate architecture, where nothing actually happens, but the steps must exist to match the holy box, box cylinder architecture. Ceremonial input massaging here, ceremonial data transformation over there, duplicated error checking... if it's easy for the LLM to do, maybe we shouldn't be doing it everywhere in the first place.

>but then every line of code we write is hard, because it's meaningful, and that feels bad enough to many developers,

I don't know that I've ever even met a developer who wants to be writing endless pools of trivial boilerplate instead of meaningful code. Even the people at work who are willing to say they don't want to deal with the ambiguity and high level design stuff and just want to be told what to do pretty clearly don't want endless drudgery.

That, but boilerplate stuff is also incredibly easy to understand. As compared to high density, high meaning code anyway. I prefer more low density low meaning code as it makes it much easier to reason about any part of the system.

So basically it’s a presentation problem.

We want to control code at the call site, boilerplate helps with that by being locally modifiable.

We also want to systematize chunks of code so that they don’t flicker around and mess with a reader.

We wanted this since forever and no one does anything because anything above simple text completion is traditionally seen as an overkill, not the true way, not unix, etc. All sorts of stubborn arguments.

This can be solved by simply allowing code trees instead of lines of code (tree vs table). You drop a boilerplate into code marked as “boilerplate ‘foo’ {…}” and edit it as you see fit, which creates a boilerplate-local patch. Then you can instantly see diffs, find, update boilerplates, convert them to and from regular functions, merge best practices from boilerplate libraries, etc. Problem solved.

It feels like the development itself got collectively stuck in some stupid principles that no one dares to question. Everything that we invent stumbles upon the simple fact that we don’t have any sensible devtime structure, apart from this “file” and “import file” dullness.

In and of itself, it's usually easy to understand. But the more fluff you stuff between the nontrivial bits, the harder it is to take in all at once. I think large quantities of simple boilerplate make the overall project harder to understand and debug. Though that is in comparison to an imagined alternative that's somehow exactly the same but with all the glue removed, so maybe that's not entirely fair.

I think you just nailed the paradox of Go's popularity among developers, managers are obvious.

I don't think that is the signal that I think most people are hoping for here.

When I hear that most code is trivial, I think of this as a language design or a framework related issue making things harder than they should be.

Throwing AI or generates at the problem just to claim that they fixed it is just frustrating.

> When I hear that most code is trivial, I think of this as a language design or a framework related issue making things harder than they should be.

This was one of my thoughts too. If the pain of using bad frameworks and clunky languages can be mitigated by AI, it seems like the popular but ugly/verbose languages will win out since there's almost no point to better designed languages/framework. I would rather a good language/framework/etc where it is just as easy to just write the code directly. Similar time in implementation to a LLM prompt, but more deterministic.

If people don't feel the pain of AI slop why move to greener pastures? It almost encourages things to not improve at the code level.

Well, Google did design Go...

I'm writing software independently, with an extremely barebones framework (just handles routing pretty much) and very lean architecture. Maybe I should re-phrase it, "a lot of characters in the code base are trivial". Imports, function declarations, variable declarations. Is this stuff code/logic? Barely, but it's completely unavoidable. It all takes time and it's now time I rarely have to spend.

Just as an example, I have "service" functions. They're incredibly simple, a higher order function where I can inject the DB handler, user permissions, config, etc. Every time I write one of these I have to import the ServiceDependencies type and declare which dependencies I need to write the service. I now spend close to zero time doing that and all my time focusing on the service logic. I don't see a downside to this.

Most of my business logic is done in raw SQL, which can be complex, but the autocomplete often helps there too. It's not helping me figure out the logic, it's simply cutting down on my typing. I don't know how anyone could be offered "do you want to have type significantly less characters on your keyboard to get the same thing done?" and say "no thanks". The AI is almost NEVER coding for me, it's just typing for me and it's awesome.

I don't care how lean your system is, there will at least be repetition in how you declare things. There will be imports, there will be dependencies. You can remove 90% of this repetitive work for almost no cost...

I've tried to use ChatGPT to "code for me", and I agree with you that it's not a good option if you're trying to do anything remotely complex and want to avoid bugs. I never do this. But integrated code suggestions (with Supermaven, NOT CoPilot) are incredibly beneficial and maybe you should just try it instead of trying to come up with theoretical arguments. I was also a non-believer once.