Internal Tool vs Production - Harness engineering: Leveraging Codex in an agent-first world

Acknowledgment that vibe coding works better for internal tools and dashboards, higher standards needed for production services

While vibe coding enables developers to generate massive volumes of code quickly, critics warn that this speed often produces "slop" that requires a significant "tax" of manual cleanup and deterministic guardrails to remain functional. The consensus suggests that while this approach is a breakthrough for internal tools and front-end projects with rapid feedback loops, it remains a "no-go" for production services where long-term maintainability and architectural integrity are paramount. Ultimately, commenters argue that navigating a million-line codebase is a feat of context management, but without human steering and strict logical oversight, the resulting output risks becoming a low-quality mess that is impossible to sustain.

View on HN · Topics

There is a sense in which it doesn’t matter at all; many of the limitations of agents in large codebases are just the context management challenges. So proving that you can cohere and progress at O(1m) is a useful scale observation. “Can I use agents in my 1m line codebase?”

There is of course another sense in which the output quality is the only thing that matters. “Can I use agents to build a 1m line codebase that I want to maintain going forward.”

I take this as being exclusively a tech demo of the former. Quality (feature velocity, bugs, scalability) is not demonstrated.

View on HN · Topics

I am at a major company that is essentially vibe coding. I’ve shipped about 100k LoC this entire half and am toward top 10% of my team. I find it likely that either

A. The code is absolute garbage and is speed for speed sake
B. They’re using an internal model that is a generation beyond GPT 5.5

I say this because we’ve attempted to do something similar using the latest gen Claude models and a significantly larger team. The code is probably along the lines of millions LoC but is an absolute mess because of vibing. There’s a price you pay for speed

View on HN · Topics

I think vibe coding is okay for a small internal tool, dashboard, etc. but it’s definitely a no-go for a production running service.

View on HN · Topics

Q1 - How much effort did you put into deterministic guardrails like AST linters, etc?

I find there’s a ton of slop unless hard guardrails are added, eg step 1 is just around syntax, step 2 is to enforce mental models

You still need someone steering direction and have a logically consistent idea of what you actually want to build

Q2 - I find that vibe coding really accelerates FE projects because it’s possible to run everything locally and check results

For pure distributed infra backend more investments have to be made into the devloop to be able to shift left the feedback loop and decouple it from humans or real deploys

View on HN · Topics

I like how they said they were spending 20% of their time addressing slop. Sounds like they’ve tried to automate the slop correction but it’s a good honest reminder.

Additionally it’s an internal tool, which is likely much more amenable to slop.

View on HN · Topics

I would never dare put that in production