ebiester

Or, alternatively, they feel like they finally cracked the code and think they can do it better. That's when Apple finally enters a market.

Consider how much money they put in to building a car to cancel it when they decided they couldn't, in fact, do it better. I'm sure there are hundreds - maybe thousands - of failed prototypes along the way.

If it’s like other things, the auditors of Anthropic will have a contract with OpenAI and vice versa.

It's the concern for the community who pays in higher prices, and the employees in their job stability.

Has everyone forgotten the social contract? We do not exist as communities to make a small number of people richer. If the trade doesn't work for all involved, we change the rules.

One thing that this misses is that in many fields, career retirement chooses you before you choose it. This is often true in development as ageism catches up with you. At some point, you keep doing interviews and nobody says "yes."

Then, even though you have enough money for retirement (or even if you don't), you are answering these questions simultaneously with handling rejection.

I'm so glad YouTube and other podcast players have moved to support 3.0 speed. As I get comfortable with one, I move it up some. For things like sports and "did you know" content, I can go 2.5 if I'm not multitasking. For technical content, sometimes I'm stuck at 1.0.

Parmesan cheese is savory, not sweet.

For people who did not grow up with hershey's, the butyric acid is what makes it taste off.

This is not a question of safety - it is a question of results. They stayed with old technologies and have optimized for cost, not flavor. (And yes, that processing was necessary in the days before a reliable milk source.)

It depends if your goal is to sell the company or evade taxes, of course.

First, no matter what you do, if a human has write access to the production database, the database can be deleted.

Second, there is a legitimate reason to destroy a database in development and automation. The biggest problem I see is often treating your development data like pets not cattle. You absolutely need to have safeguards that this cannot be run in production, but if a human has access to the credentials to run in production, the agent has access.

So, then, what do we do? In a larger organization, we can depend on the dev/ops split to maintain this. For a solo developer, or a small team, it takes a lot more discipline. Even before AI, junior and even mid-level developers didn't have the knowledge to segment. And senior devs often got complacent because they thought they knew enough.

They likely need some combination of https://www.cloudbees.com/blog/separate-aws-production-and-d..., introduction to terraform, introduction to GitHub actions, and some sort of vm where production credentials live (and AI doesn't!)

But at that point you're past vibe coding. And from what I can tell, the successful vibe coders are quickly learning that they need to go past it pretty quickly with all these horror stories.

I have all the empathy for people in the world.

A corporation is not a person. If your organization cannot handle the load, then you need to adjust your practices. The organization needs to prioritize their paying users. The organization needs to shift people from new features to keeping the lights on. And maybe the organization needs to find another strategy to manage its azure transition.

I wrote about this - https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... - Royce was describing what he saw as an anti-pattern that it was risky and invited failure without iterations.

(and my link to the Royce paper isn't working anymore - I need to fix that!) - I am planning on a followup that takes the last 3 years of change in mind.

This is a particular artifact of the government system process. These are contracted pieces of work that Company A would deliver, Company B would administer, and Company C would be contracted out for additional work. Further, all specifications were created ahead of time because changes would cost extra. (Anyone who has done government contracting can talk to the shenanigans involved with it - I have not lived in this world for a long time.)

That said, we still do ad-hoc versions of many of these. For example, a system/segment specification today is an OpenAPI document between microservices. Most larger SaaS companies have the equivalent of a Software Configuration Management plan - Who can change terraform or a GHA, what are the standards that they conform to (linter, peer review standards).

Oh certainly - I'm conflating the adjective of agile with the manifesto of agile. I've been on projects with multi-hundred page design docs and multi-week UATs. And nobody wants to go back to prince2 for example.

The point I was trying to make is we should be diving back into the older methodologies and accumulated wisdom and re-evaluate some of the older dead ends with new context.

There is a lot of room to reevaluate the lessons of software development pre-web in the context of the current environment.

Like, if waterfall of a project can be done in 2 weeks, is it agile now?

Go look up "Tokenmaxxing."

Yes, it's as stupid as it sounds.

Missing here: some organizations were rewarding high token usage as productivity without critical evaluation. People were afraid to be in the bottom because outcomes weren't being measured.

It is a giant Goodhart's law lesson

Can I rephrase it slightly?

Humans have some repeatable bugs in our wetware, and it can be predictably exploited in a way that is hard to correct. It isn't "some people" - it's all of us, and the moment we think we're immune is the moment that we are most easily affected.

Yes, even the smartest of us are idiots in some very predictable ways.

Business/Enterprise accounts are billed at $20/seat + API prices, not subscription prices. You can give them a monthly dollar quota or let them go unlimited, but they're not being subsidized like in team. And team can't get a 20x plan from what I can tell.

First, the authors make very little money on most textbooks. You would be shocked. The money is staying with the book publishers.

Second, they've started publishing new editions so quickly with only the problem sets changed (in general) so that students can't use previous editions. If you're learning on your own, you can get some good deals on older editions for just that reason.

And on top of that, they maintain their own platforms so that even if you buy them used, you have to subscribe to a service to take the tests! All of this lines up to finding as many ways to extract money from students and at interest after it's all said and done.

Okay... you're an HTMX fellow. We live in the age of AI so if you're going to make an example, don't show us the trivial things we know HTMX can do.

You need to show a real application with pieces of the system that coordinate and complex interactions. Recreate Jira's backlog and sprint board that can have an arbitrary set of business logic for how a ticket moves through a workflow. Put it through its paces, don't give me a toy.

They explicitly said they were ceding the frontier model game to others, and that they were content saying a few months behind the state of the art. In the long run, this is an interesting freeloader play that a few people are making. https://www.cnbc.com/2025/04/04/microsoft-ai-chief-sees-bene...

So, it's just changing the problem up a level.

First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?

If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?

Do teams slow down in new features because the API must be the stress test of a public api?

I'm fine with unsupported frontends but an external API will be very difficult to keep static.

I think that's unfair - if HiFiMAN, Moondrop, or even KZ bought up the Sennheiser assets there would be very little difference. (HiFiMAN had QC concerns 7-8 years back but as far as I've heard they have been much better over the last 5 years.

That was a bad acquisition and their parent company is now in a bind, but I don't see a world where they can't sell it somewhere. Hopefully it doesn't end up in private equity hell because the 600/650 line is legendary and the HDB 630 is a true leap forward.

They were different people, but they were in the same group and knew exactly what it was being used for.

These are a group that used outside signal chats to discuss war plans. What odds do you have that he didn't use a personal email to avoid future accountability?

One of the products my employer builds is used twice a year. People pay tens of thousands of dollars for the privilege of using it twice a year. It's tremendously valuable to be used twice a year.

Value and use are not always synonymous.

I think the supply shocks is the part of the pro-natalist view that is hardest for me to accept.

My counter-argument: the full expression of human achievement is not genetic; it depends on the resources given to the human; If we accept that someone cannot reach their entire potential if living in poverty, and we accept that a lot of the advantages of rich children are due to the environment and opportunities that wealth provides, then it naturally concludes that we could get all of the advantages that pro-natalists look for by creating a higher standard living for all existing children.

Only when we can provide the sustainable resources for all people on the planet can we accept the idea that we have room for more.

It isn't as if the non-globalist affiliations are any less interested in this kind of control. This is frankly ad-hominem.

Because you see the IC side of the Atlassian toolkit. The management side is much more expansive and this starts mattering when you are coordinating larger projects.

That said, if you are a smaller company, you absolutely could kill Jira pretty quick.

The frustrating thing is I also thought about this as a natural conclusion - but as a natural workflow that corporations will do when they see AGPL dependencies they want to use. (I also think there's a world where we start tightening our software bill of materials anyway.)

I do not believe it will ever again make sense to build open source for business. the era of OSS as a business model will be very limited going forward. As sad and frustrating as it is, we did it to ourselves.