| ▲ | kburman 3 hours ago | ||||||||||||||||||||||
Not to downplay Anthropic's engineering work here, but I suspect we'll see a lot more reinvention of the wheel, even at smaller startups, as AI makes writing code significantly cheaper. The tradeoff between building something custom and adapting an existing solution is changing. Whether maintaining all that custom software turns out to be equally cheap is another question. | |||||||||||||||||||||||
| ▲ | eddythompson80 3 hours ago | parent | next [-] | ||||||||||||||||||||||
When people wonder about where all the productivity of LLMs is going to I think this is part of the answer. There is no doubt everyone is far more productive with LLMs in generating code. However, a lot of productivity is going into things like that. Have you always been bothered by the limitations of Grafana? You can generate another dashboarding solution that works best for you. You know that deployment team that is so slow and annoying? Now you can generate your own deployment engine. Have you always hated how kubectl lets you manage one k8s cluster at a time? Now you can ask AI to generate fleetctl. You can start your project with DynamoDB, rewrite it to mysql, then to postgres, then to duckdb. Start with Python, switch to Golang, then switch to Rust. Deploy on AWS, then move to Azure, then move to a hybrid option then throw colocation in the mix. Don't like your source control? create a new one. Json is too limiting? Invent a hybrid JSON/HCL language. The browser sandbox is limited? Make a desktop app, make a language, make an OS, make a kernel. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | dawnerd 3 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
That many commits in a day I wouldn’t call it engineering. That’s basically brute forcing. | |||||||||||||||||||||||
| ▲ | tcdent 3 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
I think the article would tend to agree with you, given its position on the reluctance of open sourcing and/or sharing the actual Scion software stack. There's so much intricacy and subtlety in each organization and even individuals' environment being incorporated into tooling that expecting these tools to generalize at this point is perhaps an expired ethos. I even see this in the tooling that I run in my own personal stack. Many projects are candidates for sharing, and I have nothing against it, but they incorporate such specificity toward my own environment, including things like hardware, that creating shareable and more generalizable projects from them adds more to the maintenance surface than I would care to support. | |||||||||||||||||||||||
| ▲ | j45 2 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
Originally I felt that there was going to be a reinvention of the wheel, until I saw the "shape" of software development changing, and the tooling needing to support the new flexibilities in positions and process. Software development is not as much de-risking at the front like it used to be before building. Now teams can build lots of stuff that works great, except it's the wrong things. Most things are becoming the understand the problem "shape". Understanding the shape of the problem isn't something LLMs can always make as.. svelte as early on. Word generators gotta generate.. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | alexwrich 2 hours ago | parent | prev [-] | ||||||||||||||||||||||
[flagged] | |||||||||||||||||||||||