I've been doing a lot more serious flirting recently with the idea that I could actually create some basic games and connect them to the Hive ecosystem. With how good AI coding has gotten over the past year it seems more possible than ever. Already I have chatted with at least 3 users on Hive that weren't even coders before AI came along, but now that it has they are more confident than ever in their ability to bring ideas to life. One even went so far as to say that AI coding has been a literal, "life changing experience," for them. High praise indeed, especially when paired against the many haters of AI who often see only the forward-facing negative effects.
Many of the people I've talked to about this stuff believe that I would be a good candidate for this type of work. And, if I'm being completely honest: they are right. I actually have a bachelors degree in computer science (well close enough anyway). This is an industry that I've shown heavy interest in since freshman year of high school. The only things stopping me have been the extreme toxicity of the corporate workplace and the knowledge that you can't really build anything cool built by yourself. Even a small idea might take a team of 10 to complete. AI seems to be tipping those scales in a big way, as many coders are now reporting near 10x gains in their productivity.
One of the biggest pieces of advice I've been given across the board has been the need for a "scrutiny layer". AI makes a lot of mistakes so this entire process of coding with it becomes a game of cat and mouse. The scrutiny layer acts as a filter to catch those mistakes in an automated way before a person even has to go in there by hand to fix them.
An AI scrutiny layer (often called an AI trust, validation, or compliance layer) is an independent software tier designed to intercept, test, and filter AI model outputs before they reach production, clients, or decision-makers. It ensures AI actions are safe, defensible, and compliant.
What's more interesting is that multiple people have also given me the same advice in that you can often implement these scrutiny layers by pitting different AI models against themselves, and there are even several different strategies in which this can be accomplished.
To give an example you could tell one AI model (Grok) to roleplay as a skeptic investor of the product you just built. That agent then feeds constructive criticism to the other agent (Claude) about what is potentially wrong with the design or how it could fail or otherwise be attacked. Claude would the respond by either implementing changes to fix the flaws or perhaps give reasons why these issues aren't as big of a threat as implied.
Apparently this type of AI cross-referencing is quite valuable and effective because all these AI models are different. By cross-referencing them against each other the developer can cover the weaknesses of one model with the strengths of another, greatly reducing the time it takes to bug hunt and secure the product within the Internet Jungle.
Another thing that blew my mind a little was learning that Claude Code has a feature that lets you train the AI further for the specific project you are building. Apparently this is called a "context file" and they are quite common within the coding scene. You put markdown-based text commands into the file in order to put guardrails on AI so it doesn't keep making the same generic mistakes.
I've been seeing this context file floating around as well:
The four rules
I will paraphrase, because the principles are short and the wording is the easy part.
Think before coding. State your assumptions out loud. If the request is ambiguous, ask. If a simpler approach exists, push back. Stop when you are confused, name what is unclear, do not just pick one interpretation and run.
Simplicity first. Write the minimum code that solves the problem. No speculative abstractions. No flexibility nobody asked for. The test: would a senior engineer call this overcomplicated.
Surgical changes. Touch only what the task requires. Do not improve neighboring code. Do not refactor what is not broken. Every changed line should trace back to the request.
Goal-driven execution. Turn vague instructions into verifiable targets before writing a line. “Add validation” becomes “write tests for invalid inputs, then make them pass.”
That is it. That is the file.
First of all it looks nothing like the "recommended" file structure which I'll post now for context.
And they are also kind of common sense logic to the vast majority of software developers. Just goes to show that AI doesn't actually have a lot of common sense (if any) unless it's specifically baked into the cake. Here are the statements that really stand out to me:
AI does indeed have a tendency to give the user an answer no matter what even if the model itself knows it doesn't know. Picking the best guess is the default for an LLM, which is why they get stuff wrong so often. By eliminating that tendency in the context file I can definitely see how that could save a lot of annoyance caused by floundering about.
Similar to how Bitcoin spiked to $20k and I could no longer ignore it, so too has AI gotten to a power level that's impossible to fade. The barrier to entry for development has never been lower than it is right now, and there's no telling how much better it's going to get moving forward. I suppose it's time to get to work.
