Who should own each service and its decisions?
Services Architecture and Code Ownership
Examine how system boundaries, team responsibilities, and operational ownership fit together.
Your team has AI coding tools, but using them well raises questions about system boundaries, verification, and what work to delegate. We help you work through those questions. We each bring 15+ years of practice, in small, task-based engagements.
What should this system look like, who owns each boundary, and which trade-off will you regret in a year? We compare the options, name what each one costs and forecloses, and give you our recommendation. The decision stays yours.
AI coding agents come with an agent harness - the prompts, orchestration, and guardrails your model vendor ships. The work harness is the conventions, linters, and tests your team builds on top, specific to your codebase and your definition of done.
We work through it with your engineers in working sessions and review the result. Your engineers write it; it lives in your repository. We read code and advise on the architectural boundaries and verification the work needs.
We do architecture decisions and scoped reviews, SDLC and delivery-process design, and team and role structure. We examine the options, operating constraints, and consequences for the people who will live with the result.
You get our recommendation and its reasoning, including the alternatives and questions still open. We agree the boundaries of the work upfront. The scope can be a re-platform, a split, an integration, or a delivery process that no longer fits. The decision stays yours.
Most of our work is one engagement with both of us on it. Whoever is closer to the problem leads; the other one pressure-tests.
We start with one bounded question and a written output. At the end, you decide whether to continue, change the shape, or stop - with no obligation to a next stage.
The automated test suite grew while its execution time stayed roughly constant. Clearer specifications, AI coding agents, and improvements to the testing infrastructure worked together. Planner proposes, Implementer writes, Reviewer checks the diff against style, contract and the existing test corpus, Runner verifies against real systems - all three running unattended after a single human gate on the plan. Closing the loop like this took code review off a human's desk for every generated test and put it inside the loop instead: four checks per pass, coverage grew fivefold, and commits per test step fell from 0.78 to 0.17 as suites matured. The method and the charts are in E2E test harness for AI agents.
An AI-agent platform for a 10M-user enterprise, architected and taken to production, then handed to the client's in-house team after three months — operated independently ever since. The volatile AI layer was isolated so model and framework churn could not cascade through the rest of the system. One problem that work surfaced — cost, not throughput, as the thing rate limiting has to protect — turned into a three-part series, Denial of Wallet.
The blog is the practice, in the open - the artifacts we put our names behind. Choose the question closest to yours.
Who should own each service and its decisions?
Examine how system boundaries, team responsibilities, and operational ownership fit together.
Where should we focus our AI-adoption work?
Inspect the public assessment model we use in engagements, including its questions and stated limits.
How can we check that code respects our architecture?
Follow a worked example of module dependency rules enforced by automated tests.
What do our AI coding tools leave for us to build?
Understand the vendor's contribution and the codebase-specific work your team must maintain.
Hands-on Architects is the joint practice of Maciej Laskowski and Tomasz Michalak. You work directly with us, from the first conversation through the engagement.
Maciej is especially drawn to the shape of a system: which boundaries make sense, which options are worth considering, and what each trade-off means over time. He brings that perspective to the team's decisions while considering how the system will be built, operated, and changed.
Tell us what you're deciding - an architecture call, a review, a delivery-process or AI-adoption question - and we'll tell you plainly whether we're the right fit.
Get in touch →





