rorylaitila

I tried GIMP out again after a decade, and I have to say I'm presently surprised with v3. I avoided it for a long time because I remember it being a super confusing interface. Every UX idiom seemed backward to me then. But today I need to do some significant compositing, repainting and correction sporadically, and I'm tired of the Adobe tax. Maybe coupled with AI research, I've been quickly able to figure out everything I need to do.

Even on the latest models, LLMs are not deterministic between "don't do this thing" and "do this thing". They are both related to "this thing" and depending on other content in the context and seed, may randomly do the thing or not. So to get the best results, I want my context to be the smallest possible truthful input, not the most elaborated. More is not better. I think good names on executable source code and tightest possible documentation is best for LLMs, and probably for people too.

It's a concern but definitely depends on the context and my self perceived blast radius of what I'm researching. I do find myself often re-searching results to see what something more authoritative says about it, and I also continue to read source books on topics I'm taking a deep dive in. I have definitely seen current LLMs get my domain wrong.

Nice work! I met Jorin a couple years ago at a tech meetup and this was just an idea at the time. So cool to see the consistent progress and updates and to see this come across HN.

Yes I noticed this as well. I was last writing up a landing page for our new studio. Emotion filled. Telling a story. I sent it through grok to improve it. It removed all of the character despite whatever prompt I gave. I'm not a great writer, but I think those rough edges are necessary to convey the soul of the concept. I think AI writing is better used for ideation and "what have I missed?" and then write out the changes yourself.

I can totally relate. I enjoy the craft of developing and making the product 'just right.' I do use AI as a fancy auto-complete, but I don't want to lose situational awareness and go full-vibe. I think that is the sweet spot for me, just another tool. However, I see my market value of this style of work rapidly deteriorating. I'm suspect I'll be the programming-Amish. I am probably going to transition my business to more of a community-studio, with tech being an implementation detail.

I've skipped the whole 'modern' web stack. I've stayed SSR first, hrefs/forms/url as only routing primitives, progressive enhancement, vanillajs-islands only where absolutely necessary. Its great. Apps never randomly break. No build hell. UX easy to debug (just look at the HTML). No random performance degradations. No client has ever said it feels dated. Just finished my first app-like PWA, also SSR. Getting great compliments on the UI and slick interactions using just native browser transitions. The vanilla web stack gets better and better! Honestly don't know what people think they are gaining with a heavy frontend.

I dabbled in my own open source projects over the years. I learned that I really just like serving my customers directly. I don't enjoy managing PRs or responding to feedback from strangers. I think "who you enjoy to serve" is a useful frame for deciding how to go to market. Each type of go-to-market approach has it's own type of 'customer.'

Luckily we work for ourselves in our studio, and I have no one to answer to except my business partner and customers, and tech is my domain. But I have concluded "we already build fast enough." Really how much faster do we need to build? Deployments: automated. Tests: automated. Migrations: automated. Frameworks: complete. Stack: stable. Scaling: solved. OKAY so now with AI we can build "MORE!" More of WHAT exactly? What makes our lives better? What makes our customers happier? How about I just directly feed customer support tickets into Claude and let it rip.

I'm increasingly thinking either people were terrible developers, used shit tools to begin with, or are in a mass psychosis. I certainly feel bad for anyone reporting to "the business guy." He never respected you to begin with, and now he literally thinks "why are you so slow? I can build Airbnb in a weekend."

For someone who previously could achieve nothing, these tools are magical, as they can now achieve something. It feels to them like infinity because their base was 0. That alone will create a lot of things they wouldn't have been able to, good for them. However for people who already know what they're doing, I only feel slightly pushed along some asymptote. My bottlenecks simply are not measured in tokens to screen.

I make great use of value objects in my applications but there are things I needed to do to make it ergonomic/performant. A "small" application of mine has over 100 value objects implemented as classes. Large apps easily get into the 1000s of classes just for value objects. That is a lot of boilerplate. It's a lot of boxing/unboxing. It'd be a lot of extra typing than "stringly typed" programs.

To make it viable, all value objects are code-generated from model schemas, and then customized as needed (only like 5% need customization beyond basic data types). I have auto-upcasting on setters so you can code stringly when wanted, but everything is validated (very useful for writing unit tests more quickly). I only parse into types at boundaries or on writes/sets, not on reads/gets (limit's the amount of boxing, particularly on reading large amounts of data). Heavy use of reflection, and auto-wiring/dependency injection.

But with these conventions in place, I quite enjoy it. Easy to customize/narrow a type. One convention for all validation. External inputs are by default secure with nice error messages. Once place where all values validation happens (./values classes folder).

There are many layers to this. But there is one style of programming that concerns me. Where you neither understand the layer above you (why the product exists and what the goal of the system is) nor the layer below (how to actually implement the behavior). In the past, many developers barely understood the business case, but at least they understood how to translate into code, and could put backpressure on the business. Now however, it's apparently not even necessary to know how the code works!

The argument seems to be, we should float on a thin lubricant of "that's someone else's concern" (either the AI or the PMs) gliding blissfully from one ticket to another. Neither grasping our goal nor our outcome. If the tests are green and the buttons submit, mission accomplished!

Using Claude I can feel my situational awareness slipping from my grasp. It's increasingly clear that this style of development pushes you to stop looking at any of the code at all. My English instructions do not leave any residual growth. I learn nothing to send back up the chain, and I know nothing of what's below. Why should I exist?

I don't know if this is the right solution, but I appreciate the direction. It's clear that AI slop is trading on people's good names and network reputation. Poisoning the well. The dead internet is here. In multiple domains people are looking for a solution to "are you someone/something worthy of my emotional investment." I don't think code can be held to be fully AI-free, but we need a way to check that they are empathy-full.

I've developed at the speed of "vibecoding" long before LLMs by having highly thought-compressed tools, frameworks and snippets. Most of my applications use Model Driven Development where the data model automatically builds the application DAO/controllers/validations/migrations. The data model is the application. I find LLMs help me write procedures upon this data model even a little bit faster than I did before. But the data model is the design. Unless I turnover the entire design to the LLM, I am always the decider on the data model. I will always have more context about where I want to evolve the data model. I enjoy the data modelling aspect and want to remain in the driver seat, with LLMs as my implementer of procedures.