Harper talks a lot about using defensive coding (tests, linters, formal verification, etc) so that its not strictly required to craft and understand everything.
This article (and several that follow) explain his ideas better than this out of context quote.
The issue is that, (the way I see it happening more and more in the real world):
- tests are ran by machines
- linters are (being) replaced by machines/SaaS services (so.. machines)
- formal verification: yes - SHure, 5 people will review the thousands lines of code written every day, in a variety of languages/systems/stacks/scripts/RPAs/etc. or they will simply check that the machines return "green-a-OK" and ask the release team to push it to production.
The other thing that I have noticed, is that '(misplaced) trust erodes controls'. "hey the code hasn't broke for 6 months, so let's remove ABC and DEF controls", and then boom goes the app (because we used to test integration but 'come on - no need for that).
Now.. this is probably the paranoid (audit/sec) in me, but stuff happens, and history repeats itself.
Also.. Devs are cost center, not a profit center. They are "value enablers" not "value adders". Like everything and everyone else, if something can be replaced with something 'equally effective' and cheaper, it is simply a matter of time.
I feel that companies want to both run for this new gold-rush, while at the same time do it slowly and see if this monster bites (someone else first).
It’s pretty simple. Software quality isn’t on spreadsheet. The cost to build it is.
The value of the products coming from research and development are not on the spreadsheet everyone is looking at. The cost to develop them is.
If it’s not on the spreadsheet, it doesn’t exist to the people who make the decisions about money. They have orders to cut spending and that’s what they’ll do.
This may sound utterly insane, but business management is a degree and job. Knowledge about what you are managing is secondary to knowing how to manage.
That’s why there is an entire professional class of people who manage the details of a project. They also don’t need to know what they are getting details for. Their job is to make numbers for the managers.
At no point does anyone actually care what these numbers mean for the company as a whole. That’s for executives.
Many executives just look at spreadsheets to make decisions.
A business tends to break its components down into different units or departments, and then (from a financial perspective) largely boils down those units into "how much money do you spend" and "how much money did you bring in as income." Software being a cost center means that the expected income of the unit is $0, and thus it shouldn't be judged on its operating profit. It doesn't mean that software doesn't have value, that investment in software doesn't bring greater rewards.
But it does mean that the value that software brings isn't directly attributable to investment in software (as far as the business can see). And being more invisible means that it tends to get the shaft somewhat on the business side of things, because the costs are still fully visible.
Yes. You either MAKE money or SPEND money (sorry for the caps).
Audit, Security, IT (internal infra people), cleaning personnel, SPEND money.
Sales, Product Development, MAKE money.
Once the "developers" can charge per-hour to the clients, then we love them because they BRING money. But those 'losers' that slow down the 'sales of new features' with their 'stupid' checks and controls and code-security-this and xss-that, are slowing down the sales, so they SPEND money and slow down the MAKING of money.
Now, in our minds, it is clear that those 'losers' who do the code check 'stuff' are making sure that whoever buys today, will come and buy again tomorrow. But as it has been discussed here, the CEOs need to show results THIS quarter, so fire 20% of the security 'losers' to reduce HR costs, hire 5 prompt engineers to pump out new features, and pray to your favourite god that things don't go boom :)
Meanwhile most CEOs have a golder parachute, so it is definitely worth the risk!
This article (and several that follow) explain his ideas better than this out of context quote.
https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/