Amazing CTO
In my latest project, a Coaching Operating System to make my CTO coaching operation smoother due to a big influx of new clients, I came to the point to no longer look at code I ship. And it works.
This sounds incredible. But it works.
Let’s look at some reasons why this works:
I have 40 years of coding experience in many different languages and frameworks. I might be able to write better prompts because I know what can go wrong.
Agile work - small changes, I check the result and if I like it, I change it if not. I ship it if I like it.
Use Claude Code plan mode for everything. Iterate on the plan, not on the prompt. I write my requirements into Claude Code plan mode. I read the plan, I add or remove requirements until I’m happy with the plan. I tell Claude in plan mode to finally check the code and the documetnation (with URLs) to make sure the plan works. I tell Claude Code to check if there is pre-existing functionality to reuse. Then I tell Claude to start coding.
I have many tests in place. After each feature, I ask Claude Code to refactor the bew code to extract side effect free funtions and write code for them. Claude Code runs the tests after changes and I told it to decide for faling tests if the tests need to be adapted or the code has a bug.
The stack I use is very simple: Go, Alpine.js and HTMX. It might be the case that with the compiler, the very simple language of Go and most often there is only one simple way to do things in Go, Claude Code works better than with other languages.
My build process includes all the Go linters like govet, goimports, gosec, golangci-lint, nilaway, govulncheck, and staticcheck. CLAUDE.md tells Claude Code to run the “make lint” target after it finished up coding and fix the problems.
The working model is: Let the LLM code, code, code, then refactor. The LLM is a probability machine, if creates the code that is most probable for the existing codebase. Starting from scratch, or with a bad codebase, the LLM will make it much worse. LLM, LLM, LLM, refactor, LLM, LLM, LLM, refactor leads to good code. With bad code, LLMs come to a point where they can’t move forward, because one thing breaks and the fix breaks something else.
This is a game of trust. Many developers do not trust an LLM. My question is: Do you trust your coworkers? If you do, why?
The setup works very well for greenfield projects and is very suitable for startups. Hire experienced senior developers and you will be able to let LLMs write most of the code.
I would not trust AIs with the core of my existing system, in fintech, healhtec etc. or other CTO positions I’ve held in the past.
The key is to have proper guardrails in place. Think of the old times, a Head of QA gave green or red light for a release based on the guardrails - tests, not by looking at the code.
