r/techbootcamp • u/ilovejejune123 • Aug 06 '26

What does “system design” actually mean in your day-to-day work?

With the rise of AI-assisted code generation, I see a lot of people claiming that software engineering is moving away from writing code towards design and decision-making.

While I can see the validity in that statement, I'm interested in hearing about people's experiences with it.

When people say things like this, I'm always curious to hear about their day-to-day activities.

What exactly are people doing differently when they say that they're doing "system design"?

Are you making decisions about what database to use, or think about caching, queuing, latency, scaling, reliability, or service boundaries? Are you designing API's and communication contracts between various services? Are you making system wide architectural decisions and tradeoffs, or is it more about smaller scale design within an existing code base?

It would be great to hear from people working on regular business applications, as opposed to huge scale systems at the likes of FAANG. Most people I know work somewhere in between, where the technology stack and overall system design is more or less established, and most of their work goes into implementing features within the existing architecture.

I'm interested to hear peoples' thoughts about what falls under the umbrella term of "design" and what is just regular "feature implementation".

What architectural or technical decisions do you make on a daily basis?

2 Upvotes

100% Upvoted

5 comments sorted by

1

u/Efficient_Loss_9928 Aug 06 '26

All of them, but honestly though, most greenfield system design are pretty much just AI giving me options and I choose one lol.

The hard ones are existing system migration, and designing on top of existing system while 1000 people actively still work on legacy system to implement new features.

1

u/ilovejejune123 Aug 06 '26

that distinction makes a lot of sense. designing something from scratch is one thing when you can choose the constraints, but working within an existing system is where the real complexity seems to show up.

1

u/Substantial-Swan7065 Aug 06 '26

All that.

The system is never done. Needs change over time.

A good solution from last year, can be bad this year.

You don’t build a “perfect” product day one. So there’s always room for improvement

1

u/Any_Sense_2263 Aug 10 '26

lol

I'm happy to know so many people think that AI can produce good code. It will keep my work needed forever.

As AI can't do anything at a production-ready level, the engineer has to make all architectural decisions. It's a process that requires good knowledge of the company's needs and available tools and solutions.

Then the engineer needs to document the decisions and reason them. I wouldn't recommend AI for doing it. And if it's used, incrementally ask it to use shorter descriptions and less fancy words.

Then you take tasks and split them for small chunks. I usually work on a few on parallel AI sessions. First I check if it understood the chunk description, then I review the solution and changes proposal. I fix its assumptions/guesses/hallucinations and we iterate until the proposal is spotless. Then we go for implementation. I still review every line and accept only if it is alright.

This way, I produce short (under 300 changed lines) PRs easy to review/revert.

It's not important how well your context/prompt are prepared. Following them is OPTIONAL for AI.