“When your codebase follows consistent patterns, AI assistants become force multipliers. When it doesn’t, they become chaos amplifiers.”

Subscribe now

When you develop software as part of a team, it is all too easy to start producing code that branches off in style and accumulates different decisions for the same problems and styles.

While there is no perfect solution and entropy will inevitably make its way, you can do your best to keep it under control. Historically, defining your coding standards was one way of doing this.

As this article explains, we used to have these documents that could be used to expedite onboarding, facilitate code reviews, and enhance the overall cohesiveness of the projects we worked on.

Over the years, partially due to the introduction of automated linting tools, this practice has been forgotten, being replaced by the adoption of public rule sets, as if the coding conventions were restricted to more stylish options (tabs/spaces, folder structure) or lower-level definitions (use strict for JavaScript, etc.).

Now, as AI-assisted code becomes the norm increasingly, some of this documentation is experiencing a resurgence, even if it is now presented as prompts/instructions.

The reality is that good coding conventions go beyond the “style” of the code and present patterns to use and avoid. For a good imitator like AI, this is helpful as it reduces the chance of your assistant picking a random way based on its training data.

This rebirth of coding conventions is an incredible opportunity for teams of all sizes to revisit their current codebases and define what any new code should look like.

I find this approach very powerful as it enables you to perform some interesting and, otherwise time time-consuming refactoring.

For example, one of my conventions is to favor single assertion tests. This helps me keep the scope narrow and showcases potential opportunities to reshape the code if I find myself having to assert too much.

My standards define the following

Now I can come to an existing codebase and ask it to refactor according to the new (or previously overlooked) standards. And it gets me this

In real life, I would do such a refactor in small increments to make sure I can still review the changes. Even if the result still passes the tests, I find it important to still keep the human in the loop.

We stopped roadmap work for a week and fixed 189 bugs

“There is nothing more permanent than a temporary solution.”

The reality of software development is interesting. No one really knows all the steps needed to get from A to Z, which includes the technical and non-technical aspects of any non-trivial solution.

We adopt, or pretend to, agile methodologies as our best effort to accommodate that undeniable truth. Work on a small increment, learn more, and adapt for the next cycle.

Unfortunately, at least 2 things tend to happen and derail this approach from being executed:

• Too many priority changes - rightfully or I-did-not-do-it-when-I-should-have kind of changes.

• Incorrect past decisions are not addressed - tech debt or cruft are not taken care of, building on top of each other over time.

I am a fan of the “Boy Scout” approach, leaving something in a better shape than I found it. This works best for very small things, adding comments to describe why we are doing things in a certain way, targeted refactorings, and adding or improving the test suite.

Anything bigger tends to make your actual task balloon and compromise your goals.

For those, you have to be more conscious, and my advice is to bake these more foundational changes as part of your plans for incoming features.

But is there anything in between those two approaches? As this article mentions, FixIt weeks are there for you! :)

The idea is not necessarily novel, and the gist of it is to reserve a full week, once a quarter, dedicated to addressing small changes: productivity, bugs, or small annoyances that never get prioritized.

For this to take place, strict rules must be established and followed: no action should take more than Xh, and work should be focused on developer productivity or small end-user bugs/features.

This way, you avoid FixIt week from becoming a vanity effort or a pursuit of technical purity for its own sake. All things done will have a measurable direct or indirect impact on customers. Developer productivity helps you to achieve more, and those small fixes cater to customer needs.

One important thing to highlight is that FixIt weeks will not solve your architectural or process shortcomings. You are never going to catch up if you keep adding more cruft due to poor decision-making.

So, talk to your product team, establish your rules, and give it a try. Inspect and adapt!

Progress on TypeScript 7

TypeScript has been gaining momentum for a while, and earlier this year, Microsoft announced an initiative to port its tooling from TypeScript itself to Go.

The move aims to deliver up to a 10x increase in the build time, not the actual execution of the generated code.

In a recent article, we got some news on its state and the strategy around the current 5.x version.

The next version will be 6.0 and mark the last release of the original tooling codebase. Besides bug fixes, no new features will be added, with efforts focused on finalizing the feature gap on the 7.0 toolset.

If you want to try, you can use the Visual Studio Code extension or install a nightly preview.

npm install -D @typescript/native-preview

As the adoption of Typescript by bigger and bigger projects, it is nice to see improvements of this magnitude happening.

CloudFlare 2025 Year in Review

CloudFlare is a well-known and highly used CDN, bot traffic mitigation, and computing offering solution.

It released a review of 2025 internet traffic, including several categories. While it does not account for the entire internet, it is so common that its numbers can be used as a proxy to understand the current state and some trends.

Some of the numbers that I found interesting or even surprising are:

HTTP version 2 and 3 adoption

HTTP/2 reached 50% usage after 10 years of being introduced, and HTTP/3, despite being less than 2 years old, already reached 21%. I was not expecting this number, getting closer to the HTTP/1.x so quickly.

Internet Growth

Even after being around for quite some time, internet usage continues to grow at double digits.

AI bots

As the AI bots are used to crawl and search sites, the number of domains partially or completely disallowing access has increased throughout the year.

Programming Language

Another year passes, and PHP remains in the top spot of the programming language used for website development. So much for PHP is dead! :) Node.js still maintains the second place.

I recommend reading the full radar version, which offers many interactive features and allows you to drill down even further on the highlights I picked.

This will be the last Architecture Corner Newsletter of 2025! I hope you enjoyed this edition, and if you are also looking for more in-depth articles, please follow me here.