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.

I've been cataloging my collection of American vintage ads (https://adretro.com). The collection has expanded considerably in the last year. I'm working on a front end search portal for users to use, to deeply search all aspects of the collection. Built on MySQL and Lucee. Meta data is extracted with OpenAI image, stored in MySQL FTS. I'll probably add vector search after I get it live.

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?

A couple different projects. I've been cataloging and publishing my vintage ad collection at https://adretro.com. It's starting to get a lot of organic traffic after about a year online, which is cool.

I'm also working on a new strength gains-tracking app that is a lot more intuitive, motivating and friend first. I've been using it with some friends for the last 10 weeks and everyone making is consistent gains. It is my first full PWA, vanillaJs, backend is Lucee & MySQL. Works great on iOS and Android, no one has any complaints. The web stack has come a long way I am probably not going to do a native mobile app for a while. I'll probably make it public in a couple weeks.

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.

I simplify it this way. I don't delete fields or tables in migrations once an app is in production. Only manually clean them up after they are impossible to be used by any production version. I treat the database schema as-if it were "append only" - Only add new fields. This means you always "roll-forward", a database. Rollback migrations are 'not a thing' to me. I don't rename physical columns in production. If you need an old field and a new field to be running simultaneously that represent the same datum, a trigger keeps them in sync.

Don't use other companies brand names in your product titles. Regardless of what other people get away with. Regardless of what is in the Amazon fine print. Don't use trademark logos in your product images. Make your own brand name. Make it "compatible with" in the product description.

Databases store facts. Creating a record = new fact. "Deleting" a record = new fact. But destroying rows from tables = disappeared fact. That is not great for most cases. In rare cases the volume of records may be a technical hurdle; in which case, move facts to another database. The times I've wanted to destroy large volume of facts is approximately zero.

Yes, but not in relationship to products being copied. Copying the technical aspects of an idea has been possible for a long time anyway.

Knowing how to acquire, support and cultivate a growing user base is the challenge.

The availability of a technical "moat" has always been a select property of only a few products. All real moats are network effects.

Nice! Definitely addresses a workflow I deal with daily. Any plans for a Windows version?

It's one of my favorite little tricks. I use it when I'm building applications that have a lot of nested "contexts" and its not just styling/layout. Makes it easier to search for and jump to these contexts and mentally parse them. But I use it sparingly. It gets out of hand fast if you start doing <parent-nested-2ndchild-list-item>.

Continuing the brands example, by default I store all of the brands returned as is (in SQL). On occasion, I will manually come across different variations of a brand that I decide is better combined into a primary brand. All of the secondary brands get marked as relating to a primary brand. Then the next time a new ad gets tagged as a secondary brand, I know I can use the primary brand instead.

So in essence, the process is what I might call 'eventually modelled' (to borrow from the concept of eventual consistency). I use the LLM entities as is, and gradually conform them to my desired ontology as I discover the correct ontology over time.

Yeah, the output is json structured, but I mean the entity value that is returned. A simple case is classifying the Brand of the ad. It might return any of "Ford", "Ford Motor Company", "Ford Trucks", "The Ford Motor Company", "Lincoln Ford" even on very similar ads. Rather than try to enhance the prompt like "always use 'Ford Motor Company' for every kind of Ford" I just accept whatever the value is. I have a dictionary that maps all brands back to a canonical brand on my end.

When I started cataloging my vintage ad collection (https://adretro.com), I originally started with a defined set of entities (like brands, or product categories). I used OpenAI vision to extract out the categories the ad belongs to. However, I found that it would simply not be consistent in its classification. So I decided to let the model classify however it wants, and I map those results back to my desired ontology after the fact. My mapping is manually in my case. But I could see how I could use techniques to dynamically cluster.

If I remember correctly, up through 2008 even, we would punch the card into the terminal for authorization, use the imprinter to have the customer sign and track the number, and then had to phone call the processor to capture the cards at the end of the day.

Haha, yeah I was going to reply with the same. I used to work 12+ hours/day for a few months at a time. Now I struggle for anything more than a few hours a day for a few weeks at a time. AI has helped me recover some ground but it's still less output overall.

Yeah, I agree. AI helps me bust through quickly on a tedious task, where before that might have used up a lot of my motivation. The ground covered in any particular session is a lot further.

I've accepted that all the progress for me happens in tight bursts. I simply cannot do 'thought work' when I'm disinterested. I sometimes envy people who are interested in one particular project for years or decades at a time and make plodding, continual progress. However that's not me. I make inspired, unbelievable progress, and then nothing. I try to constrain the scope so that it at least remains useful, in between the bursts.

MidJourney not being the first organic spot is a bad experience. But it's normal practice that you can place ads on users searching for other company names.

This seems counter intuitive at first, but I think its reasonable. You don't get to exclude every advertiser from any random search string just because you have a domain name with it. How would that be enforced? There are many reasons to bid on brand names that are not necessarily squatting. Such as if my product is an integration of the tool. Many brand names are just basic words. Many brand names are very similar in SMBs.

But you can't use another company's trademark in your headline or adtext. Using another companies name is asking to get your ads taken down and lead to an account ban.

Thanks! Maybe I'll add some detail. Some of them are in the eye of the beholder, and maybe I take a little liberty :) It's not that they are targeting the gay community directly, but they may have subtle homoerotic wink and a nod... They definitely are not overt and would have gone over the heads of most people at the time.