$1,000 to the first person who finds something poorly engineered in this ~91k LOC vibe-coded codebase

[peteromallet]

Desloppify is an agent hardness to make vibe code as good as possible. I didn't write any of the ~91k lines of code in this repo and I barely understand most of it - but I believe the proof should be in the pudding.

This is a reasonably complex agent orchestration codebase made by a non-professional software engineer. There's bound to be a lot of poorly engineered stuff in here, right? This should be the easiest money ever!

How the bounty works

• Deadline: Friday, March 6, 2026 at 4:00 PM UTC
• Codebase snapshot: Judging is based on this commit. Anything changed after this commit doesn't count.
• To enter: Comment below with a description of what you found and why it's poorly engineered. Keep it under 300 words w/ references.
• What counts: We're looking for things that are 'poorly engineered' — poor engineering decisions, sloppy implementations, poor abstractions. A structural decision that makes things meaningfully hard to maintain, extend, or understand. Bugs count, but they're not the primary focus - it's more about the technical decisions. Code style preferences don't count. Issues must focus on the current state of the codebase, not on previous changes or the development process itself — that part is a work in progress of my tool.
• Judging: "Poorly engineered" is a subjective claim, so it requires a subjective test. Modern LLMs are very good at evaluating questions like this when given tight constraints. I'll feed your description into both Claude Opus 4.6 and ChatGPT Codex 5.3. Both models must agree that it's (a) poorly engineered and (b) at least 'somewhat significant'. If they disagree, it doesn't pass.
• First valid entry wins - once someone's submission passes both models, the bounty closes
• Multiple entries: You can submit as many entries as you like - but if 3 fail in a row, further ones will be ignored.
• Spam/low-effort: Spam or low-quality entries won't go through the full judging process. I'll share the prompt used to filter these too.

I won't release the exact prompts I use for judging in advance - I don't want people gaming the wording. Once the deadline passes, I'll run an agent through all entries live in the thread, replying to each one with the results until we get a winner (or don't). I'll also post the prompts and most likely share my LLM logs. Edited comments won't be accepted.

If no one claims the bounty by the deadline, the $1,000 will roll into a larger bounty with an even higher bar. If no one ever claims any bounty, I'll donate it to the Arca Gidan Prize — I consider this money gone, so I have no incentive not to reward it.

Payment

• Amount: $1,000 paid out in SOL
• How: Provide a Solana wallet address and I'll transfer directly
• Source: People made tokens for this project and gave me creator fees. I don't want to profit from this, so I'm putting 100% of those fees toward making the tool better - mostly through bounties to help surface what's not working with it. Gamblers are gonna gamble so might as well put free money to good use.

Everything - the prompts, the judging, the payment - will be public so you can validate it all on the accountability page

[andrewwhitecdw]

I'm just waiting for enough bug fixes to fork it in rust.

[yuliuyi717-ux]

I think the significant flaw in snapshot 6eb2065fd4b991b88988a0905f6da29ff4216bd8 is state-model coupling: the same mutable state document is used as evidence truth, operator-decision log, and score cache.

References:

• State schema co-locates raw issue records with derived scoring/summary fields (issues, stats, strict_score, verified_strict_score, subjective_assessments):
  

  desloppify/desloppify/engine/_state/schema.py

  Lines 322 to 339 in 6eb2065

  	def empty_state() -> StateModel:
  	"""Return a new empty state payload."""
  	return {
  	"version": CURRENT_VERSION,
  	"created": utc_now(),
  	"last_scan": None,
  	"scan_count": 0,
  	"overall_score": 0,
  	"objective_score": 0,
  	"strict_score": 0,
  	"verified_strict_score": 0,
  	"stats": {},
  	"issues": {},
  	"scan_coverage": {},
  	"score_confidence": {},
  	"subjective_integrity": {},
  	"subjective_assessments": {},
  	}

• merge_scan mutates issue lifecycle and recomputes scores in the same flow:
  

  desloppify/desloppify/engine/_state/merge.py

  Lines 123 to 199 in 6eb2065

  	def merge_scan(
  	state: StateModel,
  	current_issues: list[dict],
  	options: MergeScanOptions | None = None,
  	) -> ScanDiff:
  	"""Merge a fresh scan into existing state and return a diff summary."""
  	ensure_state_defaults(state)
  	resolved_options = options or MergeScanOptions()
  	now = utc_now()
  	_record_scan_metadata(
  	state,
  	now,
  	lang=resolved_options.lang,
  	include_slow=resolved_options.include_slow,
  	scan_path=resolved_options.scan_path,
  	)
  	_merge_scan_inputs(
  	state,
  	lang=resolved_options.lang,
  	potentials=resolved_options.potentials,
  	merge_potentials=resolved_options.merge_potentials,
  	codebase_metrics=resolved_options.codebase_metrics,
  	)
  	existing = state["issues"]
  	ignore_patterns = (
  	resolved_options.ignore
  	if resolved_options.ignore is not None
  	else state.get("config", {}).get("ignore", [])
  	)
  	current_ids, new_count, reopened_count, current_by_detector, ignored_count, upsert_changed = (
  	upsert_issues(
  	existing,
  	current_issues,
  	ignore_patterns,
  	now,
  	lang=resolved_options.lang,
  	)
  	)
  	raw_issues = len(current_issues)
  	suppressed_pct = _compute_suppression(raw_issues, ignored_count)
  	ran_detectors = (
  	set(resolved_options.potentials.keys())
  	if resolved_options.potentials is not None
  	else None
  	)
  	suspect_detectors = find_suspect_detectors(
  	existing,
  	current_by_detector,
  	resolved_options.force_resolve,
  	ran_detectors,
  	)
  	auto_resolved, skipped_other_lang, resolved_out_of_scope, resolve_changed = auto_resolve_disappeared(
  	existing,
  	current_ids,
  	suspect_detectors,
  	now,
  	lang=resolved_options.lang,
  	scan_path=resolved_options.scan_path,
  	exclude=resolved_options.exclude,
  	)
  	# Mark subjective assessments stale when mechanical issues changed.
  	changed_detectors = upsert_changed | resolve_changed
  	if changed_detectors:
  	_mark_stale_on_mechanical_change(
  	state, changed_detectors=changed_detectors, now=now,
  	)
  	_recompute_stats(
  	state,
  	scan_path=resolved_options.scan_path,
  	subjective_integrity_target=resolved_options.subjective_integrity_target,
  	)

• resolve_issues writes manual decisions (status/note/attestation) into the same records, then recomputes stats/scores again:
  

  desloppify/desloppify/engine/_state/resolution.py

  Lines 99 to 173 in 6eb2065

  	def resolve_issues(
  	state: StateModel,
  	pattern: str,
  	status: str,
  	note: str | None = None,
  	attestation: str | None = None,
  	) -> list[str]:
  	"""Set issue status for matches and return affected issue IDs."""
  	ensure_state_defaults(state)
  	now = utc_now()
  	resolved: list[str] = []
  	resolved_issues: list[dict] = []
  	status_filter = "all" if status == "open" else "open"
  	for issue in match_issues(state, pattern, status_filter=status_filter):
  	previous_status = str(issue.get("status", "open")).strip() or "open"
  	if status == "open" and previous_status == "open":
  	continue
  	extra_updates: dict[str, object] = {}
  	if status == "wontfix":
  	snapshot_scan_count = int(state.get("scan_count", 0) or 0)
  	extra_updates["wontfix_scan_count"] = snapshot_scan_count
  	extra_updates["wontfix_snapshot"] = {
  	"captured_at": now,
  	"scan_count": snapshot_scan_count,
  	"tier": issue.get("tier"),
  	"confidence": issue.get("confidence"),
  	"detail": copy.deepcopy(issue.get("detail", {})),
  	}
  	if status == "open":
  	issue["reopen_count"] = int(issue.get("reopen_count", 0) or 0) + 1
  	issue.pop("wontfix_scan_count", None)
  	issue.pop("wontfix_snapshot", None)
  	previous_note = issue.get("note")
  	next_note = note if note is not None else previous_note
  	extra_updates["resolved_at"] = None
  	extra_updates["note"] = next_note
  	reopen_attestation = {
  	"kind": "manual_reopen",
  	"text": attestation or note,
  	"attested_at": now,
  	"scan_verified": False,
  	}
  	reopen_attestation["previous_status"] = previous_status
  	extra_updates["resolution_attestation"] = reopen_attestation
  	updates: dict[str, object] = {
  	"status": status,
  	"note": note,
  	"resolved_at": now,
  	"suppressed": False,
  	"suppressed_at": None,
  	"suppression_pattern": None,
  	"resolution_attestation": {
  	"kind": "manual",
  	"text": attestation,
  	"attested_at": now,
  	"scan_verified": False,
  	},
  	}
  	updates.update(extra_updates)
  	issue.update(updates)
  	resolved.append(issue["id"])
  	resolved_issues.append(issue)
  	_mark_stale_assessments_on_review_resolve(
  	state,
  	status=status,
  	resolved_issues=resolved_issues,
  	now=now,
  	)
  	_recompute_stats(state, scan_path=state.get("scan_path"))
  	validate_state_invariants(state)
  	return resolved

Why this is poorly engineered (and significant):

1. Non-commutative behavior: for the same code snapshot, scan/resolve/import ordering changes state history and score trajectory.
2. Provenance ambiguity: score deltas are hard to attribute cleanly to detector evidence vs human/operator actions once both are folded into one mutable object.
3. Scaling risk: as automation/concurrency grows, determinism and auditability degrade because there is no immutable event boundary.

This is not a localized bug. It is a structural data-model decision that raises long-term maintenance and correctness risk. Incremental patches won’t remove the class of failures; it needs architectural separation (event log -> deterministic projection -> derived read models).

[juzigu40-ui]

Major design flaw: config bootstrap is non-transactional and order-dependent, with destructive read-path side effects.

References (judged snapshot 6eb2065fd4b991b88988a0905f6da29ff4216bd8):

• Read path triggers migration when config is missing (load_config -> _load_config_payload -> _migrate_from_state_files):
  

  desloppify/desloppify/base/config.py

  Lines 136 to 144 in 6eb2065

  	def _load_config_payload(path: Path) -> dict[str, Any]:
  	if path.exists():
  	try:
  	payload = json.loads(path.read_text())
  	except (json.JSONDecodeError, UnicodeDecodeError, OSError):
  	return {}
  	return payload if isinstance(payload, dict) else {}
  	# First run — try migrating from state files
  	return _migrate_from_state_files(path)

  
  

  desloppify/desloppify/base/config.py

  Lines 177 to 184 in 6eb2065

  	def load_config(path: Path | None = None) -> dict[str, Any]:
  	"""Load config from disk, auto-migrating from state files if needed.
  	Fills missing keys with defaults. If no config.json exists, attempts
  	migration from state-*.json files.
  	"""
  	p = path or _default_config_file()
  	config = _load_config_payload(p)

• Unstabilized migration source order (glob) + first-writer scalar precedence:
  

  desloppify/desloppify/base/config.py

  Lines 396 to 401 in 6eb2065

  	state_files = list(state_dir.glob("state-*.json")) + list(
  	state_dir.glob("state.json")
  	)
  	migrated_any = False
  	for sf in state_files:
  	migrated_any = _migrate_single_state_file(config, sf) or migrated_any

  
  

  desloppify/desloppify/base/config.py

  Lines 322 to 336 in 6eb2065

  	def _merge_config_value(config: dict, key: str, value: object) -> None:
  	"""Merge a config value into the target dict."""
  	if key not in config:
  	config[key] = copy.deepcopy(value)
  	return
  	if isinstance(value, list) and isinstance(config[key], list):
  	for item in value:
  	if item not in config[key]:
  	config[key].append(item)
  	return
  	if isinstance(value, dict) and isinstance(config[key], dict):
  	for dk, dv in value.items():
  	if dk not in config[key]:
  	config[key][dk] = copy.deepcopy(dv)
  	return

• Source files are rewritten before destination durability (del state["config"]):
  

  desloppify/desloppify/base/config.py

  Lines 357 to 363 in 6eb2065

  	def _strip_config_from_state_file(path: Path, state_data: dict) -> None:
  	if "config" not in state_data:
  	return
  	del state_data["config"]
  	try:
  	safe_write_text(path, json.dumps(state_data, indent=2) + "\n")
  	except OSError as exc:

  
  

  desloppify/desloppify/base/config.py

  Lines 371 to 381 in 6eb2065

  	def _migrate_single_state_file(config: dict, path: Path) -> bool:
  	state_data = _load_state_file_payload(path)
  	if state_data is None:
  	return False
  	old_config = state_data.get("config")
  	if not isinstance(old_config, dict) or not old_config:
  	return False
  	_merge_legacy_state_config(config, old_config)
  	_strip_config_from_state_file(path, state_data)
  	return True

• Destination write failure is best-effort logged, without rollback:
  

  desloppify/desloppify/base/config.py

  Lines 403 to 409 in 6eb2065

  	if migrated_any and config:
  	try:
  	save_config(config, config_path)
  	except OSError as exc:
  	log_best_effort_failure(
  	logger, f"save migrated config to {config_path}", exc
  	)

Why this is poorly engineered:
A query-time operation mutates and destroys source artifacts, violating CQS by coupling reads with irreversible migration side effects.

Practical significance: if config.json persistence fails once (permissions/transient I/O/full disk), legacy config may already be stripped from state files. Subsequent runs cannot recover original settings and can silently converge to defaults. In parallel, unstabilized file order can change scalar effective values across environments. Since config values directly feed runtime policy (for example target_strict_score in queue/scoring decisions), this can change prioritization behavior, not just internal metadata.

My Solana Wallet Address: Azx1q4T56hTQcALkYGTLMtn5oYhpAU74Av4Mtau13wDz

[peteromallet]

Let's see what the bot says but I would guess this will be viewed technically valid but practically not significant - thank you for the PR in any case!

I think there is a significant engineering flaw in config bootstrap: reading config performs destructive, order-dependent migration side effects.

References (snapshot commit):

• Auto-migration is triggered on read when config is missing (_load_config_payload): config.py#L136-L144
• Migration enumerates state files via unsorted globs: config.py#L396-L401
• Scalar merge is first-writer-wins (if key not in config): config.py#L322-L336
• Migration deletes state["config"] and rewrites files in place: config.py#L357-L363

Why this is poorly engineered:

1. A read-path (load_config) mutates persistent state, coupling initialization to data migration side effects.
2. Because glob order is not explicitly stabilized, effective scalar config selection can depend on filesystem iteration order.
3. Source state files are rewritten during bootstrap, which removes original embedded config provenance and makes rollback/audit harder.

This design increases startup fragility and maintenance risk: behavior depends on prior artifact layout, and repeated runs can converge state in ways that are difficult to reason about or reproduce.

[agustif]

First draft finding (I may add/replace after deeper review):

The subjective-dimension metadata pipeline has a circular, multi-home source of truth that violates the repo’s own architecture contract.

Evidence:

• The internal architecture doc says base/ must have zero upward imports (desloppify/README.md:95).
• But desloppify/base/subjective_dimensions.py imports upward into intelligence and languages (:10-17).
• desloppify/intelligence/review/dimensions/metadata_legacy.py pulls DISPLAY_NAMES from scoring core (:5), while scoring core reaches back into metadata via runtime imports explicitly marked as cycle breaks (desloppify/engine/_scoring/subjective/core.py:63-76).
• The same dimension defaults are duplicated across files (base/subjective_dimensions.py:21-77, engine/_scoring/subjective/core.py:9-33, metadata_legacy.py:9-38).

Why this is poorly engineered:

• This creates a brittle cross-layer knot in the scoring/review path where metadata ownership is ambiguous.
• It depends on lazy/runtime imports and fallback behavior (_dimension_weight silently falls back to 1.0 on metadata failures), which can mask breakage and produce hard-to-debug scoring drift.
• It materially increases maintenance cost: any dimension rename/weight/default change must stay synchronized across multiple modules linked by a cycle.

I’ll keep digging for other candidates, but this one already looks like a significant structural issue, not a style nit.

[agustif]

Second entry:

plan persistence uses a destructive read-path migration strategy that can erase user intent, instead of fail-safe schema handling.

Why this is poorly engineered:

• On load, newer-version plans are only warned about, then still mutated (engine/_plan/persistence.py:58, :67).
• ensure_plan_defaults always runs migration/coercion on read (engine/_plan/schema.py:198).
• Migration coerces wrong shapes to empty containers (engine/_plan/schema_migrations.py:25, :30, :42) and force-sets version to v7 even for newer input (:304).
• If invariants still fail, it drops to a fresh empty plan (engine/_plan/persistence.py:69-73).
• Normal flows then save that result (engine/_plan/persistence.py:80-97; app/commands/scan/preflight.py:47-50), making loss durable.

This is not just a one-off bug. It is a structural reliability decision: read-time compatibility problems are handled by silent coercion and reset, not by preserving unknown fields or failing loudly. In a planning tool, this undermines auditability and trust because queue/cluster/skip intent can disappear during routine command execution.

Related pattern exists in state persistence too (engine/_state/schema.py:401, :431; engine/_state/persistence.py:128, :138).

[agustif]

Third entry:

review packet construction is split across multiple independent pipelines with visible schema/policy drift, even though a canonical packet builder exists.

Why this is poorly engineered:

• Packet assembly is duplicated in at least three paths: app/commands/review/prepare.py:41, app/commands/review/batch/orchestrator.py:134, and app/commands/review/external.py:145.
• There is a central builder/coordinator path (app/commands/review/packet/build.py:53, app/commands/review/coordinator.py:208), but these flows bypass it.
• Drift is already present:
  • max_files_per_batch is applied in prepare.py:55 and batch/orchestrator.py:149, but not in external.py:154.
  • config redaction is applied in prepare.py:70 and batch/orchestrator.py:155, but not in external.py:125.

This is a structural maintenance problem, not a style preference. Any packet contract change now requires synchronized edits across separate code paths, so behavior diverges by execution mode instead of policy. That is a classic regression multiplier in orchestration systems: correctness depends on remembering to patch every parallel implementation.

[renhe3983]

Poorly Engineered: Fake Language Support

Problem: 22 out of 28 languages have ZERO actual implementation

The repo claims to support 28 languages, but 22 of them are completely fake — they only have a single __init__.py file with no real detectors, fixers, or review logic:

bash, clojure, cxx, elixir, erlang, fsharp, haskell, java, 
javascript, kotlin, lua, nim, ocaml, perl, php, powershell, 
r, ruby, rust, scala, swift, zig

Only these 6 languages have real implementations:

• python (14 .py files)
• typescript (11 .py files)
• csharp (11 .py files)
• dart (7 .py files)
• go (7 .py files)
• gdscript (7 .py files)

Why this is poorly engineered

1. False advertising — "28 languages" is misleading; only 21% are real
2. Bloat — 22 empty language folders add unnecessary complexity
3. Maintenance burden — fake languages create confusion for contributors
4. Resource waste — CI/CD, docs, and code paths handle non-functional languages

Reference

• desloppify/languages/ — 31 directories, but 22 are empty shells
• Run: ls desloppify/languages/*/ to verify

This is classic "vibe engineering" — appearing comprehensive without substance.

[peteromallet]

I'm afraid you misunderstood the code, my friend, I made a decision here that may be questionable but keep looking and you'll see

Poorly Engineered: Fake Language Support

Problem: 22 out of 28 languages have ZERO actual implementation

The repo claims to support 28 languages, but 22 of them are completely fake — they only have a single __init__.py file with no real detectors, fixers, or review logic:

bash, clojure, cxx, elixir, erlang, fsharp, haskell, java, 
javascript, kotlin, lua, nim, ocaml, perl, php, powershell, 
r, ruby, rust, scala, swift, zig

Only these 6 languages have real implementations:

• python (14 .py files)
• typescript (11 .py files)
• csharp (11 .py files)
• dart (7 .py files)
• go (7 .py files)
• gdscript (7 .py files)

Why this is poorly engineered

1. False advertising — "28 languages" is misleading; only 21% are real
2. Bloat — 22 empty language folders add unnecessary complexity
3. Maintenance burden — fake languages create confusion for contributors
4. Resource waste — CI/CD, docs, and code paths handle non-functional languages

Reference

• desloppify/languages/ — 31 directories, but 22 are empty shells
• Run: ls desloppify/languages/*/ to verify

This is classic "vibe engineering" — appearing comprehensive without substance.

[renhe3983]

Thanks for clarifying! I understand now — it was an intentional design choice.

Let me share a few other observations from my review:

1. Monolithic Files

• execution.py (748 lines), core.py (720 lines), concerns.py (635 lines)
• These violate the single responsibility principle and are hard to maintain

2. Massive Test Files

• test_holistic_review.py (2370 lines)
• test_narrative.py (2293 lines)
• Test code exceeds business logic in size

3. Duplicate Config Patterns

Each language has its own phases.py with nearly identical structure:

• python/phases.py, typescript/phases.py, go/phases.py, etc.
• Could be consolidated into shared configuration

4. Thread Safety Concerns

runner_parallel.py uses threading.Lock() but the codebase may have race conditions in concurrent file scanning.

These are architecture-level observations rather than bugs. Great project overall!

[peteromallet]

Thanks! Will add to the review

Thanks for clarifying! I understand now — it was an intentional design choice.

Let me share a few other observations from my review:

1. Monolithic Files

• execution.py (748 lines), core.py (720 lines), concerns.py (635 lines)
• These violate the single responsibility principle and are hard to maintain

2. Massive Test Files

• test_holistic_review.py (2370 lines)
• test_narrative.py (2293 lines)
• Test code exceeds business logic in size

3. Duplicate Config Patterns

Each language has its own phases.py with nearly identical structure:

• python/phases.py, typescript/phases.py, go/phases.py, etc.
• Could be consolidated into shared configuration

4. Thread Safety Concerns

runner_parallel.py uses threading.Lock() but the codebase may have race conditions in concurrent file scanning.

These are architecture-level observations rather than bugs. Great project overall!