Comment by skybrian
3 hours ago
> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.
This happens, but it's only one way to use a coding agent. I'm working on a small, personal project, but I ask it to do "code health" tasks all the time, like complicated refactorings, improving test coverage, improving the tooling surrounding the code, and fixing readability issues by renaming things. Project quality keeps getting better. I like getting the code squeaky clean and now I have a power washer.
You do have to ask for these things, though.
Some people like using hand tools and others use power tools, but our goals aren't necessarily all that different.
Indeed, one of my favourite things about coding assistants is that I can now get an easy code review on my personal projects, or once I've thought through my approach have it think up alternatives I may not have stumbled on.
I've found it very unsatisfactory (both experience and results) to use them to replace code production. But in terms of augmenting the process - used to critique, explore alternatives, surface information - they're getting really quite handy.
My favorite thing is just being able to talk through the code and problem and have someone right there too response even if it not 100% right it still gets you to think and it nice to have it push back on things you ask ect. It basically a co worker you can bug all day and everytime they are still happy to help.
And there are different contexts.
In reality there are tons of tasks at work that are boring and time constrained. There are days I don't enjoy it, and days I do. It's not binary - I still love programming by hand but at times I let Agents work whilst reviewing the results.
Lets not just assume that we know whether AI is a hand tool or a power tool
It works fine for webapps and other slop-adjacent projects.
If you try to do anything outside of typical n-tiered apps (e.g. implement a well documented wire protocol with several reference implementations on a microcontroller) it all falls apart very very quickly.
If the protocol is even slightly complex then the docs/reqs won't fit in the context with the code. Bootstrapping / initial bring-up of a protocol should be really easy but Claude struggles immensely.
> (e.g. implement a well documented wire protocol with several reference implementations on a microcontroller)
I have had an AI assistant reverse engineer a complex TCP protocol (3-simultaneous connections each with a different purpose, all binary stuff) from a bunch of PCAPs and then build a working Python server to speak that protocol to a 20-year-old Windows XP client. Granted, it took two tries: Claude Opus 4.1 (this was late September) was almost up to the task, but kept making small mistakes in its implementation that were getting annoying. So I started fresh with Codex CLI and GPT-5.1-Codex had a working version in a couple hours. Model and tool quality can have a huge impact on this stuff.
I just vibe coded a VST. Runs a mix of realtime DSP and ML models. Really nontrivial stuff. It does exactly what I want.
Claude Opus 4.5 is truly impressive.
That's an app (running ML), not a protocol.
I hear people report the opposite.
The sloppier a web app is, the more CSS frameworks are fighting for control of every pixel, and simply deleting 500,000 files to clear out your node_modules brings Windows to its knees.
On the other hand, anything you can fit in a small AVR-8 isn't very big.
Whatever you do, your mileage may vary.
Yep, but I don’t intend to let that happen to my web app! It’s not that big and I intend to keep it that way.
Dependencies are minimal. There’s no CSS framework yet and it’s a little messy, but I plan to do an audit of HTML tag usage, CSS class usage, and JSX component usage. We (the coding agent and I) will consider whether Tailwind or some other framework would help or not. I’ll ask it to write a design doc.
I’m also using Deno which helps.
Greenfield personal projects can be fun. It’s tough to talk about programming in the abstract when projects vary so much.
Given the amount of Arduino code that existed at the time LLM's were trained, I would have to agree that AVR-8 might be fine. For now it's on the Cortex-M struggle bus.