Why the Hardest Part of AI-Assisted Engineering Isn't the AI

At MasterBorn, we like our engineers to treat how they work with AI as a craft worth iterating on, not a settled question, and we're seeing more of that experimentation across the team. Błażej Bryła, one of our developers, has spent the past few months rebuilding how he works with Claude Code around exactly that idea, and we asked him to walk through it. Here it is, in his own words.

There's a lot of noise right now about AI coding assistants: demos where a model writes a whole feature in seconds, or horror stories about "AI slop" flooding pull requests. Neither picture matches what I've actually seen in my own day-to-day work.

The real story is less dramatic and more useful: once you stop treating an AI coding assistant as an autocomplete engine and start treating it as a team member that needs the same things a junior engineer needs (a clear brief, guardrails, and a review process), the results change completely.

The Core Shift: Planning Is the Bottleneck, Not Code

The single biggest change in how I work isn't about prompting tricks. It's a shift in where the effort goes.

Roughly 80% of the time spent on a typical task is now planning: scoping the problem, defining what "done" looks like, cutting work into small pieces with explicit dependencies, and making the handful of decisions that actually matter. Writing the code itself is comparatively the easy part.

That's not a bug in the process: it's the whole point.

Code has become cheap to produce. The scarce resource is precise knowledge of what should be built. An hour spent tightening the plan reliably saves a half-day of refactoring work done in the wrong place.

Precision compounds. A well-scoped plan with explicit boundaries leaves the model very little room to improvise, and improvisation is where most AI-generated mistakes come from. The failures I've seen have almost always traced back to an under-specified task, not a "bad" AI output.

Planning artifacts outlive the code. A good spec doesn't just produce one pull request. It becomes the reference document a reviewer uses on the PR, and the map someone reaches for when a related bug shows up weeks later.

In practice, this means the workflow actively resists rushing. Ticket generation won't run without at least one round of structured questioning about scope first. Implementation stops and reports back if a ticket is too vague to act on, rather than quietly filling in the gaps itself. It's a small design choice with an outsized effect: it makes "moving fast" and "thinking carefully" the same thing instead of a trade-off.

Architecture: A Thin Decision-Maker, Surrounded by Disposable Workers

One pattern makes the biggest practical difference: the main conversation with the AI never does research itself.

Instead of one long conversation accumulating context (pulled-in tickets, scanned repositories, pasted logs), the orchestrating session stays lean. It makes decisions, writes production code, and talks to me. Any task that's essentially "go fetch information" is delegated to a disposable subagent that works in its own clean context window and reports back a short synthesis, never the raw material.

That single rule solves a problem that quietly undermines a lot of AI-assisted workflows: context pollution. A model that has spent its window reading forty files has less room, and less clarity, left to make good decisions with. Keeping the "gatherer" work separate from the "decider" work keeps the decision-maker sharp for far longer, and lets the more expensive reasoning happen only where it's actually needed.

The specialized workers are also given hard constraints on what they're allowed to return. A code-exploration agent, for example, is explicitly instructed never to dump raw file contents, never to propose a fix, and never to rank code quality; it only reports where things live, how they connect, and what it couldn't find. That discipline keeps every report compact and directly usable by the next step.

State Lives on Disk, Not in the Conversation

Long AI sessions eventually hit a wall: context windows fill up, and quality degrades well before you hit the hard limit. Rather than fight that, the workflow is built to expect it.

Every task gets its own working directory holding the state of that work: a scoped brief, a specification, individual ticket files with explicit dependency relationships, and review notes. Each step in the process checks that directory first and picks up from the first missing piece, rather than assuming anything about what happened earlier in the conversation.

The practical result is that clearing the conversation and starting fresh is no longer a risky recovery move: it's a routine, low-cost action. If a session is getting long, I write a short handoff document, clear the context, and resume from the file. Nothing is lost, because nothing important lived only in the conversation to begin with.

Matching the Model to the Job

Not every task deserves the same (or the most expensive) model. Writing a commit message and making an architectural call that will be expensive to reverse are very different jobs, and the workflow routes them differently: lightweight, fast models handle mechanical work like commit messages; a balanced model handles well-defined but token-heavy implementation work; and the most capable, slower model is reserved for the judgment calls (architecture decisions, security review, root-cause diagnosis) where a mistake is costly.

This isn't just a cost optimization, though it is that too. It reflects a broader principle worth stating plainly: not all AI-assisted work carries the same risk, and treating it that way (spending your most expensive reasoning on your cheapest decisions) is how teams end up with both slow workflows and worse outcomes.

The Guardrails That Keep Humans Genuinely in the Loop

Two practices in this workflow stand out because they directly address the two things people worry about most with AI-generated code: unreviewed quality, and engineers who ship code they don't actually understand.

Sized code review, every time. Before any code is committed, it goes through a review step, but the depth of that review scales with the size and risk of the change. A small, low-risk change gets a single fast pass; anything touching authentication, money flows, data migrations, or shared infrastructure automatically triggers a deeper, multi-angle review. This "sizing gate" means review rigor is proportional to actual risk, instead of either rubber-stamping everything or over-reviewing trivial changes.

A "teach gate" before every commit. This is the practice we think matters most, and it's simple: before any change is committed, the engineer is quizzed on the diff (what changed, how, and why) at a level of depth they choose. Get an answer wrong, and the explanation restarts at a more fundamental level rather than just marking it incorrect. The rule behind it is blunt: nothing gets merged that the person shipping it can't defend in a code review.

The Bigger Lesson

None of this is really about one tool. It's a template for how to bring AI meaningfully into a technical workflow without either overselling it or getting burned by it:

1. Spend effort on precision, not typing speed. The plan is the leverage point, not how fast the code appears.

2. Separate deciding from gathering. Keep the parts that make decisions apart from the parts that fetch information.

3. Put state where it survives a reset. So recovery is cheap and routine, not a crisis.

4. Match reasoning cost to risk. Spend your most expensive judgment on your riskiest decisions, not on every task equally.

5. Require proof of understanding before shipping. A human should be able to defend what goes out the door.

What This Actually Shows

Strip away the specific tool and this workflow is really a case study in one idea: AI doesn't remove the need for engineering discipline: it raises the price of not having any.

A few things stand out, and I think they generalize well beyond my own workflow:

Maturity shows up as process, not as tool choice. Anyone can wire an AI assistant into their editor in an afternoon. The gap between "we tried AI coding" and "AI coding measurably improved our delivery" is entirely made up of the boring parts: how work is scoped, where state lives, who reviews what, and what happens before something ships. That's a process problem before it's a technology problem: the same category of problem we help clients solve when we design outcome-focused AI implementations for their business processes, not just their engineering teams.

Human oversight gets stronger, not weaker, when it's built into the architecture. The instinct with AI tools is often to either lock everything down with manual approval on every step, or let the model run free and hope for the best. This workflow lands somewhere more useful: cheap, disposable delegation for information-gathering, paired with hard checkpoints exactly where a mistake would be expensive. That's the same "AI suggests, human decides" pattern that shows up in every well-run AI deployment we've seen, regardless of industry.

The best AI workflows are designed to be interrupted. Sessions get cleared, context runs out, priorities shift mid-task. A workflow that assumes a clean, uninterrupted run from start to finish will break constantly in practice. One built to resume from a checkpoint, at any point, barely notices. That resilience is what turns a clever demo into something a team can actually depend on every day.

For engineers, this is also a signal about the kind of rigor I think matters when working with AI: not just being able to prompt a model to produce code, but bringing the same discipline to it that you'd bring to any other part of the craft: scoping problems precisely, building in checkpoints, and being able to explain and defend what you ship.

These are the same principles we bring to the AI implementations we build for our clients: the technology is rarely the hard part. The discipline around how you use it is.