ebhn

Nice article, but the methods they used seem more like they just hand wrote a function for the task and called the function neurons based on how it was implemented. It is encouraging though that a simple network can be found for a complicated task like this, kind of like the Tiny Recursive Model that came out last year.

Nice, I really like your idea. First I've heard of something like that

Totally agree with this. When I review code I don't build a strong mental model of the system, and I think you can only really do that by solving the problems that arise during the creation of the system yourself. I'm optimistic the pendulum will swing away from the "hand off a spec to an agent(s)" and back towards engineers being engaged and directing LLMs to implement/optimize smaller, more specific pieces of code, with most of the direction being determined by the user

This is super useful. Thanks for sharing!

I like this direction, but I worry about developers involvement in the design of the DSL becoming the new bottleneck with the same problems. The code which becomes the guardrails cannot just be generated slop, it should be thoroughly designed and understood imo

Working on new code review tooling specifically for reviewing your own branches/commits when you use an "AI Agent" to assist with writing code. It seems all of the tools people are building in this space attempt to automate away the review, but I want better tools for reviewing (and tracking tech debt) in the code I just generated locally. Will publish here soon

Yea my job as a SWE is to have a correct mental model of the code and bing it with me everywhere I go... meetings, feature design, debugging sessions. Lines of code written is not unimportant, but matters way less when you look at the big picture

I think that for me with things like notes/writing, privacy is #1 by a lot. Preserving the textEdit workflow is nice, but I (and I imagine other users) could definitely be convinced to modify it given the right tooling and confidence in it. I know my workflow is not a productivity global maximum (and probably not even a local maximum), but everything I've seen so far does not justify itself as moving me far enough up on the productivity scale to offset the discomfort of changing habits.

Fwiw I really like the way you summarized the "constraint". Maybe I'm out of the loop on what's out there, but I don't think I've come across too many tools like that aside from lower level things like git.

This is the main thing I have learned too. I've been building an internal tool for myself to annotate lines in each commit diff as good (green) / needs refactor (yellow) / needs rewrite (red) and it has helped me keep track of this kind of tech debt. Basically does what you could do with "TODO refactor" comments all over, but is more comprehensive and doesn't litter your source code. Plan to open source it once I've dog-fooded it a little more

That's hilarious

I actually like this idea, but most of my notes are scattered in untitled, unsaved textedit windows. It would be nice if I could run something locally that would access and scrape those unsaved notes, but would also leave them be. I don't think I'll ever stop having tons of these little note windows, but it would be nice if I could request a summary or forgotten action items in my own time.

Very cool!