I see a lot of people complaining that AI is killing craftsmanship, but I not only disagree with them... I also think it may mean the opposite.
When I started coding professionally 10 years ago, I had two mentors, Marcus and Herbert, who taught me from the first day what were the best practices and how to make software a craft. They insisted on that many times, and just now I see how lucky I was, not only by having a mentor (not one, but two!), but by setting my mind to a craft from the first day.
By craft I mean a lot of good practices, but also the pragmatism of choosing when to apply those practices. Some of them, for instance:
- Testing before code (not necessarily TDD, although I used that most of the time)
- Regression tests for any bug found
- Code reviews
- Dev environment, test environment, staging environment
- Getting the best of industry (famous?) references, like 12factor and Clean Code
- Sticking to some standards like Semantic Versioning, Conventional commits, pep8, etc.
- Automations, not only in CI/CD, but on all toil work, and share it with colleagues
- Over-communication (soft skills were also considered on that package)
And many more.
The main point I hear when people tell about how bad is the craft right now, is that people just ask AI to do the thing and push.
Back then that would be the same problem as just copy-pasting code from Stack Overflow, or not actually have interest in the problems they are solving. This mentality would just produce the same bad results 10x'ed right now, because coding is the easiest part of the job.
But the other things I mentioned as good practices, all of them are also 10x cheaper to apply right now.
Let me give you an example. When communicating with my colleagues, I often lost some precious minutes just tailoring my messages so I could be as clear as possible on what I just implemented. Now this cost is almost zero, I just run a skill and get what was done in a session. I just need to make some small adjustments on the output, and some times not even that.
Testing before code is much better now, not to say about all the other things. Back then, crafting had always a cost, a tradeoff, but now, not doing it is not doing your job.
There are still challenging parts to craftsmanship, and I think the main one is reviewing, because now only devs are the gates for the AI slop into the codebase. And reviewing is much harder, as the things AI misses are usually not obvious to the human eye.
I want to discuss this a lot more, so I will create a series of posts on how I see each of these practices being applied in the post-LLM world.
The full list of practices I think of as craftsmanship
Here is the (almost) full list of practices I think of as craftsmanship:
Technical practices
- Testing before code (Not only TDD, but the practice of "testing the test", by making it fail first)
- Regression tests for bugs
- Code reviews
- Pair/mob programming: knowledge sharing and real-time review
- Refactoring as a habit: continuous improvement of existing code
- Architectural decoupling: keeping the codebase modular and easy to understand
- Small, incremental commits/PRs: keeping changes reviewable and reversible
- Monitoring and observability: logging, tracing, alerting
- Documentation as code: ADRs (Architecture Decision Records), runbooks, keeping docs close to the code
- Dependency management: keeping dependencies updated, auditing for vulnerabilities
- Feature flags / trunk-based development: decoupling deploy from release
Environment and standards
- Dev environment, test environment, staging environment
- Sticking to standards like Semantic Versioning, Conventional Commits, pep8, etc.
- Getting the best of industry references like 12factor, SOLID principles and Clean Code
- Automations, not only in CI/CD, but on all toil work, and share it with colleagues
Design practices
- Domain-driven design thinking: ubiquitous language, bounded contexts
- YAGNI / simplicity: resisting premature abstraction
- Backwards compatibility awareness: thinking about consumers of your APIs/interfaces
Process and culture
- Over-communication (soft skills are also part of the package)
- Blameless postmortems / incident reviews: learning from failures systematically
- On-call ownership: "you build it, you run it"
- Boy Scout Rule: leave the code better than you found it
- Saying no or pushing back on scope: pragmatism about what to build at all