ClassAndBurn

Three issues, all compounding on each other, cause this. Poor foresight, overproduction, changes in youth drinking, and too much focus on small vintners.

There is a gut after production was ramped up during the COVID-19 pandemic. Everyone saw the trend line jump and assumed it wasn't a century-level event but a new trend that would last forever. Vines take a few years to start producing, if you swap or plant new acres you don't see the grapes for ~5 years. Which is now!

The US wine industry has tried for years to get younger drinkers. There is a strong relationship: the younger someone starts, the more time their palate has to develop, and the more likely they are to regularly buy more expensive wines.

The issue is they suck at it and regularly shoot themselves in the foot. I've seen party buses with kegs at tastings, which get people there but barely connect them to wine. Wineries are far, expensive (oh my god, tasting fees. They used to be excited you drove to them. They'd pour you anything. Now it's 2-3 bottles worth of $$ to walk in the door), and have special "rules" and social cues. The barrier to entry is high, and the old people who currently spend the money like it that way. So the audience is aging out.

There are 400-600 individual wineries in Sonoma and Napa. Each. Paso isn't far behind. It's just too many. How do you even choose the 2-6 you go to on a day trip to try them out? Let alone remember them in stores. There won't be consolidation like in other industries, because the brands of all the small fish are so diluted it's not worth acquiring.

There is a saying that "the best way to turn a large fortune into a small fortune is to buy a winery." And holy hell, did a ton of people do that. These small wineries don't make a profit, its a hobby for dozens to hundreds of people. They want the status, even if it costs them. So the market doesn't have clear signals for production and how to self-limit.

The fourth reason is that wineries don't grow grapes anymore. The industry is split into growers and vintners. Growers can take care of large agg with scale. Makers can choose à la carte what grapes they want that year. It's not a bad system and has enabled most of the smaller-scale wineries to launch without going totally bankrupt.

But now there are bag holders, and no one to buy their wares. If growers go out of business, there are no grapes to buy. Since Trump came in, they have already had issues getting labor. Costs have gone up, and no practical automation is available.

I believe there are separate issues with youth drinking, mostly around the risk involved in being inebriated and having a conversation or action come back to haunt you. Kids today live in a panopticon like my age never did. I can't say that I would be willing to open up the same way in today's environment.

What if agents had their version of PostSecret?

He will always be the Pirate in Muppet Treasure Island to me. Thanks for everything you gave the world

It's likely smart enough. It just needs to be told to do it and provided the ability to introspect it. How close could foundational models get to building this harness if explicitly prompted to?

We've only just started training models to use tools. Next, we'll train them to build them. Harness engineering is an ephemeral art.

Any custom harness for a problem shows that harness engineering is going away. Eventually models will introspect problems, then build custom harnesses tailored to that. Then use and modify the ephemeral harness as required.

Sol Ultra style is the path forward. The models are smart enough to self serve their tooling and processes. Given a problem they can figure it out and ask for directions when needed.

I finally built my side project and the government finally does something to make it pointless! Yay?

https://www.daylightsmearings.com/

Uncharted island found. Charted.

Any non-digital system you describe "as Code" is not a source of truth, but a Source of Hope. The code describes the intended state, something has to reconcile it with reality.

This is the same as having it in unstructured documents. Which means the auditing is still required funny enough.

So yes, this could be done. I'd love to see what run in the CI/CD for a change. When someone works on the wrong thing, or breaks compliance IRL, how do you backport it into this? "Alice is a software engineer, and created this SaaS account with her email when the company was founded. The admin email can not be changed and she has admin even though another role should control that"

They will have to update the openai. Com footer I guess

Latest Advancements

GPT-5

OpenAI o3

OpenAI o4-mini

GPT-4o

GPT-4o mini

Sora

> Deprecating install.md

> Last Friday we announced install.md and it didn't see much adoption.

With thrash like this why would anyone adopt this for something serious?

It's just an .md file, so the overhead is low. The lack on conviction in your design does not inspire confidence though.

Nvidia sees the forest of the trees. The consequences of the US government buying steaks and Intel are that there will be Federal requirements for us companies using Intel. This is entirely about the foundry business. Nvidia is at risk when 100% of the production of its intellectual property occurs in Taiwan. They're more interested than anyone else in diversifying their foundry solutions. Intel has just been a terrible partner and totally disregards its customers. It's only because of the new strategic need for the US to have a foundry business that the government is saving until. NVIDIA is understandably supportive of this.

Open models are going to win long-term. Anthropics' own research has to use OSS models [0]. China is demonstrating how quickly companies can iterate on open models, allowing smaller teams access and augmentation to the abilities of a model without paying the training cost.

My personal prediction is that the US foundational model makers will OSS something close to N-1 for the next 1-3 iterations. The CAPEX for the foundational model creation is too high to justify OSS for the current generation. Unless the US Gov steps up and starts subsidizing power, or Stargate does 10x what it is planned right now.

N-1 model value depreciates insanely fast. Making an OSS release of them and allowing specialized use cases and novel developments allows potential value to be captured and integrated into future model designs. It's medium risk, as you may lose market share. But also high potential value, as the shared discoveries could substantially increase the velocity of next-gen development.

There will be a plethora of small OSS models. Iteration on the OSS releases is going to be biased towards local development, creating more capable and specialized models that work on smaller and smaller devices. In an agentic future, every different agent in a domain may have its own model. Distilled and customized for its use case without significant cost.

Everyone is racing to AGI/SGI. The models along the way are to capture market share and use data for training and evaluations. Once someone hits AGI/SGI, the consumer market is nice to have, but the real value is in novel developments in science, engineering, and every other aspect of the world.

[0] https://www.anthropic.com/research/persona-vectors > We demonstrate these applications on two open-source models, Qwen 2.5-7B-Instruct and Llama-3.1-8B-Instruct.

This will not be true for future frameworks, though it is likely true for current ones.

Future frameworks will be designed for AI and enablement. There will be a reversal in convention-over-configuration. Explicit referencing and configuration allow models to make fewer assumptions with less training.

All current models are trained on good and bad examples of existing frameworks. This is why asking an LLM to “code like John Carmack” produces better code.. Future frameworks can quickly build out example documentation and provide it within the framework for AI tools to reference directly.

There's an awkward reckoning in open source software about inclusivity and protecting the long-term security of projects coming.

Authors from several countries were already suspicious, such as Iran. Anyone from Russia and China or unknown places are all potential risks now.

Combined with recent inclusive ideologies, it’s gonna cause hard conversations. There will be a furthering in segmenting the Internet. Why fight contributing to an open source project when you could fork it and contribute with your allies?

For true enemies, there’s no risk to licensing or copyright issues. You can merge changes from the original, no problem. China even falls into this as there’s a limited ability for US companies to litigate within the country.

People think the Network State is hot, but at the end of the day, the Internet still has borders.

Hashi never sold me on the integration of their products, which was my primary issue with not selecting them. Each is independently useful, and there is no nudge to combine them for a 1+1=3 feature set.

Kubernetes was the chasm. Owning the computing platform is the core of utilizing Vault and integrating it.

The primary issue was that there was never a "One Click" way to create an environment using Vagarent, Packer, Nomad, Vault, Waypoint, and Boundry for a local developer-to-prod setup. Because of this, everyone built bespoke, and each component was independently debated and selected. They could have standardized a pipeline and allowed new companies to get off the ground quickly. Existing companies could still pick and choose their pieces. On both, you sell support contracts.

I hope they do well at IBM. Their cloud services' strategy is creating a holistic platform. So, there is still a chance Hashi products will get the integration they deserve.

Others' concerns are valid; the separation of concerns makes infra changes safer and easier to understand. Infra-tooling is slow because of the inherent risk of managing stateful services.

Mixing the infra and application logic is the obvious path forward, though. Just as most applications don't need more than Rails and a single Postgres, most apps don't need customized infra. Simplifying the 80% unlocks cycles for more creative work. Suppose you are successful enough to have to define custom infra at some point. That's good for you. That's a great problem to have.

AI is going to standardize architectures going forward. Providing a simple set of tools in the same code as the logic makes the planner easier for Copilots and reduces the context windows. Terraform and application code have implicit dependencies. Colocating them lets you define explicit dependencies that are more understandable.

I agree here. Formal models have to become easier to create through.

Today's ecosystem requires advanced knowledge of system design and still coding abilities.

To democratize model generation we need a more iterative and understandable way of defining intented execution. The problem is this devolves into just coding the damn thing pretty quickly.

It learns the same way a human does by learning patterns. It is not illegal to comprehend how to accomplish tasks by reading other people's source code.

The arguments against my point always assume perfect memory of everything this model is consumed. This is the plagiarism position. In reality, some patterns are more common than others and generate a code that looks nearly identical. I can’t speak for the reasons for this, as I’m not familiar with all of the methods. However, I don’t assume that is the current working state or intent of Codex.

My view is the copilot is not stealing open source code. It is learning from it just as a human reader would. People's disguste is based on the assimilation of what they thought was a human trait being machine derived from their work.

The copilot service backed by an army of actual humans wouldn’t be a story at all. Nor would anyone be angry, if an individual offered coding skills as a service, and had gone through the exercise of learning great amount to open source software to do so.

No open source license was written with this in mind. Because previously learning was something only humans could do and no one had issue with sharing that knowledge. Until licenses take machine learning use into account I see no problems with Copilot.

Source cannot be open if you restrict any viewing of it.

This is like the first half of Flatland visualized[1]!

I always found imaginating Square's point of view a fun challenge. Seeing a world, I otherwise recognize the same way gives it a whole new dimension.

[1] https://en.wikipedia.org/wiki/Flatland

This is the only way to scale your impact as an IC.

The goal isn't to always have to do the repetitive reviews. It's to mentor people up so they do them for you eventually.

When you life those juniors up enough for them to mentor the next iteration you start the flywheel. You get to mentor and review people's work who do things at a higher level, and they get to learn to mentor juniors who were in their position. Everyone, even you, get to move up.

And suddenly the plot of one of the better Spiderman movies was happening in real life.

What were the limitations that required you to move all customers to a shared system at once?

Could you have selected some workspaces with lower traffic to migrate first? That would have decreased the load on the primary, potentially speeding up the replication, which is a flywheel to enable more customers to migrate to shards.

The past is judged by the values of the present.

Git is designed to require human oversight. This is usually a feature, but in recent years has become a bug with things like GitOps.

It's important to remember that Git is a terrible database because of its lack of semantic structure. All conflicts require a human who does have to context. This is why almost no one builds a system that uses Git as a two way interface. And when they do, its via Github Pull Requests (which go to humans) and not Git itself.

In all, this makes it a wonderful general purpose shared filesystem. And that's about it.

TL;DR only estimate the next milestone.

Estimates become less useful the further out they are. To get useful info about how long a project will take requires two large changes; careful definition of the problem and effective scoping of deliverables to validate your solution.

I push teams to understand the problem before attempting any implementations. Without this context people usually make something awesome that isn't useful. That's another thread on how.

The big hack is figuring out what can be delivered to test your assumption quickly. I shoot for about a month of work for this. Give or take.

Up front you get the team to agree, "this milestone should be easy to deliver, assuming we understand the problem and our assumptions are right". Then, if you miss that deliverable you stop work on the project and figure out why you were wrong.

This stop is meant to combat the Sunk Coat Fallacy. Then you can try a new approach, cancel the project, or keep going having only "wasted" a month. These are called Kill Metrics sometimes.

Long term estimates commonly fall to Sunk Cost issues in my experience. This is where a rush hits at the end and you get low quality product.

It takes a shift in how engineering communicates with other orgs to pull this off. You need to account for their needs in the milestones and keep them in the loop as a final delivery date comes into focus. It works to go from second half of the year -> Q4 -> Nov -> date. As long as you refine those with enough lead time.