Codewrinkles

356 newsletter subscribers have just received the latest issue. It explores what technical excellence as a habit looks like in practice and how to build it from the first lines of code. It also confronts a question many early-stage founders avoid. Does technical excellence matter for startups, or is it a luxury reserved for later?

Make sure to not miss future issues and subscribe: architecttocto.substack.com/subscribe

1 week ago | [YT] | 5

Codewrinkles

Most architecture debates focus on code and patterns. But success or failure happens at a much higher level: choosing the right approach to component partitioning.

My observation: the way you partition components must match the way the organisation itself communicates.

Let me explain. When it comes to component partitioning we have domain partitioning and technical partitioning. Both can work. Both can fail. And success or failure actually depends more on the organisational structure than on the partitioning strategy itself.


✅If an organisation is structured around cross-functional, product-aligned teams, domain partitioning can thrive.
✅If an organisation is structured around technical layers (frontend team, backend team, DBAs, integration specialists), technical partitioning often fits the reality better.

Choosing the wrong one means architecture fights the organisation every day.

Here’s the practical side nobody teaches you: how do you detect which structure you actually have?


Look at how people talk, not how systems are drawn.
➡️If backlog items require three teams to coordinate (frontend → backend → data), you are in a layered organisation.
➡️If decisions about a business workflow require approvals from multiple technical groups, you are in a layered organisation.
➡️If developers’ identities are “I’m the API person” or “I own the database,” that’s layering in practice.
➡️If communication naturally happens inside a vertical slice (product manager → engineer → QA → design → ops), you have domain-oriented structure.
➡️If conversations start with “what the user is trying to do” instead of “which system owns it,” you have domain orientation.
➡️If one team can implement a complete workflow without waiting on other teams, that is strong evidence for domain boundaries.

It’s much easier to see the truth from communication patterns than from org charts.

And the reality is most organisations are de facto layered but market themselves as domain oriented.

Partitioning isn’t about personal preference. It’s about matching architecture to reality.

Before choosing a model, ask yourself: how does this organisation really communicate?

1 week ago (edited) | [YT] | 14

Codewrinkles

After a year using all 3 coding agents: only 1 is worth it.

I tested GitHub Copilot, Claude Code, and Devin in production workloads across two companies.

- Copilot: Seamless but shallow. Thinks in tokens, not systems.
- Devin: Autonomous but expensive. $500/month gone in a week. 15% accuracy (SWE benchmark).
- Claude Code: Reads entire repos. Reasons architecturally. Actually works.

The trade-off: Context compaction kills reliability in long sessions. But predictable failures beat expensive supervision.

That's why right now for me there's just one obvious choice in terms of value for money.

What about you?

Note: The red X-s in the picture doesn't mean that a sepcific feature does not exist. It just means that it's lightyears away from its competition.

1 week ago | [YT] | 16

Codewrinkles

I spent a year treating Copilot, Devin, and Claude Code as real teammates.

One of them was a glorified autocomplete.
One burned money faster than it wrote correct code.
One actually changed the way we build software.

319 people received a detailed breakdown in their mailboxes today. Sounds interesting? In that case, make sure to not miss future newsletters: architecttocto.substack.com/subscribe

2 weeks ago (edited) | [YT] | 7

Codewrinkles

Stop pushing back on everything. I learned this leading a team through chaos!

AI-powered features. Fast deadlines. Requirements that changed mid-week. The company wanted startup speed. The team wanted enterprise clarity.

Classic tension. The team started to default to "no":
→ "That's not possible"
→ "That will take too long"
→ "This isn't well-defined enough"

I understood the frustration. But I saw the damage as well. Stakeholders stopped coming to us with ideas. We became "the team that blocks everything."

So I reframed it for the team: delivery isn't a battle. It's a negotiation. And in any negotiation, you need leverage.

Here's how you get it: you can't push back on everything and expect anyone to listen when it actually matters. Pick your battles. The UI change that feels wasteful? Say yes. The architectural shortcut that creates real technical debt? That's where you fight!

We started saying yes to the 80% that didn't matter. We even showed enthusiasm. We delivered fast. We built trust.

Then when we pushed back on the 20% that actually mattered, the decisions that would create real problems, people listened. Within months, we went from "the blocking team" to one of the most respected teams in the division.

The lesson:
Constant pushback doesn't protect your team. It destroys your credibility. Strategic agreement creates the leverage to win the fights that matter.

Think about your last 5 pushbacks. How many actually mattered?

2 weeks ago | [YT] | 8

Codewrinkles

The Video on thee production readi AuthN and AuthZ setup I have recently worked on will be published on Wednesday, Nov 26th. I think it will be 🔥

2 weeks ago | [YT] | 19

Codewrinkles

💡Technical decision making isn’t about knowing answers. It’s about understanding trade-offs.

People often get frustrated when architects or other technical decision makers reply with “it depends.” But the truth is: it really does depend.

You can't just stop using REST and go the gRPC way because it's “always better.” You can’t Google whether microservices is the “right” style. And you definitely can’t ask ChatGPT whether an auction system should use queues or a topic. Technical decision making isn’t about picking the “best practice.”

It’s about understanding the context: deployment environment, team skills, budgets, business drivers, constraints, timelines, and even company culture.

Let's dwell on an example: a Bid Producer service needs to send bid data to three other services. You could use a topic or queues. Topics give you extensibility and decoupling. Add a new service? Just subscribe. No changes to the producer. Queues give you isolation, security boundaries, heterogeneous contracts, and better control over scaling.

Which one is “better”? Well… it depends.

❓Do you value extensibility or security more?

❓Are heterogeneous contracts a requirement or not?

❓Do you need independent auto-scaling?

❓What does the organization care about most?


Technical decision making is about the critical thinking skills that allow you to put everything into a decision matrix and come up with the right answer for that specific context. If you want to become a technical decision maker, the key is to start practicing this skill every single day.

Any time you need to decide anything in the software you create, even the smallest decisions, like choosing between an if/else or a ternary. With enough practice, you’ll eventually master it, and you’ll notice that people around you start asking more and more for your advice.

#SoftwareArchitecture #TechnicalLeadership #SystemDesign #EngineeringExcellence #TechStrategy

3 weeks ago (edited) | [YT] | 10

Codewrinkles

What would you like the topic of the video on Monday to be?

3 weeks ago | [YT] | 11

Codewrinkles

It's been almost 4 week since I started my newsletter on Substack.
Till now, I have sent out 4 newsletters in which I:

1️⃣Talked about the technical foundation we're building at Atherio, focusing on quality, security and reliability from the ground up
2️⃣Described my AI-assisted engineering framework consisting of 4 pillars: context, scope, focus and guardrails
3️⃣Explained why my CTO journey began in Excel instead of an IDE and why this actually matters a lot in software architecture and technical decision making
4️⃣Told the story of an AI feature that didn't need AI, but just a smarter query

Next Saturday, a new newsletter will land in the inbox of over 300 people. Based on the feedback I get, it seems the contents are perceived as high quality. That's why I am fairly sure YOU don't want to miss any of the future newsletters.

I'm sure you know what to do. Here's the SUBSCRIBE link: architecttocto.substack.com/subscribe

🙏If you are one of the 304 recipients of my last newsletter and you find it useful, it would be a tremendous help if you could LIKE and REPOST this post. Thank you!

3 weeks ago (edited) | [YT] | 10

Codewrinkles

‼️You’re probably using only 20% of your coding agent’s real power. Here’s the decision framework I wish I had on day one. 👇

Most developers still use their AI coding agent like a smarter autocomplete: prompt → code → repeat.

But modern agents can automate workflows, enforce architecture, standardize procedures, and integrate directly with your tools if you use the right capability for the right type of task.

Here’s the decision tree I now apply with Claude Code:

1️⃣ Repeated tasks → Use Slash Commands
Any action you run constantly like tests, linting, builds, formatting, PR checks should become a slash command. They execute repeatable work instantly, prevent mistakes, and eliminate the “did I forget something?” problem.

2️⃣ Multi-step procedures → Use Skills
Whenever a workflow must be performed the same way every time (e.g., creating components, scaffolding features, setting up modules), define a skill. It’s a step-by-step sequence your agent follows with perfect consistency, giving you standardized outputs across your entire codebase.

3️⃣ Deep analysis or architectural enforcement → Use Specialized Agents
For architecture rules, code quality evaluation, domain-specific validation, or expert-level reasoning, create focused agents. They behave like embedded specialists who enforce your standards, catch violations early, and guide less-experienced developers toward correct patterns.

4️⃣ External tool checks → Use MCPs
If you often jump to dashboards, cloud portals, quality reports, or monitoring tools, connect them to your agent through MCPs. This gives the agent direct access to your systems, removes context switching, and lets it provide recommendations based on real, live data.

5️⃣ Complex workflows → Combine them
Your most powerful automations appear when commands, skills, agents, and MCPs work together. A command can orchestrate a workflow, trigger an expert agent, and use external data to produce a complete, end-to-end analysis without manual intervention.


Why this matters:

Used well, these tools let you institutionalize team knowledge. Architecture rules, quality gates, scaffolding patterns, and infrastructure insights stop living in people’s heads and instead become reusable, automated, enforceable assets your whole team benefits from.

If you want folder structures or practical examples for commands/skills/agents/MCPs, drop a comment. Happy to share.


#AIEngineering #AIForDevelopers #DeveloperExperience #AIAutomation #CodingAgents #SoftwareArchitecture #DevTools #EngineeringExcellence #SoftwareDevelopment

3 weeks ago (edited) | [YT] | 14