scelerat
Joined 17 years ago
Joined 17 years ago
So I love reduce, and have for many years.
There are no "hard" boundaries for ethics or "doing the right thing," and so those boundaries will always be pushed until they are useless.
Nothing technologically ground-breaking: Two front-end apps and the back end to support them. The project gave me an opportunity to try out Svelte and FastAPI in a substantial way, as well as operate in the capacity of product designer and owner which I haven't in many, many years of being a developer, since long-gone days of holding the title, "webmaster."
The two main parts were an administrative list management app, where names are entered and credentials allocated, and a checkin app designed to be used on a mobile device on the day of the festival. The challenges were making a data entry and lookup UI significantly better than the systems which had been used before, which ranged from loose sheets of photocopied hand-written notes to poorly-conceived, resource-intensive, and error-prone spreadsheets. It may sound like a low bar, but some of the biggest hurdles were convincing particular stakeholders who had been doing things one way for years to give up some control in exchange for widespread and timely synchronization.
The most satisfying part was the feedback I received as I made a dozen or so people's lives easier for a moment. The tool I built literally saved several relationships which had been frayed over the years over, yes, the seemingly inconsequential task of managing a guest list. A relatively large one, to be sure. After several years of working for companies and on projects with seemingly no direction and little direct customer feedback, it was extremely gratifying to work on something with clear goals and transparent, timely insight into how people were using the apps, enabling targeted and rapid turnaround for suggestions and requests.
Would I see the same kinds of performance gains or losses avoiding or using certain patterns in Go or Rust or Java? Are they the same examples as in C++?
What about dynamic languages like ruby or python or javascript?
For example:
Sometimes I just need to blast something out which works well enough so I can either consider the output or play with the tool it generated to see if I'm on the track for solving my bigger problem. In these instances, I just say, do it, and don't focus too much on the code it produces.
Sometimes I am using languages or tools I am not an expert in. In many of these cases, I do manually type out the LLM's suggestions so that I am more intimately familiar with the syntax, libraries and idioms being used. Frequently pausing to look at actual documentation or find examples of sample code. It's a more interactive version of what I might have been doing a couple years ago googling solutions on stack overflow.
OP's description very much mirrors my experience. I was able to do many things much more quickly with the help of the LLM, but there is no substitute for actual users interacting with the tool, saying, "I like this," or "no, this is wrong or needs work," or even, "here's something none of us thought of before, but now this tool makes me think XYZ would help us and might be achievable." That whole interaction takes real time and I don't know how you replace it with coding agents.
Secondly, on the matter of code structure, just on a qualitative level, I can see that claude will do things very efficiently on the way to a goal I give it, but it can't read my mind and know that I may want to repeat a specific pattern across two client apps. Or that its shortest-distance solution makes extensibility or broad applicability difficult. That I might want to share code and structure things in a certain way. Not without me saying so or, in many cases after it has built something workable, duplicating refactors I make with an eye for reusability or maintenance. Making those changes in time is important if you don't want to burn tokens later as the LLM tries to unravel its own spaghetti. And again, whether I am coding those intentions directly, or writing out detailed instructions in english, all of that takes time.
The actual killer app turned out to be the network itself, but for anyone who used and built things with Hypercard (a lot of people), all the patterns of components and event-driven development were like an echo from a refined past by the time it became part of the modern development toolkit.
I asked him one time what he was doing. Answering emails, he said. Customer support emails. I think he really enjoyed that part of the business.