We build the harness your team owns - and the architecture judgment behind it.

Two practicing software architects, 15+ years each. Small, task-based engagements - we help your team build its own way of working, AI included, instead of doing the work for you and leaving with the knowledge in our heads.

AI in the delivery

Four agents, forty times over.

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.

ArchitectedInproductionmonth 3HandedoversinceRunningwithout us

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.

AI Adoption

The AI work harness your team owns, not rents.

Every team using AI coding agents already has an agent harness - the prompts, orchestration, and guardrails your model vendor ships. That part is rented; every competitor on the same tools has it tomorrow.

What compounds is the work harness: the conventions, linters, and tests your team builds on top, specific to your codebase and your definition of done. Nobody sells that off the shelf - we help you build it, and it is yours to keep.

Read the Harness Model behind it →
Architecture

The architecture judgment that decides what's worth building.

Before any tooling question, there is an architecture question: what should this system look like, who owns which boundary, and which trade-off will you regret in a year?

We do architecture decisions and reviews, SDLC and delivery-process design, and team and role structure - independent of AI, the same craft we have practiced for 15+ years each, on distributed systems, services architectures, and platform teams.

Read how we make architecture decisions →

Start here

The blog is the practice, in the open - the artifacts we put our names behind.

The Harness Model, as we build it

The architecture craft behind it, independent of AI

Architecture

Services Architecture and Code Ownership

Ownership in a services architecture goes beyond code - it also covers design, operations, and evolution. This article covers ownership principles, supporting team structures, and common pitfalls.

·5 min read
Architecture

The Staff Engineer Toolkit

This post defines the Staff Engineer as a senior IC who leads through influence and broad technical judgment. It offers high-level guidance on architecture, communication, learning, time management, and execution, and calls out common pitfalls to avoid.

·12 min read
More from the blog →

The two of us

Maciej Laskowski and Tomasz Michalak - two practicing software architects, 15+ years each, still hands-on. We take small, task-based engagements. No full-time roles, no slow-moving, low-autonomy work.

Get in touch →
Read more about us →