skydhash
What Anthropic wants and what happens in reality are two different things. But with code I write, I do control the process.
> Eh no. You need to know about only a compressed part of it, not 100%. Do you really claim that you need to know 100% of the code?
I know the code I write, and I know how it interfaces with external modules. When those interfaces don’t function as described, I look at the code if I have access to it. When I don’t, the party in control has always good incentives to produce good documentation. That knowledge is usually good for some time (years even)
> my manager doesn't look at my code
Because that’s not his responsibility, just like he’s not responsible for bugs and crashes. He’s responsible for the project and the team and you can be pretty sure that he’s looking at all at the information about those. Imagine if his own manager ask him about some details and he answers: “I don’t know, Claude is doing it”.
The manager always has a very good stick: “Do a good job or you will be fired”. And me wanting food is well aligned to not produce buggy code. Or make my job harder in the future by writing unmaintainable code.
> Frankly, these discussions are tiring because there's a false notion that humans have to be in the loop 100% of the time
The code is written to process data. Someone needs to be aware of how it’s processed, so that when malformed data appears, we can collectively find where it happens. You can always play around with your own data (if regulation allows) but you need to respect your customers’ data. Not looking at the code jis just negligence.
And git is enough to version control some of the most complex software like the Linux Kernel, the FreeBSD operating system, QEMU, browsers like Firefox,... Git was insufficient for Facebook and Google because they wanted to put the whole org inside a single repo, which broke the assumption where decentralization in git would happen (repo level, not subtree level). Now it seems that another assumption is broken, that you wanted a version control system, not a snapshot or a rolling log.
[0] https://martinfowler.com/bliki/ArchitectureDecisionRecord.ht...
So you can get AI to produce code, but you should refine your mental model alongside it and not try to build a scaffold as that would always be too generic and wrong. As a scaffold good enough is already code. So exoskeletons mindset, more than hive mindset.
In most SPA, state is distributed with two copies floating around. Even if you do restrict the update flow, it’s still a lot of works to keep it consistent. That’s good enough when it’s partitioned and each side take care of its own state, but in most cases, the intersection is very large.
With SSR, the “page” is a dead copy. The only source of truth is the backend.
This labour was not the main bottleneck. I’m ready to bet that coding is a small part of the daily activities of a dev.
> Later when requirements change you reiterate and regenerate your prototype and continue.
That is incredibly wasteful. Requirements are set agains a world model that always evolves against its own set of constraints. Which does ties into the flexibility argument. No need to reinvent the wheel, when only a few things varies and some just stay true for years and decades..
>> The assembly itself is a matter of data and process. How each module is initialized, its lifecycle, which data it consumes, which data it produces
> This is taken care of by having modules follow the LKM model with ioctl interface as explained above.
Nope, it’s not. This is related to having a good mental model of how your software process data, not related to how you design your interface.
—-
As I said, your comments put “code” as a first place citizen, which no experience dev does. What I argue about is that it’s always about data, the rules that it follow, which will then be realized by code.
> DbC methodology is the quintessential "data-driven" programming since the pre/post/inv are predicates to establish sets of data values on which the subsequent code can operate safely
Like the one above. You don’t write code and assert which type of data that it can handle. That’s a fool errand as the outside world is naturally messy. You define the data first, and then write the code. Meaning when the data changes, the code needs to evolve. You need to have a very good mental how that changes propagate, which you won’t have of you just regenerating code.
That’s why no one builds a factory to produce factories. Although there are common elements, a factory is designed for the product it will create. So you start from the product, you don’t start from the factory. Your methodology is a framework for building factories, but with no mention of any product.
But in most web apps, interactive widgets are just little islands in the page. The higher concerns are routing, authorization,… which are already handled by the browser/server interaction.
If you take a look at "real" code out there and it's evolution, you'll find that the main thing that drives it is the set of requirements. On the other side you have the platform (standard and 3rd party libraries as well as frameworks). Add to that is the set of algorithmic techniques (including design patterns).
By analyzing the requirements, you will discern that often they're composed of sub-problems that are generic (which is where you algorithms techniques comes in). And some are already solved (libraries). Often there's a common shape to the requirements (or some of them) that can be extracted into "frameworks".
So what's left then is the assembly. But often requirements are evolving concepts. So you don't want your structure (architecture) to be that rigid. You can't really know the direction of evolution, so you try to predict it in some way and add flexibility in a few places. This is more an art, but there are general techniques that works well enough.
The assembly itself is a matter of data and process. How each module is initialized, its lifecycle, which data it consumes, which data it produces. A program is always part of an information system. Means data come in, got processed, and go out. And here is the majority of development type is consumed, ensuring that the data is correctly processed.
Programming concepts like type checking, memory safety, paradigms (oop, functional, relational,...), formal verification,... are all about data. Code always come in second place. So think hard about your data and its transformation.
That’s what I thought the article would talk about. If it were social media, I’d rather buy a cheap used phone, put the app on it, and turn it on only when I want to check something. Then it’s off. But I deleted/haven’t logged into my accounts for years now.
As for as minimal compute goes. my daily driver is an old laptop I put OpenBSD on. I also have an m1 air that I mostly use for shopping and meeting. Then an iPad for reading. But the key thing is that app and software are tools. It’s either tied to an activity (even relaxing ones) or it’s not used. No ricing or theming, just basic configuration to get the job done.
They don’t do organization verification, but they do verify where code comes from. You may be sure that packages are built by alpine, which made sure that the dist files comes from the sources that the maintainers added, and the latter ensure that the sources are correct. In truth, it’s a very small circle of trust.
No, he wants a project where AI is used as a major help, but the result tend towards good code, i.e readable and well abstracted. Even if the cost is high, just an example where you can extract the best practices of using AI coding.
There’s a lot of good tools out there that are not used, either because of ignorance of their existence or lack of expertise. An hour of config can pay real dividend later.
And sometimes you just use some unix utilities and hack a bash script while testing things out.
Let’s say you have an incident, and you need a resolution. Do you spend 5 minutes tinking, then solving the problem or send out the AI for the hunt and spend 30 minutes grappling with hallucinations and non-sensical output?
The 5 minutes I’ve seen is usually by someone that will send the complete output to someone else to decipher, while saying they have figured it out. Then they’ll turn into a meat proxy between the team and the agent.
In real life, for systems where incidents that require such rapid responses, you usually have fail-safes an killswitches. When you were designing your system, did you put in place alerts and monitoring to mitigate risks?
Did I imply that? Creating a bank account in my country is an adventure on its own. If I got 50 USD in my wallet, I can exchange it somewhere and pay for food and whatever. My crypto account requires a computer, an internet connection, and someone willing to take it (no one around here).
If they come to me with a cartoon-like contraception that comes straight from Acme, you can understand how reluctant I am to not be blown up like Coyote.
I think they do become more valuable. Who said something and who believe it is equally as important as what was said.
So AI being a source of truth and information is not a something that important. It's a generator and we should use it as such, getting it to map domains and repeating patterns. It should not be used as an encyclopedia or oracle.