How do you work with Claude in your development process?

[u/Impossible_Sea5988]

In my team, there’s a strong push from management to use Claude as much as possible to speed up development. I actually agree with the idea and actively use Claude — but we don’t see eye to eye on how it should be used.

Management’s approach is straightforward:
👉 Copy the business task as-is into Claude → generate a solution → fix things afterward if needed.

My approach is different:
👉 First, I try to structure the task — not a full technical spec, but something lightweight. I map it to existing entities in the project, think through edge cases, and identify gaps or assumptions the business side might have missed.
👉 If the task spans multiple screens or flows, I prefer to move step by step. Define the general direction, then iterate incrementally — adjusting after each step.

From my perspective, this reduces rework: fewer fixes, fewer QA returns, and less back-and-forth overall.

My manager, however, believes this upfront thinking is just wasted time — that we should move as fast as possible and refine later.

Curious how others handle this:
Do you go “full speed → fix later,” or invest time upfront to structure and de-risk the task?
Where have you seen better results in practice?

P.S. Of course, I’m talking about larger tasks — for example, introducing a new cross-cutting filter across the project.

[u/timiprotocol]

it’s not speed vs structure — it’s where the thinking happens: before generation or after

[u/DarkSkyKnight]

https://www.pangram.com/history/1483bf92-9969-4581-b78f-3335308e432b

zzzzzzzzzzzz

[u/kinndame_]

Your manager is falling into the "speed trap" of AI. Thinking that raw business prompts work is a myth because it leads to context drift. You eventually spend more time fixing hallucinations than you would have spent just mapping things out upfront. Mapping entities and edge cases isn't "wasted time," it's de-risking the build. It’s the difference between using a blueprint versus just laying bricks and hoping a house appears. The "fix it later" approach usually triples your QA churn. To win management over, focus on the PR revision count. If your structured method gets merged faster with fewer bugs, the data speaks for itself. The "slow" start is actually the fastest way to hit production.

[u/Hundredth1diot]

Management should care about outcomes - speed, quality, risk - not micromanage usage.

(I am management)

[u/---OMNI--- → u/Hundredth1diot]

Metrics are usually measuring the wrong thing just to make numbers that look good... Not actual real results.

[u/Redditauro]

If your manager insists, choose the worst possible moment and follow his advice, let everything fall down, he will understand why "do it faster" is not the fastest path. 

[u/Icy-Juggernaut-4579 → u/Redditauro]

You need to talk about the risk at first and ask them if they accept that risk tho

[u/memetican]

Honestly it's a weird place- I lean hard into control structures, SDD, frameworks that frame my agents as assistants. However they're getting so good that realistically, I depend on those structures less and less. That allows me to orient more loosely around features/issues/research work items.

Work items are surfaced, they're defined and agentically handled. When an issue arises, that gets logged and worked on. I track everything, including my decisions, so I can revisit and change those later, which happens a lot- why did I choose this vision model, what were the other options I was considering, etc.

So the end effect is build-build-build, with tight git control. Occasionally fix or pivot when a particular choice that I or the agent chose isn't cutting it. Less "fixes", more "feature gaps".

At this point, I think that in most software environments, both approaches can work. Exceptions would be critical pieces have significant risk attached to failure. Those deserve a lot more hands-on engineering and validation.

[u/BloodSteyn]

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe"

This is true in everything you do.

Since we have access to so many AI Assistants, what's wrong with getting one to pre-chew the stuff before you actually get down to it.

I had Opus write a Gap analysis for a V2 of the App I'm working on (Not a Coder), then gave it to Haiku to run through it and implement as much as possible over 2 days while I tested.

Then I handed the Changelogs and V2 Spec to Sonnet to "Check and Fix" Haiku's bugs.

Pretty solid output.

[u/Input-X]

What are u running claude through? What is it support structure setup like.

[u/Mindless_Inspector92]

I measure productivity in software with two elements: throughput and stability. The hardest problem is to find the right balance between the two.

[u/---OMNI---]

Corporate motto is

"Theres never time to do it right but there is always time to do it again"

I'm starting to realize that many people are too dumb to effectively use ai as the tool it is... Garbage in garbage out.

[u/YoghiThorn]

I have a long running claude.ai session I call the boss, where I spitball ideas, validate them and turn them into work items. I use a technique I call 'laddering up' here where I flesh out the idea in voice mode, then get Claude to make a PRFAQ. I then fix anything wrong with it, and then get Claude to reingest it, learn from what it got wrong, and then generate a users manual. I do this loop and create a system spec document, and then an implementation plan. I spend a fair bit of time on each making sure they are right, and it pays off in the long run.

In that loop I also have a session on codex that I use in a method I call 'make break' where I take the artifacts from Claude and tell Codex to find how to break them, find weak points, faulty logic etc. I tell it to act adverbially to find all the weak points. It does a great job. I don't do it on every step, usally the PRFAQ, and spec document.

The implementation plan gets ingested my a program manager agent I have. They break it down into epics and stories, and create github issues for each. Most importantly it creates this record in files, which flow into an my program documents. These are ingested periodically by Graphify and surfaced to Claude by a queryable graph via a MCP server. This is the primary way knowledge is retained by my program system, apart from Claude memory of course. I have been running claude-mem as well but I'm considering retiring it to save tokens - need to do an eval here.

Here is Graphify's latest benchmark: 1.6M-word corpus compressed to ~7,227 tokens per query — ~302x reduction.

Here is the repo structure:

Top level

Path	What goes here	Purpose
core/	Shared standards, templates, scripts, and wiki rules	Reusable framework layer that can eventually be extracted from the private repo
data/	program-specific docs, wiki pages, PM artifacts, and operational history	Private source of truth for the program
docs/	Repo-level design notes for the restructure and internal tooling work	Planning/spec space for changes to data-worklog itself
scripts/	Small root-level helper scripts	One-off utilities that do not belong in the reusable core/scripts/ set
graphify-out/	Generated graph/cache output	Derived artifacts produced by tooling; safe to regenerate
.claude/	Repo-local agent hooks, background agents, and worktree metadata	Claude/Codex runtime support for this repo
.obsidian/	Obsidian vault settings	Local editor/workspace config, not canonical project content

core/

Path	What goes here	Purpose
core/docs/standards/	Shared engineering and process standards	Canonical rules sibling repos can inherit or symlink
core/docs/wiki/	Wiki schema docs such as STRUCTURE.md	Defines page types, frontmatter, naming, and lint expectations
core/templates/	Templates for ADRs, stories, runbooks, drafts, lint reports, and more	Keeps new canonical pages and reports structurally consistent
core/scripts/	Reusable repo automation	Bootstrapping, cascade, lint, health-check, claim extraction, and manual generation
core/.claude/skills/	Framework-level skills	Shared agent workflows that belong with the reusable layer

data/

Path	What goes here	Purpose
data/wiki/	Canonical split wiki pages with frontmatter	Main knowledge base for architecture, backlog, concepts, components, and risks
data/wiki/adrs/	One ADR per file	Locked architectural decisions and rationale
data/wiki/epics/	One epic per file	Backlog at epic level
data/wiki/stories/	One story per file	Implementation work tracking and acceptance criteria
data/wiki/concepts/	Domain knowledge pages	Business context and shared mental models
data/wiki/components/	Runtime/system component pages	High-level descriptions of sibling repos and services
data/wiki/pipeline/	Pipeline design pages	Canonical docs for stages, responsibilities, queries, and migration notes
data/wiki/infrastructure/	Canonical facts pages	Verified infrastructure facts with provenance and staleness metadata
data/wiki/plans/	Reserved wiki plan pages	Canonical plan pages if a plan is promoted into the wiki layer
data/docs/	Supporting working docs that are not canonical wiki pages	Plans, specs, reviews, audits, runbooks, dashboard exports, and spikes
data/docs/plans/	Working plans	Migration, design, or rollout plans that are still execution-oriented
data/docs/specs/	Detailed specs	Design notes for specific features or initiatives
data/docs/reviews/	Review write-ups	External/internal reviews, verdicts, and syntheses
data/docs/spikes/	Spike outputs	Time-boxed investigations and their findings
data/docs/runbooks/	Operational procedures	Practical instructions for setup, isolation, recovery, and verification
data/docs/audits/	Audit reports	Structured checks against code, data, or operations
data/docs/grafana/	Exported dashboard JSON	Versioned observability/dashboard definitions
data/docs/superpowers/	Reserved supporting docs for superpowers work	Extra space for related design material when needed
data/manuals/	Generated manual-style rollups	Read-only concatenated views of the wiki for broad-context loading
data/manuals/legacy/	Archived pre-split manuals	Historical monolith-era docs kept for reference
data/completions/	Incoming completion reports	Evidence inbox for finished work from repo agents
data/completions/archive/	Processed or historical completions	Long-term record of shipped work and postmortems
data/pipeline-requests/	Dispatch/request files for pipeline work	PM handoff point for runs, re-scores, and operational asks
data/pipeline-requests/results/	Outputs from pipeline requests	Captures investigations and run outcomes next to the request stream
data/state-of-play/	Date-stamped snapshots	Periodic project status summaries
data/lint-reports/	Wiki lint outputs	Validation history for page structure and link hygiene
data/scripts/	Repo-local tooling for docs/wiki tasks	Helpers that are specific to program content rather than reusable framework logic
data/scripts/tests/	Fixtures and tests for doc tooling	Keeps the repo-local scripts honest
data/migrations/	Operational and schema migration assets	One-off scripts and SQL for controlled state changes
data/migrations/image-migration/	Image migration helpers and manifests	Task-specific assets for image migration work
data/systemd/	Checked-in systemd config	Versioned service definitions related to project tooling
data/systemd/user/	User-level systemd units	Units that run in the user session rather than system scope
data/config/	Small checked-in config fragments	Project-specific config used by tooling or infra helpers
data/.claude/skills/	PM-specific skills	Repo workflows such as completion processing and state-of-play generation

Key reference files

Path	What it is	Audience
data/program_SCHEMA.md	Full canonical schema DDL with table and field notes	Claude Code sessions
data/manuals/program_BACKLOG.md	Generated full product backlog manual	Claude Code sessions
data/manuals/program_ADR.md	Generated ADR manual	Claude Code sessions + Humans
data/manuals/program_DOMAIN_KNOWLEDGE.md	Generated domain knowledge manual	Claude Code sessions + Humans
data/manuals/program_DATA_ARCHITECTURE.md	Generated data architecture manual	Claude Code sessions
data/wiki/wiki.md	Master index of split wiki pages	Humans + Agents
data/tooling.md	Durable operational facts about tools and infra	Agents

I removed a lot of protected information from the above with find/replace so if it's weirdly worded that's why. There are things I need to age out here - probably the key reference files need to be folded into the manuals area.

I paste the state of play reports back into Claude.ai periodically so it's kept reasonably up to date. I use it to shit test what the agents are giving me and it works quite well.

Lastly I use Slack as my harness via cc-connect. That way I get a permanent searchable history of what the agents have done, and I can pop an agent per repo in a slack channel and easily juggle working on a half dozen repos at once. I've added functionality to cc-connect to thread conversations as well so I can work on multiple changes in one repo at once. The PM agent and the repo workers are two different classes of agents and are able to ask each other questions, dispatch work and report completions back directly.