stillpointlab

Your comment isn't rude, but it is a bit close to concern trolling. (as in, "the action or practice of disingenuously expressing concern about an issue in order to undermine or derail genuine discussion.") "Won't somebody think of the local plumbers website!"

There is an assumption being made here that isn't being made explicit: the only way that malicious behavior can be avoided is by paying a programmer. Is that a valid assumption? Or the less strong: 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?

What I feel in these comments isn't a genuine attempt to engage but rather Fear, Uncertainty and Doubt (FUD) writ large.

Also, for what it is worth, the most recent project he developed was using React, Tailwind and Postgres (which he called "Post ... something?"). It was very work-flowy (user uploads a doc, it goes into a queue for manual review, once approved it is converted and uploaded to Google Docs, an email is sent, etc). I asked him if he had investigated any workflow builders and he said no, he just vibe coded it. It's also worth noting that he is paying for QA, I think that existed already in house for his other projects. Well, actually what he said was "it is currently in testing", so I can't confirm if it is professional QA.

> Wouldn't his firm be better served by website builders like WordPress, Squarespace, Wix, etc

My understanding is the majority of his work is on WordPress. It's worth noting this is a partnership with 100+ clients, 5+ full time employees. They do television commercials, websites, banner ads, social media campaigns, etc. He is a partner at the firm and while he calls himself "non-technical" he does have experience with website design (HTML/CSS) and the administration of WordPress and databases.

To be clear: he was already delivering these kind of custom solutions to clients using contract programmers. He is well aware of requirements like authentication (in fact, our last conversation he mentioned a project he was working on that did just that). But previously, the cost of custom work was too high in some cases, since bringing on a contract programmer for certain kinds of projects pushed the budget out of range for the client. Vibe coding is opening up a new avenue for custom built functionality that was previously too expensive.

> I hope that he has the wisdom and humility

I notice this kind of thing frequently. I mean, who is lacking humility here? Someone thinking they have all of the facts, offering advice and "Why don't you just ..." kind of thinking based on assumptions. If you really think you can diagnose issues and offer advice based on the quick comment I made, you should reassess your own humility before recommending it to others.

This is a massive business opportunity for whoever owns the market.

I have a friend who owns a small/medium sized marketing firm. They typically manage social media and advertising for local businesses (butchers, plumbers, NPOs, etc.). A major cost center for them is dev. They can generally handle developing assets (images, videos, text copy) and publishing them (Facebook, YouTube, Instagram) but if they need any kind of interactivity (even basic forms or CRM-like stuff) they used to hire programmers.

This friend is now "vibe coding" the simple interactivity that previously they had to outsource. In the last few months he has pitched, won and crucially delivered simple apps for a few clients. We're not talking complex web apps, it's mostly CRUD forms and basic workflows, the kind you see people go on about using n8n on Twitter. He's talking to me these days about React, Tailwind, DNS and all of that stuff.

His clients don't know, or care, how he delivers. The local butcher doesn't know about "best practices" or whatever. He just cares that if someone signs up for his newsletter that he gets a notification and that person gets his weekly meat deals email.

His firm is picking up more and more complex projects like these and saving a huge amount on costs. Turn-key services that enable guys like him are going to reap the rewards.

> Natural language is not sufficient to give precise instructions

On consideration, this is the core of our disagreement and it is probably one that we will not see past.

I have to assume that you see human/computer interactions as master-slave relations. You are the master providing instructions and the computer is a slave that MUST do precisely what you instruct it to do. I would wager that you feel frustrated when you deal with other people who choose to do things in a way that is different than how you want them to be done.

One thing I was taught when I became a manager was that I should focus on outcomes. I should explain to people what the result I wanted was, rather than to be really picky about the implementation. I found that sometimes people could realize my desired outcomes in a way that was better than I would have done it. It was enlightening.

There is an idiom in English, about winning the battle but losing the war. It is when a person becomes so obsessed with controlling tiny details that they lose sight of the overall goal.

I doubt we will see eye-to-eye on this, but I am arguing that we will have better outcomes if we obsess less about the details of how computers implement our goals and we spend more time focusing on the goals we want to achieve.

You have no evidence for any of your claims (either for "impossibility" or degree of difficulty) and I strongly doubt your rationalization will stand the test of validation in reality.

You are also completely moving the goal posts. My original comment was about the hubris of man to prevent processes that operate at a scale beyond his means. The processes that are driving forward the march towards AI are beyond your ability to stop. And now you are arguing (again, with no evidence) the relative difficulty of slowing it down (a much weaker claim compared to stopping it) vs. contributing to safe co-existence.

But in the interest of finding some common ground let me point out: attempting to slow it down is actually getting on board to my project (although, in a way I think is ineffective). It starts with accepting that it can't be prevented and choosing a way to contribute to safe coexistence by providing enough time to figure it out.

You are stating a contradictory position: A person who doesn't believe AI can possibly emerge but is actively working to prevent it from emerging. I suggest that such a person is confused beyond help.

edit As an aside, you might want to read Don Quixote [1]

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

I couldn't even tell you who is liable right now for bugs that impact human's negatively. Can you? If I was an IC at an airplane manufacturer and a bug I wrote caused an airplane crash - who is legally responsible? Is it me? The QA team? The management team? Some 3rd party auditor? Some insurance underwriter? I have a strong suspicion it is very complicated as it is without considering LLMs.

What I can tell you is that the last time I checked: laws are written in natural language, they are argued for/against and interpreted in natural language. I'm pretty confident that there is applicable precedent and the court system is well equipped to deal with autonomous systems already.

> Natural language is trying to be a new programming language, one of many, but it's the least precise one imho.

I disagree that natural language is trying to be a programming language. I disagree that being less precise is a flaw.

Consider:

- https://www.ietf.org/rfc/rfc793.txt

- https://datatracker.ietf.org/doc/html/rfc2616

I think we can agree these are both documents written in natural language. They underpin the very technology we are using to have this discussion. It doesn't matter to either of us what platform we are on, or what programming language was used to implement them. That is not a flaw.

Biological evolution shows us how far you can get with "good enough". Perfection and precision are highly overrated.

Let's imagine a wild future, one where you copy-and-paste the HTML spec (a natural language doc) into a coding agent and it writes a complete implementation of an HTML agent. Can you say with 100% certainty that this will not happen within your own lifetime?

In such a world, I would prefer to be an expert in writing specs rather than to be an expert in implementing them in a particular programming language.

As the other commenter noted, you are simply wrong about that. We control the effects the tide has on us, not the tide itself.

But let me offer you a false dichotomy for the purposes of argument:

1. You spend your efforts preventing the emergence of AI

2. You spend your efforts creating conditions for the harmonious co-existence of AI and humanity

It's your choice.

They're not stopping the tide, they are preparing for it - as I suggested. The tide is still happening, it just isn't causing the flooding.

So in that sense we agree. Let's be like he Dutch. Let's realize the coming tide and build defenses against it.

There is an old cliché about stopping the tide coming in. I mean, yeah you can get out there and participate in trying to stop it.

This isn't about fatalism or even pessimism. The tide coming in isn't good or bad. It's more like the refrain from Game of Thrones: Winter is coming. You prepare for it. Your time might be better served finding shelter and warm clothing rather than engaging in a futile attempt to prevent it.

I get you are being sarcastic, but lets actually consider your idea more broadly.

- Machine code

- Assembly code

- LLVM

- C code (high level)

- VM IR (byte code)

- VHLL (e.g. Python/Javascript/etc)

So, we already have hierarchical stacks of structured text. The fact that we are extending this to higher tiers is in some sense inevitable. Instead of snark, we could genuinely explore this phenomenon.

LLMs are allowing us to extend this pattern to domains other than specifying instructions to processors.

I love all of this experimentation in how to effectively use AIs to co-create output with human steering. This pattern, of the human human focusing on the high-level and the AI focusing on the low level feels like a big win.

In some sense, we are starting with a very high-level and gradually refining the idea to a lower and lower levels of detail. It is structured hierarchical thinking. Right now we are at 3 levels: requirement -> spec -> code. Exposing each of these layers as structured text documents (mostly Markdown right now it seems) is powerful since each level can be independently reviewed. You can review the spec before the code is written, then review the code before it gets checked in.

My intuition is that this pattern will be highly effective for coding. And if we prove that out at scale, we should start asking: how does this pattern translate to other activities? How will this affect law, medicine, insurance, etc. Software is the tip of the iceberg and if this works then there are many possible avenues to expand this approach, and many potential startups to serve a growing market.

The key will be managing all of the documents, the levels of abstraction and the review processes. This is a totally tractable problem.

I've been using the term context engineering for a few months now, I am very happy to see this gain traction.

This new stillpointlab hacker news account is based on the company name I chose to pursue my Context as a Service idea. My belief is that context is going to be the key differentiator in the future. The shortest description I can give to explain Context as a Service (CaaS) is "ETL for AI".

I could not disagree more. I don't think you are wrong, I just choose a different approach.

There seem to be multiple approaches to working with LLMs. My own personal experience has been that carefully explaining my request, providing specific and highly relevant context (and avoiding irrelevant and distracting context) has lead to significant productivity on my side. That is, it may take me 15 minutes to prepare a really good prompt but the output can save me hours of work. Conversely, if I fire of a bunch of low-effort prompts I get poor results and I end up spending a lot of time in back-and-forth with the LLM and a lot of time fixing up its output.

This is true in my experience but it doesn't go against my larger point. Choosing the "goldilocks" context is a bit of an art, not too big not too small. It reminds of a famous witty quote [1]: “I apologize for such a long letter - I didn't have time to write a short one.”

If you send too much info at once it does seem to confuse the agent, just like if you ask it to do too much all at once. That is yet another property it shares with a junior engineer. It is easy to overwhelm a new contributor to a project with too much information, especially if it isn't strictly relevant.

I feel we are seeing this now with the adoption of coding agents.

My experience is that AIs amplify what you put in them.

If you put in lazy problem definitions, provide the bare minimum context and review the code cursorily then the output is equally lackluster.

However, if you spend a good amount of time describing the problem, carefully construct a context that includes examples, documentation and relevant files and then review the code with care - you can get some very good code out of them. As I've used them more and more I've noticed that the LLM responds in a thankful way when I provide good context.

> Always ask for alternatives

> Trust but verify

I treat the AI as I would a promising junior engineer. And this article is right, you don't have to accept the first solution from either a junior engineer or the AI. I constantly question the AIs decisions, even when I think they are right. I just checked AI studio and the last message I sent to Gemini was "what is the reasoning behind using metatdata in this case instead of a pricing column?" - the context being a db design discussion where the LLM suggested using an existing JSONB metadata column rather than using a new column. Sometimes I already agree with the approach, I just want to see the AI give an explanation.

And on the trust front, often I let the AI coding agent write the code how it wants to write it rather than force it to write it exactly like I would, just like I would with a junior engineer. Sometimes it gets it right and I learn something. Sometimes it gets it wrong and I have to correct it. I would estimate, 1 out of 10 changes has an obvious error/problem that I have to intervene.

I think of it this way: I control the input and I verify the output.

That is good context, thanks! Once I found my bug I had a moment of not being sure who to blame. Honestly, I'm a bit surprised that the ISO8601 spec dictates that absent the Z the date-time ought to be interpreted as local. At the least, I expected there would at least be a way for me to say "trust me JS, this date is UTC so please parse it that way" - but the only way I could find to force that to happen was to manually add a "Z".

But the insanity of inconsistently choosing local/UTC based on the presence of time is genuinely painful. Dates and times are hard enough as it is, why would they do that? It gives me some amusement that this was one of the motivating use cases behind the Temporal spec.

I haven't had too much trouble with Shadow DOM so far, and I was especially surprised to learn about `<template shadowrootmode="open">` recently. It makes SSR rendering of web components with shadow DOMs viable and appears to be well supported in browsers.

The fact that they do not include the trailing 'Z' for UTC timestamps is a frustration for me. It caused a few hours of debugging since JavaScript date parsing assumes that dates that lack the trailing Z are in the client time zone. I had to add a hack to check if a UTC date did or did not have the trailing Z and append the Z if it was missing.

This is made worse when you have a lot of `createdAt` columns that get set to NOW. You have to deal with the missing Z in all places where it matters. And in general, it is pointless to use the `localtime` parameter since that is the server time, and for UI I want to display the time local for the user. So I want to deal exclusively in UTC on the server and do any time zone conversions on the client.

Worth noting that when I changed to PostgreSQL, its date function does add the Z which makes life easier in general. But it is an inconsistency to be aware of if you use both DBs.