stillpointlab

I'm currently in build mode. In some sense, my project is the most over complicated blog engine in the history of personal blog engines. I'm literally working on integrating a markdown editor to the project.

Once I have the MVP working, I will be working on publishing as a means to dogfood the tool. So, check back soon!

This is a good article, but it has a flaw that I keep seeing in these. Articles like this say "I built this app, and that app, and another app, and another one". Ok, let's see them. Are they any good? Please post the github link, or link to the webpage.

I'm reminded of the motto of the Royal Society: Nullius in verba.

Yes, the whole point that it is true. But only for a short window.

So consider differing perspectives. Like a teenage kid that is hanging around the stables, listening to the veteran coachmen laugh about the new loud, smoky machines. Proudly declaring how they'll be the ones mopping up the mess, picking up the stragglers, cashing it in.

The career advice you give to the kid may be different than the advice you'd give to the coachman. That is the context of my post: Andrew Ng isn't giving you advice, he is giving advice to people at the AI school who hope to be the founders of tomorrow.

And you are probably mistaken if you think the solution to the problems that arise due to LLMs will result in those kids looking at the past. Just like the ultimate solution to car reliability wasn't a return to horses but rather the invention of mechanics, the solution to problems caused by AI may not be the return to some software engineering past that the old veterans still hold dear.

Not to slip too far into analogy, but that argument feels a bit like a horse-drawn carriage operator saying he can't wait to pick up all of the stranded car operators when their mechanical contraptions break down on the side of the road. But what happened instead was the creation of a brand new job: the mechanic.

I don't have a crystal ball and I can't predict the actual future. But I can see the list of potential futures and I can assign likelihoods to them. And among the potential futures is one where the need for humans to fix the problems created by poor AI coding agents dwindles as the industry completely reshapes itself.

This mirrors insights from Andrew Ng's recent AI startup talk [1].

I recall he mentions in this video that the new advice they are giving to founders is to throw away prototypes when they pivot instead of building onto a core foundation. This is because of the effects described in the article.

He also gives some provisional numbers (see the section "Rapid Prototyping and Engineering" and slides ~10:30) where he suggests prototype development sees a 10x boost compared to a 30-50% improvement for existing production codebases.

This feels vaguely analogous to the switch from "pets" to "livestock" when the industry switched from VMs to containers. Except, the new view is that your codebase is more like livestock and less like a pet. If true (and no doubt this will be a contentious topic to programmers who are excellent "pet" owners) then there may be some advantage in this new coding agent world to getting in on the ground floor and adopting practices that make LLMs productive.

1. https://www.youtube.com/watch?v=RNJCfif1dPY

> the embeddings can be reused by the model

I can't find any evidence that this is possible with Gemini or any other LLM provider.

I'm reading the docs and it does not appear Google keeps these embeddings at all. I send some text to them, they return the embedding for that text at the size I specified.

So the flow is something like:

1. Have a text doc (or library of docs)

2. Chunk it into small pieces

3. Send each chunk to <provider> and get an embedding vector of some size back

4. Use the embedding to:

4a. Semantic search / RAG: put the embeddings in a vector DB and do some similarity search on the embedding. The ultimate output is the source chunk

4b. Run a cluster algorithm on the embedding to generate some kind of graph representation of my data

4c. Run a classifier algorithm on the embedding to allow me to classify new data

5. The output of all steps in 4 is crucially text

6. Send that text to an LLM

At no point is the embedding directly in the models memory.

> Embeddings are crucial here, as they efficiently identify and integrate vital information—like documents, conversation history, and tool definitions—directly into a model's working memory.

I feel like I'm falling behind here, but can someone explain this to me?

My high-level view of embedding is that I send some text to the provider, they tokenize the text and then run it through some NN that spits out a vector of numbers of a particular size (looks to be variable in this case including 768, 1536 and 3072). I can then use those embeddings in places like a vector DB where I might want to do some kind of similarity search (e.g. cosine difference). I can also use them to do clustering on that similarity which can give me some classification capabilities.

But how does this translate to these things being "directly into a model's working memory'? My understanding is that with RAG I just throw a bunch of the embeddings into a vector DB as keys but the ultimate text I send in the context to the LLM is the source text that the keys represent. I don't actually send the embeddings themselves to the LLM.

So what is is marketing stuff about "directly into a model's working memory."? Is my mental view wrong?

The irony is I alt-tabbed to HN to read this article after starting Claude Code on an implementation pass.

My usage of Claude Code sounds different to a lot of ways I hear people using it. I write medium detail task breakdowns with strict requirements and then get Claude to refine them. I review every single line of code methodically, attempting to catch every instance Claude missed a custom rule. I frequently need to fix up broken implementations, or propose complete refactors.

It is a totally different experience to any other dev experience I have had previously. Despite the effort that I have to put in, it gets the job done. A lot of the code written is better than equivalent code from junior engineers I have worked with in the past (or at worst, no worse).

Many people here are taking away from this that substituting our own writing with the writing from an LLM is a danger for human development.

I see things more optimistically. If good writing leads to good thinking, then anything I do to improve my ability to write well transitively helps me to think well.

In that sense, I actually see a huge benefit to LLMs in improving my writing and therefore improving my thinking. Not only can I ask for detailed and powerful feedback, I can also ask for more details on background context or related topics that I wouldn't be aware of.

I believe judicious use of LLMs can make us better than we could be without them.

As I alluded to in another comment, you are fighting upstream against the dominant Western conception of learning. But any musician I have ever met worth their salt knows the importance of learning songs and transcribing their favorite artists.

I think one of the causes is that some people struggle for years with music and then one day they learn a bit of theory and they experience a moment of enlightenment. Suddenly, all of their confusion is dispelled and what was once difficult is clear as day. They then think "if I had only know this years ago I wouldn't have struggled!". But they are wrong. It was the years of struggle that helped them understand the theory, not the other way around.

It's the "wax on, wax off" of Karate Kid and the wise old Mr. Miyagi.

I read a music theory book from the 1800s and in the first chapter the author stated that while he endeavored to write useful theory to help students they must realize that if some composition they write follows all of his rules but sounds bad, it is bad. And if they write a composition that breaks his rules but it sounds good then it is good. These are old, old ideas that we re-learn over and over.

We were using Mongo and stored the ids with the prefix in the DB as the primary key. Pretty much everywhere we were passing them around as strings, never as 128 bit int, so there was no integrity checking outside of the app layer.

The only drawback was marshalling the types when they come out of the db layer. Since the db library types were string we had to hard cast them to the correct types, really my only pain. That isn't such a big deal, but it means some object creation and memory waste, like:

    // pseudo code:
    const results = dbclient.getObjectsByFilter( ... );
    return results.map(result => ({
        id: result.id as ObjectId,
        ...
    }));

We normally didn't do it, but it would be at that time you could have some `function isObjectId(id:string) : id is ObjectId { id.beginsWith("object:"); }` wrapper for formal verification (and maybe throw exceptions on bad keys). And we were probably doing some type conversions anyway (e.g. `new Date(result.createdAt)`).

If we were reading stuff from the client or network, we would often do the verification step with proper error handling.

It's about not putting the cart before the horse. Theory is a guide to the songs, not a set of rules to be mastered in isolation.

In philosophy there is a test of necessity and sufficiency. Theory is definitely not sufficient to become a proficient musician (let alone a composer). I think it is arguable whether or not it is necessary (I would argue not and handwave towards the list of musicians who are literal legends despite 0 theory). So as a strict answer to your question: maybe not.

However, practically, learning some theory is obviously beneficial to many learners and can speed up the process of acquiring the skill. But again, beware of cart before horse.

Take one famous legend who is infamous for his insistence he know no theory: B.B. King. I mean, anyone who analyses his music can point out a laundry list of complicated theoretical things he is doing in his playing. He just doesn't know the "book names" for it since he learned those things in a different way. He definitely know what a "6" chord is, when to use it, what scales to use with it, etc. But if you asked him to explain it to you he'd probably show you 4 or 5 songs instead of writing you an essay.

I've used the approach described for uuids on a project and I liked it. We were using typescript so we went further using template literal types [1]

    type UserId = `user:${uuid}`;
    type OrgId = `org:${uuid}`;

This had the benefit that we could add validation (basic begins with kind of logic) and it was obvious upon visual inspection (e.g. in logs/debugging).

1. https://www.typescriptlang.org/docs/handbook/2/template-lite...

I can confirm this is effective - I have done the same.

I haven't done extensive experiments, but I have noticed anecdotal benefits to asking the LLM how they want things structured as well.

For example, for complex multi-stage tasks I asked Claude Code how best to communicate the objective and it recommended a markdown file with the following sections: "High-level goal", "User stories", "Technical requirements", "Non-goals". I then created such a doc for a pretty complex task then asked Claude to review the doc and ask any clarifications. I then answer any questions (usually 5-7) and put them into a "Clarification" section. I have also added a "Completion checklist" section that I use to ensure that Claude follows all of the rules in my subdirectory "README.md" files (I have one for each major sub-section of code, like my service layer, my router layer, my database, etc). I usually go and do 2-3 rounds of Claude asking questions and me adding to the "Clarification" section and then Claude is satisfied and ready to implement.

The bonus of this approach is I now have a growing list of the task specifications checked into a "tasks" directory showing the history of how the code base came to be.

This is a common feeling, and it is in some respect related to western culture. We prize "knowledge" very highly because it is demonstrably effective.

My comment isn't meant to devalue knowledge but to put it in relation to "something else". That something else is the thing you have knowledge about. The thing to appreciate is that you can become an expert on knowledge itself, without ever becoming expert in the thing the knowledge is about.

Consider some painting theory topics: color theory, contrast, perspective, proportion, etc. Imagine someone who attains expert level knowledge of any one (or combination) of these subjects but they are still unable to draw a picture that is a pleasing representation of their subject. You can easily study all of these topics for a lifetime without every picking up a pencil or a brush.

My other comment mentions the map vs. territory distinction. So let's deeply consider this. You are in unfamiliar territory and you feel lost. You think to yourself: "If I only had a map then I wouldn't feel so lost". But does that mean you should spend the rest of your life studying map making? An alternative is to survey the territory with your own eyes and learn to pick out the trails that many others have cut into the wild. And then follow some of those trails. You might end up at a dead end and have to turn back to a previous fork in the road. You may find yourself scratched up as you try to get through dense thickets, or bogged down up to your shins in a swamp. Those are the kinds of experiences that teach you the land in a way no map could ever. And they are experiences you can't get by sitting in a tent studying a map. If your goal is to find a new trail through the territory - no map will even show it. That will only come from the hard won experience of trekking relentlessly through the wild.

As the philosopher Mike Tyson once said: "Everyone has a plan until they get punched in the face". It sucks getting punched in the face by other people, by learning a new language, learning to paint, learning music. Some people avoid it at all costs, thinking that studying the theory is the same thing.

Just remember that all of the scratches and bruises you are getting as you fail at painting are scratches on your ego. It can take it. You will get better, as long as you keep trying it is inevitable you will learn. And it is very useful to glance at a map now and again. Just don't get too reliant on it.

I think the idea is very deep and applicable to many aspects of life.

Learning grammar, vocabulary, semantics, etc. is definitely valuable. But immersing yourself in a culture where the language is spoken, listening how it is used in practice, speaking it yourself with a native, that is a truly powerful way to learn the language.

I'm not religious but I am reminded about a story where Jesus was challenged about his disciples picking some wheat on the Sabbath, breaking a law. The Pharisees demand an answer and Jesus says that the Sabbath was made for man, not man for the Sabbath. He was pointing out the inverted relationship and the corruption that results.

The same can happen with music, programming, language learning, etc.

Another analogy most people will recognize: the map vs. the territory. Music theory is the map, the songs are the territory. No matter how much you study the map you will benefit tremendously from walking the territory.

Something you hear often in the jazz community, especially from experienced pros is "everything you need to know about theory is in the songs".

It is usually in response to newcomers thinking they need to learn everything about every scale, every mode, every chord. They ask questions like "what scale should I play over this chord" or they get in really deep into some obscure theory thinking. I see it all the time with posts, even here on HN, where someone says "I figured out music!" and then you get some dry 1000 word essay on harmonic overtone series, and the maths of intervallic relationships.

But all of that intellectualization is replaceable and improved upon by learning a massive number of songs. Not just chord progressions, not just melodies in isolation, but beginning to end tunes. I was watching a live stream by industry veteran Jimmy Bruno and he was asked how many songs he knew and could play mostly from memory and he pondered for a minute and said "probably 2000".

> you can take action against the human

I think that will depend on a case-by-case. I don't have any recent examples but I recall someone trying to sue one of those strip-mall tax preparation franchises over incorrect filings. My understanding is that the documents that you sign when you enroll in those services are pretty strictly in the favor of the company. I doubt you could ever go after the specific "human" that made the error even if it was maliciously done.

In the same way, if you pay for a tax service that uses AI agents, what you can and cannot "take action" for will probably be outlined in the terms of service that you accept when you sign up.

I would guess millions of people already use software based tax filing services (e.g. turbo tax) where no human at all is in the loop. I don't understand how swapping in an LLM significantly changes the liability in those cases. The contract will be between you and the entity (probably a corporation), not you and "computers".

Worth stating I am NOT a lawyer.

This looks (at a glance) similar in many ways to Adobe's defunct MXML [1] which was the backbone of the Flex platform built on Flash.

Apparently this lives on in Apache Royale [2]

Using XML for an user interface description language is quite common, from XUL to XAML to JSX. In my experience, XML is well suited to this task.

1. https://en.wikipedia.org/wiki/MXML

2. https://apache.github.io/royale-docs/features/mxml

Your list almost exactly matches my experience and deserves to be a blog post explaining how to use LLM coding agents effectively.

However, I think the applicability is beyond frontend (and to be fair you said "like CRUD apps / frontend"). There are a lot of domains where patterns are clearly established and easily reproduceable. For example, I had a basic XML doc type and with a couple of simple prompts in Claude Code I was able to: add namespaces, add an XSD, add an XSL to style into HTML, add full unit tests. That isn't rocket science, but it isn't code I really want to write. In 5 minutes I leveled up my XML doc significantly with a few hundred lines of XSD/XSL/tests.

This example is a case where I happily pass the task to an LLM. It is a bit like eating my vegetables. I find almost no joy in writing schema docs or tests, even when I recognize the value in having them. The XSL to HTML is a nice added bonus that cost me nothing.

I didn't say all the data. In fact, what you are suggesting is exactly what I mean. The compartmentalized access is exactly the bridge we need.

In fact, giving RBAC functionality to middle managers would be a key component to any strategy for AI deployment activity. You want traceability/auditability. Give the middle managers charts, logs, visibility into who is using what data with which LLMs. Give them levers to grant and deny access. Give them metrics on outcomes from the use of the data. This could eve even make legal happy.

This missing layer will exist, its just a matter of time.

> such as datasets that are not properly integrated into the cloud

I believe this is a core issue that needs to be addressed. I believe companies will need tools to make their data "AI ready" beyond things like RAG. I believe there needs to be a bridge between companies data-lakes and the LLM (or GenAI) systems. Instead of cutting people out of the loop (which a lot of systems seem to be attempting) I believe we need ways to expose the data in ways that allow rank-and-file employees to deploy the data effectively. Instead of threatening to replace the employees, which leads them to be intransigent in adoption, we should focus on empowering employees to use and shape the data.

Very interesting to see the Economist being so bullish on AI though.

I disagree with you but I'll only repeat and expand on my final statement: I'm glad there are people seriously studying this. If you are right (which I doubt) I hope it comes to light with evidence. And if you are wrong, I hope you have the grace to admit it.

I totally agree, and I use LLMs for this. I have a script that will output my directory structure (just the folders and filenames + the lines of code; aggregate for folders and per file). Then I ask the LLM to give me feedback. Surprisingly this has lead to some very useful feedback and improvements.

I have to be careful of confirmation bias when I read stuff like this because I have the intuition that we are uncovering a single intelligence with each of the different LLMs. I even feel, when switching between the big three (OpenAI, Google, Anthropic) that there is a lot of similarity in how they speak and think - but I am aware of my bias so I try not to let it cloud my judgement.

On the topic of compression, I am reminded of an anecdote about Heidegger. Apparently he had a bias towards German and Greek, claiming that these languages were the only suitable forms for philosophy. His claim was based on the "puns" in language, or homonyms. He had some intuition that deep truths about reality were hidden in these over-loaded words, and that the particular puns in German and Greek were essential to understand the most fundamental philosophical ideas. This feels similar to the idea of shared embeddings being a critical aspect of LLM emergent intelligence.

This "superposition" of meaning in representation space again aligns with my intuitions. I'm glad there are people seriously studying this.

> I'm telling you that if we merely "contribute" to safe co-existence, we all die.

I hear you. I believe you are wrong.

> it really is the standard in any other field, is proving safe coexistence to a reasonable standard

No it isn't. It often becomes the standard after the fact. But pretty much every invention by man didn't go through a committee. Can you provide some counter-examples? Did the Wright brothers prove flight was safe before they got on the first plane? Did the inventors of CRISPR technology "prove" it is safe? Or human cloning? Or nuclear fission? Your very argument rests on the mistakes humans made in the past and the out-sized consequences of making the same kinds of mistakes with AI. Your argument must be: we have to do things differently this time with AI because the stakes are higher.

These are old and boring arguments. I've been watching the less wrong space since it was overcoming bias (and frankly, from before). I've heard all of the arguments they have to make.

But the content of this discussion was on inevitability and how to respond to it. The person I replied to suggested that it was a mistake to see the future as something that happens to us. It was a call to agency. I was pointing out that not all agency is equal, and hubris can lead us to actions that are not productive.

It is also the case that fear, just like hubris, can lead us to actions that aren't productive. But perhaps we should just move on from this discussion.

I see you chose to respond to my weaker argument and ignore the second: "A plugin is less secure if developed by a coding agent when compared to any possible programmer. Is that a valid assumption? Aren't all of the well-known issues in WordPress plugins the fault of programmers?"

You are also conflating professional engineering, a licensed profession requiring insurance, etc. with software "engineering". You don't want to admit that the quality of "engineering" that is available on Upwork or in the average contract software developer is likely as bad, in fact, probably worse than the latest crop of LLMs.

> Instead of engaging with this argument

What argument? You are expressing vague feelings of concern and stating incorrect assumptions. I can't change how you feel and those feelings are valid. They are certainly motivating your reasoning and leading you to the incorrect assumptions.

You are stating conclusions (e.g. "He will deliver a seemingly working site to his customers with security issues and bugs, and it will only be a matter of time for them to be exploited.") as if you have a crystal ball and then demanding that I defend this figment of your imagination.

> What I am arguing for is for using these new tools smartly and conservatively

You've moved the goalpost here. You said "These issues could be mitigated or avoided by hiring an experienced developer." Now you are back peddling, suggesting you actually meant to say we should use the tools "smartly and conservatively".

So how about you state yourself clearly: Can non-programmers use these tools "smartly and conservatively". And if so, why do you assume the friend I mentioned in question, someone who has been in the business for decades hiring for and delivering software, is incapable of doing so. And if not, provide an actual argument to that effect.

Congrats to your girlfriend! Actually shipping their own app is a feat that many programmers never achieve, instead spending their entire lives working on projects for others.

I'm going to jump on this to think aloud about the unlock this ability gives the world for customized apps. My neighbor is a landscaper and he is constantly complaining to me about invoicing software. He has gone through 10+ apps trying to find one that fits his particular set of requirements. He was telling me recently that he spent several phone calls with a developer who had shipped an iOS app that was close to what he needed trying to explain what he wanted. He knows I am a programmer and is always hinting that I should develop an app that would meet his requirements.

But I know better. Invoicing/scheduling software is really difficult, especially to appeal to everyone. Each small business has so many tiny requirements that are specific to their business and their personality. You can't just have one piece of software that appeals to everyone, that meets all of the requirements, without it becoming bloated and complicated. And if I built to his particular requirements, I would have exactly 1 customer, which isn't sustainable as a business (I mean, he wants to pay ~20/month).

But now we have a world where that kind of highly customized software will be possible. As more and more LLM-ready building blocks emerge, custom software may become the norm rather than the exception.