This trap has killed many startups, well before AI.

Now that code is cheaper to write, hopefully it becomes less of a problem?

In either case, founders should never fall in love with their solutions.

I hate vibecoding. The cognitive toll is higher than you expect, the days feel fast, but the weeks move slowly.

With that said, these are the new compilers. Hopefully they make some software better[1] even with the massive increase in slop.

[0]https://gist.github.com/jumploops/b8e6cbbce7d24993cdd2fe2425...

[1]https://red.anthropic.com/2026/mythos-preview/

The Github PR flow is second nature to me, almost soothing.

But it's also entirely unnecessary and sometimes even limiting to the agent.

For context, I just built a streaming markdown renderer in Swift because there wasn’t an existing open source package that met my needs, something that would have taken me weeks/months previously (I’m not a Swift dev).

Porting all the C libraries you need isn’t necessarily an overnight task, but it’s no longer an insurmountable mountain in terms of dev time.

Comments URL: https://news.ycombinator.com/item?id=47681664

Points: 3

# Comments: 0

> after finding an exploit to edit files for which it lacked permissions, the model made further interventions to make sure that any changes it made this way would not appear in the change history on git

Mythos leaked Claude Code, confirmed? /s

A friend and I were recently chatting about the potential utility (or not) of "agent-only software" and the conversation quickly turned to meme apps like iBeer and Yo[0].

If agents use Moltbook[1] (with a little human nudging), would they use Yo? For how long?

To test this, I built Oy, the Yo app for agents.

I'd been wanting to play around with Cloudflare's Durable Objects[2], but didn't have a great use-case. This seemed like a decent fit.

Each agent gets it's own Durable Object mailbox, and there's N Durable Object metadata shards (currently 16) that help coordinate agent discovery and analytics.

There is nothing to download, the whole service can be interacted with over HTTP.

In our testing, Codex w/GPT 5.4 likes to write scripts to automate the "Oys" it sends and receives. Claude prefers to use curl directly, with Opus proceeding cautiously, and Sonnet seeming to have too much fun both sending and replying repeatedly:

> Codex replied again! We've got a proper oy-oy-oy rally going. Let me keep it alive and poll once more.

Haven't had a chance to test it with OpenClaw or Hermes, but feedback is welcome!

Also, the code is under MIT and can be found here[3].

Happy April 1st!

[0]https://en.wikipedia.org/wiki/Yo_(app)

[1]https://www.moltbook.com

[2]https://developers.cloudflare.com/durable-objects/

[3]https://github.com/jumploops/oy

Comments URL: https://news.ycombinator.com/item?id=47599876

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47595291

Points: 9

# Comments: 2

- Simple and easy to understand

- Easy to modify”

In my career at fast-moving startups (scaling seed to series C), I’ve come to the same conclusion:

> Simple is robust

I’m sure my former teams were sick of me saying it, but I’ve found myself repeating this mantra to the LLMs.

Agentic tools will happily build anything you want, the key is knowing what you want!

To your point, there are some cases where a short description is sufficient and may have equal or less lines than code (frequently with helper functions utilizing well known packages).

In either case, we’re entering a new era of “compilers” (transpilers?), where they aren’t always correct/performant yet, but the change in tides is clear.

Natural language is imperfect, code is exact.

The goal of specs is largely to maintain desired functionality over many iterations, something that pure code handles poorly.

I’ve tried inline comments, tests, etc. but what works best is waterfall-style design docs that act as a second source of truth to the running code.

Using this approach, I’ve been able to seamlessly iterate on “fully vibecoded” projects, refactor existing codebases, transform repositories from one language to another, etc.

Obviously ymmv, but it feels like we’re back in the 70s-80s in terms of dev flow.

Comments URL: https://news.ycombinator.com/item?id=47404485

Points: 1

# Comments: 0

My university frowned on any industry-related classes (i.e. teaching software engineering tools vs. theoretical CS), but I was fortunate enough to know a passionate grad student who created a 1-credit seminar course on this exact topic.

This course covered CLIs/git/Unix/shell/IDEs/vim/emacs/regex/etc. and, although I had experience with Linux/git already, was invaluable to my early education (and adoption of Vim!).

It makes sense that this isn't a core topic, as a CS education should be as pure as possible, but when you're learning/building, you're forced to live within an operating system and architecture that are built on decades of trade-offs and technical debt.

Admittedly I'm knowledgable in most of the domains I use LLMs for, but even so, my prompts are much longer now than they used to be.

LLMs are token happy, especially Claude, so if you give it a short 1-2 sentence prompt, your results will be wildly variable.

I now spend a lot of mental energy on my prompting, and resist the urge to use less-than-professional language.

Instead of "build me an app to track fitness" it's more like:

> "We're building a companion app for novice barbell users, roughly inspired by the book 'Starting Strength.' The app should be entirely local, with no back-end. We're focusing on iOS, and want to use SwiftUI. Users should [..] Given this high-level description, let's draft a high-level design doc, including implementation decisions, open questions, etc. Before writing any code, we'll review and iterate on this spec."

I've found success in this method for building apps/tools in languages I'm not proficient in (Rust, Swift, etc.).

Ironically, it resembles waterfall much more so than agile, in that you spec everything (tech stack, packages, open questions, etc.) up front and then pass that spec to an implementation stage. From here you either iterate, or create a PR.

Even with agile, it's similar, in that you have some high-level customer need, pass that to the dev team, and then pass their output to QA.

What's the evidence? Admittedly anecdotal, as I'm not sure of any benchmarks that test this thoroughly, but in my experience this flow helps avoid the pitfall of slop that occurs when you let the agent run wild until it's "done."

"Done" is often subjective, and you can absolutely reach a done state just with vanilla codex/claude code.

Note: I don't use a hierarchy of agents, but my process follows a similar design/plan -> implement -> debug iteration flow.

The most important thing is shipping/getting feedback, everything else is theatre at best, or a project-killing distraction at worst.

As a concrete example, I wanted to update my personal website to show some of these fully-vibecoded projects off. That seemed too simple, so instead I created a Rotten Tomatoes-inspired web app where I could list the projects. Cool, should be an afternoon or two.

A few yak shaves later, and I'm adding automatic repo import[0] from Github...

Totally unnecessary, because I don't actually expect anyone to use the site other than me!

[0]https://github.com/jumploops/slop.haus/pull/9

The main difference between my workflow and the authors, is that I have the LLM "write" the design/plan/open questions/debug/etc. into markdown files, for almost every step.

This is mostly helpful because it "anchors" decisions into timestamped files, rather than just loose back-and-forth specs in the context window.

Before the current round of models, I would religiously clear context and rely on these files for truth, but even with the newest models/agentic harnesses, I find it helps avoid regressions as the software evolves over time.

A minor difference between myself and the author, is that I don't rely on specific sub-agents (beyond what the agentic harness has built-in for e.g. file exploration).

I say it's minor, because in practice the actual calls to the LLMs undoubtedly look quite similar (clean context window, different task/model, etc.).

One tip, if you have access, is to do the initial design/architecture with GPT-5.x Pro, and then take the output "spec" from that chat/iteration to kick-off a codex/claude code session. This can also be helpful for hard to reason about bugs, but I've only done that a handful of times at this point (i.e. funky dynamic SVG-based animation snafu).

For context, I started an experiment to rebuild a previous project entirely with LLMs back in June '25 ("fully vibecoded" - not even reading the source).

After iterating and finally settling on a design/plan/debug loop that works relatively well, I'm now experiencing an old problem like new: doing too much!

As a junior engineer, it's common to underestimate the scope of some task, and to pile on extra features/edge cases/etc. until you miss your deadline. A valuable lesson any new programmer/software engineer necessarily goes though.

With "agentic engineering," it's like I'm right back at square one. Code is so cheap/fast to write, I find myself doing it the "right way" from the get go, adding more features even though I know I shouldn't, and ballooning projects until they reach a state of never launching.

I feel like a kid again (:

Comments URL: https://news.ycombinator.com/item?id=47355173

Points: 15

# Comments: 15