Using AI to help with programming is becoming increasingly popular as time goes on, with developers across the industry embracing tools like Junie, GitHub Copilot, ChatGPT, and Claude to accelerate their workflow. We're seeing plenty of horror stories where things go spectacularly wrong - from subtle bugs that slip through code reviews to complete architectural disasters that require massive refactoring efforts. Security vulnerabilities introduced by AI-generated code have made headlines, and there are countless tales of junior developers blindly copying and pasting AI suggestions without understanding what the code actually does.

But who's really at fault here? Is it the AI tools themselves, user inexperience, or deeper integration issues within our development processes? To answer this question, I've deliberately tested AI coding assistants across various scenarios. And I think I've figured it out, it's a junior dev that just needs a lead dev

So you want job security in software development. Whilst your colleagues build maintainable, scalable systems that any competent developer could understand and modify, you're about to learn how to create complex systems that your organisation will never dare let you go. After all, who else could possibly understand the intricate web of dependencies you're about to weave?

The cruel irony of software development is that the better you build something, the less valuable you become. Well-architected systems with clear documentation, comprehensive tests, and intuitive design patterns practically maintain themselves. A junior developer can jump in, understand the codebase quickly, and start contributing meaningful changes. Meanwhile, the poorly-built system that requires constant nurturing, mysterious deployment rituals, and deep knowledge of its Byzantine internals? That's the one that comes with job security.

Parthenon is now available under GPLv3 and the Skeleton Application is available under the MIT License. When I was doing sales calls with companies about Parthenon part of the risk factor was what if I decided this project wasn't viable as a business. Every time, I said I would open source the code and continue to work on it. Well, I decided a year ago that I needed to change my approach and focus on a single area instead of trying to solve lots of problems as Parthenon does. So I created BillaBear, which uses Parthenon, to focus on billing. Which is actually building the billing system I wanted in Parthenon.

Today is the release of Parthenon 2.1. It's a small release putting in some nice little features before big drive to build a powerful billing system starts. It has one key feature which is the Data Export Module. Which I think will be super useful to companies that deal with data exports from their system. Then there are a few minor features which will help will small little issues.

I've started to document the design decisions made for Parthenon. One of the main decisions made was to make classes that aren't meant to be extended to be final. There are many schools of thought when it comes to development. With many people having different opinions about when and why to use final classes, I thought I would add my opinion to the mix.

Decision​

The decision was made to make classes that aren't meant to be extended final. All final classes should have an interface that matches their publicly available methods.