> I do wish to point out, of course, that the whole reason it was possible to experiment cheaply and come across this serendipity was because 9 months ago, faced with the choice to either do the bad easy thing or the good nothing, I chose to do the bad easy thing.5 The SQLite database worked! I understood how it worked, behind the scenes with its B-trees and its Full Text Search extension.

This is the most important takeaway, imo, and a very valuable technique: Start with the obvious, stupid solution that definitely works. Then do the optimized version, while making sure it matches the naive implementation. In this case, the optimized version could even be generated from the naive one.

▲

miki123211 an hour ago | parent | next [-]

A modern spin on this technique is as follows: Write (or use an LLM to write) something so simple that it is both obviously correct and very easy to verify the correctness of. Then, use that same LLM to create a comprehensive suite of tests, which further prove the correctness of the simple implementation. Once the tests are there, let the LLM run wild and ask it to optimize the hell out of the implementation while keeping the tests untouched.

▲

NooneAtAll3 3 hours ago | parent | prev | next [-]

problem with such approach is that sometimes "obvious easy thing" becomes so entrenched and affecting everything, that ripping it out becomes unproportionally monumental task

▲

moron4hire 5 hours ago | parent | prev | next [-]

Technical debt, like all forms of debt, can be used for leverage.

▲

Imustaskforhelp 5 hours ago | parent [-]

I feel like it is important to manage the risk and to clearly manage this debt. personally I try to stay safe from both debt and technical debt until there are sound reasons for both.

It is KISS stack for me personally (Keep it stupid simple)

I would still consider technical debt to be different than other forms of debt though, It feels way more of a tradeoff to me but perhaps all debt can be classified as such. Either way I think it makes for an interesting decision nonetheless.

	▲	kanwisher 4 hours ago \| parent [-]
		If the product fails all technical debt goes away. So using technical debt to prove out a product is very different. Cause often times you don’t have the money or resources to build correctly at first since you don’t know if the expected payoff will be there

▲

simmonmt 6 hours ago | parent | prev | next [-]

It jumped out at me too, but because I wondered what it would look like in the AI version of this story. Having had it build the SQL version do you ... a) miss the leap because you don't understand how it works, don't care to know, and go off to vibe the next thing b) ask it lots of questions because reasons to develop that deep understanding then make the leap or c) rely on it (prompt: "this can't be good enough do better") to go make the leap for you.

(Assuming for the sake of argument that you guided it to the SQL version first)

	▲	embedding-shape 6 hours ago \| parent \| next [-]
		Depends on what your overall goal is with what you're building. Is it to rush out as many features as you possible can, before VC-funding falls through the floor so you too can get a slice of the pie before the party is over? Or are you "retired" in your 30s and now have time to build the perfect software for you? Do you need to publish and release an experiment to see how people react to it or use it, before you can know if it's the right thing or not? Almost everything needs to be contextualized before you can even begin to answer what the right way forward is, depends so heavily on what situation you're in.
	▲	goosejuice 5 hours ago \| parent \| prev \| next [-]
		Fwiw, giving opus 4.7 two sentences about building a cli doing Finnish to English translation and looking for a space efficient solution leads to an answer pointing to fst. For the same reasons stated in the blog. This is without a search tool. The K shaped LLM scenario makes a lot of sense to me. Educated and experienced devs get better output because they know what to ask.
	▲	6 hours ago \| parent \| prev [-]
		[deleted]

▲

baublet 7 hours ago | parent | prev [-]

Came here to add this, too. Sometimes the most valuable thing a solution can buy you is time to think of a better solution.

	▲	chrisweekly 6 hours ago \| parent [-]
		Yes - tho I'd refine it to say it's not just more time, it's time plus the forcing function of a working solution requiring more deeply understanding the problem space.