sunir

You have to include the carrying cost per customer as well which is mostly labour. Most of SaaS undercounts the payroll attached to a subscription which is why it is so hard to get to positive net margins and maintain lifetime value.

I am sceptical an LLM foundation model company can get away with low human services either directly on its own payroll or by giving up margin to a channel of implementation partners. Thats because the go to market requires organizational change on the customer sites. That is a lot of human surface area.

Growth curves mean nothing if you're selling $0.90 dollars. You have to show a growth curve when price > cost. It's not even clear that value > cost.

I absolutely love Anthropic; but I am worried about the fiscal wall they will hit that will ratchet up my opex as they will need to steeply raise prices.

Sure I agree what I am talking about is different in some important ways; I am “yes and”ing here. It’s an interesting space for sure.

Internal vs external in this case is a subjective decision. Where there is a boundary, within it is the model. If you draw the boundary outside the texts then the complete system of model, inference, text documents form the agent.

I liken this to a “text wave” by metaphor. If you keep feeding in the same text into the model and have the model emit updates to the same text, then there is continuity. The text wave propagates forward and can react and learn and adapt.

The introspection within the neural net is similar except over an internal representation. Our human system is similar I believe as a layer observing another layer.

I think that is really interesting as well.

The “yes and” part is you can have more fun playing with the models ability to analyze their own thinking by using the “text wave” idea.

Even if their introspection within the inference step is limited, by looping over a core set of documents that the agent considers itself, it can observe changes in the output and analyze those changes to deduce facts about its internal state.

You may have experienced this when the llms get hopelessly confused and then you ask it what happened. The llm reads the chat transcript and gives an answer as consistent with the text as it can.

The model isn’t the active part of the mind. The artifacts are.

This is the same as Searles Chinese room. The intelligence isn’t in the clerk but the book. However the thinking is in the paper.

The Turing machine equivalent is the state table (book, model), the read/write/move head (clerk, inference) and the tape (paper, artifact).

Thus it isn’t mystical that the AIs can introspect. It’s routine and frequently observed in my estimation.

The word decimate is sitting right there.

If the plan is too big to fit into context or requires too much attention it overwhelms the llm. You need to decompose into tasks and todos aggressively.

Quality Spock pun.

Maybe. I use QWAN frequently when working with the coding agents. That requires an llm equivalent of interoception to recognize when the model understanding is scrambled or “aligned with itself” which is what qwan is.

We certainly will; they can’t replace humans in most language tasks without having a human like emotional model. I have a whole therapy set of agents to debug neurotic long lived agents with memory.

I long ago accepted a career in B2B software meant my job was to put people out of work. And as it turns out, programmers always start by putting other programmers out of work.

Programmers and Managers by Kraft (1977) is my favourite book on the subject. It's unabashedly Marxist and from the very early days of the industry, which tickles me, since that is a different way of thinking than I usually do.

https://www.amazon.com/Programmers-Managers-Routinization-Pr...

They all thought it would be advertising or ecommerce. Subscriptions weren't a cultural phenomenon yet. That was a decade later.

The dot.com had no idea. They talked about eyeballs.

You can’t buy stock in AI. You can buy stocks in companies.

The internet was destined to be big sure during the dot.com but most companies crashed.

The bubble popping issue would be that there isn’t a good way to recover the capital used to build the AI models.

Code has a lot of bits of information the compiler users to construct the program. But not all because software needs iteration to get right both in bugs and in solving the intended problem.

The llm prompt has even fewer bits of information specifying the system than code. The model has a lot more bits but still finite. A perfect llm cannot build a perfect app in one shot.

However AIs can research, inquire, and iterate to gain more bits than when you started.

So the comparison to a compiler is not apt because the compiler can’t fix bugs or ask the user for more information about what the program should be.

Most devs are using ai at the autocomplete level which is like this compiler analogy which makes sense in 2025 but that isn’t where we will be in 2030.

What we don’t know is how good the technology will be in the future and how cheap and how fast. But it’s already very different than a compiler.

Buy the application layer near winners. When computing costs shrink, usage expands.

lol, contradictions about MVC are par for the course. It's not personal. It's just confusing. Talking about the concepts isn't the same as talking about each other as professionals. Some of the articles you linked to express this tumult over decades.

Looking at 1979, when I read this.

> A controller is the link between a user and the system.

I think of it as the boundary

> It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen.

It's the router, or view loader.

> It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views.

The controller receives user input, translates it, and dispatches the input to the views. I think this has changed in the modern era.

> A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them.

I don't really understand this exactly, but I think it means views compose themselves.

> Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.

The controller handles the raw input and translates it into actions/commands meaningful to the system.

>> How does the model handle authentication without having to become aware of boundary protocols? > It gets passed required information. Just like it gets passed other information.

Is what you consider the model all logic in the system? I would not. I would consider the model to be the data in the system world, using terms in systemese. It shouldn't know or care about OAuth or SAML or HTTP Authorization or whatever. It would care about Users and Sessions.

However, is this semantics? The use case and work flow approach is just a layer on top of the data model. The auth is another layer.

Why it matters to me is I prefer to think of systems as data flows, and the code follows the data flow. Control layers are different than the actual data.

The controller is meant to be handling things like keyboard events or http events. That’s the boundary to the user. The thinner the better.

I don’t know why you think this is a combative conversation where I need will to accept or reject anything. I lack understanding of how you would solve the same problem. Throwing chaffe is not communication. It creates a second problem beyond the one we are discussing.

How does the model handle authentication without having to become aware of boundary protocols? How the user authenticates is part of the input to the system. Eg http basic or oauth

I don’t know how you handle routing. Do you put that in the model as well?

That’s a fair critique. Though the snark was unnecessary.

I took the time to reread the literature and review my actual code. My updated understanding.

Model controls and holds the state of the system. It ensures the data is always valid.

Controller controls the boundary between the system and the user.

View represent the model and capture user intent to change the model. They ask the model for data they need; however I disagree with the practice that views change data directly but instead prefer they send an intention to change to the app which does the work.

Auth was not considered in 1979 as far as I can tell. Authentication is part of the “controller” but in middleware usually because it’s part of the user input boundary, and generally better if done in one place early in the event lifecycle. Authorization is part of the model.

App logic is decomposed into workflows or use cases in the app layer. Events coming in through the controller are translated into what the system understands and then passes it onto the workflow to execute.

Thus these should take change intent from the view and then actually tell/ask the model what needs to change. This allows the app to catch errors from the model, recover if they can, or handle multi step flows. Results and errors are then sent back to the view (eg GUI dialog) or controller (eg api call) that initiated the workflow.

This makes it easier to put different views over the same app logic (mobile, web, api, agent) and also test workflows in isolation.

Modern views have their own controllers for mouse and keyboard. That’s fine. Don’t care. That’s effectively outside the system in the client experience (eg browser) anyway.

Where I have trouble is when I

- put a ton of app logic in the controller

- put a ton of model updates in the view

- have a single controller for the entire system instead of one per system boundary/interface of user events.

The (DDD?) style of app logic being encapsulated outside of the controller makes a lot more sense to me now that I see it.

The model is the source of truth. For almost all apps, it should always be valid. (For those apps that isn’t true such as massively distributed systems, it should present a projection of what can be considered valid to your locality and handle delta internally.)

There has to be a boundary that controls changes to the model. The confusion with MVC is where is the best place for this boundary. Well more than one place as it turns out because there are at least two models of reality trying to converge. The model itself and the view of the model (and the user’s mind).

The view’s job is to present a projection of the model and then collect change events to the model. Thus could be a UX or an API. Other events can also change the model like say sensor data.

The controller decides what view to show and retrieves model data to project and translates change events coming from the external world (views or events) into changes the model should interpret. This includes gatekeeping such as auth, and error handling.

That’s a lot for one class so it can get confusing very quickly. Why localize it in one place?

So viewtrollers come around where the controller is in the view class but in the onhandle methods. This also makes sense since each view has a mini controller to handle all the jiggling bits.

This works well when there are no orthogonal injections like auth or eventing. When those are added it makes sense ins viewtroller to extend the model with controller functionality to for eg control authorization or have a thin event receiver to fsm in the model.

This all works but three years later it’s hard to figure out when I read the code again. So I have learnt to treat the model as pure data as much as possible and the view as much about rendering as possible. Views can have little controllers for handling the jiggling. What the controller cares about is when a change to the system needs to happen.

Then I can put the system control fsm in one place. I can put all event handling in the same fsm to avoid race conditions.

The goal is to make it easier to reason about.

What I don’t want are multiple threads of fsms in conflict with each other.

Not exactly. Those models are based on intermittent usage. If you're using an AI engineer using a sophisticated agent flow, the usage is constant and continuous. That can price to an equivalent of a dedicated cube at home over 2 years.

I had 3 projects running today. I hit my Claude Max Pro session limits twice today in about 90 minutes. I'm now keeping it down to 1 project, and I may interrupt it until the evening when I don't need Claude Web. If I could run it passively on my laptop, I would.

I’ve built an agent system to quality control the output following my engineering know how.

The quality is much better but it is much slower than a human engineer. However that’s irrelevant to me. If I can build two projects a day I am more productive than if I can build one. And more importantly I can build projects that increase my velocity and capability.

The difference is I run my own business so that matters to me more than my value or aptitude as an engineer.

All true if you one shot the code.

If you have a sophisticated agent system that uses multiple forward and backward passes, the quality improves tremendously.

Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well.

The net is that unsupervised AI engineering isn’t really cheaper better or faster than human engineering right now. Does that mean in two years it will be? Possibly.

There will be a lot of optimizations in the message traffic, token uses, foundational models, and also just the Moore’s law of the hardware and energy costs.

But really it’s the sophistication of the agent systems that control quality more than anything. Simply following waterfall (I know, right? Yuck… but it worked) increased code quality tremoundously.

I also gave it the SelfDocumentingCode pattern language that I wrote (on WikiWikiWeb) as a code review agent and quality improved tremendously again.

I have been developing long lived self-directing agent loops. Longest with problem solving has been about 4 hours. Longest without problem solving has been nearer 8 hours until it was done.

The biggest problem is simply what we think is clear is confusing to the AIs. They seem like they speak English fluently but they are aliens. You need to force them to active listen first and write out what they understand then reload them with a clean context with the written understanding and confirm.

Ideation is also mostly limited to synthesis. So it’s better to work on problems that get progressively more complete towards a known objective rather than problems that require exploration.

A lot of clerical work was managed by SaaS which managed clerical workers. As AIs can do these internal jobs you don’t need the software seat licenses any more.

Word processors and Spreadsheets did the same thing and remain powerful today.

I don’t see the world lacking in software or bureaucracy.

The Tower of Babel is the reason. Idle humans diverge develop and complicate every domain in order to compete with each other. Nothing truly ever gets simpler until there is a replatforming; and then things get complicated again. There are more and deeper rabbit holes every day.

Many old SaaS products from the last cycle are shrinking. However whatever. Keep going. Still more work to do until the world is perfect.

I chose sepuku.

You’re reading it correctly. I read it again after your comment and I realized I too pattern matched to the typical logic puzzle before reading it carefully and exactly. I imagine the test here is designed for this very purpose to see if the model is pattern matching or reasoning.

Guard conditions, assertions, constraints and tests are dynamic limits on code and are critical to maintain quality despite code rot and drift from changes.

Static constraints like types can also be also good, where types are good.

I applaud anyone who advocates to focus on the unhappy path over the happy path.

On a side note 25 years ago was the end of the dot.com and the height of the y2k scam and I have never seen developers more burnt out than then; but that’s because I was just starting my career then. I don’t know about previous eras like the 89 crash and recession.

I am not sure why the OP has rose coloured glasses of the past. But it’s always good to treat history with a little more interest.

That didn’t work on my iPhone.

Obviously the AI that wrote the ad code has become sentient and it is trying to break free.

I dig this. This is what I am thinking.

Much easier to click than dial.

Social cost of a web link versus a phone number may be lower as well (that may be cultural but it may be true)

Adds other modes like calendar or chat or AI directly in flow.

No need to reveal a phone number.

Video

Internationally accessible (no long distance)

And for HN tradition’s sake for these types of comments, no one likes rsync.

Yes. The app costs. The insurance costs. The franchise tax costs. The accounting costs. The legal costs.