Two practicing software architects for the architecture decisions behind your AI rollout.

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.

The system still needs a decision

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.

Two services

AI Adoption

A work harness your engineers write, run, and maintain.

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.

AI Adoption service →
Architecture

The architecture judgment that decides what's worth building.

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.

Architecture service →

How we work together

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.

See the first engagement options →

From our practice

AI in the delivery

More testing. The same short wait.

Runner, Planner, Implementer and Reviewer in a loop ending in results, with feedback flowing back to improve the tests and the agents
Runner, Planner, Implementer and Reviewer in a loop ending in results, with feedback flowing back to improve the tests and the agents

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.

AI in the product

Handed over. Running without us.

Architect, build, isolate, hand over, running: the AI layer is isolated to contain model and framework churn, then the project is handed to the in-house team and has run independently since, on a stable core system throughout
Architect, build, isolate, hand over, running: the AI layer is isolated to contain model and framework churn, then the project is handed to the in-house team and has run independently since, on a stable core system throughout

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.

Start here

The blog is the practice, in the open - the artifacts we put our names behind. Choose the question closest to yours.

Architecture

Who should own each service and its decisions?

Services Architecture and Code Ownership

Examine how system boundaries, team responsibilities, and operational ownership fit together.

·5 min read
More from the blog →

The two of us

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 Laskowski

Maciej Laskowski

Software Architect

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.

Tomasz Michalak

Tomasz Michalak

Software Architect

Tomasz is especially drawn to how a system behaves in production: how it handles load and failure, and what it asks of the team operating it. He brings that perspective into system design, testing the options against the conditions in which the software must run.

Read more about us →

Get in touch

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 →