I'm extremely cautious about complexity, yet have adopted a claude-based dev flow. It comes down to watching and guiding it, and not letting it run autonomously. At a certain point your codebase will tip over into the patterns you've defined and claude will recognize and follow them. Just treat Claude as a vim editor mode and you will see a big difference, and your relationship to the tool will change.
Happy to see a new CSS-in-JS lib. All of this madness about runtime performance costs does not apply to 99.9% of the population. But good abstractions do. And then there's latency, and machines are getting faster, and browsers getting better, etc etc. This whole argument and the related FUD was all a non-issue to begin with, at the great cost to DX.
> This same colleague then invested time into understanding the kernel subsystem, the exact reasons why the original C program was written how it was, and rewrote the Rust translation himself. The difference was night and day; the code flowed naturally, explained itself and the underlying subsystems, and may genuinely be some of the nicest parts of the entire codebase.
This is the point that everybody needs to calm down and understand. LLMs are fantastic for POCs _which then get rewritten_. Meaning: the point is to rewrite it, by hand. Even if this is not as fast as shipping the POC and pretending everything is ok (don't do this!) it still drastically speeds up the software engineering pipeline and has the potential to increase Good Code overall.
A perfectly reasonable rule in software organizations is: For greenfield code, LLMs are strictly required for 1st-pass prototyping (also required!). And then: Hand writes (within reason) for production code. Your company will not lose their competitive edge following this guideline, and this includes your hard-earned skills.
That sounds nice in theory but how many managers are going to tolerate a rewrite when there is something "good enough" sitting in front of them? (They can't see the tech debt and the vulnerabilities, just that it Apparently Does The Thing.)
I'm not sure how this guideline makes sense. LLMs are great at dumb things I shouldn't have to type but can be well defined before they write something.
This statement, makes almost zero sense - A perfectly reasonable rule in software organizations is: For greenfield code, LLMs are strictly required for 1st-pass prototyping (also required!). And then: Hand writes (within reason) for production code. Your company will not lose their competitive edge following this guideline, and this includes your hard-earned skills.
"Give me a proxy, written in go, that can handle jwt authentication" isn't your traditional crud stuff, but Claude answers that quite well.
You do know that in a business environment proof of concept is more a proof of production. Shit doesn't get rewritten when it can at this very moment start generating revenue and profits.
The only way to learn real software engineering is on the job. It is not theory but practice. Assume you know nothing, and humble yourself to learn. It will take many years!
Textual is A++. Feels a bit less snappy than Ink, but it makes up in all things with its immense feature-set. Seriously fun building apps of all kinds with this lib.
reply