ai_goodpractice: one developer's guide to an AI-first coding workflow

A repository that is one README and nothing else

ai_goodpractice is described as a full guide to help you integrate AI in your workflow, for both beginners and experienced users. The repository contains exactly two entries, .gitattributes and README.md, and the README is the project. There is no code, no example repository, no configuration to copy, and no test suite, and the project metadata does not even record a primary language or a licence.

That shape is stated rather than hidden. The guide opens with a disclaimer explaining that it is fully hand-written, that there was zero prompting involved in the thinking or the creation of it, and that the author believes AI could never express their own thoughts and lifestyle as well as they can no matter how well it is prompted. Everything in it is presented as the author's own experience and views, with the invitation to think for yourself and to share it if it speaks to you.

The scale of the claim is worth stating plainly, because a reader will notice it. The author says they have used AI for more than eight hours per working day for a number of months, that they were previously somewhat against fully agentic workflows, and that they would now almost never go back to normal coding. The stated benefit is to multiply work power by ten or twenty, and to be able to achieve any project within six months where before it might have taken a year or two.

These are the author's figures for their own work, published without measurement, and the repository has no release history to speak of. The last push was on 2026-10-02 and there are no tags, so the guide has been revised in place.

Three steps, and the step the author says people skip

The guide has a stated structure of three steps, and the second one is where the practical content lives.

Step one is setup. You download an AI integrated editor or assistant, and the guide names Cursor, VS Code, Claude Code and ChatGPT as examples. Then you think of the AI as a partner who may be more skilled than you overall but less skilled in specific areas, which is why prompting is treated as extremely important. The advice is to put yourself in the AI's position on every prompt and ask how easy it would be to understand what your boss expects, refining and adding context when the answer is no. The third instruction is proper setup of the environment, and the author is emphatic that this is underrated and the most important step, and that many people do not bother, with a claim that it makes the experience twenty times better.

Step two is the practice section, headed Rules, Skills and MCPs, and the framing is a risk one. Whenever you start a new project or bring AI into an existing one, the point is to think of all the possible ends of the project and how the AI could drift away from what you want, and to gate that. The first example given is a coding style rule derived from an attached folder or URL and applied as a rule for the repository, and the guide immediately annotates it as not the best example.

The third step is where the guide says it will cover time management and how to never work again, which is the least technical part of the document and the part a reader is most likely to skip.

Rules written with the model, and the question of where they live

The prompt examples in the rules section are more instructive than the advice around them, because the author critiques his own first attempt.

The first version asks the model to build a code style rule from an attached folder path or URL and apply it as a rule for the repository. The author marks it as not the best example, and the improved version asks the model to analyse the code style from the attached path or URL in depth and apply it as a rule for the repository, with the explanation that this is a much better prompt because it has no redundancy and it asks for depth. The difference between the two sentences is the whole lesson: name the depth you want, do not repeat yourself, and point at a specific source.

There is also a longer example about test rules, stating that temporary tests should be deleted or cleaned up afterwards inside a tests/temp directory, that the long term tests should sit in one directory named tests and be kept clean, and that the tests should be kept minimal and target exactly what is desired. That is a concrete, checkable instruction, which is the kind of thing that works as a rule.

The open question the guide raises without settling is scope. You have to decide whether a rule is a user rule or a repository rule, and the author's own leaning is that code style and similar things fit better inside the repository, particularly when you work on several projects with different styles. The repository-level answer has a practical consequence for teams, since a rule that lives in the repository is reviewable in a pull request and shared with everyone, while a rule in your own configuration travels with you and is invisible to your colleagues.

There are also rules for coding practice itself, including a preference for implementing logic cleanly inside its own functions, for keeping helper use to a minimum, and for storing anything meant to be shared inside a helpers folder, with the folder structure copied from a reference repository.

The endurance argument, and the model dependency

A section of the guide is about physiology, and it is the part with the least support and the most confidence. The author describes learning about prompt hacks and physiology based ideas that they use daily to improve the workflow and withstand a full day of non-stop working, up to sixteen hours or more, without pharmaceutical aids. The promise is that you can reach full usage on all your subscriptions every month and get true work done with AI.

That is a personal endurance claim, and it should be read as one. Nothing in the repository presents a method, a measurement or any evidence for the figures, and the guide itself says the author does not claim to have found the best way to prompt or use AI, that the result is heavily model dependent, and that people who have actually worked on improving AI systems probably understand prompting better than they do. The invitation to contact the author on X to discuss and improve the guide is a sign of good faith about the limits of the document.

The model dependency is concrete rather than abstract, though. The reference setup is Cursor with a mix of Claude, ChatGPT and Grok, and previously Composer. So the advice is really advice about a specific combination of tools, and the tools change faster than the guide does. A reader who takes the prompting advice and applies it to a different model, or to a different coding agent, should expect to re-derive some of it.

The other thread the guide touches on is the role change, and it is the part most likely to make a reader uncomfortable. The claim is that you should not think of yourself as a programmer any more but as a leader or manager, that you become a translator between the idea and the model, and that you should ditch the idea that you will code anything. The guide also insists this is not a reason to stop learning, which is the thread it says it will return to later.

What a reader can take from it, and what to check first

The honest summary is that this is a well-organised personal account with a useful sequence and an unverified headline, and the value of reading it depends on which of those you need.

What it gives you is a starting order that is easy to adopt: choose a tool, set up the environment properly rather than skipping it, and write the rules that stop the agent drifting, and it gives you that last part as prompts you can copy and adapt, with a worked example of a weak prompt next to a stronger one. It also raises the questions a team has to answer anyway, such as whether a rule belongs to the repository or to the person, and it is honest about being model dependent and about the fact that the author expects others to know more about this than they do.

What it does not give you is evidence, tooling, or a safety story. The productivity figures are unmeasured, the six month claim and the twenty times better setup claim are assertions, and the guide says nothing about where your code goes once it is in a hosted assistant, which is the first question a team with a policy on third-party data handling has to answer. It also says nothing about review, testing or verification of generated code, beyond the mention of a rules approach to temporary tests.

So the sensible way to use it is as a prompt to your own process rather than as a standard to follow. Pick one of the rules examples, apply it to a small side project rather than a live codebase, and see whether the agent actually drifts less. Write down where your rules live. Check what your model vendor does with your code before you send a private repository through a hosted assistant, because no guide can answer that for you. And if you are the kind of reader the author invites, the guide is an open document, and the missing licence means you cannot reuse its text without asking.

Editorial conclusion

ai_goodpractice fits a developer who is curious about an agent-first workflow and wants a concrete starting order, because the setup, then the rules, then the endurance advice is a usable sequence, and the prompt examples come with the author's own critique of the weaker ones. It is the wrong tool for anything that needs evidence, since the throughput and productivity claims are unmeasured personal impressions, and it is the wrong tool if you work under a policy about what may be sent to a hosted model, because the guide assumes a hosted assistant and says nothing about data handling. Before you adopt any of it, test the prompting advice on a small task of your own rather than a real project, decide where your rules should live, the repository or your user configuration, since the guide raises that question and does not settle it, and read the model dependency section, because the advice is explicitly tied to the models the author was using at the time.

Frequently asked questions

Official sources

1. Issues
2. README
3. xop01/ai_goodpractice on GitHub