Below is an ever-expanding set of guidelines we adopt in our engineering org at Brainbase.
How to use this guideline effectively?
Problems with multiple correct solutions. The primary purpose of these rules are to remove or significantly reduce uncertainty in engineering problems where multiple solutions could be correct, which are most problems. When faced with these problems, you can use the following rules as tie-breakers, where the solution fitting most (preferable all) of these rules should be implemented.
Writing specs. A secondary benefit of these guidelines are that you internalize them in coming up with better engineering problems to solve.
Rules
- Do not code manually: Human coding is now simply too slow. I like Andrej Karpathy’s view that code has now become a compiled artifact similar to machine code or binary, it’s simply something that is low leverage to be working with directly. If you are writing code manually, you are doing something wrong.
- Your job is theory of mind: Engineering is the job of specifying a problem such that your compilation tool of choice can compile it into your compiled artifact of choice. Previously, your means of specification was through code, where your job was to write out your instructions in a specific syntax that your compiler could understand and convert it to binary. In many ways, your job now is much the same. The difference is that your compiler of choice is now an LLM, and your responsibility is now to specify your problem in a way that is “syntactically correct” for models. For a model, syntactical correctness has less to do with regex and more to do with removing cognitive blockers. The most important question to ask at every step is “What does the LLM not know?”.
- Work in milestones
- Work in vertical slices