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

Points: 2

# Comments: 0

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

Points: 3

# Comments: 0

Our notes:

Sonnet 4.6 feels like a fundamentally different model than Sonnet 4.5, it is much closer to the Opus series in terms of agentic behavior and autonomy.

Autonomy - In our zero-shot app building experiments, Sonnet 4.6 ran up to 3-4x longer than Sonnet 4.5 without intervention, producing functional apps on par in terms of quality to the Opus series. Note that subjectively we found Opus 4.5 and 4.6 are better "designers" than Sonnet 4.6; producing more visually appealing apps from the same prompts.

Planning / Task Decomposition - We found Sonnet 4.6 is very good at decomposing tasks and staying on track during long-running trajectories. It's quite good at ensuring all of the requirements of an input prompt are accounted for, whereas we were often forced to goad sonnet 4.5 into decomposing tasks, Sonnet 4.6 does this naturally.

Exploration - In some of our complex "exploration" tasks (e.g. cloning/remixing an existing website), Sonnet 4.6 often performs on par or better than Opus 4.5 and 4.6. It generally takes longer, and takes more tokens, though we believe this is likely a consequence of our tool-calling setup.

Tool-use - Sonnet 4.6 seems eager to use tools; however, we did find that it struggles with our XML-based custom tool use format (perhaps exclusive to the format we use). We did not have a chance to assess with native tool use

Self-verification - Similar to Opus 4.5/4.6, Sonnet 4.6 has a proclivity for verifying it's work.

Prompting - We found Sonnet 4.6 is very sensitive to prompting around thinking, planning, and task decomposition. Our prompt built for sonnet 4.5 has a tendency to push sonnet 4.6 into incredibly long thinking and planning loops. Though we also found it requires significantly less careful and specific instructions for how to approach problems.

How are we thinking about this:

We can't launch this model day 0, it requires more changes to our harness, and we're working on them right now.

But it reminds me a bit of 3.5 to 3.7 --> It's a pretty different model that behaves and responds to instructions in new ways. So it requires more tuning before we can extract its full potential.

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

Points: 3

# Comments: 0

[1] https://x.com/karpathy/status/2017442712388309406

It feels like such a super power. What you're describing is particularly important in the era of long running AI processes. Something as simple as running a deploy creates pressure on your agent orchestration. But if everything is powered by OBAN you have wonderful ways to build durability.

By the way, it's all "free" and built-in.

In other language ecosystems, people literally pay for durability that has this shape (like temporal)

This is vibe argumenting.

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

Points: 4

# Comments: 0

I understand the "enjoy doing anyway" part and it resonates, but not using AI is simply less productive.

some people are building custom, tailored social networks only available to their family, church, community, sports team, school, etc...

This was previously impossible but now AI changes that. I don't know if it will materialize, but a more federally distributed web with tons of small private social networks could be a future of healthy social

If i were to try this out with some somewhat sensitive company data, what is the security profile of this? Would it potentially leak the data to MCP servers? Do I have control?

It combines the "opinionated" aspects of ruby and rails and the power of erlang. The BEAM is like no other runtime and is incredibly fun to work with and powerful once you get how to use genservers and supervision trees.

We use Elixir for Mocha, and my one issue with it (I disagree with OP on this) is that live-view is not better than React for writing consumer grade frontends. I wish Phoenix took a much stronger integration with React approach, that would finalize it as the top choice for a web stack.

The title is deeply ironic.

Lovable and bolt took a massive shortcut: they outsourced the backend to a third party (supabase).

This makes their ceiling to build "useful" software incredibly low.

The right approach takes a lot more time: pick an opinionated framework (think ror) and build up a full stack app builder from the ground up.

Took us months and months of work to get it working, but now people _can_ build "useful" software (thats our bar)

Code is a medium, painting is a medium, piano is a medium, and prompting is a medium.

This sounds a little bitter.

Unsurprisingly, I see he didn't have much to say about faceit and esea.

I think CSGO anti-cheats are a league above the rest (I'm not sure why, maybe because the scene is more competitive?)

In addition to what you're saying: - hosting costs - live sandboxes costs

They're betting on LLM costs going way down and VC funded until then

- The churn from companies like lovable is indeed very high, and user frustration is high also.

- There are sub-niches available. Building internal tools is not the same as landing pages is not the same as saas. In the previous website builder market, different players (webflow, squarespace, wix) found and dominated a sub-niche

- The market is way bigger than anyone realizes. Today hundreds of millions for basically early adopters and highly tech-savvy users. This tech can and will go mainstream

- A huge issue with lovable, solved by others like mocha and replit, is the app backend. Lovable took a shortcut and partnered with supabase but that deal will not last. Supabase is losing big on their free tier (had to raise 200M to support it) and both want to capture the margin from the customer. There will be a reckoning.