Python, Software Development, and Tools — Digest #60
I’ve gone back and forth on Hexagonal vs Clean Architecture for years, and this one finally made the distinction click for me. The author’s…

Python, Software Development, and Tools — Digest #60
I’ve gone back and forth on Hexagonal vs Clean Architecture for years, and this one finally made the distinction click for me. The author’s point is that even if both end up looking similar on disk, the Ports-and-Adapters mindset — where Django is just a swappable detail bolted onto your domain — is what actually keeps you honest about isolating business logic. Worth a read if you’ve ever felt your “domain” code quietly turn into a pile of Django models.
This hit a nerve. The claim is that what holds devs back from becoming architects isn’t skill, it’s still thinking in code instead of systems — and I’ve definitely caught myself asking “where does this file go?” instead of “how should this behave as it grows.” It pins the shift to 2026 realities (async Django, LLMs everywhere, event-driven, modular monoliths), and I’m curious where the rest of the series goes.
Timely for me, since my own .claude/ folder had quietly turned into the junk drawer the author warns about. The takeaway I’m taking to heart: treat it like real project infrastructure — separate broad instructions from specific rules, reusable workflows from automated hooks, team standards from my personal tweaks. Going to do a cleanup pass after reading this.
I like that this comes from the Fowler camp, because it treats AI coding as something you can actually govern at team scale instead of vibes. The idea is to version your prompts like code and keep them in sync — and the rule that stuck with me is “when reality diverges, fix the prompt first, then the code.” It’s honest about not being for everything (skip it for hotfixes and exploratory spikes), which made me trust it more.
The clearest mental map I’ve seen of how a frontier model actually gets built, start to finish — data, tokenization, pretraining, the three post-training stages, then inference and alignment. The bit I keep repeating to people: pretraining burns ~60% of the cost, but the quality really comes from data, preference tuning, and reasoning RL. The lab-by-lab breakdown (Anthropic leaning into post-training/alignment, OpenAI on reasoning, etc.) is a nice bonus.
A fun one because it leans into how I actually work now — Claude for planning, Cursor for the codebase. Here it’s Claude doing the “reward engineering” (designing rewards, sniffing out reward-hacking) and Cursor scaffolding the Gymnasium env and debugging the training curves. The line that stuck: in RL “code can run perfectly while the agent learns nothing” — which is exactly the kind of bug that makes RL 1miserable to debug solo.
메타데이터
- post_id
- 4e866560c6f2
- slug
- python-software-development-and-tools-digest-60-4e866560c6f2
- url
- https://medium.com/@denis.volokh/python-software-development-and-tools-digest-60-4e866560c6f2
- canonical_url
- https://medium.com/@denis.volokh/python-software-development-and-tools-digest-60-4e866560c6f2
- author_url
- https://medium.com/@denis.volokh
- status
- ok
- fetched_at
- 2026-06-09 15:37:30