brihati

I was digging through a magic number in code that has lived in the code for quite some time & couldn't figure out why that specific value was chosen. Digged through docs, PRs, PRs' comments, talked/brainstormed with people but no result. After hours of searching, it was buried in commit message

Wait... WHAT??? From now on, should I start reading commit messages? Do you have such weird stories?

I am having conversations with engineering leaders where they have expressed concerns that it's not only the code but a lot of other things around code:

1. Alignment between engineering teams and other stakeholders which causes the delay in finalising the requirements 2. Scope changing mid sprint, which was not accounted during planning, hence pushing deadlines 3. Engineers who have the most context of system X, is on leave or have left the company, hence decisions are delayed 4. Senior engineer changing the approved design mid sprint because of some flaws in approved design 5. Identified dependencies on other teams who have their hands tied up with other urgent tasks .... & so on

Curious what this looks like at your company. What's the most expensive coordination failure your team has experienced? How much did it cost the company?

I have been using claude code extensively for coding at my startup, but I am feeling that I can be more productive by utilising the time when the claude code is writing code instead of just staring what claude is doing.

One may think that it's a marginal time, but I have timed it, it's 2.5-3 hours per day split over 1/2 minutes window over the whole day.

Since the time window is short, I want something that I can complete in that time window. I have been solving chess puzzles during that time, but want to do something which benefits my startup in the long run, maybe learn something new.

How are you utilising that time?

Not looking for books that taught you something new, but ones that changed how you think – the kind that made you see patterns or connections you couldn't unsee. What book rewired your thinking?

We use Claude code internally and it does a good job generating first-pass system designs when given templates and existing architecture. It often captures the obvious components and tradeoffs quickly.

Even so, system design still seems slower than expected. People spend days aligning, gathering context, and iterating on designs that feel like they could have started much closer to a workable draft.

For those who already use AI tools while designing systems:

What parts of system design remain difficult or slow? Where do AI-generated designs tend to break down?

Besides HN, are there any communities where I can discuss an idea with peers?

When starting a greenfield project, do you take the time to write things down sketching out the domain, architectural direction, and key trade-offs to clarify your thinking upfront, or do you prefer to let the design emerge incrementally as you vibe code?

Problem with ambiguous boundaries, messy constraints and no linear path to a solution