mark242

Your compiler created the bytecode that the CPU runs. How can you take pride in writing your Rust code?

When I'm building, and get approached by large customers who have specific needs for them, those needs go at the end of our backlog. There's a hard and fast rule that unless it's an issue with authentication or accepting money, nobody gets to jump the line. We re-evaluate our backlogs periodically, and treat large-customer requests similarly to small-customer requests; who is this going to serve, what additional revenue could this generate, will this increase retention. If there are other projects that, combined, will move the needle more than doing one project for one enterprise client, guess what, that enterprise client doesn't get to jump the line.

Toothpaste making did not completely take over the world's supply of plastic for caps.

Where were the shoes that you are currently wearing manufactured?

"If a local district starts losing funding, then it would have to close / shrink schools, and people from outside the educational system would be allowed to establish independent (secular) charter schools within the district."

There is zero incentive for "people outside the educational system" to do this. Kids will absolutely suffer because of this plan.

The answer to this, like always, is that teachers need to be paid more.

npm install

If "we will opt everyone in because otherwise we won't get enough data because we know users won't opt in" is your business model, maybe it's time for a rethink.

Except you kind of do -- understanding data structures, understanding software engineering concepts, all of the things that you learn as a good engineer, those are ways that you help guide the LLM in its work.

Another way to look at this is that AI coding agents take the fun out of a software engineer's job.

Completely backwards - the fun in the job should be to solve problems and come up with solutions. The fun in the job is not knowing where to place a semicolon.

I love that "The Grandfathered In" section. Here's just one sample of a place that presumably this stupid website wants to keep up and running:

https://www.latimes.com/environment/story/2025-10-04/chevron...

The guy who made this site is selling a $7k stove? Good luck with that, my dude.

Title clickbait for sure, but the process has radically changed in the past 6 months due to this new generation of models.

"Perfect code from the agent everytime" isn't really what the expectation is. Bugs are always going to be shipped into production, no matter who or what is writing the code. Where SDLC is really getting compressed is in the iteration phase.

For example:

- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.

- Bugfixing is a matter now of an agent watching error logs, diagnosing traces, and immediately issuing PRs with suggested fixes, something that again would have taken hours at least and is now down to minutes (and can be a 24x7 operation, which for most businesses is a revelation).

- Engineers have the freedom to land enhancements that in the Before Times would have sat in the backlog for months and years on end because of the time commitment. That has knock-on effects of quality, features, and just overall improvements for users.

It is a very, very, very different world that we're operating in, and what used to be huge steps of the SDLC now take less time than checking your email in the mornings with your first cup of coffee.

I would argue that it's going to be the opposite. At re:Invent, one of the popular sessions was in creating a trio of SRE agents, one of which did nothing but read logs and report errors, one of which did analysis of the errors and triaged and proposed fixes, and one to do the work and submit PRs to your repo.

Then, as part of the session, you would artificially introduce a bug into the system, then run into the bug in your browser. You'd see the failure happen in browser, and looking at Cloudwatch logs you'd see the error get logged.

Two minutes later, the SRE agents had the bug fixed and ready to be merged.

"understand how these systems actually function" isn't incompatible with "I didn't write most of this code". Unless you are only ever a single engineer, your career is filled with "I need to debug code I didn't write". What we have seen over the past few months is a gigantic leap in output quality, such that re-prompting happens less and less. Additionally, "after you've written this, document the logic within this markdown file" is extremely useful for your own reference and for future LLM sessions.

AWS is making a huge, huge bet on this being the future of software engineering, and even though they have their weird AWS-ish lock-in for some of the LLM-adjacent practices, it is an extremely compelling vision, and as these nondeterministic tools get more deterministic supporting functions to help their work, the quality is going to approach and probably exceed human coding quality.

Many years ago, java compilers, though billed out as a multiple-platform write-once-run-anywhere solution, those compilers would output different bytecode that would behave in interesting and sometimes unpredictable fashion. You would be inside jdb, trying to debug why the compiler did what it did.

This is not exactly that, but it is one step up. Having agents output code that then gets compiled/interpreted/whatever, based upon contextual instruction, feels very, very familiar to engineers who have ever worked close to the metal.

"Old fashioned", in this aspect, would be putting guardrails in place so that you knew that what the agent/compiler was creating was what you wanted. Many years ago, that was binaries or bytecode packaged with lots of symbols for debugging. Today, that's more automated testing.

Someone who makes horseshoes then learns how to make carburetors, because the demand is 10x.

https://en.wikipedia.org/wiki/Jevons_paradox

"You have to assume that any work done outside classroom has used AI."

That is just such a wildly cynical point of view, and it is incredibly depressing. There is a whole huge cohort of kids out there who genuinely want to learn and want to do the work, and feel like using AI is cheating. These are the kids who, ironically, AI will help the most, because they're the ones who will understand the fundamentals being taught in K-12.

I would hope that any "solution" to the growing use of AI-as-a-crutch can take this cohort of kids into consideration, so their development isn't held back just to stop the less-ethical student from, well, being less ethical.

11% success rate for what is effectively a spear-phishing attempt isn't that terrible and tbh it'll be easier to train Claude not to get tricked than it is to train eg my parents.

Go get yourself some home insurance on a single-family house in Miami.

Roam has always felt like a bit of a chore -- while it's easy enough to set up backlinks, having to do that one step has always been like a waste of time to me. This is the kind of thing that imo an agentic workflow could do for you:

- Just start typing

- Let the LLM analyze what you're typing, given the RAG database of everything else you've added, and be able to make those kinds of correlations quickly.

- One-button approve the backlinks that it's suggesting (or even go Cursor-style yolo mode for your backlinks).

Then, have a periodic process do some kind of directed analysis; are you keeping a journal, and want to make sure that you're writing enough in your journal? Are you talking about the same subjects over and over again? Should you mix things up? Things like that would be perfect for an LLM to make suggestions about. I don't know if Roam is thinking of doing this or not.

And what happens to these datacenters when the underlying GPU tech becomes obsolete within 2-3 years?

Tesla is only in business today because it was able to sell carbon credits to other automakers. Take that government subsidy away and Tesla would have died in 2009.

The bespoke UK/EU models are not the priority, again because they aren't being made in the US, so yes the quality drops.

You cannot get, for example, a new Focus in the US market. When you could, they were much higher quality.

The only Chevrolet you can buy in the UK is the Corvette. Chevrolet makes nine SUVs, four trucks (with however many infinite variations), and exactly one shitbox non-Corvette car.

If US automakers started turning their eyes towards smaller more efficient cars, where hauling Brayden to and from their soccer games didn't require multiple tons of steel, then they could compete in the EU market.

The real problem is that American consumers are demanding these gigantic monstrosity SUVs and trucks which literally cannot fit on European streets. When Ford et al were making hot hatchbacks, they were incredibly popular overseas. The inefficiency is at the consumer level.

This is absolutely spot on.

What do you mean, I can't scale up because I've used my hardware capex budget for the year?

I'm curious about what "reasonable amount of hosting" means to you, because from my experience, as your internal network's complexity goes up, it's far better for your to move systems to a hyperscaler. The current estimate is >90% of Fortune 500 companies are cloud-based. What is it that you know that they don't?

The problem is not so much React as it is the JS ecosystem, but React is just very visible when you have these issues because there are so so so many packages being imported.

And the root of the problem is peer dependencies and the JS community's lack of backwards compatibility and maintenance.

Take any decently-sized JS application, whether React or whatever else. Put it in Github. Turn on dependabot. Watch your pull requests go up by 5-10 PRs per week, just to bump minor versions, and then watch how 1 of those PRs, every single time, fails because of a peer dependency on a lower version.

This has been a problem forever in the community, and there's no good solution. There's also just no feasible way to make a solution due to the nature of the language and the platform itself. You just have to absorb that problem when you decide to use eg Node for your backend code or React/etc for your frontend code.

There are entire categories of saas and enterprise vendors that are about to be completely blown away.

For example -- not long ago, when you wanted to do l10n/i18n for your business, you'd have to go through a pretty painful process of integrating with eg translations.com. If you're running an ecommerce site with a lot of new products (and product descriptions) coming online quickly, that whole process would be painful and expensive.

Fast forward to today -- a well-crafted prompt to Llama3.1 within a product pipeline makes that vendor completely obsolete. Now, you could argue that this kind of automation isn't new, you could have done it with an api call to Google translate or something similar, and sure, that's possible, but now you have one single interface into a very broad, capable brain to carry out any number of tasks.

If I was a vendor whose business was at all centered around language or data ETL or anything that involves taking text and doing something with it, I would be absolutely terrified at someone writing a 20-line python script with a good system prompt that would make my entire business's reason for being evaporate.

16 thousand Cybertrucks sold in Q3.

To compare, 3.9 million cars sold in Q3.

That is fundamentally wrong. Pushing content moderation onto every person who posts a message on social media is a chilling effect on people posting. Pushing content moderation onto every person who reads a message on social media is a chilling effect on people reading.

Because the alternative is pretty provably worse for you, and for them.

* You have to save your (hopefully unique!) email/password in a password manager which is effectively contradictory to your "I won't use a cloud service" argument.

* The company needs to build out a whole email/password authentication flow, including forgetting your password, resetting your password, hints, rate limiting, etc etc, all things that Google/Apple have entire dedicated engineering teams tackling; alternatively, there are solid drop-in OAuth libraries for every major language out there.

* Most people do not want to manage passwords and so take the absolute lazy route of reusing their passwords across all kinds of services. This winds up with breached accounts because Joe Smith decided to use his LinkedIn email/password on Midjourney.

* People have multiple email addresses and as a result wind up forgetting which email address/password they used for a given site.

Auth is the number one customer service problem on almost any service out there. When you look at the sheer number of tickets, auth failures and handholding always dominate time spent helping customers, and it isn't close. If Midjourney alienates 1 potential customer out of 100, but the other 99 have an easier sign-in experience and don't have to worry about any of the above, that is an absolute win.

Here's what I would like from a Kubernetes-like system.

I have a collection of machines.

I have a very simple file that defines A) what I want to run, B) how the pieces communicate to each other, and C) how I want it to scale.

Make that work without me having to think about any of the underlying infrastructure. (If this sounds suspiciously similar to Heroku, there you go)