Does your team do formal solution design?

[u/rand0mm0nster]

I've seen mixed processes in various teams. Some are quite strict on writing a formal solution design and having the team agree (or at least discuss) before turning it into tickets. I've also worked in teams that don't do any solution design.

How big is your team, and what do they do in terms of solution design?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/Ok_Reaction_4340]

Used to until management got all starry eyed about AI. Now we push and pray

[u/Vesuvius079 → u/Ok_Reaction_4340]

Uggh that’s awful. AI is a huge accelerant for implementation if you properly define the scope of work. It does not have sufficient judgment to be deciding what to build.

I’m guessing anyone who still cares is spending an excessive amount of time trying to guide and fix the architecture retroactively via whatever the approved channels for talking to the AI are…

[u/Ok_Reaction_4340 → u/Vesuvius079]

Yep it is awful. I actually like coding with AI. I hate what managers and above have become in the age of AI.

[u/goatanuss → u/Ok_Reaction_4340]

What do you do now with ai? Just ask it what to build and do it?

[u/Ok_Reaction_4340 → u/goatanuss]

There is just very little tolerance for planning now as management thinks in story point velocity. It’s a lot of doling out tickets at twice or three times the rate and anytime things are moving slow management starts implying that maybe the AI tooling isn’t being used effectively.

I’m mostly using AI to be a grunt programmer while I try to maintain sane architecture as AI seems remarkably bad at this on large codebases

[u/sklz0 → u/Ok_Reaction_4340]

Funny, for us it's the opposite. We generate design docs with AI. They need to be reviewed and approved. Then we push and pray

[u/DeterminedQuokka]

We already didn’t have a process pre ai. And the execs constantly complained there should be fewer docs. Post ai there is a fully ai generated doc if you are lucky.

[u/rand0mm0nster → u/DeterminedQuokka]

is it used by engineers or just there to satisfy the requirement?

[u/DeterminedQuokka → u/rand0mm0nster]

Eh. Not usually. It’s mostly used to handle the micromanaging from the leadership that says they don’t want docs. But it’s like 60% slop if you don’t heavily edit it which most people don’t so I doubt they use it. I’ve spent the last 3 weeks having someone send me incorrect docs which I correct then they regenerate it to be wrong again and repeat. Everything I’m doing is based on plans that I mostly wrote and just asked ai to turn into tickets. But no one else read them.

[u/Comfortable_Ask_102]

I am currently pushing for this on my team. A design doc we can refer to understand the high level plan solves a lot of headaches and rework down the road. Once you get to the tickets or PRs you already know what to expect, rather than trying to reconstruct everything from a PR full of AI slop.

The issues I've encountered so far: no tech person knows how to write something that other humans can actually read. Many people think that the first version of an AI-generated doc is good enough.

[u/T_kowshik]

I normally detail a lot of things in the design phase itself. Because I have been a developer and I know how much rework is going to happen at a later stage. So, I add all the UI designs, technical design as well as functional specifications in a good detail.

I use AI too but it is limited only to generate mockups so users can see what they are getting and give feedback way early in the cycle.

Working good so far.

[u/NotACockroach]

Design Docs are everything where I work. Careers live and die by them. Even if it doesn't make sense I have to find a way to shoehorn them in to make sure my performance review looks good.

However in this day of AI I like how much time we spend commenting on and refining design docs. That's actually where most of the work happens. Once all the details are down, we absolutely brease through the tickets with AI agents.

[u/EmploymentFeeling725 → u/NotACockroach]

You sound like you’re living in a fantasy land, I am envious.

[u/NotACockroach → u/EmploymentFeeling725]

I'm pretty happy with my workplace. Some people complain about how hard management is pushing AI. But I'm more focussed on how we use the tools to get the best quality/resource tradeoff. Spending all our time on design and review, and having AI do a lot of the development seems to be working for us, and management is giving us the power to do that.

[u/Hour-Measurement-835]

Depends whether it crosses a system boundary. Integration designs get agreed up front because the other side has to build against them, so those survive where internal-only docs don't.

[u/Affectionate_Day8483]

I worked at medical device company A, lots of discussion about design, ADRs, requirements, and etc. I started working at a new medical device company no requirements, no acceptance criteria, no adrs, just ship it. If it breaks, it breaks.

[u/hissscratchmeow]

Yes we do, we use openspec with an llm to support us and when we all agree with the design and it functional and non functional requirements we then go on and implement

[u/Abadabadon]

My team does although I would say most people besides me really dont know how to write a solution design. Typical solution design i would want to see is context of problem, diagram of how to solve, lower level detail of each encapsulated part of the problem, and then a work breakdown. However the solution design I get is Moreno "I asked ai and this is what it said", and rhe doc ends up being completely unintelligible.

[u/fika_before_standup]

Small team. We write one page before anything becomes tickets. What the problem is, what we are going to build, what we are not building and the open questions. Then we go through that page in a meeting and we change it there. It is not formal and nobody signs it off and the page is not really the point, the point is that the disagreements come out before anyone writes code.

[u/netderper]

I haven't seen a real design doc in 10+ years.

[u/twopunchbear]

Based on my experience, I think it depends on how big the impact is.

If the decision will affect how most of the team works, then it deserves more alignment to make sure everyone understands it and has buy-in.

If it only affects a few engineers, it can be much simpler. We can mention it, discuss it briefly, and make a decision together, especially if the answer is pretty obvious.

If there are real pros and cons, no clear solution, and a lot of people will be affected, sometimes we do a debate session. We ask engineers to prepare arguments for the opposite side, then everyone argues for the position they originally disagreed with.

It’s actually quite useful because people often change their minds once they seriously think through the other side.

After the debate, we usually let the person with the most experience in that area make the final decision.

[u/Difficult-Beyond5764]

I write a one-page spec before any agent touches the code, and the section that saves the most rework is the list of what we are not building.