The author implies they're a highschool aged programmer.
They're likely along for the ride with their parents and very online.
I'd probably do the same thing at their age.
I think they are fairly interchangeable,
In Roo Code, Claude uses the tools better, but I prefer gemini's coding style and brevity (except for comments, it loves to write comments)
Sometimes I mix and match if one fails or pursues a path I don't like.
I've been actively developing a commercially deployed SvelteKit application, and I'd like to share some thoughts on my experience.
What initially drew me to SvelteKit was its simplicity. After setting up the project, I could work on one HTML/JS/CSS file at a time, leveraging the benefits of a modern framework without the accompanying complexity. This approach reminded me of the early days of web development, where dropping HTML files into an Apache server was all it took to get things running.
However, it's disheartening to see Svelte shifting away from that straightforward paradigm. From the outset, Rich Harris positioned Svelte's ease of use and simplicity as its key selling points. The current version of SvelteKit isn't bad per se, but I found myself preferring the earlier iterations. Back then, I didn't have to deal with constructs like `+page` for routing. I could place Svelte files wherever I wanted, and they would render seamlessly, all while enjoying the advantages of a modern framework.
This change adds layers of complexity that weren't necessary before, potentially moving away from what made Svelte appealing in the first place. I picked it up because I already knew what I needed to know.
I also use Astro + Svelte. It's nice but I wouldn't say it's less complex than sveltekit. But I just like being able to introduce dynamic components and server side functionality gradually into a base static site.
The default model on ollama is the 7b distillation.
Its ability to solve basic math problems with reasoning is pretty cool, but other models of that size (qwen 2.5, phi4) have been generally more useful to me.
These tiny models still strike me as toys, not a whole bunch of real-world utility.
There is a frustrating gap between benchmarks and real world ability.
O1 or even O3 might be able to crack academic level math problems, but I still wouldn't trust it to correctly fill out a McDonalds application using a PDF of my resume and a calendar of my availability.
A lot of that has to do with certainty. The GPTs and Claudes will be replacing graudate-level research assistant jobs and other jobs that are very high skill but have soft success criteria long before they replace travel agents, which have low skill but very hard criteria for success.
The reasoning models are much better suited to questions that have answers and a conclusion to arrive at. Ie exactly what benchmarks ask. Rather than make me a todo list app or whatever.
It’s a bit like you get instruct tuned models and you get chat tuned ones. It’s not really one worse than the other just aimed at different uses
These benchmarks are mostly focused on math, which benefits a lot from an improved CoT and is also less sensitive to having "reduced knowledge" in smaller model.
While this raises valid concerns, Copilot and friends can actually enhance learning by exposing devs to new patterns and approaches.
They still require problem-solving and critical evaluation skills. By handling routine tasks, they free up time for higher-level thinking.
It's just another abstraction layer, like high-level languages were. Responsible use combined with continuous learning can boost productivity without sacrificing knowledge.
The impact differs between experienced devs and beginners. As these tools evolve, we'll likely develop new meta-skills around AI collaboration. Like any tool, it's about how we use it.
