Personal software factories are a waste of time | Hacker News Reader

Personal software factories are a waste of time

peterp.me

108 pointsthegreatpeter99 comments

In spite of this, I actually kind of did build a "software factory". The main reason why was because there is a number of things I build that really are just means to an end, tools where I could not give a shit less if the code sucks or anything as long as it does roughly what I want. This stuff will most likely never be posted anywhere, but that's not the point, because it still has quite a bit of utility. Having a "software factory" to build and maintain it seemed a lot less annoying than being a "meat proxy" all day just to maintain some tools that aren't very important.

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.

I don't necessarily disagree with this post but I really disagree with how it is written and with the contempt it expresses towards a fellow tech guy.

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

My only guess is a software factory is like a boilerplate starting point and I'm still not sure

what immediately came to mind for me is something like gastown. If that is the case I think I'd agree with the auther and a parallel from pre-AI would be "using kubernetes for personal projects is a waste of time" - so much time and resources spent on something that is way overkill and in many ways just would get in the way of just shipping something, anything and then going from there.

I don't think we should even be talking about the software factory anymore.

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.

>I don't necessarily disagree with this post but I really disagree with how it is written and with the contempt it expresses towards a fellow tech guy.

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.

I think he's right in that the software factory somewhat should emerge. You shouldn't start a project by saying "well, I first should build a software factory to make this faster". Start by building the thing by directing an agent. If you find yourself writing the same thing over and over put it into a skill which you should think of and treat as a macro. When you find yourself developing clear patterns what skill gets invoked when it might be time to start a software factory which in essence puts those decisions and relevant informations behind a pretty interface.

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.

I mean, my personal software factory was building one small project with an overtly enthusiastic and strict set of precommit checks that all must pass. Then starting every new project with "using the same precommit checks from project X"

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.

Same. I documented my patterns and conventions into a scaffold project +Claude docs and have been able to confidently vibe code my way to very reasonable projects. My stack is sveltekit+trpc

Doesn't this suit a prepush hook or CI job better?

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

I guess people have different working styles.

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.

There's a 2 part answer to this.

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.

Everything is being rethought right now. So many paradigms are broken. There wasn't ever a better time to build a software factory.

Any actual success stories?

You are assuming that a success story will be very visible. It may be, for very practical reasons, not be.

What do you mean? Someone in secret founding the key to unlimited productivity and using it to build a robot army for world dominance?

My interpretation is much less dramatic. If you find a way to make a dollar from 95 cents of tokens and scale it in any meaningful way, you would be foolish to tell hacker news about it.

Thank you for translating my hyperbole.

I'll be excited when someone vibe codes a solution to the asymmetry of how cheap it is to lazily demand receipts versus the time it takes to ideate, build (vibe or otherwise) and market a sufficiently credible "success story" for the skeptics.

A success story shouldn’t be completed on demand, though, it should be something that was already made and just pointed at. Where is the asymmetry there?

How about the assymetry to lazily assume successes without receipts?

doesn't have to be profound, just something that is verifiable and have it loop until some statement is true:

"pull out all hardcoded strings in web app into i18n files. do not stop until hard coded strings linter stops complaining"

"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"

I am successfully shipping code on side projects/business (real side business with real revenue) through my software factory all the way to production and shipping code all the way to PR within my day job. We aren’t ready to fully pull the trigger and go all-in, but my day job is mostly on the same page that this or something like it is the future.

I've given up on sharing anything I make. Distribution was already hard before LLMs, because the market was so saturated that you needed a big advertising budget or a good pre-existing channel to reach anyone. Now that making things isn't special, you don't even get the small boost of having made anything.

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.

I don't really understand what the post is about.

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.

The productivity gains of people using their own "custom" harnesses and agent tooling (e.g. letting agents talk to eachother over a messaging board) is questionable at best a waste of time at worst. No one I've talked to is actually applying the scientific method and measuring how long and how many tokens it costs to get a certain task done with just a plain chat input vs all this custom harness/tooling crap.

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.

Eh, managing multiple chat windows gets difficult. After a certain point, I have so many different threads going that a software factory is the only thing keeping things going.

Needs change when you go from 2 or three chat windows to 100.

Have you considered shipping instead of having 100 rambling chats? After a change is done you kill the chat.

What I'm getting from the contents of the blog post is that there's a constant fight the author has with their audience that I'm summarizing as "I think your endeavor is foolish and you shouldn't do it, but I'm not your boss so who cares, but it's a bad idea, but it could be useful, but you shouldn't do it".

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.

Exactly. As for the article itself, I would take with a grain of salt as the author's previous company built some sort of software factory. I think we can give them the benefit of the doubt and move on.

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.

People are building software factories? First I've heard of it. I just build software for my needs and call it a day.

If you don't have a factory, then what's the point.

> People are building software factories?

I'm sure that old Java EE programmers have their LLMs building software factory factories by now.

It was not immediately clear to me what the author meant by 'software factories'.

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.

The problem with a "software factory" as a dev is that it leads to infinite dev work. Build project A and struggle to get users, start project B.

The author is saying, build project A and stick with it. This isn't new to the "AI era" but it's more pertinent.

Thanks for clarifying. I can stand behind that, it’s a solid argument.

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!

Sounds to me like people understand different things under a software factory.

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.

I fully agree with the sentiment, but is it attacking a strawman or are people really building "software factories"? this is the first time I've even seen the term used in the context of LLMs. what would a software factory on top of an LLM even look like?

> "software factories"

framework

I have my own dark factory for a small company I work in several projects. The factory is: agent orchestration and swd. Basically I refine the work to do, create a bunch of tickets on day 1 and the factory deliver the work during the rest of the week.

An example https://www.youtube.com/watch?v=lx0Eaane4Ng

I am pretty happy with gas city: https://github.com/gastownhall/gascity

I'm not a software engineer and it's enabled me to build a startup with $4k mrr in the last few months solo.

what the fuck is this and why the fuck i need that

I know a few entrepreneurs and they all independently started building these kind of factories around the same time, so this is definitely not a straw-man.

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.

No the pitch is that you see your software development process itself as an automatable process.

>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.

I guess it depends on what people define it as. But I've seen many devs build custom harnesses of sorts, and spend lots of time on that to wire it all together, to then really not achieve much with them. Examples being tools or stuff that got superseded once mcps became a thing. Or spend hours making gigantic folder of skills that specified loads of stuff that the next generation model just could infer. Or build a gigantic parallel agent suite when the bottleneck wasn't the agents in the first place.

None of those things sound like anything I have in mind for a software factory. If anything they have the anti-factory ethos in mind.

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.

In my head it's a bit like people ending up making a game engine when they set out to make a game. It's funnier to spend time on the techy stuff than the other stuff. So in this sense, you spend time making lots of automations and build the factory, but very little time actually building the product.

So first off, talking about "LLMs" is kinda a yellow flag that you might be a bit behind the times, here: in ~April of this year[1], "agentic engineering" became truly tractable for serious work. We've all been playing with LLMs for coding and research since ~2023 of course, but they were mostly limited to the chatbot paradigm; even after years of Claude Code "harnesses", most engineers were still not trusting them to perform significant tasks on their own due to inevitable quality issues.

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...

so first off, i'm not an AI avoider - i use LLMs all day at work, and have several personal projects i'm likewise using claude for. but a single, interactive session produces code as fast as i can handle, if i want to keep a tight rein on the quality of the output - i often find myself having to look at the code generated from some intermediate stage and course-correct.

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).

> talking about "LLMs" is kinda a yellow flag that you might be a bit behind the times, here: in ~April of this year[1], "agentic engineering" became truly tractable for serious work

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.

Your entire post is a huge red flag that tells me you don't know anything you are talking about just based on the first paragraph.

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.

The author is wrong, and a software factory isn't a distraction.

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

That's just a non-sequitor though - "this isn't a distraction because I built a thing" isn't actually an argument from anything but personal satisfaction.

His argument is that you first need to know what you are building before you build the factory to build it.

If you know what you're building, the software factory is a foregone conclusion.

I think a 'software factory' is an attempt to align development with your own internal mental model. People have got a sniff of being able to have magic powers, where their thoughts can align 1:1 with some type of output.

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.

Well, I’m building one for work and for my side-business (both real companies, making real money, with established processes, albeit different magnitudes/scales) and I disagree with this.

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...

Depends. I say, let your needs drive your personal infrastructure. For example, I wanted to run Claude Code in YOLO mode 6 months ago, but I have lots of projects that I wanted to keep separate from one another (or at least be intentional about how they interact), and especially I wanted give some a set of permissions that they needed, but not this other set, and vice versa, and I could see them doing "grep -r" and "find $HOME" to just search over everything (with constant "I'm sorry, I exfiltrated these API tokens, so you need to rotate them"), so I built a little container setup to isolate them, and it's been working decently well for me and given me peace of mind when I let a project cook for a few hours.

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?

I think now it's the time to create personal software factories. And keep them personal. Nobody will be interested in your opinions and choices that eventually have to be made to build it. But we should still build them. The way to scale ai driven development is to increase your trust on the agents, and that's essentially building a personal software factory. We can share techniques, strategies, designs. Trying to make it too generic and share it outside of your use case is what's wasteful.

I do agree with the tendency of certain personality types to build factories, I've seen already way too many projects like that.

100% agree, that’s the premise of a post I wrote recently [0]. I think for the foreseeable future these factories will be incredibly custom to your company’s workflow and it will take a while for a “one size fits all” to emerge if it ever does. Does an “open core” end up “winning” that every company augments (at the code, not just config) level to suit their needs?

[0] https://joshstrange.com/2026/10/12/there-are-many-like-it-bu...

Its pretty easy to put together a microservice framework, along with some API spec driven tools to generate android and iOS clients then just work on UI.

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.

This article would work better if it first defined what exactly a software factory is.

AI wet dreams

What's a software factory? Honestly I have no idea. Is it something that takes in prompts and spits out a released software? That's already my Claude Cowork setup by default.

Or is it just a collection of AGENTS.md docs?

It's whatever shareholders want it to be.

I still have no idea what this post is about.

Agreed. I'm not someone who usually has trouble with comprehension, yet when I hit the paragraph which starts "I'm not saying...", I realized I still didn't know what TFA is saying. Based on the title, I expected it would lead with some clearly stated reasons why "Personal software factories are a waste of time" perhaps followed by examples and supporting facts.

Instead, TFA begins addressing objections and potential misinterpretations before even making it's case.

> A system of work where triggers, not humans, start agent sessions, so more work runs AFK and HITL time is saved for what needs it.

Reference: https://www.aicodingdictionary.com/?term=software-factory

Oh so this is what they refer to as loops

What a horrendous UI, with all the important content crammed on the right-bar, and the real, non-misleading content in a small font, after the bad summary.

Can this be at the top? I had no idea such a term existed. And I don't think it should, either.

A play on 'factory farm', where developers are kept in deplorable conditions to produce code as efficiently as possible.

Along this line of thought. I think the "internal tools" product category is dead. I remember trying to deploy one of these things - Tooljet, Retool.. I can't remember exactly, and thinking, maintaining the stack and the tools is not worth the effort. But then I didn't work in a big enterprise company. So maybe others had a reason or manpower to maintain them. Now I doubt anyone wants a programmable drag and drop form builder - aka no-code/low-code software factory.

I have seen this argument many times before over the years. Formerly it was applied to someone creating a new programming language.

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.

AFAICT there have only been two programming languages that people rely on today that were created after the year 2000: Go and Rust. Both were sponsored by large organizations which had clear goals that drove the design and development. All other modern languages are not going anywhere. The days of Python and Ruby and Perl and PHP being personal projects that people created, that grew into widespread languages that other people use seriously, are over. (Zig feels like it's a potential counterexample, but it's already been 10 years; for every other language mentioned above, after 10 years they were clearly well along their adoption curve.)

Typescript (2012), lean(2013), Julia(2012), zig(2016), swift(2014)

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.

Typescript was Microsoft and Swift was Apple, so those follow the same pattern of Go and Rust.

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.

Well there was perl 0 from I'm-not-sure-when before perl 1. Similarly Python started development in 1989. Mojo seems to be the most prominent of the new languages, but I suspect there are plenty of things out there waiting to catch on. I suspect there will be a generation of people who will have seen the advantages of Rust who will go on to attempt to write a language that keeps those advantages but doesn't invoke the trauma of Rust.

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?

Kotlin

Swift (2014) and Kotlin (2011) are huge because of iOS and Android, respectively. C# came out in July 2000, does that count? However there are post-2000 languages in real use that aren't developed or annointed by huge companies, some started as solo dev projects or academic projects.

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.

I don’t know…

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.

what is software factories bro?

He's probably right about this.

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.

I guess it depends how you look at it. I agree there's a lot of new products being built that will get zero maintenance. But also think there's some awesome stuff coming out that is changing the name of the game. And that's thanks to personal software factories. I think it's better to see it as a personal software lab rather than a factory.

- a bit unrelated but i had to ask

- 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?

I don't know about "factory" but I've built personal libraries, templates and methodology on how to solve problems or create stuff across different tech stacks. I don't think those were a waste of time then or now.

I agree, a lot of people are making software factories that don’t need them.

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.

> non-devs are applying AI in mind blowing ways and you still haven't built shit.

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.

"a software factory is just an extension of what you've always done: start projects, give up on them and go back to work on Monday" ... OUCH.

The phrase always seemed a bit silly to me.

Having a streamlined process and good tooling with automation makes sense though.

Wow, I didn't know you could be this much AI pilled. Really opened my eyes to the possibilities.

Thanks for writing that

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

"software factory" = agents and general vibecoding ?

So, don't use agents. Use LLMs like a search engine?

Is anything not a waste of time

made this for our auto framework and our speed multiplied. i dont think i would do this for a personal project, but for my company? well i like money

It's like playing video game.

If the predictions of the death of software engineering come to fruition, the only acceptable result of that is a world where "software" is a detail about how computers do things that some people can investigate for the sake of their curiosity, or because they are particularly meticulous about some detail. A world in which any software can be created by prompting eventually converges into a world where people solve their own problems with software, without thinking about the act of creating software. The idea of selling software in that world becomes ridiculous, and computers reach their potential as a tool normal people and businesses alike can use to solve problems.

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

Not very convincing

damn, i just did that for more then a year. all this wasted time, just before i wanted to release it. /s

well, im gonna release it now and see if anybody else wants it.

Reply on news.ycombinator.com