I changed the way Antsand talks about itself. If you have followed the site for a while, you might look at the new homepage and ask: did we pivot into AI?

No. The message changed because it had fallen behind the work.

About fourteen years ago, I started building tools for things I needed myself: keeping notes, recording what I was doing, sharing it with people around me. That grew into a place to publish. Over time I needed forms, page layouts, styles, accounts and a way to run more than one website without rebuilding the same machinery every time. I did not sit down on day one and write “software factory” on a whiteboard. I kept solving the next problem, and the system grew into one.

For years our public writing mostly talked about the visible end of that work: websites, blogging, UI, SEO and how to get a page online. Those subjects still matter. But if I only show the finished page, you miss the part I have spent the most time building: the machinery that makes another page, another site and another change possible.

So what are we saying now?

Build software you can own. That is the line on the new homepage. For me it means the site should not be a mysterious one-off. I should be able to see where its content comes from, which parts are shared, where the data lives, who can change it and how I would recover if an update goes wrong.

Inside Antsand, an article starts as an authored note. A site definition chooses its pages, sections and routes. Shared PHP, templates, styles and JavaScript supply the working parts. The generated website gets its own runtime and, where needed, its own local member state. I call this a software factory because I can improve the common machinery and then use it to build different sites. I do not mean one prompt makes a finished company.

We have two concrete examples now. This Antsand blog is where I explain the product and engineering decisions. ShivasNotes is where I work through kernels, AI runtimes and longer technical writing. They share pieces of the factory; they should not share a reader's purchase, account or editorial identity by accident. I wrote a separate walkthrough of those two websites if you want to see the mechanics.

Where AI fits, and where it doesn't

Agents are now part of how I work. One can investigate a bug, another can prepare a change, and another can challenge the test evidence. That can move work forward quickly. It also creates new ways to fool yourself. An agent saying “fixed” is not the same as the generated site working. A test against source code is not a test of the page a reader receives. And a convincing summary is not permission to publish or deploy.

That is why I want Antsand to explain the whole path: the request, the patch, the checks, the generated result and the human decision to release it. Some changes need only a content sync. Others change authorization or payments and need a much stronger gate. If a check is skipped, the release record should say so. This is the agentic workflow I care about: not agents running wild, but agents doing useful, reviewable work inside a system whose boundaries we understand.

What is actually different?

The software has changed a lot. The message has changed more visibly. I am putting the factory, design system, operating discipline and agent workflow at the front instead of leaving them behind a list of website tips. Older articles will stay in the archive where they are useful. Some need a careful update, not a new slogan pasted over what I wrote at the time.

You can see that shift in the frontend. The homepage now starts with “Build software you can own” and points readers toward the architecture and field notes behind the sites, rather than asking them to infer the platform from a collection of older marketing articles. We are still tuning the navigation, the featured stories and the way those stories connect. A cleaner homepage does not magically harden a deployment; it gives us a more honest front door to the work.

We are also not claiming that Antsand is a fully autonomous factory or a mass-market SaaS product. There are hard edges we are still working through: safe regeneration when a site has real members, release evidence across source and generated code, and knowing when a local test is not a production guarantee. I would rather show those edges than sell you a diagram where every arrow is green.

What I want it to become

My first customer for this factory is still me. I want Antsand to be the place where I can manage the websites, content, members, forms, design changes and release decisions behind the projects I run. The more of that work I can do through one understandable system, the less I have to stitch together by memory when something changes on a Tuesday night.

That does not mean every project becomes the same website. It means I can carry forward the parts that should be shared, while keeping a site's audience, data and voice its own. Over time I want the same discipline to cover more internal workflows, including how agents propose changes and how I inspect the evidence before those changes reach people.

Could the right customer eventually use some of this machinery with us? Maybe. But I do not need to pretend this is a self-serve product today, or chase that story before the internal system is dependable. If a good fit appears, I would rather onboard them deliberately around a problem we can actually solve.

So yes, the new site looks and sounds different. But the direction is familiar to me. Notes became publishing. Publishing needed reusable parts. Reusable parts needed site boundaries. Multiple sites needed a factory. Agents make that factory more capable, and also make the checks and ownership more important.

I want this blog to follow that work as we do it. Expect practical stories: how a change moves through the factory, what broke during a sync, why a design component looks different on two sites, and where I still have to stop and make a decision myself. If you are building your own internal platform, I hope there will be something here you can take apart and use.