kissgyorgy

Maybe I don't understand the reasoning or the premise, but subagents can make writing code, experimenting way faster and you don't have to manage them, a large and smart model will manage them for you.

Also there are harnesses (e.g. omp) which are using multiple LLMs debating, questioning, reviewing other LLMs output and you get a pretty good result at the end that way, which makes your job of reviewing them faster too.

I'm pretty sure Jev is one of the fastest adapted new technology in production. The concept is so simple and there are so many use cases which are very useful at the right places.

I'm not sure we are looking at the same font, this one looks way crispier and more readable than any other font I have ever seen before.

I don't think it's even competitive with Gemma 4 E2B

Please don't be attached to a tool emotionally, it's not healthy. Think of it like a huge autocomplete or text editor, it's not really different! It's just a tool.

This is probably slower than writing the code yourself. Doesn't make sense to me. Using an agent without YOLO mode is not wort it.

The way I rather do it is tightly control the output by skills written yourself, prompts, plans, etc. and have the closest possible outcome you would write yourself.

    we expect substantial benefit for legitimate defensive work, while meaningfully constraining prohibited offensive use.

That's literally impossible. Writing an exploit agains a known vulnerability needs the exact same knowledge that defending against the exploit of the same vulnerability.

Also just making the model better at code is just making it better to writing offensive code.

This is exactly what LLMs are really bad at. They don't have the knowledge (and don't ask for) the invariants of the system and write defensive code at every step of the way, which is not just unnecessary, it's bad because if an unexpected state still get into the system, you will never notice and bad data will flow through and makes everything unpredictable.

I cancelled in the minute my subscription stopped working in Pi. Not going back to the slopfest what Claude Code is.

There is not a lot of explanation WHY is this better than doing the opposite: start coding and see how it goes and how this would apply to Codex models.

I do exactly the same, I even developed my own workflows wit Pi agent, which works really well. Here is the reason:

- Claude needs a lot more steering than other models, it's too eager to do stuff and does stupid things and write terrible code without feedback.

- Claude is very good at following the plan, you can even use a much cheaper model if you have a good plan. For example I list every single file which needs edits with a short explanation.

- At the end of the plan, I have a clear picture in my head how the feature will exactly look like and I can be pretty sure the end result will be good enough (given that the model is good at following the plan).

A lot of things don't need planning at all. Simple fixes, refactoring, simple scripts, packaging, etc. Just keep it simple.

You need to be very specific about what to build and how to build it, what tools to use, what architecture it should do, what libraries, frameworks it should include. You need to be a programmer to be able to do this properly and it still takes a lot of practice to get it right.