BAU Workshop: Architecture and Specifications

My team and I ran a workshop at Bahçeşehir University about how we built IDMS, our graduation capstone. We built the project together; I led the backend architecture.

In my opening, I focused on the architecture behind the interface. We traced a request through five layers: product and frontend; API and security; data, storage, and access control; workers, queues, and retrieval-augmented generation; and reliability, observability, and testing.

That was a teaching model for understanding the system. The point was to connect the parts into a request path, not present a list of technologies as an explanation.

We also connected the discussion to spec-driven development: give an AI coding tool an architecture, clear constraints, small implementation tasks, and a way to validate the result independently.

A request to implement a component is more useful when its inputs, outputs, and boundaries are explicit. The surrounding system needs to know what a response means, which state can change, and how a failure is represented.

Generating code does not settle those questions. Faster implementation can help realize a coherent design, but it can also spread an unclear assumption through more of the application.

The main point was simple: AI can help a team build faster, but weak architecture can also help it make mistakes faster.

I closed with this: the model is replaceable; the architecture decisions and specifications remain responsibilities the team has to own.

The workshop was a collective effort. The value of tracing the full request was making the connections visible—so each layer could be discussed as part of a system, rather than as an isolated demonstration.