Personal software factories are a waste of time
Posted by thegreatpeter 3 days ago
Comments
Comment by jchw 3 days ago
I could be misunderstanding what a "software factory" is but I think whatever I have done fits the criteria. I have a custom agent that goes around implementing software and maintaining private repositories completely autonomously and I can communicate with it using issues and comments.
It seems like a useful pattern, just maybe not what people had in mind. I think people figured that you'd build an AI Microsoft or something. I don't think that's true because most of what a company like that does isn't really software engineering anyway, but there is probably still something to this pattern.
Comment by myzek 3 days ago
First of all - after reading all that, I still don't fully know what the author exactly means by "software factory". Please define the term if you are to argue about it so we know exactly what you're talking about.
Second of all - the author is glorifying one approach to tech (the "idea guys") and severely downplaying other approaches. Just because he finds this fun and entertaining doesn't mean everyone does - and the world needs all of those people. Idea guys are cool and they just got a very powerful tool, but we still need those passionate devs who dedicate a lot of their time to building and researching massive projects even if they're not sure they make sense
Comment by dogleash 2 days ago
It's the same "look at how right I am" post we've all read dozens of times. Dismissive and condescending about what projects should or shouldn't be explored, and of the people who explore the wrong ideas. Same as always, just with a fresh coat of paint for the AI age.
I have thoughts on what may be fruitful and worthwhile to explore. But this post isn't about that, really.
Comment by lichenwarp 3 days ago
Comment by RaftPeople 2 days ago
For home stuff I've shifted to a software day spa
But for work, I've gone a step further and now run a software CPG distribution center combined with a software recycling plant.
The code flows out of the DC, gets consumed by the business and then tossed back to the recycling plant, fully green from a 1's and 0's perspective.
Comment by shlant 3 days ago
Comment by ajmurmann 3 days ago
My software factory emerged that way and for the 50-70% of simpler tasks I work on this saves me so much time and, more importantly, mental overhead.
Comment by brightball 3 days ago
Using Elixir, Phoenix, LiveView and Ash for everything creates a very well defined and verifiable structure for every part of the codebase with a precommit that looks like this:
precommit: [
"compile --warnings-as-errors", # Fail compilation if any warnings exist
"deps.unlock --check-unused", # Fail if unused dependencies are unlocked
"deps.audit", # Scan dependencies for known security vulnerabilities
"cmd mix hex.audit", # Audit Hex packages for retired or vulnerable versions
"migrations.safety", # Check database migrations for unsafe operations
"format --check-formatted", # Verify code matches the formatter style
"credo --strict", # Run strict static code analysis checks
"sobelow --exit --threshold high --skip", # Fail on high-confidence security issues only
"ash.codegen --check", # Ensure Ash generated code is up to date
"usage_rules.sync --check", # Verify usage rules are synchronized
"cmd bun run lint", # If there's JS beyond LiveView
"test" # Run the full test suite
]
The result has been excellent consistency across my code base and the AI learns fast how it should be working. Everything comes out very readable if I want to dig into something.For the most part, everything I ask for gets 1 shotted with this approach with typically rare minor tweaks and refinements.
Comment by vekker 2 days ago
I personally want to keep my commits light & fast, so it's not an impediment to commit often. I've always found even a simple reformatter on commit can be a bit annoying. Ideally for every micro-task done I commit, even if it's messy and even if I decide to revert the work later. It becomes kind of like a reasoning trace. Only when the task is completed, must the code comply to all the necessary checks, and then it becomes a PR and CI jobs run to validate
Comment by brightball 2 days ago
1. If these all took a very long time to run, it would create a case to defer to the CI. With Elixir, virtually every check you see runs maximally parallel and the entire precommit stack finishes very quickly. I use this as part of queued, local "/goal" commands because I have built up a level of trust that queuing a dozen goals and then reviewing them in the morning will be correct virtually every time.
2. Since everything finishes quickly, having it setup as a precommit check let's the agent see and correct all of the failures locally before anything goes up to the CI itself. All of these checks are duplicated at the CI layer, but it's extremely rare for anything to fail. As a bonus, the AI learns and adapts to the feedback of these checks so it's correct the first time eventually.
Comment by reddit_clone 2 days ago
If you commit early and often, yes this could turn annoying really fast. May be GP works with local-changes/git-index for a bit and commits when somewhat satisfied.
Comment by jweatherby 3 days ago
Comment by nielsole 3 days ago
Comment by coldtea 3 days ago
Comment by iugtmkbdfil834 3 days ago
Comment by lukan 3 days ago
Comment by joshstrange 2 days ago
Comment by schmookeeg 3 days ago
Comment by neko_ranger 3 days ago
"pull out all hardcoded strings in web app into i18n files. do not stop until hard coded strings linter stops complaining"
or
"create tests to test uncovered lines by code coverage. do not stop until all files at at least 95% covered per the reporting tool output"
Comment by stavros 3 days ago
I think about posting a Show HN of something I made, and then think "everyone will have made ten things before lunch, why would I", and just never share now.
Comment by kaashif 3 days ago
I don't think it's natural for a software engineer to want to build a "software factory" because I have never heard of anyone doing that. I'm sure it's a thing.
What I see everyone doing is just building software, incorporating their feedback into agents.md, skills, etc, to make their harness better. Is that a factory? Should people not do that?
I still don't really understand.
Comment by simplesocieties 3 days ago
All you need is the source code for your existing project and the claude code/codex/opencode cli and boom, you are ready to ship. Most people doing the impressive stuff with AI are just using it, not building harnesses or "agentic" tooling.
Comment by arcbyte 3 days ago
Needs change when you go from 2 or three chat windows to 100.
Comment by jurgenburgen 3 days ago
Comment by rc-1140 3 days ago
I think if you have plans for a software factory (read: some kind of conceptual framework for a loop that turns tasks into code/features), you should try it. My opinion is that even if your implementation is a bust or you never take it past a proof of concept, you've at least done something to inform yourself about what's out there and what you've tried.
Better to have a graveyard of barely started projects that give depth to your knowledge instead of relegating yourself to prompt slavery because [frontier model of the financial quarter] can do Marvel + Bioshock + Ted Lasso + Command and Conquer or whatever horrifying Consumptionslop™ that people like Nikita Bier love so much.
Comment by honr 3 days ago
With that out of the way, I think trying out developing software-building automation is a great learning experience, regardless of the final outcome. Beside [re]learning various ropes that might have been modernized recently, you are likely to end up with bonus [possibly tiny] helper tools that you can carry into your other software development projects. Or you might learn new [non technical] disciplines around software development life cycle.
Comment by sheepscreek 3 days ago
I think they mean a side-gig or business, a SaaS essentially. While I disagree with them that they 'are a waste of time', it depends entirely on the 'what'.
A lot of bars have shifted in a never-been-seen-before way. Many intractable or unsolvable problems for a single developer, that required teams and 6 months or years, can now be solved in a few evenings.
That does NOT mean that everyone is capable of doing this. Which leads to my argument that there is still a market for many ideas, just not your kanban boards, todo lists or scheduling assistants. Have to look beyond at harder problems (the author mentions a few good ones) that solve a genuine user need end-to-end. This also means niche products are low-effort now and could be worth doing, even for a few select customers.
My favorite kind are developing new software for niche/old devices, to make them do new things. People who are making old TVs usable again for lack of software support are my heroes.
Comment by jmathai 2 days ago
The author is saying, build project A and stick with it. This isn't new to the "AI era" but it's more pertinent.
Comment by sheepscreek 1 day ago
I even think that most ideas no matter how dumb they sound in the present could become profitable businesses in the future. Survival is key here. Basically outlast your naysayers until an opportunity appears and then grab it with both hands. You’ll automatically have the first mover advantage.
The most famous example I can think of is Nvidia!
Comment by zhivota 3 days ago
Comment by georgemcbay 3 days ago
I'm sure that old Java EE programmers have their LLMs building software factory factories by now.
Comment by brokenmachine 3 days ago
Comment by codebastard 3 days ago
I believe a software factory is just the next step in the mantra everything is code.
One wants to write a feature description and acceptance criteria into the "box" as fuzzy and with least details as much as possible.
To enable this, one creates for the factory access to information of the domain, requirements and software stack as required by the environment.
And this one attempts all with tools, documentation and processes optimized for the ai.
All with the goal use less tokens, context and speed up every action taken by an agent as much as possible.
That's why there is a trend to plugin based self evolving harnesses which try to automate this with opionated solutions.
Therefore I don't see a reason why building tools for easier testing and less tokens usage is a waste of time especially because one learns more a more areas in ones work one can automate and because depending on your tool choice it can be done without your input and one misses the chance to experiment if ones input in that regard will improve the factory or not.
Comment by zem 3 days ago
Comment by collin128 3 days ago
I'm not a software engineer and it's enabled me to build a startup with $4k mrr in the last few months solo.
Comment by firemelt 2 days ago
Comment by eterm 3 days ago
I'd say give it another couple of months and you won't be able to move for announcements about this kind of thing.
The "sales pitch" is that factories are to agents what agents were to models; Personally I'm not convinced we need an extra automation layer, with all the downsides that come with even more disconnection from the product being built, but some people are starting to swear by them.
Comment by imtringued 3 days ago
>with all the downsides that come with even more disconnection from the product being built,
With vibe coding you are already fully disconnected from the process.
With a software factory you are reconnecting yourself to the old process.
Comment by matsemann 3 days ago
Comment by imtringued 3 days ago
The meaning is in the name. It is a factory for software. You have actionable work items that are put in a queue (assembly line) to be worked off (along dedicated stations). Then you have a quality assurance process at the end that rejects faulty parts.
And the goal of the developer is to optimize the process instead of the end result because you can regenerate the end result from scratch as many times as you want, not too different from a compiler.
If agents have excellent single shot performance then it would be best to lean in on it and build cattle software instead of wasting human time with AI written pet software.
Comment by matsemann 3 days ago
Comment by d13z 3 days ago
Comment by Fordec 3 days ago
Comment by dvh 3 days ago
framework
Comment by bbor 3 days ago
Now, that has changed. This isn't just better models, it's a qualitative improvement in capabilities, a step-change, an inflection point; what the MLrs like to call emergent capabilities, in a loose sense.
To pick just one very tangible example close to my heart: This is why the three.js subreddit[2] has exploded in popularity, showcasing demos by non-engineers that blow any three.js app I saw pre-singularity out of the water, which took hundreds of hours of specialized engineering to make (ask me how I know...). The community is reacting[3] much like the mathematicians, understandably.
---
Ok now to answer your actual question (sorry -- that was the intention, originally!) as concisely as I can. "Software factories" are any system you setup to help you build software in deeply agentic ways. All the major harnesses and "ADEs" like Zed could arguably fit here already, but there's a massive ecosystem of other takes, as this article implies. I don't want to give them too much credit for just snagging the name, but the "Factory" startup does embody the idea pretty well: https://docs.factory.com/
They often (though not necessarily, IMHO) include some services that spawn their own agents after deterministic checks ("latent services", in my lingo) and services that use DL models more subtly to empower otherwise-symbolic services ("semilatent services").
In my biased experience, they often focus on a few central usecases, solving the problems that individual devs run into when trying to run multiple harnesses on multiple projects without friction, longterm decoherence, token wastage, or bottlenecks:
1. Code review. This is the big one and far trickier than it seems (trust me!), so often tried then abandoned. There's a huge startup just for this: https://www.coderabbit.ai
2. Cross-harness syncing of settings, hooks, and/or various flavours of very important markdown -- AGENTS.md files, skills, and subagents personas being the big ones.
3. Cross-agent, harness-agnostic coordination and communication. This just recently reached both the main harnesses, but it seems internal for now; a `BULLETIN.md` helps me a TON.
4. More generally, cross-agent coordination when it comes to worktrees, resource sharing (e.g. OCR queues on my 4090, for me), persisting agent-facing content (e.g. reports, trackers, scratch files, .jsonl blobs) in a convenient place that doesn't clog up the repo, and other technical details that might otherwise have to be figured out again and again by each agent.
5. Enforcing standards, either through hooks (blockers, nudges, or revertable fixes) or the aforementioned services. Think commit messages, prose simplicity, doc conventions, etc., though the sky's the limit, here. Like an intuitively-intelligent, more complexly triggered, agent-only precommit setup, in a way.
6. Finally, there's a whole ecosystem of tooling for agents, which I like to call "ACIs"/"Agent-Computer Interfaces". The sky is both the ground and the limit, here; it's really whatever the dev finds their agents to be oddly inefficient about, or just straight up bad at. I personally some to make edits "self-healing", normalize post-OCR cleaning, and capture quick screenshots w/ optional aesthetic critique[4], if that gives you a sense.
TL;DR: Fun stuff to make that speeds you up because it's tailormade to how you work! I made a bunch because I've been ""self-employed"" and thus had the time to explore myself[5], tho I understand why a more realistic after-work paradigm would make this kind of work wasteful.
On that note, back to writing cover letters -- apologies if the long message bothers anyone. I really should start a blog or get a hobby or something, huh
---
[1]: i.e. Mythos and GPT-6, though obviously access rolled out slower to orgs/people without the special access programs, and even slower to people who prefer open models, where GLM-5.3[-Flash] was the first real contender[9]. For internal agent usage see this graph https://epoch.ai/data-insights/openai-coding-agent-spending and/or this writeup from June https://www.anthropic.com/research/claude-code-expertise
[2]: https://www.reddit.com/r/threejs/top/?t=month
[3]: https://www.linkedin.com/posts/danielgreenheck_i-think-its-t...
[4]: https://gitlab.com/doering-ai/libs/tact , https://gitlab.com/doering-ai/libs/mend , https://gitlab.com/doering-ai/apps/piq
[5]: Most of it is still private, but I made a subset public at https://gitlab.com/doering-ai/libs/fleet , and my code review & hooks are at https://gitlab.com/doering-ai/apps/gate
[9] https://www.anthropic.com/research/glm-5-3-and-the-spread-of...
Comment by imtringued 3 days ago
There is no qualitative change whatsoever. The training dataset now contains more agentic sessions and that alone was enough. Most model architectures that came out this year haven't meaningfully changed anything in terms of making models more expressive, if anything they took steps backwards in the name of inference optimization.
So it literally is better models in the form of better data and nothing else, otherwise it wouldn't have been so easy for competitors to clone leading capabilities.
Also LLM just means it is a large model that can output language and technically the LLM archetype was replaced by almost every new model being a VLM (vision language model) which is a meaningless nit pick.
Comment by yjftsjthsd-h 3 days ago
It's still LLMs though? This feels like saying we've moved on from using compilers now that we have IDEs; that's just a wrapper and we're still using the first thing.
Comment by zem 3 days ago
i do use agents for code review but again in a very human-in-the-loop manner; i will ask for a review and then read it over before feeding it to my coding LLM session and asking it to read and iterate on it. as you say, it can be surprisingly tricky to get right, and i like the confidence of the human being the coordinating reviewer.
thanks for all the examples, though - that does give me a lot more context for what people mean by "software factories" (and the assurance that they don't fit the way i work).
Comment by joshstrange 2 days ago
My prediction is that, at least for a while, software factories will be incredibly custom, and might always be that way. Perhaps there will be some sort of open core software factory that then companies augment as needed, but I doubt we’ll have a one-size-fits-all. I could be completely wrong. Nine months ago, I thought software factories were silly, so don’t take my word for it.
I wrote about this recently here: https://joshstrange.com/2026/10/12/there-are-many-like-it-bu...
Comment by Olscore 3 days ago
People are thinking about this from a quantity angle, but the key is quality, and achieving a self-maintaining project at home. I built a distributed trading system that runs multiple strategies in US options and MUST be correct. So my goal wasn't to build huge quantities of software and pump out garbage, but to ensure correct behavior and proper fixes in the codebase with agents.
Open sourced my methodology: https://github.com/pullboard-dev/pullboard
Comment by hilariously 3 days ago
Comment by imtringued 3 days ago
If you know what you're building, the software factory is a foregone conclusion.
Comment by gaiagraphia 3 days ago
If you try and one shot stuff, you're going to get a smell of the LLM, but if you build an entire ecosystem of development, it's going to be something a little more unique to know you are and what you know.
I think we're going to see some huge changes in language, in how we learn, present, build and design things. As these millions of 'software factories' start maturing and competing, we're going to see some interesting standardisations win out.
It should be applauded that people want to push capabilties of their new toys to the max. I wonder if some people are also scared about the golden age of LLMs coming to an end soon, and want to dig a huge moat ASAP, too... The more you can get deterministic tools and frameworks up and running, the less at mercy you're going to be in the future to huge AI companies.
Comment by wakaru44 2 days ago
I do agree with the tendency of certain personality types to build factories, I've seen already way too many projects like that.
Comment by joshstrange 2 days ago
[0] https://joshstrange.com/2026/10/12/there-are-many-like-it-bu...
Comment by saulpw 3 days ago
Now I find that sometimes I do have tasks that I just want completed, and they're small or obvious or scoped enough that I know my role would be basically opening up a session and telling it to implement it and then asking another LLM for review and then fix the problems it found and then rubberstamp it--this is all for my personal setup so "QA" just involves me trying out the feature in my normal workflow anyway. So now I have a little miniature "software factory" that does the above, but without me needing to be in the loop. I press Alt+N and type e.g. "make TTS streaming" and continue about my other business, and in 5 minutes my text-to-speech setup has gone from nothing showing up until I toggle my push-to-talk switch, to words showing up at every pause.
I know it's not a bigco "software factory" but it serves my needs. And isn't that what this new era is about? We have a magic genie that grants wishes as long as they're well-enough defined and it's connected to the right other pieces to make it happen. So create an internal process that allows that genie to grant your wishes reliably and in bulk. What else is a "software factory" anyway?
Comment by Varyz 1 day ago
Comment by BatchJob 3 days ago
I dont think the author is right to say it because of all the vibe coding that this is pointless.
I think it might be pointless because we are witnessing in essence the destruction of computing itself. And writing code with or without AI will eitehr not be possible (hardware unavailable) or become so unsavory and unenjoyable (jobs nobody wants) that computing for any reason but subsistence (or world domination) will die.
Its even conceivable that the platforms LLMs generate all this code for (the web, mobile, desktop) will die.
Comment by uejfiweun 3 days ago
Comment by mnd999 3 days ago
Comment by tecoholic 3 days ago
Comment by simianwords 3 days ago
Or is it just a collection of AGENTS.md docs?
Comment by devilsdata 3 days ago
Comment by mrandish 3 days ago
Instead, TFA begins addressing objections and potential misinterpretations before even making it's case.
Comment by raahelb 3 days ago
Reference: https://www.aicodingdictionary.com/?term=software-factory
Comment by xpct 3 days ago
Comment by simianwords 3 days ago
Comment by marcosdumay 3 days ago
Comment by win311fwg 3 days ago
Comment by jswelker 3 days ago
Comment by dbg31415 3 days ago
I’m really enjoying the software factories that I’ve built lately.
You can tell me they’re a waste of time, but man are they ever good at what I need them for.
And it’s keeping all my code standardized, and all my repositories running the same way… I’m really enjoying working with them.
Without them, AI just sort of solves the problem anyway it wants to in any given moment. Things get really chaotic.
I basically just use them to enforce standards and consistency between similar projects.
Comment by firemelt 2 days ago
Comment by thewileyone 2 days ago
Comment by Lerc 3 days ago
People always told them they were wasting their time, and they were probably right about that.
On the other hand every programming language that people rely upon today also had people telling them this when they started out.
It's ok to attempt something that probably won't work if all you need is for enough people to make enough attempts that one of them works.
Comment by saulpw 3 days ago
Comment by Lerc 3 days ago
Languages less than 10 years old are still in their infancy. It's fairly common for the first 10 years of a language to be quite niche.
The Languages bought by large corporations can avoid that 10 years by making it used by decree, that can make it more popular sooner, but it doesn't guarantee long term success,
There is probably a language that exists today that will be a top 50 language in a decade or two that neither of us knows about. Time is one of the best design resources.
Comment by saulpw 3 days ago
10 years is enough time. The industry was absolutely using Perl (1987) in 1997 and I was using Python (1991) professionally by 2003.
I mentioned Zig already; Julia also feels like it fizzled in a similar way, by getting attention without commensurate adoption.
But I will concede that you're right about Lean. It feels important that it's solving tomorrow's problem (i.e. today's) rather than yesterday's problem.
Comment by Lerc 3 days ago
Things do go a little slower these days however. It was 5 years and one month between the release of the Vic-20 and the Amiga. How different is your computer to the one you had 5 years ago?
Comment by hackingonempty 3 days ago
There is a lot of news right now about AI writing proofs in Lean (2013.) Lots of people rely on Elixir (2012) and Gleam (2016) is up and coming. I wouldn't give up on Scala (2004) just yet, it's really one of the best languages out there with some great libraries and runs on the JVM. You could argue that Reason (2016) and ReScript (2020) are just dialects of OCaml but they are industrial strength tools that people rely on in production.
...and don't even try to take Clojure (2007) away from any hands that are not truly cold and dead.
Comment by yareally 3 days ago
Comment by vivzkestrel 3 days ago
- your other blog post says https://www.peterp.me/articles/clustering-node-js/ you should clustering for max performance in nodejs
- are you using it in production or do you run multiple docker instances?
Comment by sroerick 3 days ago
I'm not sure that there is a "One Size Fits All" software factory out there. I think that they kind of have to grow with your organization.
However, I think being able to build a software factory is probably a very useful skill. And it feels pretty great to just send a list of bullet points over XMPP and know they'll get integrated overnight.
Comment by herunan 3 days ago
Comment by theturtletalks 3 days ago
You need to look at people making software factories that actually need them to get to their end goal.
My personal software factory has been building an open-source Shopify for every vertical and I think it’s immaculate…no bias.
Comment by abrookewood 2 days ago
Comment by VCFundedGenYer 3 days ago
Excuse you, I am not impressed by non devs vibeslopping things that barely function or are riddled with security vulnerabilities with unreadable code.
I guess we are not the same.
Comment by eluru 1 day ago
Comment by wseqyrku 2 days ago
Comment by Havoc 2 days ago
Having a streamlined process and good tooling with automation makes sense though.
Comment by yieldcrv 3 days ago
What this doesn’t solve is the money problem, which is the incentive to considering the software factory.
All of the examples in the article, like the fruit fly brain or a de-slopped android tv, also do not solve the money problem. they are examples of nontechnical people showing initiative, in the way that the technical person is not, but they are not examples of monetized things that demonstrate either party has solved that for themselves.
Just saying stop doing something while offering no alternative or addressing the reason why the pattern exists wont really provide any introspection
The software factory is still the way out for a software engineer or anybody inspired to produce software slop
Comment by sublinear 3 days ago
So, don't use agents. Use LLMs like a search engine?
Comment by whattheheckheck 3 days ago
Comment by smileduck 3 days ago
Comment by advael 3 days ago
To be clear, as someone who currently makes a living on making software, this is a major upheaval and sucks for me at least in the short term, because of the economic realities of the society in which we live. However, there are only two classes of alternatives. One is that the "AI can make all software" world fails to materialize. We're certainly not guaranteed this outcome, LLMs still generate sprawling and buggy code and we are in an era of unprecedented levels of tech rot. It's possible this is an unsolvable problem, and engineering, while probably assisted by LLMs, still requires people do a lot of manual work, or at least steering and guiding. The idea that we can already get reliable software out of claude go brr is uh... pretty misguided and silly, and at best the people who push that idea are, shall we say, optimistic. I think software engineering for a company continues to suck in this world, and I hope there's the opportunity for more people to go around being computer-touchers for non-computer-people in a more integrated context, rather than some massive "tech industry" increasingly insulating itself from society at large and building shit to try to ensnare and enthrall people, as it has been for the last few decades.
But I do think it's pretty plausible we get there, get to the computer that you just interact with by asking it for things - which it builds as software on the backend because software is a way more reliable and cheap way to repeatedly do the same task than throwing an LLM at the problem fresh each time you need something - but mostly people don't worry about that part. In that world, we either get to own computers or we don't, and if we don't, we are in an authoritarian dystopia the likes of which the world has never seen and may never escape. That's the second alternative. Governments outlaw computers or companies make it impossible for consumers to get their hands on them or some combination of these. This is the world that most large tech firms clearly want, and even as they praise open source software and rely on it as the backbone of most things they do, they seek to enclose the commons and use it as a means of societal control and get fat off of rent-seeking. A world in which the awesome power of the general purpose computer is a tool of control by an elite aristocracy is a world of either extermination or oppression of an unprecedented number of people, both in sheer numbers and percentage of the population. I think it behooves almost everyone to fight against this class of outcome tooth and nail, no matter what promises the present crop of aristocrats tries to entice you with
Personally I want the world where a computer is just a tool most people have, that does computation things a person or organization wants, and asking in a way that gets them what they want is a pretty normal skill to have. Star Trek really feels prescient as I watch "non-technical" people start to engage with solving their own problems with computers more. It feels very plausible that people find themselves asking for things we currently have to write programs for in plain natural language. I think we could get there on our current trajectory. But we could also get a world where governments and corporations conspire to hoard computation and lock the general public out of it.
I don't think "software factories" are useless in this moment any more than I think writing programming languages was useless ten years ago. I do agree that there's an infinitesimal likelihood of this making you money in the short term, though. You likely won't be able to sell them, make a business out of them competing with the big guys, or maybe even leverage them at your corporate job. For your own purposes, though? Why not? Not everyone cares about setting the terms by which we build things with computers, but some do, and more power to them. Letting this be monopolized is a part of how we get the bad outcomes. If operating systems had fully become a monopoly, we'd already be much further into the bad outcomes than we are
Comment by alchemist1e9 3 days ago
Comment by artempartos 2 days ago
Comment by piro0919 3 days ago
Comment by no_no_no_no 3 days ago
Comment by rspoerri 3 days ago
well, im gonna release it now and see if anybody else wants it.