Error
Invalid input: 1 validation error for PlanRequest current_km Input should be greater than 0 [type=greater_than, input_value=0.0, input_type=float] For further information visit https://errors.pydantic.dev/2.5/v/greater_than
Even if it broke after some sort of vibe coding session, the fact that we’re now pushing these tools to their limits are what’s allowing Anthropic and Boris getting a lot of useful insights to improve the models and experience further! So yeah, buckle up, bumps expected
Over the holiday period, I have vibecoded a simple running/fitness app that I wish I had, but never found!
The app is geared towards running, offering comprehensive plans for different distances and durations, with the ability to log runs/save plans, export to PDF and focused on simplicity.
It uses a progressive distance building approach to allow runners to safely reach their goals.
As an extra, it offers some dedicated strength training for running as well as healthy/hearty meals focused on lean protein, veggies and all the cliches :)
I know there's nothing new or unique about an app like this, but, I like that I have one single place where I can generate a running plan, have some nice meal ideas for when I lack inspiration, as well as some strength training added in the mix!
If this resonates and it's helpful, there's an option to buy me a coffee which will help cover all the vibecoding/hosting costs :)
I hope it's as useful for someone as it has been for me (currently following a plan generated with it for a trail run in a few months' time!).
GLM-4.7 in opencode is the only opensource one that comes close in my experience and probably they did use some Claude data as I see the occasional You’re absolutely right in there
I got their z.ai plan to test alongside my Claude subscription; it feels about on par with something between sonnet 4.0 and sonnet 4.5. It's definitely a few steps below current day Claude, but it's very capable.
dumbness usually comes from lack of information, humans are the same way - the difference between other llms is that if opus has information it has a ridiculously high accuracy on tasks.
z.ai (Zhipu AI) is a chinese run entity, so presumably China's National Intelligence Law put in place in 2018, which requires data exfiltration back to the government, would apply to the use of this. I wouldn't feel comfortable using any service that has that fundamental requirement.
Google, OpenAI, Anthropic and Y Combinator are US run entities, so presumably the CLOUD Act and FISA require data exfiltration back to the government when asked, on top of the all the "Room 641A"s where the NSA directly taps into the ISP interconnects, would apply to the use of them. I wouldn't feel comfortable using any service that has that fundamental requirement.
I wouldn't use any provider: z.ai, Claude, OpenAI, ... if I was concerned about the government obtaining my prompts. If you're doing something where this is a legitimate concern (as opposed to my open source stuff), you should get a local LLM or put a lot of effort into anonymizing yourself and your prompts.
I agree completely, I meant in terms of opensource ones only.
Opus 4.5 is the current SOTA and using it in Claude Code is an absolute amazing experience.
But, paying 0 to test GLM-4.7 with opencode, feels like an amazing deal! I don’t use it for work though. But to keep “gaining experience” with these agents and tools, it’s by far the best option out there from all I’ve tried.
Claude spits that very regularly at the end of the answer, when it's clearly out of it's depth, and wants to steer discussion away from that blind-spot.
Perhaps being more intentional about adding a use case to your original prompts would make sense if you see that failure mode frequently? (Practicing treating LLM failures as prompting errors tends to give the best results, even if you feel the LLM "should" have worked with the original prompt).
Inspired by a lot of back-and-forth work with several different agents, as well as shaped by my own understanding of using context windows (and tokens) in as efficient a way as possible, the LLMs and myself have came up with a quite cool system heavily inspired by Anthropic's skills to dynamically extend an agent's capabilities.
Based on how it works, the name "Lazy Skills" was the most logical one!
The thing is all these big labs are so “transformer-pilled”, and they need to keep the money furnaces growing that I think it’ll take considerably more than 10 years, more like 20-30 if we’re lucky.
I both agree and disagree with this post, but I might be misunderstanding it.
Near the end, it states:
“Enjoy writing it, it doesn’t have to be nice or pretty if it’s for you. Have fun, try out that new runtime or language.”
It doesn’t have to be nice or pretty EVEN if it’s NOT for you.
The value in prototyping has always been there and it’s been very concrete: to refine mental models, validate assumptions, uncover gaps in your own thinking (or your team’s), you name it.
Unfortunately it feels that the pendulum has swung in the completely opposite direction. There’s a lot of “theatre” in planning, writing endless tickets and refining them for WEEKS before actually starting to write code, in a way that’s actively harmful for building software.
When you get stuck in planning mode you let wrong assumptions grow and get baked in into the design so the sunken cost keeps rising.
Simply have a BASIC and SHARED mental model of the end goal with your team and start prototyping. LLMs have made this RIDICULOUSLY CHEAP. But, the industry is still stuck in all the wrong ways.
> It doesn’t have to be nice or pretty EVEN if it’s NOT for you.
> There’s a lot of “theatre” in planning, writing endless tickets and refining them for WEEKS before actually starting to write code, in a way that’s actively harmful for building software.
I'd love to have a "high paying job" where I am allowed to start prototyping and modelling the problem and then iteratively keep on improving it into fully functional solution.
I won't deny that the snowballing of improvements and functional completeness manifests as acceleration of "delivery speed" and as a code-producing experience is extremely enjoyable. Depth-first traversal into curiosity driven problem solving is a very pleasurable activity.
However, IME in real world, someone up the chain is going to ask "when will you deliver this". I have ever only once been in a privileged enough a position in a job to say "I am on it and I will finish it when I finish it... and it will be really cool"
Planning and task breakdown, as a developer, is pretty much like my insurance policy. Because when someone up the chain (all the way down to my direct manager) comes asking "How much progress you have made ?" I can say (OR "present the data" as it is called in a certain company ?) "as per the agreed plan, out of the N things, I have done k (< N) things so far. However at this (k+1)th thing I am slowing down or blocked because during planning that-other-thing never got uncovered and we have scope-creep/external-dependency/cattle-in-the-middle-of-the-road issue". At which point a certain type of person will also go all the way to push the blame to another colleague to make themselves appear better hence eligible for promotion.
I would highly encourage everyone to participate in the "planning theatre" and play your "role".
OR, if possible start something of your own and do it the way you always wanted to do it.
I feel like this is the time to mention "How Big Things Get Done", by Bent Flyvbjerg. "Long planning vs. start prototyping" is a false dichotomy. Prototyping IS planning.
Put another way, refining tickets for weeks isn't the problem; the problem is when you do this without prototyping, chances are you aren't actually refining the tickets.
Planning stops when you take steps that cannot be reverted, and there IS value in delaying those steps as much as possible, because your project then becomes vulnerable to outside risk. Long planning is valuable because of this; it's just that many who advocate for long planning would just take a long time and not actually use that time for planning.
For my money, certain types of software shouldn't have tests, too much planning, or any maintenance whatsoever
Prototypes (start ups) rarely have the luxury of "getting it right", their actual goal is "getting it out there FAST to capture the market (and have it working enough to keep the market)"
(Some - apologies but I'm not a game dev enough to be able to say what types this applies to) Game devs - they're more or less build it, ship it, and be done with it, players tend to be forgiving of most bugs, and they move on to the next shiny thing long before it's time to fix all the things.
Once the product has traction in the market, and you have paying customers, then it's time to deal with the load (scale up) and bugs, I recall reading somewhere that it's probably best to drop the start up team, they did their job (and are now free to move on to the next brilliant idea), and replace them with a scale up team, who will do the planning, architecting, and preparation for the long term life of the software.
I think that that approach would have worked for Facebook (for example) they had their PHP prototype that captured the market very quickly, and (IMO) they should have moved through to a scale up team (who could have used the original code as a facade, strangling it to replace it with something funky (Java/C++ would have been what was available at the time, but Go would be what I would suggest now)
I’ve been reading the comments here… idk which companies you all work at, but, at least in all places I’ve worked you’ll have 2/3 people who are REALLY GOOD. Then you’ll have like 3/4 people who can sort of “trail” after those. And then there’s “the rest”.
I’ve seen “the rest” making informed and “well planned” decisions that are just terrible approaches to a given problem.
An LLM can actually be a net positive versus this rest.
You get tailored running schedules and also some body weight strength workouts and healthy meals all in one!
reply