larve

I think that due to the nature of language, often the prompting technique that you use is indeed the best, for you, since it allows you to express yourself “naturally” and thus have more consistent and effective session with a model adopting a similar style and using similar abstractions when building.

I'm always a very serious person while I wait for people to join the stream. I'm sorry you weren't impressed, but tbf that's not really my goal, I just like building things and yapping about it.

Not sure what you mean? This was a demo in a live session that took about 30 minutes, including ui ideation (see pngs). It’s a reasonably well featured app and the code is fairly minimal. I wouldn’t be able to write something like that in 30 minutes by hand.

Since I get downvoted because I guess people don’t believe me, I’m sitting at breakfast reading a book. I suddenly think about yaml streaming parsing, start a gpt research, dig a bit deeper into streaming parser approaches, and launch a deep research on streaming parsing which I will print out and read tomorrow at breakfast and go through by hand. I then take some of the gpt discussion and paste it into Manus, saying:

“ Write a streaming go yaml parsers based on the tokenizer (probably use goccy yaml if there is no tokenizer in the standard yaml parser), and provide an event callback to the parser which can then be used to stream and print to the output.

Make a series of test files and verify they are streamed properly.”

This is the slot machine. It might work, it might be 50% jank, it might be entire jank. It’ll be a few thousand lines of code that I will skim and run. In the best case, it’s a great foundation to more properly work on. In the worst case it was an interesting experiment and I will learn something about either prompting Manus, or streaming parsing, or both.

I certainly won’t dedicate my full code review attention to what was generated. Think of it more as a hyper specific google search returning stackoverflow posts that go into excruciating detail.

https://chatgpt.com/share/68b98724-a8cc-8012-9bee-b9c4a77fe9...

https://manus.im/share/kmsyzuoRHfn1FNjg5NWz17?replay=1

You can look at my GitHub, and I stream full unedited sessions on https://youtube.com/@program-with-ai

Trivial is a pretty big word in this context. Expanding an idea into some sort of code is indeed a matter of waiting. The idea, the prompt, the design of the overall workflow to leverage the capabilities of llms/agents in a professional/long-lived codebase context is far from trivial, imo.

I only review what needs to be reviewed, I don’t need to fully review every prototype, shell script, dev tool etc… only what is in the critical path.

But if llms show us one thing, it’s how bad our code review tools are. I have a set of tree sitter helpers that allow me to examine different parts of a PR more easily (one that allows me to diff semantic parts of the code, instead of “files” and “lines”, one that gives me stats on what subsystems are touched and crosscorrelation of different subsystems, one for attaching metadata and which documents are related to a commit, one for managing our design documents, llm-coding intermediary documents, long lasting documents, etc… the proper version of these are for work but here’s the initial yolo from Manus: https://github.com/go-go-golems/vibes/tree/main/2025-08-22/p... https://github.com/go-go-golems/vibes/tree/main/2025-08-22/c... https://github.com/go-go-golems/vibes/tree/main/2025-08-15/d... https://github.com/go-go-golems/vibes/tree/main/2025-07-29/p...).

I very often put some random idea into the llm slot machine that is manus, and use the result as a starting point to remold it into a proper tool, and extracting the relevant pieces as reusable packages. I’ve got a pretty wide treesitter/lsp/git based set of packages to manage llm output and assist with better code reviews.

Also, every llm PR comes with _extensive_ documentation / design documents / changelogs, by the nature of how these things work, which helps both humans and llm-asssisted code review tools.

I don't think so, although I think at that point experience heavily comes into play. With GPT-5 especially, I can basically point cursor/codex at a repo and say "refactor this to this pattern" and come back 25 minutes later to a pretty much impeccable result. In fact that's become my favourite past time lately.

I linked some examples higher up, but I've been maintaining a lot of packages that I started slightly before chatgpt and then refactored and worked on as I progressively moved to the "entirely AI generated" workflow I have today.

I don't think it's an easy skill (not saying that to make myself look good, I spent an ungodly amount of time exploring programming with LLMs and still do), akin to thinking at a strategic level vs at a "code" level.

Certain design patterns also make it much easier to deal with LLM code: state reducers (redux/zustand for example), event-driven architectures, component-based design systems, building many CLI tools that the agent can invoke to iterate and correct things, as do certain "tools" like sqlite/tmux (by that I mean just telling the LLM "btw you can use tmux/sqlite", you allow it to pass hurdles that would otherwise just make it spiral into slop-ratatouille).

I also think that a language like go was a really good coincidence, because it is so amenable to LLM-ification.

I have linked my github above. I don't know how that fares in the bigger scope of things, but I went from 0 opensource to hundreds of tools and frameworks and libraries. Putting a number on "productivity" makes no sense to me, I would have no idea what that means.

I generate between 10-100k lines of code per day these days. But is that a measure of productivity? Not really...

Their main point is "AI coding claims don't add up", as shown by the amount of code shipped. I personally do think some of the more incredible claims about AI coding add up, and am happy to talk about it based on my "evidence", ie the software I am building. 99.99% of my code is ai generated at this point, with the occasional one line I fill in because it'd be stupid to wait for an LLM to do it.

For example, I've built 5-6 iphone apps, but they're kind of one-offs and I don't know why I would put them up on the app store, since they only scratch my own itches.

In case the author is reading this, I have the receipts on how there's a real step function in how much software I build, especially lately. I am not going to put any number on it because that makes no sense, but I certainly push a lot of code that reasonably seems to work.

The reason it doesn't show up online is that I mostly write software for myself and for work, with the primary goal of making things better, not faster. More tooling, better infra, better logging, more prototyping, more experimentation, more exploration.

Here's my opensource work: https://github.com/orgs/go-go-golems/repositories . These are not just one-offs (although there's plenty of those in the vibes/ and go-go-labs/ repositories), but long-lived codebases / frameworks that are building upon each other and have gone through many many iterations.

codeact is a really interesting area to explore. I expanded upon the JS platform I started sketching out in https://www.youtube.com/watch?v=J3oJqan2Gv8 . LLMs know a million APIs out of the box and have no trouble picking more up through context, yet struggle once you give them a few tools. In fact just enabling a single tool definition "degrades" the vibes of the model.

Give them an eval() with a couple of useful libraries (say, treesitter), and they are able not only to use it well, but to write their own "tools" (functions) and save massively on tokens.

They also allow you to build "ephemeral" apps, because who wants to wait for tokens to stream and a LLM to interpret the result when you could do most tasks with a normal UI, only jumping into the LLM when fuzziness is required.

Most of my work on this is sadly private right now, but here's a few repos github.com/go-go-golems/jesus https://github.com/go-go-golems/go-go-goja that are the foundation.

I don't think that COBOL, BASIC, SQL have failed. They allowed many non-technical people to get started building things with computers. The skills to vibe-code (or more generally building applications with LLMs) are not reading and writing english, they are the skill of using LLMs to build applications.

In the context of people not learning "real programming", you can equate LLMs to say, wordpress plugins or making a squarespace site. Deployment of software has never been gated by how much effort it took to write it, there's millions of wordpress sites out there that get deployed way faster than an LLM can generate code.

If we care about the security of it all, then let's build the platforms to have LLMs build secure applications. If we care about the craft of programming, whatever that means in this day and age, then we need to catch people building where they are. I'm not going to tell people to not use computers because they want to cash out, they will just use whatever tool they find anyway. Might as well cash out on them cashing out while also giving them better platforms to build upon.

As far as the OP goes, these kind of security issues due to hardcoded credentials are basically the hallmark of someone shipping a (mobile|web) app for the first time, LLMs or not. The only reason the LLM actually used that is because it was possible for the user to provide it tokens, instead of replit/lovable/expo/whatever providing a proper way to provision these things.

Every cash~out fast bro out there these days uses stripe and doesn't roll their own payment processing anymore. They certainly used to do so because they just clicked a random wordpress plugin. That's what I think a more productive way to tackle the issue is.

A computer always was a tool to enable people without technical knowledge to build software. That was true for me as 9 year old in the 80ies.

LLMs are incredible engineering tools and brushing them aside as nonsense is imo doing a disservice to everybody, and especially ourselves if we take our craft seriously. You can literally replace llm with php and post the same take on usenet in 1999, or whenever you started writing software.

I am tired of engineers just throwing their hands up and being defeatist while fully endorsing whatever narratives the ai industry is throwing out there, when what we are talking about is a big pile of floats that is able to generate something that makes it into the App Store. It is unprecedented in its abilities, but it’s also nothing new conceptually. It makes computer things easier.

fair enough, i missed that part.

what about having vibe coders catch up to experienced software developers also using LLMs / AI tools?

maybe the article should reflect that? This just seems like "I found an app that has a security hole and I'm being a dick about it". Sure, feel free to do it, I don't think it's productive, and actually toxic. This is not a new situation, this is a pattern that we have observed since the internet existed, vibe coding or not. However, compared to 30 years ago, we now have better investigation and disclosure procedures, as well as a much better understanding of how to build secure applications and teaching people about them. It's not about this guy Christian, it's about a whole generation of new developers that are joining us more senior developers. I think that is fantastic.

I feel like it is. What should happen? Everybody born after 2015 is forbidden to use a computer? Or should only be allowed under strict supervision to be typing in code by hand? When people told me that in the nineties, with my linux, putting up shoddy cgi-bins, I just gave them the finger and said "whatever man".

The people who made an influence in my life and taught me how to do things properly were those that took me seriously as someone building software. And this person built software, the same way I now build software without having to think about every byte and malloc, and knowing that I don't really have to gaf about how much memory i allocate. It's fine, because we have good GCs and a lot of resources to learn about memory management when things hit the limit. The solution wasn't to say that everybody not programming C or assembly would not be allowed near a computer.

right, do you think this article is going to be very productive in that regard? If the author of the blog approached the author of the software in that manner (hey, you have kids on the app, btw I spammed them with porn humor), do you think they would wave it away?

As for the human code thing, it's not bait. I don't know if you were around in the php or early node days, but beginners were... not writing that kind of code.

I agree that the ease of vibecoding things that turn out to be useful that people do immediately want to pay money for it means that tackling security issues is a priority.

Saying that certain people shouldn't be allowed on the internet, based on your decades of experience _being_ on the internet, is just going to cause you to wither away and drown in cynicism.

Not only would you contact the author first, but spamming users with edgy notifications is puerile at best. As for “it’s just prompting an AI”, who cares, this person built an application that people find useful. This is the world we are at now, where a new set of people can use computers to make things happen. More senior developers can rage against the clouds, but that only gets you so far. This kind of gatekeeping happens at each wave of democratization of building software.

There’s also some pervasive view that handcrafted human code is somehow of superior quality which… uh…

This take is toxic. You could write the same article in 2001 and lament all the newcomers writing insecure applications in php3, or in 2009 with all the newcomers writing insecure applications with node.js.

The solution is not to aggressively shame people into doing things the way you learned to do them, but to provide not just education and support, but better tools and frameworks to build applications such as these securely.

What are we doing?

re o3: you can zip the file, upload it, and it will use python and grep and the shell to inspect it. I have yet to try using it with a sqlite db, but that's how i do things locally with agents.

Here's maybe the most impressive thing I've vibecoded, where I wanted to track a file write/read race condition in a vscode extension: https://github.com/go-go-golems/go-go-labs/tree/main/cmd/exp...

This is _far_ from web crud.

Otherwise, 99% of my code these days is LLM generated, there's a fair amount of visible commits from my opensource on my profile https://github.com/wesen .

A lot of it is more on the system side of things, although there are a fair amount of one-off webapps, now that I can do frontends that don't suck.

Software methodologies and workflows are not engineering either, yet we spend a fair amount of time iterating and refining those. You can very much become better at prompt engineering. There is a huge differential between individuals, for example.

The code coming out of LLMs is just as deterministic as code coming out of humans, and despite humans being feckle beings, we still talk of software engineering.

As for LLMs, they are and will forever be "unknowable". The human mind just can't comprehend what a billion parameters trained on trillions of tokens under different regimes for months corresponds to. While science has to do microscopic steps towards understanding the brain, we still have methods to teach, learn, be creative, be rigorous, communicate that do work despite it being this "magical" organ.

With LLMs, you can be pretty rigorous. Benchmarks, evals, and just the vibes of day to day usage if you are a programmer, are not "wishful thinking", they are reasonably effective methods and the best we have.

Useful boilerplate:

- documentation (reference, tutorials, overviews) - tools - logging and log analyzers - monitoring - configurability - unit tests - fuzzers - UIs - and not least: lots and lots of prototypes and iterating on ideas

All of these are "trivial" once you have the main code, but they are incredibly valuable, and LLMs do a fantastic job.

Even putting the common lisp aside, PAIP is my favourite book about programming in general, by FAR. Norvig's programming style is so clear and expressive, the book touches on more "pedestrian" parts of programming: building tools / performance / debugging, but also walks you through a serious set of algorithms that are actually practical and that I use regularly (and they shape your thinking): search, pattern matching, to some extent unification, building interpreters and compilers, manipulating code as data.

It's also extremely fun, you go from building Eliza to a full pattern matcher to a planning agent to a prolog compiler.

It's always hard to parse if people mean functional programming when bringing up Lisp. Common Lisp certainly is anything but a functional language. Sure, you have first order functions, but you in a way have that in pretty much all programming languages (including C!).

But most functions in Common Lisp do mutate things, there is an extensive OO system and the most hideous macros like LOOP.

I certainly never felt constrained writing Common Lisp.

That said, there are pretty effective patterns for dealing with IO that allow you to stay in a mostly functional / compositional flow (dare I say monads? but that sounds way more clever than it is in practice).

As a long time embedded programmer, I don't understand this. Even 20 years ago, there is no way I really understood the machine, despite writing assembly and looking at compiler output.

10 years ago, running an arm core at 40 Mhz, I barely had the need to inspect my compiler's assembly. I still could roughly read things when I needed to (since embedded compilers tend to have bugs more regularly), but there's no way I could write assembly anymore. I had no qualms at the time using a massively inefficient library like arduino to try things out. If it works and the timing is correct, it works.

These days where I don't do embedded for work, I have no qualms writing my embedded projects in micropython. I want to build things, not micro optimize assembly.

Yes, better understanding of the stack makes you a more efficient prompt engineer. and yes I don't say this ironically, prompt engineering / vibe coding is not easy, as evidenced by the amount of people who think it's only good greenfield yeet prototypes.

A lot of my programming skills have atrophied over the last two years, and a lot of skills have become that much sharper (architecture, algorithm and design pattern knowledge, designing user facing tools and dev tools, setting up complex infrastructures, frontend design, ...) because they are what allow me to fly with LLMs.

Yet calculators don't seem to have reduced the number of people in mathematics, engineering and other mathematics heavy fields. Why would it be any different with people using AI to learn coding?