There has been a lot of talk on Twitter this past period about software factories, and why you should not review code or why you should review code, how SaaS is dying because they have no more value because the code has no more value, how the value comes from XYZ now.

The takes are all over the place, so here's, I guess, my take as well. I do want to preface this post with a beautiful John O'Nolan quote from 2017:

Truth is nobody knows fucking anything, so take it all with a grain of salt. Take what's useful, discard what is not, yada yada yada.

It is just a fancy name. It sounds more complex than it is. And I know because I'm contributing to, or forking to be more precise, Open Inspect.

It's basically a platform, if you will, where you create issues in your tracker (Linear, etc) and it drives the software development life cycle with various human-in-the-loop moments.

So you might create a Linear issue to explore or shape up some new feature or project idea. An automation picks it up, starts a planning session. You might review the plan, or even the agent might ask questions from you in a grilling fashion.

This may result in a number of implementation-ready issues, other automations pick those up and start LLM-powered agents to work on it. Eventually, PRs gets opened. Another agent takes those PRs and reviews them. An implementation agent addresses the review. You might also review after the automated review is addressed.

Maybe you also have a nightly automation to spawn an agent to look for recently introduced bugs, or to look at dependencies and security issues.

Or you could have an automation that, whenever a Sentry alert or user bug report comes in, it automatically diagnoses it, maybe even opens a PR to fix it.

All of this tends to happen in the cloud, not on your laptop, so you don't have to keep it open anymore. You can even interact with the factory from your phone, maybe from Slack.

There are many software factories out there, plenty of them are good and in fact the space is quite saturated. But I like the idea of it being open source and me being able to make changes to it hence Open Inspect is what I use.

I added white boarding to it, I fixed certain reliability issues & cost leaks. And I'm looking to add more new features to it to suit my specific needs and workflows.

Yes, I do, but not always. And not always to the same degree.

I think we're reaching a fork where some software can be built with minimal actual code review, but more so just leaning on architectural review and QA.

I’ve built this like that. You can point to any place on the map, in the whole world, and it will give you a walkability report that is actually much better than all of the pre-existent walkability scores on the market. I know because I dogfooded the shit out of it.

And I've been able to build this in weekends and evenings over the course of one or two months.

In my opinion, that is genuinely insane. It proved to me that if you still actually review code line by line, you are going to be a bottleneck, and you will lose out on a lot of the productivity gains that agents and software factories deliver.

That said this is not a commercially-ready project. This whole discussion of whether you should review code, how much of it, which of it, and how thoroughly you should review it is a question of trade-offs. It should be answered on a case-by-case basis.

For some software, it might be acceptable or even desired that you move slower, that you review things line by line to make sure it is as reliable & secure as can be, it is as maintainable and extensible as can be, and so on and so forth.

Part of your job as a software engineer now is becoming this act of being able to tell when and how much rigor you want to apply to the act of making software.

It's easy to look at these software factories and see that a lot of the job is being abstracted away from us. It's also very easy to become fearful of it all.

Short story: five years ago, I decided to stop calling myself a software developer or a web developer and start calling myself a software engineer. It sounded more important, more fancy, and better paid, to be honest.

As I advance through my career now, it increasingly feels like almost none of what we do is actual engineering. Maybe this is just me maturing, or maybe it's the changes that came with AI-assisted coding, or maybe both.

Even when it's not CRUD or basic work per se, I feel like it's really more about figuring out the right UX, the right product decisions, the business logic for it all, and figuring out the right architecture to deliver something reliable on time and within budget.

Like, we're not rebuilding Docker or Kafka or all of these amazing feats of engineering.

Sometimes you might have to deal with some eventual consistency issues or security considerations and you definitely might care about the long term maintainability and extensibility of the software you’re making. All of these are important things and they’re not easy to get right.

But we're mostly just putting tools and code together to move data from point A to point B so that some business outcome can be achieved.

Sometimes the outcome is a fund raise. Other times, it's more revenue or time saved doing some recurrent body of work. It can be a lot of things. The end game is, as this old but still very true article from 2011 from Patrick McKenzie says, money.

And this has been true for as long as software engineering has existed, but I feel like it's even more so in your face now with AI. Less and less people care about artisanal code in 2026. Hardware & existent tools/frameworks are more powerful than ever and you can scale pretty far with a simple architecture.

Which is why I'm kind of going back to the old name of software developer, because I feel more like a real estate developer now. I’m getting a budget or a deadline to achieve some goal. I get it done. The thing doesn't have to be perfect, but we certainly don't want it to fall on people’s heads.

Now I just sat down and explained to you how we are doing less engineering and more development, how whether we review code or not is more in question now and also how amazing these software factories are.

And I think we can agree that a lot of software in the world, especially in startups, services relatively small amounts of people and/or non-critical needs. For a lot of it you might be willing & able to lower your rigor and I think we’re seeing that trend.

Some call this enshittification, but if we are honest, some software really doesn't deserve as much rigor. It creates real value. It should exist, but good enough might still be good enough sometimes.

So then, with that trend and that frame of mind, you might say, "Well, shit, everybody's gonna have their own software factory and build their own things, and software engineers are fucked."

To that, I want to remind you of Jevons Paradox. Please Google it or have your favorite LLM explain it.

I want to remind you that not all software is non-critical or small scale.

I want to tell you that if this happens and people build their own small pieces of software, those may evolve into bigger-scale, higher-criticality software over time and an engineer would have to maintain and build upon them.

But I also want to give you a personal short story.

Every morning, I get up out of bed and I go for a walk with my wife and baby. On our walk, we hit this specialty coffee shop, and we spend somewhere along the lines of $7 every day there.

Obviously, we've gotten friendly with the owner. One time she's sat me down and did napkin math with me to explain how I'm spending ~$200/mo with her and I'd amortize my coffee machine in X time if I made my own coffee.

My reaction to her was "yes, I could do it cheaper if I did it myself but..." and there are many buts:

The whole experience is entirely different!

So guess what? I'm not making my fucking coffee! I'll keep going to her and spend the $200 a month.

And people are not gonna be making their fucking software, not the most of them at least.

Do you really think 40yo Suzy working accounting is gonna go and automate her job away when she's still using Microsoft Office from ten years ago?

Do you think the CEOs of all of these corporations are gonna go build their own software and remove all of the management structure they've created and is effectively ingrained?

Or maybe the startup founder who's busy talking to customers and VCs. Do you think he will have the time to fully build everything he wants to build all alone?

You are fine. If you adapt, if you play with this new technology, if you start to understand where rigor pays off and where it doesn't, you will still have a job. In fact, as explained by Jevon's paradox, the demand for software development might even grow.

P.S.: one more quick thought. A lot of you conflate rigor and good engineering or good code with the LLM coding things in your specific subjective style that you've grown to love over the years. I think that is something you will have to reconcile with yourself.