Work architecture: how I stopped treating eight projects as eight different problems

I used to think about project architecture mainly as a technical decision.

Choose the stack, organize folders, split services, decide where each responsibility lives.

Today I look at architecture much more broadly.

To me, architecture is also how work enters the system, how it is understood, how it becomes a decision, how it becomes a task, and how it eventually becomes execution.

That shift in perspective is what made it possible for me to work across several fronts at the same time — software, automations, internal tools, and even games — without feeling like I have to relearn how to work every time I switch projects.

Today I can keep something close to eight projects moving in parallel with a curious feeling:

it does not feel like I am working on eight different systems. It feels like I am applying the same working system to eight different contexts.

And that difference changed the way I build things.

Before, every project started from zero

For a long time, my process was much more direct.

I had an idea.

I explained the idea.

I opened an agent, gave it the context, and started building.

That works surprisingly well for small things.

The problem starts when the project grows.

Old decisions appear that nobody remembers, features start depending on one another, bugs turn out to be requirement problems, things that once looked important stop being important, new ideas show up in the middle of the work, and changes begin affecting several parts of the system at once.

At that point, having a good agent or writing a better prompt is no longer enough.

The problem stops being "how do I implement this?" and becomes:

how do I organize all of this without losing the original product intent?

That is when practices I only understood superficially started making much more sense: PRDs, backlogs, acceptance criteria, roadmaps, discovery, and Agile cycles.

PRDs became a compression layer

I no longer see a PRD as a huge document that needs to exist because some process says so.

To me, it became a way to compress the project.

If I need to re-explain an entire product every time I make a decision, the work architecture is already wrong.

A well-structured PRD lets me quickly return to a few fundamental questions:

• what problem are we trying to solve?
• for whom?
• what behavior actually matters?
• what is in scope and out of scope?
• what decisions have already been made?
• what constraints exist?
• how do we know the solution worked?

That structure works for a corporate product, an open-source tool, or a game.

The domain changes.

The mental skeleton does not.

And that dramatically reduces the cost of context switching.

A backlog is not a to-do list

Another major change was stopping treating the backlog as a giant queue of tasks.

A useful backlog tells a story.

Some things unlock others.

There are hypotheses.

There is known debt.

There are features that only make sense after a foundation is ready.

There are good ideas that should not consume energy yet.

When that map is organized well, I do not need to keep the entire project in my head.

I can leave one project, spend a few days on another, and come back knowing:

where we are, what comes next, and why that order exists.

That matters even more when I work with agents.

If I just hand over a loose list, an agent can execute a task perfectly even when that task should not be happening yet.

Implementation quality does not fix the wrong priority.

Acceptance criteria removed a lot of ambiguity

One of the biggest changes in my work has probably been learning to write better acceptance criteria.

A task like:

"build an inventory system"

can mean twenty different things.

But once I start defining:

• what the user can do;
• what the user cannot do;
• what should happen in empty states;
• how errors are handled;
• what conditions end the flow;
• which existing behaviors must continue working;

the task stops being an intention and starts becoming something verifiable.

That has a huge impact when AI is part of the process.

The more open-ended the request, the more decisions the agent has to invent.

The better the criteria, the less it needs to guess.

I do not need to specify every line of code.

But I do need to reduce the number of product decisions that get made accidentally during implementation.

The roadmap stopped being a promise

My relationship with roadmaps changed a lot too.

I used to think more naturally in sequences:

first we do A, then B, then C.

Now I see a roadmap more as a direction that has to survive contact with reality.

The goal still exists.

But new information can change the route.

Discovery can invalidate a feature.

A test can show that a foundation needs to be rebuilt.

An implementation can reveal an opportunity better than what was originally planned.

That is where Agile really started making sense to me.

Not as "doing sprints."

But as the ability to keep structure without turning planning into rigidity.

I know where I want to go, I know what the next bets are, and I know why they are in that order.

But the system can absorb change.

The same process started working for games too

One of the most interesting realizations was that this does not only work for traditional software.

I have been using the same reasoning in game development.

A game has a vision.

It has scope.

It has systems that depend on other systems.

It has a backlog.

It needs acceptance criteria.

A mechanic like "the enemy chases the player" sounds simple until you ask:

• when does the chase start?
• when does it stop?
• at what distance?
• what happens if line of sight is lost?
• can the enemy cross certain areas?
• which behavior has priority?
• how do we visually know the state changed?

Suddenly, a game-design mechanic starts benefiting from the exact same tools I would use for a product feature.

That was an important shift for me.

The methodology stopped belonging to the type of project.

It started belonging to the way I solve problems.

Working around more people changed how I think

Another factor that accelerated this change was spending more time in environments where different people solve different kinds of problems.

When you work alone for too long, there is a quiet risk:

you start confusing your way of solving a problem with the way to solve the problem.

That breaks quickly around more people.

Someone sees a dependency you missed.

Someone else asks a question that changes the discovery.

A developer finds a technical limitation.

Someone from the business explains an exception that was not visible in the flow.

A stakeholder completely changes the weight of a decision with information you did not have.

That exposure taught me something I now consider one of the most important skills:

identify what kind of problem is in front of me before trying to solve it.

Today I look for the root before the solution

Before, when something broke, my instinct was to jump quickly into implementation.

What code do we need to change?

Which agent can solve it?

Where is the bug?

Today I try to classify the problem first.

Is it actually a bug?

Is it an undefined business rule?

Is it an architecture decision?

Is the requirement incomplete?

Is it a dependency?

Is it a priority problem?

Is there an inconsistency between the documentation and the implementation?

Is a feature trying to compensate for a problem that belongs in another layer?

That classification sounds simple, but it saves an absurd amount of work.

A team can spend hours fixing code for a problem that started as a poorly defined product decision.

The faster I can reach the root, the less energy gets wasted treating symptoms.

It also changed how I work with agents

This is probably where the evolution is most visible.

I used to be much more likely to throw an entire problem at a single agent.

The agent would understand it, plan it, implement it, and try to validate everything inside the same context.

Today I prefer to think in terms of orchestration.

Not necessarily many agents doing everything at the same time, but clearer responsibilities.

I can have one stage focused on discovery.

Another on architecture.

Another on backlog decomposition.

Another on implementation.

Another reviewing acceptance criteria.

Another looking at tests, regressions, or security.

The project architecture becomes a kind of shared protocol between those stages.

That also makes it possible to work across several projects at once.

I do not need one giant context to carry my entire working life.

The project carries its own context.

The secret to many projects is reducing the cost of coming back

I think this is the core idea.

Working on many projects should not mean remembering many things.

It should mean being able to recover the state of any project quickly.

If I come back to a repository after a week and need two hours just to figure out what I was doing, there is a work-architecture problem.

When the project has:

• a vision;
• a PRD;
• recorded decisions;
• a roadmap;
• a prioritized backlog;
• acceptance criteria;
• technical documentation;
• an explicit current state;

coming back becomes cheap.

And when coming back is cheap, parallel work stops feeling so intimidating.

Memory stops being the bottleneck.

My work architecture is now as important as my stack

I still enjoy trying frameworks, models, IDEs, agents, automation tools, and new stacks.

But I started noticing that changing technology rarely improves my productivity as much as improving the system around it.

A smarter agent helps.

A better IDE helps.

A new model helps.

But if the project does not know what it wants, none of those things solve the real problem.

On the other hand, when the context is well structured, almost any good tool can produce results.

That is why I now consider PRDs, backlogs, acceptance criteria, documentation, and roadmaps part of my development architecture.

They are not things that sit around the code.

They are part of the infrastructure that allows the code to keep evolving.

What actually changed

Maybe the biggest difference is that I feel less need to control every detail of execution.

My job became much more about building a system where the right decisions can happen.

Define the problem well.

Break the problem down.

Make constraints explicit.

Organize dependencies.

Set criteria.

Create ways to validate.

Then distribute execution.

That is what allows me to move from a browser to an automation, from a desktop tool to a game, and then back to another product without feeling like I am changing the way I work completely.

The projects are different.

The work architecture stays the same.

Next: my complete workflow

This post was more focused on the why behind this structure.

Next, I want to get into the how.

I want to document the complete workflow I use today: how I organize projects, where PRDs and documentation live, how I structure backlog and roadmap, how I distribute work across agents, how I preserve memory between sessions, which tools I use on my computer and on my VPS, and how I connect all of it so I can work across several fronts without turning the process into a mess.

It will probably be the closest thing to a "making of" of how I build today.

Because in the end, the stack changed many times.

What actually started scaling was the system around it.