I know what you mean. Quite often when I’ve worked in a project where there is a pull request template, a lot of the time people don’t bother to fill it out. However, in an ideal world, people would be proud of the work that they’ve delivered, and take the time to describe the changes when raising a pull request.

I’m not an architect, but I do dislike how much of development work has AWS wrangling, dealing with the architectural hoops that are mentioned in the article

Things are getting easier. Many of the JavaScript runtimes support TypeScript out of the box now.

Back in the day, I used CakePHP to build websites, and it had a tool that could “bake” all the boilerplate code.

You could use a snippet engine or templates with your editor, but unless you get a lot of reuse out of them, it’s probably easier and quicker to use an LLM for the boilerplate.

I also make use of ‘⚠’ to mark significant/blocking comments and bullet points. Other labels, like or similar to conventional comment prefixes, like “thought:” or “note:”, can indicate other priorities and significance of comments.

Thank you for introducing me to conventional comments! I hadn’t heard of them before, and I can see how they’d be really useful, particularly in a neurodiverse team.

How does one measure code quality? I’m a big advocate of linting, and have used rules including cyclomatic complexity, but is that, or tools such as SonarQube, an effective measure of quality? You can code that passes those checks, but what if it doesn’t address the acceptance criteria - is it still quality code then?

There is Whisper IME.

A good companion piece to this article, is the Dead Framework Theory article, which discusses AI coding tools bolstering React’s dominance.

The author does make some good points about colours as visual cues, instead of just making things look colourful. I have to admit prior to reading this post, I always picked my themes on aesthetics, but it has made me think about colour as utility.

These are all very good points, and there is in value of having a common framework for front-end development. However, I would argue React isn’t always the right tool for the job, yet it has become the dominant framework, and that dominance is being further bolstered because of generative AI.

This isn’t about React being the best tool or that it’s Model is good for LLMs (I don’t see any evidence there at all). It’s about React being past the point where network effects make alternatives viable.

So even if a better framework came along, and ideally one that’s not owned by Meta, it would be very difficult for it to take hold because of this.

Exactly but generative AI has exacerbated the problem

What is new is the scale of the problem being created as lightning-speed code generators spew reams of unread code into millions of projects

After a bit of experimentation, I’ve managed to find a cleaner solution to enforcing the ticket number in the subject:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // Enforce scope to match JIRA ticket format like PER-123
    'jira-ticket-rule': [2, 'always'],
    'subject-case': [0],
  },
  plugins: [
    {
      rules: {
        'jira-ticket-rule': ({ subject }) => {
          return [
             subject && subject.match(/[A-Z]+-\d+/),
            'Your subject should contain a JIRA ticket eg PER-123',
          ];
        },
      },
    },
  ],
};