I was there in the early days (90's, early 2000's)
It was categorically, undeniably better--that's where the nostalgia is coming from.
There are lots of reasons why this happened (and those are interesting questions.) But simply denying that it was better doesn't seem particularly reasonable to me.
I miss the early days. I made my first "telnet" connection in either 1990 or 1991. I remember exploring gopher, FTP, early web sites, the transition from BBSes to early ISPs. It was all so exciting and new.
The Internet of today is barely recognizable. The very thing that made it sustainable (commercialization) is also what led to its demise.
There are still sites (like HN!) that give me a taste of the old world. But they are few and far between.
Constraints tend to make you enjoy something more. I agree that a lot of the things that annoy me today weren't present back then. But a lot of other things that I take for granted these days also weren't present back then.
(author here) I strongly agree that these systems start to break down once the code base gets larger (we've seen that with our own projects)
But our reaction to it has been to say "ok, well the best practice in software engineering is to make small, well-isolated components anyway, so what if we did that?"
We've been trying to really break things apart into smaller pieces (and that's even evident in mngr, where much of the code is split out into separate plugins), and have been having a ton of success with it.
I realize that that might not be an option for more brownfield / existing / legacy projects, but when making something new, I've really been enjoying this way of building things.
(author here) I agree that it's super important to understand what software actually does--that's part of the whole reason we made mngr in the first place!
I believe we can use these types of tools to make software more understandable, and mngr is an example of how to do that.
In our case study, we're using AI to increase our test coverage, and if you look at it, I would argue that we are making it more understandable--now instead of just having 100's of tests, we simply have a document that describes how the software is supposed to work, and the tests are linked to that document, and checked to ensure that they conform.
That means that anyone--not just the author of the software--is now able to read through the high level tutorial description of how the commands work in order to understand what the program should do!
And as for the tests themselves, we've been able to make nice testing infrastructure--like the transcripts and recordings that were highlighted in the post--to make it even easier for us to verify the behavior of the software.
We also have an incredibly detailed style guide and set of tests and guidelines to ensure that the entire code base is consistent, and high quality. You can drop into any of the code and pretty quickly understand what is happening. And if not, claude will do an excellent job of describing how any given component works, and how it relates to the others.
Finally, mngr itself is designed to be fully transparent when it is running--you can literally attach to the coding agent you are running and see exactly what is happening, and the program makes extensive log outputs for everything it does (feel free to open a PR if you'd like to see more!)
It's not perfect formal verification, but it does feel like we're making meaningful progress on making it easier to understand software--not harder.
And it is great! Really! Reading your post I was thinking if I could not do the same to write tests in an automated way in project I am working on. It would be awesome!
Though in an other hand we are living in a corporate, capitalistic, and a lot inhumane economic system. If this way of automation would work and deliver consistent output in a way of working software for 2 or 3 years, how long it would take to C-level suits to figure out that it is way better to have 2 or 3 Product Owners and maybe one Designer to write description of the entire programme and then just feed it to one of those automation pipeline? If tech giants will price product like that reasonably and it will work actually, how long it will be till it will cause entire industry to collapse and you will be able to produce software by paying to those tech giants? And it there will be like 5 of those only in the entire world - because nobody else will have enough GPUs. How soon till they came to agreement and split the world in areas of monopoly:
- if your company is in Asia you can either buy your application from Google or Alibaba.
In a world when everything is done in a computer via the software, such concentration of power would be bad for everyone.
Of course I doubt it will come that, simply because this would be very hard to achieve with our level of technology and some human involment will be necessary. But maybe I am kiding myself and I will loose my job entirely in few years along with tens of thousands other Software Engineers in a few years.
These are real problems, and I think you nailed it: the concentration of power is the core issue.
I don't have a simple, perfect solution. We're just trying to make it possible for individuals and smaller companies to have access to the same kinds of tooling that the largest companies already have access to, and hopefully equalize the playing field at least a little bit...
If anyone has better ideas, I'd love to hear them!
Since Sculptor allows you to use custom docker containers (devcontainers), you can check out the other projects in there.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
It actually originally worked that way, and you can still mostly kinda use it that way (except that, because of CSRF protection, it's obnoxious -- run the program once to figure out the command line that the backend python process is started with, eg, via `ps -Fe` on linux, then shut down the app, then run that process. As long as you don't set the `ELECTRON_APP_SECRET` env var, CSRF will be disabled. Use `netstat -pant | grep -i listen` to figure out what port it is listening on)
Obviously not the most user friendly or usable, but we found that people often got pretty confused when this was a browser tab instead of a standalone app (it's easy to lose the tab, etc)
sculptor_backend seems to consume a lot of CPU and memory when just idling. Would you consider switching from Electron to Tauri so it uses the native WebView of the OS?
I haven't tried it, but it might work if you set the env var yourself (I think you can create a `.env` file in `~/.sculptor/.env` and it will be injected into the environment for the agent)
I'd give it a good 20% chance of working if you set the right environment variables in there :) Feel free to experiment in the "Terminal" tab as well, you can call claude directly from there to confirm if it works.
Nope, not based on vibekit, but it looks like a cool project!
Our approach is a bit more custom and deeply integrated with the coding agents (ex: we understand when the turn has finished and can snapshot the docker container, allowing rollbacks, etc)
We do also have a terminal though, so if you really wanted, I suppose you could run any text-based agent in there (although I've never tried that). Maybe we'll add better support for that as a feature someday :)
It was categorically, undeniably better--that's where the nostalgia is coming from.
There are lots of reasons why this happened (and those are interesting questions.) But simply denying that it was better doesn't seem particularly reasonable to me.