My guess is that there's probably a missing abstraction layer in the 3d editors somewhere. I am pretty bullish on AIs ability to solve this problem, even just based on existing image to 3d models like TRELLIS and HY3D. They work pretty darn well and take a lot of the burden out of not just modeling, but texturing and uv unwrapping.
That being said, I have a correlate here for music production and you could definitely make a lot of the same arguments about it, and they'd be true -- really high learning curve to make something halfway decent even assuming you have the taste part sorted. Some of it is the ability to just creatively think in another language once you become fluent in it.
I think AI can give you leverage when it does stuff you could actually do it manually yourself because you can manually evaluate it and correct it competently. The hard part is how would you evaluate work that is beyond your current competence level?
If that isn't easy, if it's incompressible relative to your current skill level, then that's the very human part that will always be a bottleneck. And that's fascinating to me because if there were better AI tools for music production when I picked it up a few decades ago, I don't know that I would have developed the same fundamentals.
What will fundamentals look like in a post-agentic world? If a lot of the manual gruntwork disappears or is more heavily abstracted, I believe that will matter a lot more.
First of all, it's so cool to see you on HN and creating this. I'm not sure how much the HN community is aware of this, but JUCE is the standard for cross platform music plugin development and needs to work efficiently in hard realtime settings. Many of my favorite plugins are JUCE based (such as the Valhalla stuff) and I'm a huge fan. Tracktion is a great DAW as well that I got a lot of mileage of in my younger days (ended up with Renoise because I'm a tracker guy after all long term).
I mention all this to say someone like you picking up the desire to build an agentic platform really piques my interest. Right now I am using Opencode for most of the stuff I am trying to do at $WORK and it does a good job on the whole at having sufficient functionality. But the release pace is blistering and it does feel bloated - both in terms of functionality as well as system prompts.
Moreover, I observed all of the same issues you mentioned and certainly wanted more of a tree like experience as well as a more UI forward experience. In order to get the functionality I wanted (good worktree support, sandboxing, etc) I eventually just had to let go of using opencode's UI and embrace the TUI because it was the only thing I could embed into a workflow that let me set up all of that in a sane manner. But problems still remain with the "doom scroll" experience when to your point clearly a tree based experience would be better.
I was ready to just settle with my cobbled together opencode flow and maybe migrate to Pi later on and just accept i'd have to roll my own GUI harness for my nontechnical team members. But seeing what you've put together so far (and knowing it's you who wrote it so I'm probably going to just see a step function level better quality in architecture/efficiency) is going to make me reassess in a good way. Some things that I'll be considering:
- Worktree support
- Sandbox support
- Skills/subagent handling
- Hashline based editing (feel like this is a huge part of why
people get better results from pi/omp over opencode/codex/claude code)
- Ability to customize tool calls + have rich embeds
- Web UI support (if i'm building this out for team members, native GUI can get messy and web client is ideal)
- Long horizon efficiency (IE i regularly get to 200k-400k context length sessions; while the model handles it fine, opencode gui will get laggy while the tui keeps chugging along)
For a lot of this stuff, it's less critical that all of this works perfectly out of the box and more critical that the architecture makes it easy to build (ie as with Pi ecosystem). What I'm after long term is something a bit like https://github.com/ColeMurray/background-agents in capability but without the overly tight coupling and design decisions that product has made.
The way I want to get there is to find the right base (whether that's Pi, OpenCode, or your project Juggler) and build the background agent harness layer. Previously it was just Pi and OpenCode and neither was really perfect (GUI story was probably the weakest for both) but it's great that I have another option to diligence that might actually be a better fit for what I'm trying to do.
Excited to see how this develops and kick the tires on it myself. The tree paradigm feels like the killer feature to me; not sure of anything else besides pi/omp that has it.
I understand the concern and it's fair but I am very curious about what happens when the two notions of "free" (free as in beer, and free as in freedom) start to diverge because the former gets easier to do.
The latter as always been more durable. Linux doesn't have the mindshare it does because it's "free" as in beer - it's because it's "free" as in freedom.
The price of freedom, of brewing your own beer, is sometimes higher than buying it from the store. But for many folks, the control over the supply chain is what makes it worth it. In LLM-land, it might take a little bit of time for folks to catch up -- or maybe a lot of that is already in motion as companies get paranoid (and rightfully so) to frontier labs getting a little grabby about data. If you need a ZDR environment, "free" as in freedom has a very high premium that you will pay and rightfully so.
I kinda like the music comparison because it's so rich with sociological analogues. You have the gear snobs who can't stop buying more premium gear but never sit down and write anything. The kids who pick up a copy of Garageband and put together hits with their natural talent, sense of taste and and interesting story to tell. Soundtrack and videogame composers who have hybrid instincts of session musicians and architects. Avant garde musicians who you're never fully sure of whether they're playing a joke you're in on (or on you) and that's kinda the point. Music critics who have never played or written music a day in their life and yet end up becoming arbiters (or more accurately, delegates) of taste. Fandom stans and ringleaders who absorb it as an identity and run extraordinarily well organized cults with an iron fist.
You can probably find correlates here with coding and AI any which way you look. Coding is so rich that you can use it to do artistic, creative pursuits because it really is an interactive and world building medium if you want it to be. And it can also be a practical, reliable machine that helps you get useful business objectives done. And anywhere in between!
Perhaps the author is indexing on the former because there's an intrinsic value to that, and intrinsic values seem to be quite drowned out by the noise of extrinsic values in this media supercycle.
But I don't think it'll be that way forever. Whenever things get too noisy, people have a way of seeking peace and quiet.
I don't disagree with your conclusions (enterprises will pay top dollar for service guarantees, integration, and someone they can sue) but by that same logic there is no clear winner with Anthropic/OpenAI. Claude has a habit of going down on me when I need it most and seems to be struggling to even keep 3 nines of availability. They're actively hostile to integration and seem more convinced they should be suing others than behaving in a way that doesn't get them sued.
That's not to say I don't believe that there won't be a closed source correlate. I just don't know if OAI and Ant are all that exists.
"Anyone who depends on code review to find bugs is living in a fool's paradise. As everyone should know by now, it is not in general possible to find bugs by examining the code."
I think this is pretty clumsily stated. The way I would best summarize what it should be is "The person best suited to address bugs in the code is the author/owner." That's usually some blend of detecting and fixing them. Code review can certainly surface bug-prone patterns being introduced (or extended), and even catch them directly.
But as many of the peer commenters state here, the depth of code review that finds buggy behavior and risky structuring is pretty involved and an expensive use of time. At most places I've reviewed code prior, this was always amortized as cost of doing business. Maybe partly because there wasn't a "theoretically" faster alternative, and maybe because we were trying to avoid 2 steps forward 1 step back.
Now, I think we are struggling with "the clinical trial problem" where there is more pressure to ship using AI but it doesn't actually abridge the QAing and review part. The problem with trying to abridge that part is it just creates backpressure like a spring and then catastrophically explodes 10x worse later on than if it was dealt with directly. It can be very easy to build a circle of pitfalls that were completely unnecessary. I think that automated code review techniques are going to have to evolve to keep up with the new paths that code can be generated through.
And to anyone that has to go through new, arms race enhanced forms of slop cannons -- my heart goes out to you, because the old ones were never particularly pleasant to deal with.
I've seen folks make it work with a 3090 on 4 bit quant using turboquant for KV cache. That's key because 3090s remain the most cost effective gpu metal for enthusiasts (albeit 24g) and the jump to 5090 (32g) is quite expensive and not always worth the LLM specific performance; sadly, good 32g metal is somewhat lacking in the price point at or above the 3090.
One of the most challenging kinds of thought to work through with my engineers in professional communication is nuance. For example, they may say something like this, but actually mean "For a particular situation, this is wrong."
The context a decision is evaluated is particularly important for "rules of thumb" like this. There's the rule of 3 (which many senior engineers imparted to me earlier on in my career) - don't refactor until you've actually duplicated it thrice, but even so, what they speak of is a catch-22 that's pretty important to reason about carefully.
On one hand, if you overcorrected on the fear of abstraction, you could easily end up with 500 duplicates that are slightly different and need to be maintained 500 different ways, slowly causing slightly wrong behavior some of the time, data corruption, combinatoric explosion. Surely, once there is such a situation, some degree of abstraction is the only right decision.
On the other hand, if you overcorrected on the fear of duplication early on, you could easily end up with a premature optimization and complexity -- complexity which, most importantly, could be rooted in a gap of understanding of how the code will be used and what direction it may go in over time (often based on which direction the business will go over time).
The only answer that actually works, of course, is "somewhere in the middle." Obviously, that's pretty vague and not very useful. Where, exactly, in the middle IS the right place?
As the years have gone by, I've become more and more steadfast that the answer to that question is and must be an art and not a science. Of course, it must always be rooted in practicality, the actual context of the code around it and where the code/business was in the past and where it will be in the future.
But just as importantly, some of it must be based around beliefs in the face of imperfect information about what you want to invest in for the sake of the technology, the team that develops it, and the business that relies on it. It could be that for your team, your values make it make sense to go a little bit further than "good enough" on normalizing your data modeling, because the way you like to run your business requires that normal form to do the analytics and make decisions productively. It could be that for your team, your values make it make sense to go a little bit further than "good enough" on splitting service boundaries and ensuring clean queues and message passing infrastructure, because you have seasonal spikes where you need to scale up to a ton of load and then scale down after without constantly doing a song and dance or pre-provisioning fragile infrastructure.
But the most common thread there is - art, not a science. Every single decision depends on YOUR team, YOUR business, YOUR needs - and like any art, there is no universal rule or discovery or best practice in the industry that will magically work for your needs without working through the details of whether it appropriately fits your situation or not.
So with that said - I can't really agree with you. At any place I've ever worked with a competent team, maintaining duplicate code is just not that hard and follows the same process for being dealt with. Built a robust test suite that encodes the actual differences and the shared structure. Pull out the pieces that have a good reason to be abstracted and redesign the pieces that encode the true differential structure in a way that is intuitive. Lather rinse repeat. It's always straightforward because it's known - by the time you are doing this process, you've had tons of repetitions and data on what is driving you to develop the abstraction, so when you make the decision, you are making it empirically.
Conversely, I have seen many otherwise competent teams slowed to a halt with premature abstraction. Frameworks that were well intended and reduced duplication, but encoded coupling between components that at a certain point in the businesses progression, fought with reality rather than aided, and all because they were frozen into place before anyone empirically had really clear data about whether the abstraction would be worth it long term. Well intended "clean code" refactors that were meant to solve the old "bad duplication" but instead created a far more difficult to reason about "abstracted base" of code that didn't really solve any of the domain modeling problems and was just as difficult to maintain without introducing buggy behaviors (if not more so) than before.
The biggest problem is that premature abstraction is sexy and fun. There are incentives and dopamine hits from doing it extraneously. But fixing legacy duplication is not fun. And so when it gets done, it tends to get done in a pragmatic way to relieve pain rather than to elicit pleasure. That, I believe is one of the biggest confounding sociological aspects of this whole discussion.
What makes you think there will actually be a guillotine? This isn't the French Revolution era.
The alternative to your wet dream is that both Bernie and Luigi are hapless and actually incapable of altering the systems they rail against besides symbolic token gestures meant to appease the hopes of someone, anyone to serve as a messianic figurehead.
What if -- bear with me here -- the very thing that makes those founders able to make the $1B they would otherwise make would drive them to also ask why it is that someone else who had no hand in building or funding it gets lion's share of the $900M while they get only $100M?
You don't /know/ that people need to collectively get over "this" -- you have a feeling that it seems more fair to do that than the alternative. But you can look at what happens elsewhere in the world with regimes that implement exactly what you are describing. And what happens is the people who are most equipped to be the golden gooses that you are proposing are just as equipped to simply most somewhere they can do so unencumbered.
That's why what you're proposing will just never really work.
What happens to the person who earns their income laying bricks when an automatic bricklaying machine is built? Is it unethical for them to earn that income because they are operating the machine? What about the person who finds them people who need bricks laid because the person who lays bricks finds it hard to get good clients who aren't a pain?
I really wish people weren't so easily seduced by the labor theory of value.
The kind of abliteration you are mentioning is no longer state of the art or the most common form of removing the refusal layer in most models. Your your understanding was up to date about a year and a half ago, but has been out of date since after that.
Couldn't agree more. Maybe it's because it's a shining example of their ideological system that actually alters /my/ life, in ways that are tangible and which i can grasp, and makes it better.
It might change soon. Nemotron 120b was never flashy but always well regarded in the community and had material strengths at long context. The 550b next gen version is out now and still very fresh. It is too early to tell but for some reason I believe the impact it will eventually have is quite strong. NVIDIA open weight models are really good. They're not flashy but they're always well put together, well documented, well licensed, and in general make for truly great bases for customization - whether it's Nemotron or Cosmos.
Cosmos 2 in particular already has taken the image diffusion world by storm in a finetune (Anima) essentially replacing/dethroning the previous budget king SDXL. I wonder if the newest Nemotron could have the same impact for open weights LLM?
You can always run deepseek yourself, v4-pro and flash are open weights. It's a little tricky to get the hang of self deploying open weight models but you do fully own your deployment substrate and privacy narrative at that point.
I've been really enjoying claude design but my biggest critique of it (and frankly how vanilla claude handles files in general) is that it has no native conception of git-like version control. In code land you can work around this with harnesses so there's only so much harm claude code/opencode can do, but to your point in small biz land when it's putzing around with a system of record without rewindability, things could get really messy really fast.
A couple more thoughts here - the hard part is not just the data side of it, it's replaying/unplaying actions. Many actions are non-reversible. Code is clean in the same way that google docs is clean. But for many business processes, some actions just can't be unwound once started. If claude initiates a wire that it shouldn't, no amount of git technology will undo that wire.
It's been a very strange realization to have with AI lately (which you have reminded me of) because it also reminds me that the same thing works with humans. Not the killing part at least, but the honeypot and jailing/restricting access part.
Probably because telling someone not to do something works the 99% of the time they weren't going to do it anyways. But telling somebody "here's how to do something" and seeing them have the judgment not do it gives you information right away, as does them actually taking the honeypot. At the heart of it, delayed catastrophic implosions are much worse than fast, guarded, recoverable failures. At the end of the day, I suppose that's been supposed part of lean startup methodology forever -- just always easy in theory and tricky in practice I suppose.
401k rollovers into IRA aren't that hard these days and you could always use that IRA to have a more customized strategy, more specifically direct indexing of a major fund minus key ticker symbols you don't want exposure to. Of course, that all presumes that you won't regret excluding this long term.
That being said, I have a correlate here for music production and you could definitely make a lot of the same arguments about it, and they'd be true -- really high learning curve to make something halfway decent even assuming you have the taste part sorted. Some of it is the ability to just creatively think in another language once you become fluent in it.
I think AI can give you leverage when it does stuff you could actually do it manually yourself because you can manually evaluate it and correct it competently. The hard part is how would you evaluate work that is beyond your current competence level?
If that isn't easy, if it's incompressible relative to your current skill level, then that's the very human part that will always be a bottleneck. And that's fascinating to me because if there were better AI tools for music production when I picked it up a few decades ago, I don't know that I would have developed the same fundamentals.
What will fundamentals look like in a post-agentic world? If a lot of the manual gruntwork disappears or is more heavily abstracted, I believe that will matter a lot more.