iggori

I recorded a real time, unedited 30 minute run of the AI workflow I use every day. It shows the architecture agent planning the change, the SWE agent doing small TDD cycles, the lead SWE agent running review gates, and how the loop deals with drift as it happens. This is the actual system I work with, and I hope seeing it in action gives you ideas for your own process.

I wrote this because it feels like we’ve built an economy where recurring obligations replaced ownership, and our kids are the first generation who won’t remember anything else. I’m trying to understand whether this is sustainable or if we’re normalizing something that breaks under its own weight.

LinkedIn recently moved job IDs out of readable DOM attributes into protobuf-encoded SDUI. Most people read this as a technical migration. It isn't. Talent Solutions generates over $7B of LinkedIn's $16B in annual revenue. The job ID was the last piece of metadata that let third parties reconstruct LinkedIn's job graph from the outside. SDUI removes it from the client permanently. This is the same move Facebook made with the feed, Instagram made with Bloks, and TikTok never needed to make because it never exposed structure in the first place. LinkedIn is the last major platform to seal its supply side. The DOM just became the wall.

The past is exactly the point. Most of these shifts repeat older economic transitions. When the cost of producing or distributing something collapses, the pricing model that depended on scarcity eventually breaks. AI is pushing software into that same pattern. The argument is that subscriptions survive only where the value is genuinely continuous or genuinely fresh, and everything else gets repriced the way previous cycles did.

This essay argues that most subscription models are starting to break for structural reasons, not because of "fatigue". Three forces are converging: income pressure, context exhaustion, and AI-driven repricing of entire software categories. Together they are pushing the subscription model back toward the few places where it actually fits the underlying economics.

The core claim is simple. Subscriptions only make sense in two cases. The first is when the product behaves like a utility, where value is continuous and tied to real consumption. The second is when the subscriber receives fresh context on an ongoing basis, where the value cannot be front-loaded or completed. Everything else is a static product wrapped in a recurring fee, and that category is being squeezed from both sides.

The essay looks at Adobe, Spotify, Netflix, BMW, and the broader SaaS market to show how the subscription model became the default, why it worked for a decade, and why the math is now reversing. AI is lowering the cost of building software to the point where small teams can replicate entire product surfaces for a fraction of the incumbent price. At the same time, consumers are discovering that many subscriptions deliver value that is finite, not continuous.

The argument is not that subscriptions disappear. It is that they stratify. The ones that survive are the ones that could not exist in any other form. The rest face a slow collapse as both consumers and builders shift to models that match the actual flow of value.

I wrote a piece about why so many AI agents drift, skip steps, or fall apart in production even when they look solid in demos. The argument isn’t about model quality. It’s about the abstraction layer we’re using.

LLMs don’t execute instructions. They predict tokens. A prompt full of rules isn’t a rulebook to the model; it’s a set of competing statistical pulls. When those pulls conflict, the model doesn’t resolve them by hierarchy. It averages them. That’s the root of drift.

The essay looks at a few examples: OpenAI moving away from instruction‑governed plugins toward structured actions, Devin’s long‑horizon failures that look like “bugs” but are really drift, and Sierra’s constraint‑based architecture that avoids this by making certain behaviors structurally impossible.

The core idea is that instructions compete, but constraints accumulate. If you treat an LLM like software, you get drift. If you treat it like a probability field, you design the boundary layer differently.

https://productics.substack.com/p/instructions-are-suggestio...

I wrote a short conceptual manifesto about physics. It does not replace any equations. It looks at the way we picture the universe and tries to offer a clearer and more unified way to think about it.

The idea is that every stable structure exists because an inward tendency and an outward tendency balance each other. We already see this pattern at every scale, but we usually treat each case as unrelated. Gravity here, radiation pressure there, quantum exclusion somewhere else, dark energy at the largest scales. The math works, but the intuitive picture ends up fragmented.

The piece suggests looking at gravity not as something mass exerts, but as the response of the surrounding spacetime configuration to the presence of mass. Mass creates an imbalance. The environment adjusts. What we call gravity is that adjustment. This is close to emergent gravity and entropic gravity, but expressed in plain language.

The outward tendency is not exotic. It is empty space itself. Low density regions behave in consistent ways across scales. A droplet holds its shape in a vacuum. A galaxy holds its structure because rotation and the surrounding void balance gravity. The universe expands because the low density side of the system behaves the way low density regions tend to behave.

The question is whether this balance pattern is a useful way to think about structure across scales. If it breaks, the reasons why will be interesting. If it holds, then some of the mysteries we treat as separate might be different views of the same underlying rule.

https://open.substack.com/pub/productics/p/the-picture-of-th...

AI can write code, but it cannot keep a real system coherent. It forgets decisions, breaks rules, and recreates logic that already exists. Bigger models and longer context windows do not fix this.

I saw this while orchestrating a 350k line production marketplace that my AI agents built end to end. They acted as the full development team inside a deterministic process I designed. I stayed on the problem and architecture side, they lived on the solution side. The system only held together because the structure around the models carried the memory they lacked.

This paper argues that we need an architectural memory layer. A persistent substrate that stores decisions, enforces invariants, and keeps the system stable across inference boundaries. The idea was battle tested by using AI agents to build the entire platform under real constraints.

I am now building the actual system that provides this layer. If you want to follow the work or join early tests, you can find updates on my Substack. The goal is to gather people around the idea, not to market anything.

Full paper is here.

Spent the last year building a full production system solo. Not a side project. Hundreds of thousands of lines, dozens of services, CI/CD, Terraform, multi-locale UI, thousands of tests. Real constraints, real consequences. At small scale the AI was genuinely useful. At medium scale it started making subtle mistakes. At large scale it behaved exactly as it was built: a next-token predictor with no memory of the system it was modifying. It fixed bugs while breaking invariants elsewhere. It refactored modules while forgetting why they existed. It regenerated logic that was already there. I had strict rules, enforced invariants, a TDD roadmap. Didn't matter. The substrate has no concept of continuity. This isn't a prompting problem. The architecture is missing a layer that every other platform had before it could scale. Operating systems have it. Compilers have it. Databases have it. AI tooling doesn't. Devin got 13.86% on SWE-bench. LangChain and AutoGPT collapsed under real workloads. Not because the models are bad. Because the substrate can't hold a system together. Wrote up what that missing layer is and why nobody has built it yet. If you build real systems with AI, curious whether this matches what you're seeing.

People keep treating OpenAI’s $100B raise as a company story. It is not. It only makes sense when you look at the whole stack.

Hyperscalers spent $251 billion on capex in 2024 and are projecting far more. Nvidia’s supply chain is booked 12 to 18 months out. OpenAI raised at a $157 billion valuation on roughly $3.7 billion in revenue, implying a 42x multiple and a roadmap that needs roughly 93 percent CAGR for five years to match that valuation. Those are not marketing numbers. They are structural constraints.

Put those facts together and you get a coordination trap. Hyperscalers must show forward demand to justify capex. Model companies must project revenue to justify valuation. Nvidia must keep a beat and raise cadence to keep its supply chain moving. None of these actors can slow down without losing allocations, market position, or investor credibility. The $100B raise is the cost of keeping that system intact for one more cycle. It is stabilization, not expansion.

If you want the full argument with the mechanisms, the math, and what this means for founders and engineers, read the essay here: https://productics.substack.com/p/openais-100b-raise-isnt-ab...

Thanks for reading it. The arcade metaphor is not about business models but about the pattern of optimizing for spectacle over durability. The point is that many AI products behave like arcade machines in the sense that they are impressive in isolation but collapse when they have to deal with state, dependencies, or long running tasks.

On the redundancy point, I appreciate the feedback. The piece is part of a larger series where I intentionally revisit the same idea from different angles to make the underlying pattern clear.

I have been noticing a pattern in a lot of AI products. The demos look great, but the moment you try to use them inside a real workflow they fall apart. It feels like we built an arcade of impressive tricks instead of tools that can survive real constraints. I wrote a longer piece about why this is happening and why so many AI products are stuck in demo mode. The short version is that we keep optimizing for the thing that looks good in isolation instead of the thing that works when it has to deal with state, dependencies, and long running tasks. If you build systems for a living, this will probably feel familiar.

That’s exactly the tension I’m pointing at. If Europe wants real tech independence, it needs to fix the internal incentive structures that make shipping slow and risky. Curious whether people see signs of that changing anywhere.

I get what you mean about long‑term ownership. My point in the article is a bit narrower. In many EU companies people don’t even get ownership inside the work itself. Decisions are spread so thin that nobody can push, take responsibility, or move anything forward.

I’m trying to understand whether this is a specifically European pattern or if US engineers run into the same thing.

Not trying to bash Europe. I’m trying to understand whether these incentive failures are universal or more common here. I’d love to hear from people who’ve worked on both sides.

I wrote this after years of working inside large European companies. What looks like an "innovation problem" is usually an incentive problem. People aren’t rewarded for taking risks, owning outcomes, or pushing things forward, so the system defaults to safety and process.

I’m curious how this compares to what engineers see in the US. Is it the same pattern or something different?

Style aside, the interesting bit for me was the claim that AI adoption is stuck because nobody has shipped the platform layer yet. Curious what others think about that part.

Read an interesting piece arguing that AI adoption isn’t slow because of the models, but because nobody has shipped the platform layer yet. No OAuth, no events, no sandbox, no real “App Store moment.” Feels like the pre‑platform era of mobile all over again.

I wrote a short piece about something I keep seeing in AI‑assisted engineering: we’re moving faster than ever, but a lot of that speed is built on foundations that quietly rot underneath us. The article isn’t anti‑AI — I use these tools every day — but it’s a look at the structural costs we tend to ignore until they blow up in our faces.

If you’ve been working with AI in real codebases (not demos), I’d be curious how this matches your experience.

I keep running into the same thing with AI tools: they’re powerful, but everything around them feels rationed. Token buckets, session limits, weird pricing. It’s like using a prepaid SIM card.

I dug into the economics behind it and ended up writing a long piece about the “scarcity trap” we’re in right now. The short version: the whole stack is upside‑down, and GPU scarcity leaks into every layer above it.

If anyone here has been building real systems with AI, I’d be interested in your take. Tnx

I’m not trying to present myself as a guru or a celebrity engineer. My background is in product and technical leadership, not in being the “hero coder.” I didn’t build an AI system — I built a real production platform where AI was one of the tools in the workflow.

The article isn’t meant to be profound. It’s just a practical report from someone who pushed AI‑assisted development into a full product environment and saw where it helped and where it broke. I shared it because some of these patterns might be useful to others, and because I’m also interested in learning from people who’ve taken different approaches.

If your experience is different, I’d genuinely like to compare notes — that’s the whole point of posting it here.

I’m not offended — just to clarify the context. I’m not a native English speaker, so I sometimes use AI to help with phrasing or structure. The ideas, experience, and arguments are mine; AI just helps me express them more clearly for an English‑speaking audience.

I don’t see anything wrong with that. For many non‑native speakers it’s simply a tool that removes friction and lets us focus on the actual content instead of grammar. The engineering work and the analysis in the article are based on real experience, not generated text.

If you disagree with the conclusions, I’m happy to discuss them — that’s why I posted it.

I spent a year building a 300k‑line production platform alone using AI‑assisted engineering. It worked — but only when AI was cheap and predictable. As model behavior shifted and costs rose, the entire system began to break in ways most teams haven’t experienced yet.

This essay is a field report from operating at the edge: • how deterministic workflows collapse under model churn • why reasoning‑first models break text‑pattern assumptions • why AI engineering economics now resemble aviation, not cloud • what architecture survives when the foundation keeps moving

If you’re building AI‑native systems, this is a look at the failure modes that are coming for everyone.